接前面的章節。

　　12.2 Requests within a Dialog

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

　　此請求的構成需要以下Request-URI和Route頭域值：

　　METHOD sip:proxy1

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

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

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

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

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

　　其他請求構成方式在Section 8.1.1中有更多介紹。

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

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

　　繼續更新中。