【正文】 。有狀態(tài)代理服務(wù)器可能選擇 “分叉 ”（ fork）轉(zhuǎn)發(fā)一個(gè)請(qǐng)求，即將一個(gè)請(qǐng)求向多 個(gè)目的地路由。 代理服務(wù)器是一個(gè)邏輯 SIP 實(shí)體。branch= z9hG4Bk5619b 。如果最終響應(yīng)沒有發(fā)送，那么 UAS 的處理 方式將取決于原請(qǐng)求的類型。 服務(wù)器如何處理 CANCEL 請(qǐng)求依賴于服務(wù)器的類型。 CANCEL 請(qǐng)求不能包含任何 Require 或 ProxyRequire 頭字段。 有狀態(tài)的代理服務(wù)器應(yīng)當(dāng)應(yīng) 答收到的 CANCEL，而不是簡單地轉(zhuǎn)發(fā)從下游實(shí)體收到的響應(yīng)。branch=z9hG4bK392kf 。 UAC 發(fā)送 BYE 請(qǐng)求之后即認(rèn)為本次會(huì)話已經(jīng)結(jié)束了。branch= z9hG4Bk412kg 。 reINVITE 過程不能重疊，如果已經(jīng)有一個(gè) reINVITE 事務(wù)正在執(zhí)行，就不能發(fā)起新的reINVITE 事務(wù)。branch=z9hG4bKfw19b 。 UAS 構(gòu)建響應(yīng)消息時(shí)，按照如下方法：構(gòu)建狀態(tài)行（ StatusLine）；復(fù)制收到請(qǐng)求的 Via 頭字段，做部分修改；復(fù)制 To 頭字段，添加 tag 值（即 UAS 的標(biāo)識(shí)）；完全復(fù)制 From 頭字段， Cseq 頭字段和 CallID 頭字段； Contact 頭字段修改為 UAS 的地址。 各頭字段的說明見上文。 圖 最基本的兩個(gè) UA 之間的 SIP 呼叫 最基本、最簡單的 SIP 呼叫是兩個(gè) UA 之間之間的點(diǎn)對(duì)點(diǎn)呼叫。 如果 SDP 語法分析器不能識(shí)別某一類型 (Type),則整個(gè)描述丟失 。媒體級(jí)信息作用于特殊的媒體流。 SDP 介紹 會(huì)話描述協(xié)議（ SDP， Session Description Protocol）規(guī)定了對(duì)描述會(huì)話的必要信息怎樣進(jìn)行編碼。 當(dāng) Contact 頭字段包含一個(gè)顯示名稱的時(shí)候，帶有所有的 URI 參數(shù)的 URI 應(yīng)放于三角括號(hào)中，否則， URI 后面的參數(shù)都認(rèn)為是頭字段參數(shù)而不是 URI 參數(shù)。該頭字段用于把某對(duì)話中 的事務(wù)進(jìn)行排序且提供了一種唯一標(biāo) 識(shí)某事務(wù)的方法（即INVITE、 ACK等 method），并能夠區(qū)分某請(qǐng)求是新的請(qǐng)求還是從發(fā)的請(qǐng)求。當(dāng)被叫發(fā)出請(qǐng)求時(shí)， From 字段中就是使用被叫的地址。 To 頭字段等價(jià)性的判定同 From 頭字段。brance=z9hG4bK87asdks7 Maxforwards： 在 RFC3261 中規(guī)定， MaxForwards（最大轉(zhuǎn)發(fā)次數(shù)）頭字段必須和任何方法一起規(guī)定向下游轉(zhuǎn)發(fā)消息的代理服務(wù)器和網(wǎng)關(guān)的個(gè)數(shù)。 tag=2443a8f7 Via 通過 Via: SIP/。 消息體 見 節(jié)。 下面分別給出請(qǐng)求消息和響應(yīng)消息的完整的例子。 除了以上方法以外，還有其他擴(kuò)展的方法，如 INFO、 NOTIFY 等等。 定位服務(wù)器 定位服務(wù)器（ Location Server）不是 SIP 實(shí)體，但是它們是任何實(shí)用 SIP 協(xié)議的體系結(jié)構(gòu)中非常重要的一部分。 按照工作模式，代理服務(wù)器分為有狀態(tài)代理服務(wù)器（ Stateful Proxy）和無狀態(tài)代理服務(wù)器（ Stateless Proxy）兩種類型（《 SIP 揭密》中分得更細(xì)，分為保留呼叫狀態(tài) PROXY，保留狀態(tài) PROXY 和無狀態(tài) PROXY）。 UAC 和 UAS 是邏輯上的兩個(gè)部分，每個(gè)終端系統(tǒng)都包含了 UAC 和 UAS 的功能。SIP 協(xié)議 SIP 協(xié)議簡單介紹： 一、 SIP 基本概念 定義 SIP（ Session Initiation Protocol，會(huì)話發(fā)起協(xié)議）是由 IETF（ Inter 工程任務(wù)組） 提出的IP 電話信令協(xié)議 , 是采用 UTF8 字符集來進(jìn)行編碼的文本協(xié)議。 圖 一個(gè)簡單的 SIP 呼叫的例子 如圖 所示， Tesla 發(fā)起 INVITE（請(qǐng)求）， Marconi 接收 INVITE 請(qǐng)求，因此，此時(shí) Tesla就是用戶代理客戶端 （ UAC）， Marconi 是用戶代理服務(wù)器端（ UAS）；會(huì)話建立后， Marconi發(fā)起 BYE（結(jié)束）請(qǐng)求， Tesla 發(fā)送對(duì)應(yīng)的響應(yīng)，因此，此時(shí) Marconi 就是用戶代理客戶端（ UAC）， Tesla 是用戶代理服務(wù)器端（ UAS）。 無狀態(tài)代理服務(wù)器只是作為一個(gè)簡單的消息 轉(zhuǎn)發(fā)實(shí)體，它根據(jù)請(qǐng)求消息來做轉(zhuǎn)發(fā)目的地和路由決策，然后把請(qǐng)求轉(zhuǎn)發(fā)到下游的某個(gè)實(shí)體；對(duì)于響應(yīng)消息，則只簡單地將其往上游方向轉(zhuǎn)發(fā)。位置服務(wù)器存儲(chǔ)并且向用戶返回可能的位置信息。 SIP 響應(yīng) 響應(yīng)消息的起始行為狀態(tài)行（ StatusLine），狀態(tài)行由協(xié)議版本、狀態(tài)碼和狀態(tài)原因短語組成，各個(gè)部分之間用一個(gè)空格字符進(jìn)行分隔。 一個(gè)完整的 SIP 請(qǐng)求消息如下所示： INVITE sip: SIP/ Via: SIP/:5060。 Responses 狀態(tài)行 響應(yīng)消息的起始行為狀態(tài)行（ StatusLine），狀態(tài)行由協(xié)議版本、狀態(tài)碼和狀態(tài)原因短語組成，各個(gè)部分之間用一個(gè)空格字符進(jìn)行分隔。 branch=z9hG4bK776a 只出現(xiàn)在請(qǐng)求中 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/。當(dāng)某客戶端沿著某條鏈路發(fā)送請(qǐng)求消息的時(shí)候，使用該字段可以有效地防止鏈路中出錯(cuò)或者發(fā)生回環(huán)。它的縮寫形式為 t。 From 的縮寫形式是 f。如果兩個(gè) Cseq的數(shù)字序列以及方法都相等那么這 兩個(gè) Cseq 就是等價(jià)的。 解析顯示名稱、 URI、 URI 參數(shù)以及頭字段參數(shù)的規(guī)則同樣適用于 To 和 From 頭字段。兩個(gè) SIP 實(shí)體可以通過攜帶 SDP 消息體來使它們之間的多媒體會(huì)話達(dá)成一致。例如，它能作為一個(gè)編碼器給音頻流編碼或者是給視頻流發(fā)送端口號(hào)。 如果 a=的某屬性值不理解 ,則予以丟失 整個(gè)協(xié)議區(qū)分大小寫 =兩側(cè)不允許有空格 會(huì)話級(jí)的描述就是媒體級(jí)描述的缺省值 所有均格式為 = 一個(gè)例子 v=0 //SDP 版本 o=Tesla 2890844526 2890844526 IN IP4 //會(huì)話發(fā)起者是 Tesla，地址是 s=Phone Call //會(huì)話名字是 Phone Call c=IN IP4 //接收地址是 t=0 0 //在什么時(shí)候是激活的 m=audio 49170 RTP/AVP 0 //音頻流，端口是 49170，音頻流在 udp 上通過 RTP 傳輸， //值 0意味音頻是在單個(gè)信道中使用 PCM u—law進(jìn)行編碼和以 8kHz的頻率采樣 a=rtpmap:0 PCMU/8000 三、 SIP 協(xié)議行為 會(huì)話過程 UAC 通過向服務(wù)器發(fā)送 INVITE 消息開始會(huì)話發(fā)起過程，該請(qǐng)求可能通過網(wǎng)絡(luò)中間的服務(wù)器設(shè)備的轉(zhuǎn)發(fā)，最終到 UAS。如上圖所示。具體地，請(qǐng)求行（ RequestLine）中的 RequestURI 設(shè)置為與 To 頭字段一值（除 REGISTER 以外的 所有請(qǐng)求的初始 RequestURI 都應(yīng)該與 To 頭字段一值）；Via 頭字段設(shè)置為響應(yīng)消息將要被發(fā)送的地址，其 brance 參數(shù)值在時(shí)間和空間上也必 須唯一（即不同的 method 有不 同 brance 值，兩種情況除外， CANCEL 與對(duì)應(yīng)的 INVITE 的 brance值相同，對(duì)非 2xx 的最終響應(yīng)的 ACK與對(duì)應(yīng)的 INVITE 的 brance 值相同）； MaxForwards一般設(shè)置為 70； To 頭字段包含了請(qǐng)求消息的邏輯接收者，可以是 SIP 或 SIPS URI，其 tag值標(biāo)識(shí)了對(duì)話中的對(duì)端，在 INVITE 消息中不應(yīng)該出現(xiàn)； From 頭字段設(shè)置為消息發(fā)送者的地址，其 tag 值標(biāo)識(shí)了消息的發(fā)起 者； Cseq 設(shè)置為不同于其他事務(wù)的整數(shù)序列和 INVITE方法； CallID 設(shè)置為全局時(shí)間上和空間上都唯一的 ID 號(hào)； Contact 頭字段設(shè)置為 UAC（請(qǐng)求發(fā)送者）的地址。 如果 INVITE 請(qǐng)求中攜帶了 SDP 請(qǐng)求，則在 200OK消息中攜帶 SDP 響應(yīng)。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。 對(duì)于 reINVITE 事務(wù)的 ACK和 2XX 響應(yīng)的生成，與初始 INVITE 過程相同。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。 UAS 行為 UAS 收到 BYE 請(qǐng)求之 后，需要查詢匹配的會(huì)話。received= To: Nikola Tesla From: G. Marconi CallID: CSeq: 1 BYE ContentLength: 0 請(qǐng)求的取消 圖 請(qǐng)求的取消 CANCEL用于取消客戶端發(fā)送的前一個(gè)請(qǐng)求。因此，由于 CANCEL“跳 ”到每一個(gè)有狀態(tài)的代理服務(wù)器時(shí)都會(huì)被應(yīng)答，所以它是個(gè) “逐跳 ”（ hopbyhop）的請(qǐng)求。 一 旦 CANCEL 請(qǐng)求構(gòu)造完畢，客戶端應(yīng)當(dāng)檢查是否已收到了被取消請(qǐng)求（下文將統(tǒng)稱為原請(qǐng)求）的任何響應(yīng)消息（臨時(shí)的或最終的）。無狀態(tài)代理服務(wù)器將簡單地轉(zhuǎn)發(fā)；有狀態(tài)代理服務(wù)器會(huì)會(huì)其做出應(yīng)答并產(chǎn)生自己的 CANCEL 請(qǐng)求； UAS 將對(duì) CANCEL 請(qǐng)求做出應(yīng)答。如果原請(qǐng)求是一個(gè) INVITE，UAS 應(yīng)立即對(duì)它發(fā)送 487（請(qǐng)求終止）響應(yīng)。received= To: G. Marconi From: Nikola Tesla CallID: CSeq: 5 INVITE Contact: ContentLength: 0 3． CANCEL MESSAGE CANCEL sip: SIP/ Via: SIP/:5060。當(dāng)一個(gè)請(qǐng)求消息到來 時(shí)，一個(gè)能作為代理服務(wù)器的 SIP 實(shí)體首先決定是否需要由自己來應(yīng)答這個(gè)請(qǐng)求，例如請(qǐng)求消息中 可能有格式錯(cuò)誤，或者在執(zhí)行代理功能之前需要先獲得客戶端的鑒權(quán)證書等，而該實(shí)體亦可用任何適當(dāng)?shù)腻e(cuò)誤碼來響應(yīng)。任何被轉(zhuǎn)發(fā)到多個(gè)地點(diǎn)的請(qǐng)求都必須在有狀態(tài)模式下處理。 有狀態(tài)代理服務(wù)器 一個(gè)工作在有狀態(tài)模式下的代理服務(wù)器就是一個(gè) SIP 事務(wù)處理引擎。當(dāng)立即回送臨時(shí)性響應(yīng)消息（如 100Trying）到服務(wù)器端事務(wù)時(shí)，代理服務(wù)器核心必須作為 UAS 進(jìn)行處理。 一個(gè)無狀態(tài)的 proxy 并沒有事務(wù)的 概念，或者用于描述有狀態(tài) proxy 行為的應(yīng)答上下文。 確認(rèn)請(qǐng)求的有效性； 168。對(duì)任何其他的 消息內(nèi)容，在消息轉(zhuǎn)發(fā)時(shí)應(yīng)忽略其語法構(gòu)造 是否正確并保持原樣。該響應(yīng)中必須包含一個(gè) Unsupported 頭字段，其中列出那些不能被理解的選項(xiàng)標(biāo)簽； 168。這也使得遵從 RFC3261 的實(shí)體能夠在通過嚴(yán)格路由的代理服務(wù)器時(shí)保留 RequestURI。地址集中的每個(gè)目的地都被表示成一個(gè) URI。這些機(jī)制的輸出結(jié)果被用于構(gòu)造目標(biāo)地址集。 如果原請(qǐng)求的 RequestURI 所指定的資源位置不在本代理服務(wù)器負(fù)