接歷史文檔。
12.3 Termination of a Dialog
Dialog的結束流程獨立于此method的使用環(huán)境，如果一個(gè)外部dialog請求生成了一個(gè)非2xx最終響應，任何通過(guò)以前請求響應創(chuàng )建的歷史dialogs將會(huì )結束。結束確認dialogs的機制是依賴(lài)于具體的method。在此規范中，BYE method 將會(huì )結束和它關(guān)聯(lián)的會(huì )話(huà)和此dialog。具體細節參考請Section 15。
13 Initiating a Session
13.1 Overview
當一個(gè)用戶(hù)代理客戶(hù)端期望發(fā)起一個(gè)會(huì )話(huà)（例如，語(yǔ)音，視頻或者游戲）時(shí)，它會(huì )發(fā)送一個(gè)INVITE請求。這個(gè)INVITE請求將會(huì )詢(xún)問(wèn)服務(wù)器端來(lái)創(chuàng )建一個(gè)會(huì )話(huà)。這個(gè)請求可能會(huì )通過(guò)代理進(jìn)行轉發(fā)，最后抵達一個(gè)或者多個(gè)UAS端，此UAS端是最終接受此請求的服務(wù)器端。這些UAS端將需要定期查詢(xún)此用戶(hù)端，確認是否接受此邀請請求。
一定時(shí)間后，那些UAS端返回一個(gè)2xx響應表示能夠接受此邀請（表示此會(huì )話(huà)已被創(chuàng )建）。如果此邀請沒(méi)有被接受的話(huà)，UAS將會(huì )對用戶(hù)代理發(fā)送一個(gè)3xx，4xx，5xx或者6xx響應，狀態(tài)錯誤碼發(fā)送取決于被拒絕的理由。在UAS發(fā)送最終響應之前，UAS也能發(fā)送一個(gè)臨時(shí)響應（1xx），通知對方正在聯(lián)系被呼叫方來(lái)處理UAC流程。
在收到一個(gè)或多個(gè)臨時(shí)響應后，UAC將會(huì )獲得一個(gè)或者多個(gè)2xx響應，或者一個(gè)非-2xx最終響應。因為需要耗費一定的時(shí)間等待接收邀請的最終響應消息，邀請（Invite ）事務(wù)的可靠性機制處理方式和其他的請求（OPTIONS）有所不同。一旦UAC收到一個(gè)最終響應，此UAC需要對每個(gè)它收到的最終響應發(fā)送一個(gè)ACK確認消息。發(fā)送ACK的流程處理取決于響應的類(lèi)型。對于介于300和699之間的最終響應，ACK的處理是在事務(wù)層來(lái)完成對，并且需要遵從一系列規則（具體規則參考Section 17）。對于2xx響應，ACK是由UAC core來(lái)生成。
由INVITE收到的2xx響應創(chuàng )建一個(gè)會(huì )話(huà)，同時(shí)它也在UA之間創(chuàng )建了一個(gè)dialog。一個(gè)UA是發(fā)起此INVITE請求的，一個(gè)UA是生成2xx響應的。因此，當從不同遠端UA收到多個(gè)2xx響應（因為INVITE分叉），每個(gè)2xx創(chuàng )建一個(gè)不同的dialog。所有這些dialog都屬于同一呼叫。
此章節提供了一個(gè)使用INVITE創(chuàng )建會(huì )話(huà)的細節。支持INVITE的UA也必須支持ACK，CANCEL和BYE。
13.2 UAC Processing
13.2.1 Creating the Initial INVITE
因為初始請求表示一個(gè)dialog外部請求，它的構建過(guò)程遵從Section 8.1.1 章節的處理流程。對于此INVITE具體情況來(lái)說(shuō)，需要增加額外的步驟。
- 任何Allow頭域（Section 20.5）應該出現在此INVITE中。它表示在一個(gè)dialog生命周期內，UA發(fā)送此INVITE時(shí)援引了何種methods。例如，在dialog中，UA接收INFO請求的能力應該[34]包含一個(gè)Allow頭，此Allow頭列出此NFO method。
- 任何Supported頭域（Section 20.37）應該出現在此INVITE中。它枚舉了UAC可以理解的所有拓展。
- 任何Accept頭域（Section 20.1）也可能出現在INVITE中。它表示UA可以接受何種 Content-Types，接受Content-Types的方向不僅是UA接收響應側，而且還在由此INVITE創(chuàng )建的dialog中的后續請求側。Accept頭域非常有用，它原來(lái)表示各種會(huì )話(huà)描述格式的支持能力。
UAC可以增加一個(gè)Expires頭域（Section 20.19）來(lái)限制請求的有效性。如果在Expires頭中的時(shí)間設置超時(shí)，沒(méi)有收到此INVITE的最后應答響應，UAC core應該對此INVITE生成一個(gè)CANCEL請求，參考Section 9章節。
UAC也可以發(fā)現其他有用的頭域添加到頭域中，其中包括 Subject（Section 20.36）， Organization（Section 20.25）和User-Agent（Section 20.41）頭域。所有這些頭域包含和INVITE相關(guān)的信息。
UAC可以對此INVITE添加一個(gè)消息體。Section 8.1.1.10 具體描述了如何構建頭域--Content-Type，和需要說(shuō)明消息體內容。
針對包含會(huì )話(huà)描述的消息體，規范有一些特別的規則，消息體相應的Content-Disposition是一個(gè)“會(huì )話(huà)”。SIP使用offer/answer模式支持UA發(fā)送一個(gè)會(huì )話(huà)描述，稱(chēng)之為offer端，offer端包含了此會(huì )話(huà)的推薦的描述。此offer端指示它所期望的通信方式（語(yǔ)音，視頻或者游戲）， 通信方式所支持的參數（例如編碼類(lèi)型）和從應答方接收媒體的地址。對端UA則攜帶另外一個(gè)會(huì )話(huà)描述做出響應，稱(chēng)之為answer，它指示何種媒體方式可以被接受，所支持媒體方式的參數和從提供方接收媒體的地址。offer/answer交互是在dialog的context中進(jìn)行，因此，如果SIP INVITE導致了多個(gè)dialog的話(huà)，每個(gè)dialog就是一個(gè)獨立的offer/answer交互。當發(fā)生offer和answer時(shí)，此offer/answer描述規定了限制條件（例如，當一個(gè)offer正在處理時(shí)，用戶(hù)不能創(chuàng )建一個(gè)新的offer）。通過(guò)這樣的處理方式，在SIP消息中的offer和answer雙方能夠體現這樣的限制措施。在此規范中，offers和answers僅能夠出現在INVITE請求，響應和ACK中。這里，關(guān)于offers和answers模式有進(jìn)一步的限定。對于初始INVITE事務(wù)，規則包括：
- 初始offer必須是在一個(gè)INVITE中，或沒(méi)有在INVITE中，如果沒(méi)有的話(huà)，初始offer是在從UAS返回UAC的第一個(gè)可靠的非失敗消息中。在此規范中是2xx 最終響應。
- 如果初始響應在INVITE中，應答必須是在從UAS返回到UAC的一個(gè)可靠非失敗消息中，UAC和那個(gè)INVITE有關(guān)聯(lián)關(guān)系。對于此規范來(lái)說(shuō)，僅表示為此INVITE的2xx最終響應。同樣相似的應答也可以被置于任何臨時(shí)響應中，這些臨時(shí)響應是發(fā)送到前面應答方的響應。UAC必須把它收到的第一個(gè)會(huì )話(huà)描述視為此應答方，并且必須忽略任何在針對此初始INVITE的后續響應中的會(huì )話(huà)描述。
- 如果此初始offer是在從UAS返回到UAC的第一個(gè)可靠非失敗消息中，從 answer必須是在此消息的確認消息中（在此規范中，ACK支持的2xx響應中）。
- 對第一個(gè)offer來(lái)說(shuō)，如果UAC已發(fā)送或已收到一個(gè)應答后，此UAC可能在請求中生成后續的offer，這些請求的處理是基于那個(gè)method指定的規則來(lái)進(jìn)行的，但是，此處理方式僅支持兩種狀態(tài)，第一種是如果UAC已經(jīng)收到了前面offer的應答后的狀態(tài)，和如果UAC沒(méi)有獲得應答，它不發(fā)送任何offer的狀態(tài)。
- 對初始offer來(lái)說(shuō)，一旦UAS發(fā)出或收到了應答，此UAS一定不能在對初始請求的響應中生成后續的offer。這表示，直到此初始事務(wù)完成前，基于此規范的UAS永遠不能單獨生成后續的offer。
具體來(lái)說(shuō)，以上規則中，對此規范單獨指定了兩個(gè)交互來(lái)支持UA的法則-offer是在INVITE中， answer 是在2xx響應中（也可能在1xx響應中）或者offer是在2xx響應中，answer是在A(yíng)CK中。所有支持INVITE的代理必須支持它們的這兩個(gè)交互。
所有用戶(hù)代理必須支持Session Description Protocol （SDP） （RFC 2327 [1]）作為一種手段來(lái)描述會(huì )話(huà)，它們構建offer和answer的方式必須遵從此流程，這個(gè)流程在定義在[13]章節。
此offer-answer模式的限制所描述的僅應用在消息體中，此消息體的Content-Disposition頭值是一個(gè)“會(huì )話(huà)”。因此，INVITE和ACK中包含一個(gè)消息體是可能的，例如，一個(gè)INVITE中包含一張圖片（Content-Disposition: render），并且從ACK是一個(gè)會(huì )話(huà)描述（Content-Disposition: session）。
如果此Content-Disposition 頭域值丟失的話(huà)，Content-Type application/sdp的消息體會(huì )說(shuō)明這個(gè)disposition "session"，其他的內容類(lèi)型會(huì )說(shuō)明"render"值。
一旦INVITE創(chuàng )建后，UAC遵從一個(gè)處理機制，這個(gè)機制在第八章的dialog外部發(fā)送請求的章節中定義。這樣會(huì )導致一個(gè)客戶(hù)端的事務(wù)構建，此事務(wù)構建最終發(fā)送此請求并且對UAC返回響應。
