【正文】 用戶代理 用戶代理（ UA， User Agent）表示一個終端系統(tǒng)。 圖 一個簡單的 SIP 呼叫的例子 如圖 所示， Tesla 發(fā)起 INVITE（請求）， Marconi 接收 INVITE 請求，因此，此時 Tesla就是用戶代理客戶端 （ UAC）， Marconi 是用戶代理服務(wù)器端（ UAS）；會話建立后， Marconi發(fā)起 BYE（結(jié)束）請求， Tesla 發(fā)送對應(yīng)的響應(yīng)，因此，此時 Marconi 就是用戶代理客戶端（ UAC）， Tesla 是用戶代理服務(wù)器端（ UAS）。 代理服務(wù)器是一個邏輯 SIP 實體。 無狀態(tài)代理服務(wù)器只是作為一個簡單的消息 轉(zhuǎn)發(fā)實體，它根據(jù)請求消息來做轉(zhuǎn)發(fā)目的地和路由決策，然后把請求轉(zhuǎn)發(fā)到下游的某個實體；對于響應(yīng)消息，則只簡單地將其往上游方向轉(zhuǎn)發(fā)。 重定向服務(wù)器 重定向服務(wù)器（ Redirect Server）是一個 SIP 實體，它接受用戶代理或代理服務(wù)器的請求，對這些請求發(fā)送 3xx（ 重定向響應(yīng)）響應(yīng)，響應(yīng)消息中包含了請求的目標用戶的可能地址的列表，以便用戶代理或代理服務(wù)器重新發(fā)送請求消息。位置服務(wù)器存儲并且向用戶返回可能的位置信息。一些定位服務(wù)器實用輕量目錄訪問協(xié)議（ LDAP， Lightweight Directory Access Protocol） [RFC1777]和 SIP 服務(wù)器進行通信。 SIP 響應(yīng) 響應(yīng)消息的起始行為狀態(tài)行（ StatusLine），狀態(tài)行由協(xié)議版本、狀態(tài)碼和狀態(tài)原因短語組成，各個部分之間用一個空格字符進行分隔。 1xx：臨時響應(yīng)，表示請求消息正在被處理； 2xx：成功響應(yīng)，表示請求已被成功接收，完全理解并被接受； 3xx：重定向響應(yīng)，表示需采取進一步以完成該請求； 4xx：客戶機錯誤，表示請求消息中包含語法錯誤信息或服務(wù)器無法完成客戶機請求； 5xx：服務(wù)器錯誤，表示服務(wù)器無法完成合法請求； 6xx：全局故障 ，表示任何服務(wù)器無法完成該請求； 二、 SIP Message Message Struct SIP 消息分為請求和響應(yīng)兩類，其中請求消息是 UAC（客戶端）發(fā)往 UAS（服務(wù)器端），響應(yīng)消息是 UAS 發(fā)往 UAC。 一個完整的 SIP 請求消息如下所示： INVITE sip: SIP/ Via: SIP/:5060。請求行的格式如下所示，由方法名、請求 URI和協(xié)議版本組成，各部分之間均用一個空格字符進行分隔。 Responses 狀態(tài)行 響應(yīng)消息的起始行為狀態(tài)行（ StatusLine），狀態(tài)行由協(xié)議版本、狀態(tài)碼和狀態(tài)原因短語組成，各個部分之間用一個空格字符進行分隔。一些頭字段可以在請求 或應(yīng)答兩種消息中使用，而其他的頭字段只能單獨特定地用于請求（或應(yīng)答）。 branch=z9hG4bK776a 只出現(xiàn)在請求中 Accept 接受 Accept: application/sdp Acceptencoding 接受的編碼 AcceptEncoding: text/plain Acceptlanguage 接受的語言 AcceptLanguage: en Authorization 授權(quán) Authorization: Digestusername=Cust1,realm=, nonce=9c8e88df84f1cec4341ae6e5a359, opaque=,uri=sip:, response=e56131d19580cd833064787ecc Callinfo 呼叫信息 CallInfo: m/。本字段還可以包含下列參 數(shù)： maddr、 ttl、 received和 brance。當某客戶端沿著某條鏈路發(fā)送請求消息的時候，使用該字段可以有效地防止鏈路中出錯或者發(fā)生回環(huán)。例如： MaxForwards: 70 To： 該頭字段指定了請求的邏輯 接收者。它的縮寫形式為 t。 而 RequestURI 含有在信令路徑中下一跳的地址，并因此在路途中被每 個代理改變。 From 的縮寫形式是 f。 CallID 區(qū)分大小寫并逐字節(jié)比較。如果兩個 Cseq的數(shù)字序列以及方法都相等那么這 兩個 Cseq 就是等價的。 Contact 頭字段的值中還可以包含一個顯示名稱、含有 URI 參數(shù)的 URI 和頭字段參數(shù)。 解析顯示名稱、 URI、 URI 參數(shù)以及頭字段參數(shù)的規(guī)則同樣適用于 To 和 From 頭字段。舉例如下： Route: Bodies（ SDP） 請求和 應(yīng)答都可能含有消息體，它被一個空行和消息頭分開。兩個 SIP 實體可以通過攜帶 SDP 消息體來使它們之間的多媒體會話達成一致。一個 SDP 描述含有會話級信息和媒體級信息。例如，它能作為一個編碼器給音頻流編碼或者是給視頻流發(fā)送端口號。 媒體級部分以 m 行開始。 如果 a=的某屬性值不理解 ,則予以丟失 整個協(xié)議區(qū)分大小寫 =兩側(cè)不允許有空格 會話級的描述就是媒體級描述的缺省值 所有均格式為 = 一個例子 v=0 //SDP 版本 o=Tesla 2890844526 2890844526 IN IP4 //會話發(fā)起者是 Tesla，地址是 s=Phone Call //會話名字是 Phone Call c=IN IP4 //接收地址是 t=0 0 //在什么時候是激活的 m=audio 49170 RTP/AVP 0 //音頻流，端口是 49170，音頻流在 udp 上通過 RTP 傳輸， //值 0意味音頻是在單個信道中使用 PCM u—law進行編碼和以 8kHz的頻率采樣 a=rtpmap:0 PCMU/8000 三、 SIP 協(xié)議行為 會話過程 UAC 通過向服務(wù)器發(fā)送 INVITE 消息開始會話發(fā)起過程，該請求可能通過網(wǎng)絡(luò)中間的服務(wù)器設(shè)備的轉(zhuǎn)發(fā)，最終到 UAS。 在會話建立成功以后，任何一端 UA 可以通過發(fā)送 reINVITE 請求來調(diào)整會話，修改會話的某些屬性，例如：增加或刪除媒體流，改變媒體發(fā)送或接受地址等。如上圖所示。 UAC 的 INVITE 消息的產(chǎn)生 RFC3261 規(guī)定，由 UAC產(chǎn)生的一個有效的 SIP 請求消息必須至少包含下列頭字端： Via、MaxForwards、 To、 From、 CSeq 和 CallID 頭字端，不僅是在 INVITE，它們在所有的 SIP請求消息中都是必選的。具體地，請求行（ RequestLine）中的 RequestURI 設(shè)置為與 To 頭字段一值（除 REGISTER 以外的 所有請求的初始 RequestURI 都應(yīng)該與 To 頭字段一值）；Via 頭字段設(shè)置為響應(yīng)消息將要被發(fā)送的地址，其 brance 參數(shù)值在時間和空間上也必 須唯一（即不同的 method 有不 同 brance 值，兩種情況除外， CANCEL 與對應(yīng)的 INVITE 的 brance值相同，對非 2xx 的最終響應(yīng)的 ACK與對應(yīng)的 INVITE 的 brance 值相同）； MaxForwards一般設(shè)置為 70； To 頭字段包含了請求消息的邏輯接收者，可以是 SIP 或 SIPS URI，其 tag值標識了對話中的對端，在 INVITE 消息中不應(yīng)該出現(xiàn)； From 頭字段設(shè)置為消息發(fā)送者的地址，其 tag 值標識了消息的發(fā)起 者； Cseq 設(shè)置為不同于其他事務(wù)的整數(shù)序列和 INVITE方法； CallID 設(shè)置為全局時間上和空間上都唯一的 ID 號； Contact 頭字段設(shè)置為 UAC（請求發(fā)送者）的地址。 SDP 請求和響應(yīng)這個協(xié)商過程，不能并行，只能當一次交互完成之后才能發(fā)起新的協(xié)商過程。 如果 INVITE 請求中攜帶了 SDP 請求，則在 200OK消息中攜帶 SDP 響應(yīng)。branch=z9hG4bKfw19b MaxForwards: 70 To: G. Marconi From: Nikola Tesla CallID: CSeq: 1 INVITE Subject: About That Power Outage... Contact: ContentType: application/sdp ContentLength: 158 v=0 o=Tesla 2890844526 2890844526 IN IP4 s=Phone Call c=IN IP4 t=0 0 m=audio 49170 RTP/AVP 0 a=rtpmap:0 PCMU/8000 Ringing MESSAGE SIP/ 180 Ringing Via: SIP/:5060。received= To: G. Marconi From: Nikola Tesla CallID: CSeq: 1 INVITE Contact: ContentType: application/sdp ContentLength: 155 v=0 o=Marconi 2890844528 2890844528 IN IP4 s=Phone Call c=IN IP4 t=0 0 m=audio 60000 RTP/AVP 0 a=rtpmap:0 PCMU/8000 MESSAGE ACK sip: SIP/ Via: SIP/:5060。 reINVITE 請求的產(chǎn)生 reINVITE 過程所采用的 SDP 協(xié)商過程與建立會話的 INVITE 過程相同：會話中的任意一方可以通過在 reINVITE 消息中攜帶一個新的 SDP 請求來更新會話內(nèi)容；或者， reINVITE 可以不攜帶 SDP，讓其對方在 200OK 中攜帶 SDP。 對于 reINVITE 事務(wù)的 ACK和 2XX 響應(yīng)的生成，與初始 INVITE 過程相同。 如果 UAS 返回了 2XX 響應(yīng)，但是沒有受到 ACK，它必須發(fā)送 BYE 來結(jié)束本次對話。received= To: G. Marconi From: Nikola Tesla CallID: CSeq: 2 INVITE Contact: ContentType: application/sdp ContentLength: 155 v=0 o=Marconi 2890844528 2890844528 IN IP4 s=Phone Call c=IN IP4 t=0 0 m= video 61000 RTP/AVP 32 a= rtpmap:32 MPV/90000 MESSAGE ACK sip: SIP/ Via: SIP/:5060。 UAC 行為 會話中的任意一方可以通過發(fā)送 BYE 請求來結(jié)束已經(jīng)建立的會話。 UAS 行為 UAS 收到 BYE 請求之 后，需要查詢匹配的會話。對于正在處理的請求消息，UAS 返回 487 響應(yīng)。received= To: Nikola Tesla From: G. Marconi CallID: CSeq: 1 BYE ContentLength: 0 請求的取消 圖 請求的取消 CANCEL用于取消客戶端發(fā)送的前一個請求。 CANCEL 請求最適合于 INVITE 請求，因為它會需要很長的時間來產(chǎn)生響應(yīng)。因此，由于 CANCEL“跳 ”到每一個有狀態(tài)的代理服務(wù)器時都會被應(yīng)答，所以它是個 “逐跳 ”（ hopbyhop）的請求。這些頭字段值的一致性使得 CANCEL 請求能與被取消的請求相匹配。 一 旦 CANCEL 請求構(gòu)造完畢，客戶端應(yīng)當檢查是否已收到了被取消請求（下文將統(tǒng)稱為原請求）的任何響應(yīng)消息（臨時的或最終的）。CANCEL 請求的目的地址、端口和傳輸方式必須與原請求的相同。無狀態(tài)代理服務(wù)器將簡單地轉(zhuǎn)發(fā)；有狀態(tài)代理服務(wù)器會會其做出應(yīng)答并產(chǎn)生自己的 CANCEL 請求； UAS 將對 CANCEL 請求做出應(yīng)答。 然后， UAS 對 CANCEL 請求進行事務(wù)匹配。如果原請求是一個 INVITE，UAS 應(yīng)立即對它發(fā)送 487（請求終止）響應(yīng)。 CANCEL 的響應(yīng)消息被傳遞給一個服務(wù)器 端事務(wù)以便發(fā) 送。received= To: G. Marconi From: Nikola Tesla CallID: CSeq: 5 INVITE Contact: ContentLength: 0 3． CANCEL MESSAGE CANCEL sip: SIP/ Via: SIP/:5060。branch=z9hG4Bk5619b