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