如果你對Sip協議中Call, Dialog, Transaction和Message之間的關系感覺到迷惑,那么,那么我可以告訴你,你并不孤單,因為大多數初學者對于這些名詞之間的關系都會感到疑惑.
Messages(消息)?消息是在服務器和客戶端之間交換的獨立文本, 有兩種類型的消息,分別是請求(Requests)和響應(Responses).

Transaction(事務)? 事務發生于客戶端和服務器端之間,包含從客戶端發出請求給服務器,到服務器響應給客戶端的最終消息(non-1xx message)之間的所有消息. 如果請求是一個"Invite"消息,并且最終的響應是一個non-2xx消息,那么該事務包含一個"Ack"響應消息.如果服務器的響應是一個2xx消息,那么,隨后的ACK是一個單獨的事務.?
A sip transaction consists of a single request and any responses to that request, which includes zero or more provisional responses and one or more final responses.The branch parameter value in the VIA header is used to identify the transaction created by that request

Dialog(對話)對話是兩個UAs(user agent) 之間持續一段時間的端到端(peer-to-peer)的SIP 關系. 一個對話由一個Call-ID, 一個local tag 和 一個remote tag來標識.對話過去也叫做 "call leg".dialog的建立是收到UAS的響應（To tag）時開始建立的。收到180響應時建立dialog叫做早期對話（early dialog）,收到2XX的應答開始才是真正的dialog建立。 A dialog represents a peer-to-peer SIP relationship between two user agents that persists for some time, as a call-leg.It is identified at each UA with a dialog ID, which consists of a Call-ID, From tag and To tag. We can call a dialog is established when three values are all generated
Session(會話) session 是媒體交換之后才建立的。具體而言就是通過offer/answer方式交換sdp的媒體。 session的建立可以使INVITE-200 也可以是200-ACK。這要看媒體的交換發生的時間。 具體來說，INVITE 中的消息體用sdp語言來描述自己可處理的媒體類型，200OK中 帶回UAS端可處理的媒體類型。這個時候媒體交換就算是完成了。也就是session建立起來了。?
In the SDP specification, a multimedia session is a set of multimedia senders and receivers and the data streams flowing from senders to receivers. ?A session is defined by the SDP user name, session id, network type, address type, and address elements in the origin field.
A session can have multiple RTP sessions corresponding to the UDP ports define in the line of the SDP.

Call(呼叫)?：一個呼叫是由一個會議中被同一個發起者邀請加入的所有成員組成的。一個 SIP 呼叫用全局唯一呼叫標識（CALL_ID）來識別。因此，如果一個用戶被不同的人邀請參加同一個多點會議，每個邀請都有一個唯一的呼叫。
注: Dialog和Session都翻譯成了會話,但兩者顯然不同.
下面的示意圖清晰的顯示了它們之間的關系 (RINGING 是 1xx 響應,? OK是 2xx 響應)?

caller呼叫callee的號碼來建立一系列的對話(Dialogs),這些對話組成了一個呼叫(Call).

1.對話和事務處于信令層，而會話處于媒體傳輸層。SIP使用SDP來通知傳輸層（RTP）來創建、增加、移除和修改會話。
2.一般來說，在會議應用中SIP可以通過請求來讓另一方加入已有會話中。在這種情況下，新的對話會被創建。
3.對話是end-point對end-point的關系，即真實的通信雙方，
??而transaction 是hop by hop的關系，即路由過程中交互的雙方。

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

呼叫（call）：?呼叫是一個非正式的術語，用來表示一個多媒體會話，用Call-ID來標識；不論兩方通話還是在多方通話中，在每個UA中是使用同一個Call-ID；

事務(transaction)：?請求（UAC）+最終響應（相鄰的UAS），SIP基于事務。所謂相鄰就是說transaction存在于相鄰的SIP實體，而不是存在于兩個UA之間。CSeq標識。一個事務中包含一個請求消息、0個或多個臨時響應消息、1個或多個最終響應消息（2xx~6xx）。SIP是事務性的協議。事務的區分通過Via字段棧頂的Branch的值來確定，這是由于對于請求消息每經過一個有事務狀態的Proxy的時候，該Proxy需要為這個事務創建一個服務器端事務和一個客戶端事務，并且將自己的URI添加到Via的棧頂，并生成一個Global ID做為Branch的值，以此值來表示一個與之相對應的事務。SIP在事務層面定義了狀態機和定時器來實現重傳。

?

下圖是一個回復200 OK的成功的INVITE事務：是不是INVITE事務區別在于?UAC需要為每個INVITE最終請求（2xx～6xx）生成ACK響應，而其他的請求消息（INFO,OPTION,etc）則不必如此。因為INVITE的地位比較重要， 所以需要這樣一個三次握手的機制來保證會話的雙方都能夠確保事務的完整性，這一點和TCP連接建立的三次握手比較像。

?

?

注意在上圖這兩個UA中，每一個代理服務器都將自己的地址加入返回的ACK的Via頭域中，而非成功的transaction則不會加入，見RFC 3261 (p.24)。CSeq頭域的值必須與INVITE相同，并且CSeq的方法必須是ACK。中間響應消息 1xx 的使用則是為了節省網絡開銷設計的，一旦 UC 收到任何一個中間響應消息，則 UC 必須停止消息重發定時器，不再從發這個請求消息，反之則直到收到最終響應消息或重發定時器超時。一旦客戶端UAC的事務在Calling狀態收到任何中間響應消息1xx，事務則自動切換到Processing狀態，停止請求消息的重發。并且需要將中間響應消息傳送給TU事務用戶。在呼叫業務中，TU以及上層應用可以根據中間響應消息在用戶界面上提示用戶。一旦事務切換到Processing狀態，任何其他中間響應消息也都要傳送給TU。

?

而非INVITE事務則如下：

當UAC發出非INVITE請求時，它就會在事務管理子層上開啟定時器F（TCP）或者是E（UDP），確保超時的時候進行重傳。這適用于除了 ACK請求外的其他非INVITE請求。每次超時重傳時E的時間都被翻倍，直到最大的4秒。而F超時時，UAC就會認為是Timeout，這個事務將被刪除。

?

對話(dialog/leg）：?代表著兩個SIP UA之間持續一段時間的端到端的聯系（如：一段通話）。也就說僅僅存在于端到端的信令關系。當一個UAS發出對于INVITE（或者REFER）的非失敗最終響應<=>200OK（BYE），則Dialog建立，同時這也是session的開始。UA和SIP代理服務器之間不會有對話。在SIP中呼叫中包含一個或多個Dialog（這僅僅存在于多方通話中）。Dialog終結于任意一端發出 BYE。Early Dialog可以通過UAC發出的CANCEL進行終結，更確切的說，所有早期對話在接收到非2XX最終響應時就被終結了。 Call-ID-value、To、From進行標識。Forking時體現明顯。

在這個Forking的例子中，這個用戶注冊了三個設備，在用戶被呼叫時，INVITE的Contact頭域就被轉換為三個INVITE發往三個設備。后邊的q指的是優先級，q越小，優先級越高。其中的SIP注冊服務器相當于一個Forking代理，盡管這個實體接收到兩個ACK，但是除了這些ACK外，它與主叫方的信令交互都是屬于一個transaction的，而與被叫方則分別建立了Transaction。另外，被叫方收到的兩個ACK由分別建立了Transaction。注意Device3返回了488這樣的非成功響應，SIP注冊服務器（Forking代理服務器）沒有將該響應發回主叫方，這是SIP代理一個重要的特征，SIP代理還能自行發出Request:CANCEL消息。

?

?

?

UAS對話層接收到一個新的對話請求INVITE消息后，在建立會話的響應消息2xx中，將請求消息里面的所有Route-Record字段拷貝到2xx消息中，并且UAS的對話層必須添加一個Contact字段使得對話中后續的響應（INVITE在2xx響應的情況下也包括ACK消息）、請求消息可以直接和本UA聯系。當UAC收到UAS的INVITE的2xx響應消息后，如果2xx中不包含任何Route-Record字段的，則UAC可以選擇直接發送ACK到Contact中地址&端口。

?

會話(session)：?多方用戶的媒體關系，在對話的控制下建立。

?

下圖是Early dialog、Session、Dialog、Transaction等的在一個UA-UA的呼叫中的體現：

?

?

在這個例子中，通過INVITE事務而成功建立起來的dialog必須有一個ACK進行回應，這是第二個transaction的開始，盡管ACK并沒有回復，但是由于新的 branch-value被填入，所以這個ACK代表了一個新的Transaction的開始。注意，此時?transaction number (CSeq)?并沒有根據INVITE而增加--也就是說若收到的最終響應不是2XX（是3XX--6XX），則該transaction中包含ACK，若最終響應是2XX，則ACK屬于一個新的transaction(此處存疑，國外有資料將其視為一個新的transaction，但是RFC3261中的意思卻是ACK不屬于INVITE Transaction，也不創建新的Transaction，但會重新計算Transaction參數--branchID)。早期對話是UAS以一個1XX響應作為回應時建立的。這樣做的好處是在UAC可能在早期對話中發出諸如UPDATE這樣的SIP請求。

總結

以上是生活随笔為你收集整理的SIP 中的Dialog，call，session 和 transaction .的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。