【轉】SIP 中的Dialog，call，session 和 transaction

若是你對Sip協議中Call, Dialog, Transaction和Message之間的關係感受到迷惑,那麼,那麼我能夠告訴你,你並不孤單,由於大多數初學者對於這些名詞之間的關係都會感到疑惑.

 

M essages(消息) 消息是在服務器和客戶端之間交換的獨立文本, 有兩種類型的消息,分別是請求(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請求。