接前面的章節(jié)。

　　12.2 Requests within a Dialog

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

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

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

　　注意，一個ACK不是一個目的地刷新請求。

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

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

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

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

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

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

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

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

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

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

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

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

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

　　METHOD sip:proxy1

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

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

　�。ó�(dāng)此請求抵達一個松散-路由時（loose-router），它將被返回到此Request-URI中）。

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

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

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

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

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

　　繼續(xù)更新中。