接前面的章節(jié)。

　　12.2 Requests within a Dialog

　　-旦介于兩個(gè)UA之間的dialog創(chuàng)建以后，如有必要，其中之一UA可以在dialog中發(fā)起新的事務(wù)。發(fā)送請(qǐng)求的UA將會(huì)在事務(wù)中充當(dāng)UAC的角色。接收請(qǐng)求的UA將會(huì)在事務(wù)中充當(dāng)UAS的角色。注意，在UA執(zhí)行事務(wù)期間，這些事務(wù)創(chuàng)建了不同的dialog ,它們的角色可能是不同的。

　　在dialog中，請(qǐng)求可以包含Record-Route和Contact頭值。盡官這些請(qǐng)求可能修改遠(yuǎn)端目的地URL,但是，這些請(qǐng)求不能導(dǎo)致dialog中路由組修改。

　　具體來(lái)說(shuō)-些請(qǐng)求中，不刷新目的地請(qǐng)求的這些請(qǐng)求不修改dialog的遠(yuǎn)端目的地URL ,刷新目的地請(qǐng)求的可以修改。在使用一個(gè)INVITE創(chuàng)建的dialog中，只有re-INVITE是一個(gè)被定義的目的地刷新請(qǐng)求。參考（ Section 14 ）獲得更多討論。其他拓展可以通過(guò)不同的方式在dialog中定義其他的目的地刷新請(qǐng)求。

　　注意，一個(gè)ACK不是一個(gè)目的地刷新請(qǐng)求。

　　目的地刷新請(qǐng)求僅更新dialog的遠(yuǎn)端目的地URL ,不更新從Record- Route構(gòu)建的路由組。更新后者將會(huì)引起與RFC 2543向后兼容的問(wèn)題。

　　Dialog中的請(qǐng)求是通過(guò)此狀態(tài)多種組件構(gòu)成，此狀態(tài)被存為dialog的一個(gè)部分。

　　請(qǐng)求中To頭域的URL必須設(shè)置為遠(yuǎn)端URL（從dialog狀態(tài)中獲得）。在請(qǐng)求中To頭域中的標(biāo)簽tag必須設(shè)置為dialog ID的遠(yuǎn)端標(biāo)簽tag。請(qǐng)求的From URL必須設(shè)置為dialog狀態(tài)中設(shè)置的本地URL地址。請(qǐng)求中From頭中的tag標(biāo)簽必須設(shè)置為dialog ID的本地tag標(biāo)簽。如果遠(yuǎn)端或者本地標(biāo)簽tags值為空，標(biāo)簽參數(shù)必須從各自的To或者From頭中忽略。

　　初始請(qǐng)求中的To頭和From頭使用URL方式以及在此后續(xù)請(qǐng)求中的URL使用方式是通過(guò)RFC2543的向后兼容性來(lái)完成的，RFC2543中使用URL來(lái)支持dialog的身份確認(rèn)。在本規(guī)范中，僅使用tags標(biāo)簽來(lái)確認(rèn)dialog的身份。預(yù)計(jì)，在mid-dialog中的初始To和From頭URL強(qiáng)制映射處理方式將會(huì)在此規(guī)范的后續(xù)重審中被廢棄。

　　此請(qǐng)求的Call-ID必須設(shè)置為dialog的Call-ID。在每個(gè)方向上（當(dāng)然，除了ACK和CANCEL以外，這些請(qǐng)求中的號(hào)碼等于此請(qǐng)求被確認(rèn)或者取消的號(hào)碼），一個(gè)dialog請(qǐng)求必須包含一個(gè)嚴(yán)格單調(diào)增加和持續(xù)的CSeq序列號(hào)（每次遞增一個(gè)數(shù)值）。因此，如果本地序列號(hào)不是空值，本地序列號(hào)必須遞增一，并且此值必須存儲(chǔ)在CSeq頭中。如果本地序列號(hào)為空，必須選擇一個(gè)初始的值，根據(jù)Section 8.1.1.5中的指導(dǎo)來(lái)選擇。CSeq頭中的method必須匹配請(qǐng)求中method。

　　CSeq使用32 bits長(zhǎng)度的數(shù)字串，在一個(gè)單呼叫中，一個(gè)客戶(hù)端能夠生成一個(gè)請(qǐng)求，一秒內(nèi)可能大概需要136年才需要涵蓋這樣的數(shù)字。選擇了序列號(hào)的初始值以便在同樣呼叫中的后續(xù)請(qǐng)求將不會(huì)在包含此序列號(hào)數(shù)字。非零的值允許客戶(hù)使用一個(gè)基于時(shí)間的初始序列號(hào)。例如，客戶(hù)端可以選擇最有效率的31 bits長(zhǎng)度作為初始序列號(hào)（32bits秒級(jí)為標(biāo)準(zhǔn)）。

　　UAC使用此遠(yuǎn)端目的地和路由組來(lái)創(chuàng)建請(qǐng)求中的Request-URI和Route頭域。

　　如果路由組設(shè)置為空，UAC必須把遠(yuǎn)端目的地URL置于Request-URI中。UAC一定不能給請(qǐng)求添加Route頭值。

　　如果路由組不為空，在路由組的第一個(gè)URL中包含了lr參數(shù)（Section 19.1.1）的話(huà)，UAC必須把遠(yuǎn)端目的地URL置入到Request-URI，并且必須包含一個(gè)Route頭，此Route按續(xù)包含路由組值和所有參數(shù)。

　　如果路由組不為空，并且它的第一個(gè)不包含lr參數(shù)，此UAC必須把從路由組中的第一個(gè)URL置入到Request-URI，去除任何Request-URI不支持的參數(shù)。此UAC必須添加一個(gè)Route頭，此頭值按續(xù)包含剩余的路由組值。然后，作為最后的值，此UAC必須把遠(yuǎn)端目的地URL置入到Route頭值中。

　　例如，如果遠(yuǎn)端目的地是sip:user@remoteua，并且路由組route set包含：

　　<sip:proxy1>,<sip:proxy2>,<sip:proxy3;lr>,<sip:proxy4>

　　此請(qǐng)求的構(gòu)成需要以下Request-URI和Route頭域值：

　　METHOD sip:proxy1

　　Route:  <sip:proxy2>,<sip:proxy3;lr>,<sip:proxy4>,<sip:user@remoteua>

　　如果路由組中的第一個(gè)URL不包含lr參數(shù)值，此proxy表示不能理解此規(guī)范中的路由機(jī)制，使用RFC 2543的規(guī)范來(lái)執(zhí)行，使用第一個(gè)Route頭替換這個(gè)Request-URI，第一個(gè)Route頭是當(dāng)進(jìn)行消息轉(zhuǎn)發(fā)時(shí)收到的路由頭。處理消息過(guò)程中，通過(guò)（嚴(yán)格路由）strict router時(shí)，把路由頭中結(jié)尾的Request-URI保存到那個(gè)Request-URI中。

　　（當(dāng)此請(qǐng)求抵達(dá)一個(gè)松散-路由時(shí)（loose-router），它將被返回到此Request-URI中）。

　　在一個(gè)dialog中，UAC應(yīng)該在任何目的地刷新請(qǐng)求中包含一個(gè)Contact頭，而且，除非處理過(guò)程中有一個(gè)需求需要修改它，URL應(yīng)該和此dialog中前面請(qǐng)求所使用的URL相同。如果"secure" flag為true的話(huà)，那個(gè)URL必須是一個(gè)SIPS URI格式。就像在Section 12.2.2討論的一樣，在目的地刷新請(qǐng)求中的Contact頭將會(huì)更新遠(yuǎn)端目的地URL。這樣就會(huì)支持UA提供一個(gè)新的contact地址，在此dialog生命周期內(nèi)，它的地址也會(huì)發(fā)生改變。

　　但是，請(qǐng)求不是目的地刷新請(qǐng)求的話(huà)，此請(qǐng)求不會(huì)影響此dialog中的遠(yuǎn)端目的地URL地址。

　　其他請(qǐng)求構(gòu)成方式在Section 8.1.1中有更多介紹。

　　一旦請(qǐng)求構(gòu)建完成后，服務(wù)器的地址會(huì)被處理，使用同樣的外部dialog請(qǐng)求處理方式發(fā)生此請(qǐng)求（Section 8.1.2）。

　　在Section 8.1.2中規(guī)定的處理流程中，如果沒(méi)有Route頭的話(huà)，此流程將會(huì)導(dǎo)致請(qǐng)求被發(fā)送到一個(gè)地址，這個(gè)地址標(biāo)識(shí)在topmost Route頭中或者Request-URI中。受限于某些限制，它們?cè)试S此請(qǐng)求被發(fā)送到其他可選目的地地址（例如，默認(rèn)的outbound proxy沒(méi)有出現(xiàn)在路由組中）。

　　繼續(xù)更新中。