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