筆者在前面的章節(jié)中已經(jīng)針對(duì)一些基礎(chǔ)概念做了比較全面的分析和詳解,通過(guò)對(duì)這些必要的基礎(chǔ)概念的分享,讀者可以對(duì)SIP的基礎(chǔ)骨干有了一個(gè)清晰的認(rèn)識(shí)。萬(wàn)里長(zhǎng)征第一步。學(xué)習(xí)任何知識(shí),都需要我們從基礎(chǔ)輪廓開始,慢慢接觸細(xì)節(jié)知識(shí)。我們?cè)谝郧暗膶W(xué)習(xí)中可以獲知,SIP協(xié)議實(shí)際上是基于HTTP協(xié)議發(fā)展而來(lái)的(SIP協(xié)議不是HTTP協(xié)議的擴(kuò)展),因此,它的基本操作流程也同樣符合HTTP協(xié)議的基本原理。進(jìn)一步來(lái)說(shuō),其基本的處理流程就是一個(gè)請(qǐng)求和響應(yīng)的流程。如果讀者需要進(jìn)一步了解其SIP流程和基本的概念,可以查閱:
SIP協(xié)議及新IP企業(yè)通信網(wǎng)絡(luò)技術(shù)概論-核心SIP技術(shù)介紹-2
SIP協(xié)議及新IP企業(yè)通信網(wǎng)絡(luò)技術(shù)概論-核心SIP技術(shù)介紹-2
我們按照以上圖例根據(jù)不同的呼叫業(yè)務(wù)可以進(jìn)一步解讀出SIP消息中關(guān)于請(qǐng)求和協(xié)議的更多的技術(shù)細(xì)節(jié),最基礎(chǔ)的兩個(gè)大類就是請(qǐng)求methods和響應(yīng)碼,請(qǐng)求methods可以支持不同的請(qǐng)求,響應(yīng)碼也根據(jù)對(duì)端狀態(tài)支持了非常不同的響應(yīng)碼。在請(qǐng)求和響應(yīng)交互中,通過(guò)不斷變換的SIP頭進(jìn)行進(jìn)一步的協(xié)商來(lái)完成呼叫流程。所以,我們?cè)诒菊鹿?jié)的討論中,我們將對(duì)SIP消息核心知識(shí)進(jìn)行全面討論,主要包括通常使用的請(qǐng)求methods(13或者14種methods),響應(yīng)碼(1xx-6xx)和SIP頭。在具體實(shí)戰(zhàn)的操作過(guò)程中,技術(shù)人員同樣需要通過(guò)雙方的交互信息來(lái)對(duì)流程做相應(yīng)的處理,也需要這些交互消息來(lái)排查問(wèn)題。
注意,我們這里所說(shuō)的SIP消息和SIP規(guī)范中的message有著非常明顯的不同。此消息和彼消息是完全不同的內(nèi)涵。一般來(lái)說(shuō),SIP消息就是請(qǐng)求和響應(yīng)的消息,客戶端對(duì)服務(wù)器端發(fā)送請(qǐng)求消息,服務(wù)器端對(duì)客戶端返回響應(yīng)消息。我們這里通常所說(shuō)的SIP消息是指一般的SIP請(qǐng)求和響應(yīng)消息,而在SIP規(guī)范中的message是SIP規(guī)范的一種擴(kuò)展的method,它允許SIP終端之間發(fā)送即時(shí)消息(instant message)。
1、SIP請(qǐng)求methods和響應(yīng)碼
請(qǐng)求和響應(yīng)是SIP響應(yīng)的兩大核心要素。這兩大要素結(jié)合SIP頭決定著呼叫的最終結(jié)果。在具體的SIP請(qǐng)求中,根據(jù)RFC3261,SIP請(qǐng)求根據(jù)SIP呼叫請(qǐng)求的不同環(huán)境,SIP請(qǐng)求又細(xì)分6種不同的methods,這6種methods是RFC3261規(guī)范所規(guī)定的methods,另外還有8種常用的擴(kuò)展SIP methds,這8種methods不是RFC3261的規(guī)范規(guī)定的methods,它們是通過(guò)SIP的擴(kuò)展協(xié)議獲得的支持。所以,我們這里總共介紹14種不同的常用的SIP請(qǐng)求方式。
在SIP請(qǐng)求methods中,我們經(jīng)常遇到的SIP請(qǐng)求methods包括:
- REGISTER:用來(lái)注冊(cè)一個(gè)用戶代理,通過(guò)臨時(shí)綁定一個(gè)用戶代理的URI到AOR地址,這樣服務(wù)器端能夠獲悉其用戶代理的位置。簡(jiǎn)單來(lái)說(shuō),它負(fù)責(zé)注冊(cè)contact消息。
- INVITE,通過(guò)邀請(qǐng)一個(gè)用戶參與到會(huì)話來(lái)發(fā)起一個(gè)呼叫。另外,INVITE也可以修改會(huì)話。
- ACK,一個(gè)acknowledgement或者消息確認(rèn)是作為一個(gè)對(duì)200 OK響應(yīng)或其他響應(yīng)的一個(gè)確認(rèn)響應(yīng)。這些響應(yīng)是初始INVITE請(qǐng)求的結(jié)果,此時(shí)應(yīng)該會(huì)產(chǎn)生會(huì)話,ACK僅對(duì)INVITE負(fù)責(zé)或者(re-INVITEs)。
- CANCEL用來(lái)取消待處理的請(qǐng)求。
- BYE用來(lái)指示結(jié)束呼叫或者會(huì)話。
- OPTIONS 負(fù)責(zé)查詢服務(wù)器端的媒體支持能力。
- INFO,負(fù)責(zé)mid-session的SIP信令消息之間的通信,它是一個(gè)RFC3261的擴(kuò)展協(xié)議,具體規(guī)范參考RFC2976。具體使用示例包括PSTN網(wǎng)關(guān)的PSTN信令消息,傳輸會(huì)話中中需要傳輸?shù)腄TMF,計(jì)費(fèi)賬號(hào)余額,無(wú)線移動(dòng)端的無(wú)線信號(hào)狀態(tài),會(huì)話之間傳輸圖片或者其他非媒體的數(shù)據(jù)。
- PRACK,其全稱是Provisional ACK,從字面意思可以看出,它本身是一個(gè)臨時(shí)的ACK。因?yàn)樗且粋(gè)臨時(shí)的響應(yīng),所以它僅用來(lái)對(duì)1xx臨時(shí)響應(yīng)做出響應(yīng)。在某些情況下,如果初始INVITE請(qǐng)求沒(méi)有攜帶SDP消息體的話,在1xx臨時(shí)響應(yīng)后,PRACK可以包含相關(guān)的SDP消息體。另外需要注意,為了驗(yàn)證其可靠性,每個(gè)臨時(shí)響應(yīng)(例如從UAS來(lái)的183響應(yīng))都給定一個(gè)序列號(hào),通過(guò)響應(yīng)消息中的RSeg頭來(lái)傳輸,從UAC來(lái)的PRACK的消息中包含一個(gè)RAck頭,表示一個(gè)針對(duì)臨時(shí)響應(yīng)的序列號(hào)的確認(rèn)。它也是通過(guò)一個(gè)RFC3261規(guī)范的擴(kuò)展協(xié)議來(lái)支持,具體規(guī)范參考RFC3262。
- Refer 用來(lái)轉(zhuǎn)接呼叫,也可以用來(lái)聯(lián)系外部資源。Refer method是SIP規(guī)范的擴(kuò)展協(xié)議。具體關(guān)于定義Refer method規(guī)范,讀者可以查閱RFC3515。
- SUBSCRIBE用來(lái)在稍晚時(shí)間請(qǐng)求一個(gè)事件提醒或一系列事件。常見的示例是用來(lái)訂閱一個(gè)請(qǐng)求提示(Notification),當(dāng)某人的IM在線狀態(tài)發(fā)生改變(離線,在線,忙狀態(tài)等)以后,對(duì)其發(fā)送提示事件。關(guān)于訂閱的擴(kuò)展協(xié)議,讀者可以查閱RFC3265。
- NOTIFY用來(lái)對(duì)已訂閱的事件發(fā)送notify提示消息,它也可以通過(guò)SIP服務(wù)器端對(duì)SIP客戶端發(fā)送客戶端事件提示,例如語(yǔ)音郵箱留言等。讀者也可以按照RFC3265的規(guī)范進(jìn)一步了解notify提示method。
- Update用來(lái)支持客戶端更新會(huì)話協(xié)商中的一些參數(shù),例如媒體流的參數(shù)以及編碼等。注意,update不會(huì)影響dialog的狀態(tài)。關(guān)于更多update method,讀者可以參考SIP的擴(kuò)展協(xié)議RFC3311。
- Publish發(fā)布和注冊(cè)一樣,它也允許用戶創(chuàng)建,修改和移除狀態(tài),不同的是它負(fù)責(zé)發(fā)布事件狀態(tài),用戶可以根據(jù)事件本身狀態(tài)來(lái)提示訂閱用戶。具體規(guī)范查閱RFC3903。
- Message method是SIP的擴(kuò)展協(xié)議,用來(lái)傳輸請(qǐng)求的消息體中的即時(shí)消息。通過(guò)SIP 初始會(huì)話技術(shù),結(jié)合在線狀態(tài)和即時(shí)消息構(gòu)成了當(dāng)前最強(qiáng)大的即時(shí)通訊系統(tǒng)。目前,即時(shí)消息或者IM使用已經(jīng)非常普及,包括我們的QQ等。但是,SIP的強(qiáng)大之處在于提供了在線狀態(tài)應(yīng)用,對(duì)基于會(huì)話初始應(yīng)用機(jī)制提供支持,但是對(duì)即時(shí)消息支持不是SIP的優(yōu)勢(shì)。因此,讀者可以看到,在SIP應(yīng)用中即時(shí)消息的使用仍然不是市場(chǎng)主流。關(guān)于SIP 消息的規(guī)范讀者可以查閱RFC3428,關(guān)于在線狀態(tài)和即時(shí)消息規(guī)范讀者可以查閱RFC2778和RFC2779。
關(guān)于以上SIP method的其他深入討論,讀者可以查閱參考鏈接,或者閱讀筆者的歷史文檔。因?yàn)槠,這里不再介紹。一些比較常見的method,例如, 100rel/PRACK,讀者可以查閱歷史文檔:
SIP拓展協(xié)議RFC3262概述和100rel/PRACK詳解
2、SIP請(qǐng)求和響應(yīng)中的header
前面我們介紹了SIP的methods和它的一些控制協(xié)議支持的methods。在各種methods中,INVITE是我們最常用的method。在這些methods中需要通過(guò)各種header來(lái)進(jìn)行通信協(xié)商。在本章節(jié)我們重點(diǎn)介紹一下method中的header和其響應(yīng)中的header。因?yàn)槠,我們這里僅介紹INVITE method和其響應(yīng),讀者可以查閱SIP規(guī)范和其具體擴(kuò)展協(xié)議深入了解更多的用途說(shuō)明。以下是根據(jù)RFC3261官方介紹的一個(gè)基本的示例
INVITE的SIP頭 |
INVITE 200 OK響應(yīng)的SIP頭 |
||
頭名稱 | 說(shuō)明 | 頭名稱 | 說(shuō)明 |
Request-Line | 表示請(qǐng)求類型,INVITE中包含目的地UA的SIP URI和其SIP以及版本 2.0 | Status-Line | 表示正在使用SIP 2.0, 返回 200 OK。 |
Via | 表示傳輸層協(xié)議使用,使用UDP,包含響應(yīng)返回的IP地址和端口,branch ID(不可修改的)確認(rèn)事務(wù)的唯一性,和RPORT | Via | 服務(wù)器端插入的頭,支持回環(huán)檢測(cè),允許 200 OK找到返回到終端的路徑。返回此請(qǐng)求的響應(yīng),要注意,如果有route的話,應(yīng)該發(fā)route;如果沒(méi)有route,則發(fā)Contact返回響應(yīng);如果沒(méi)有Contact,則發(fā)From返回。 |
From | 顯示呼叫方信息,呼叫方SIP URI,事實(shí)上是呼叫方的caller ID | From | 初始呼叫方信息和其SIP URI |
To | 顯示被呼叫方的信息 | To | 初始被呼叫方UA |
Call-ID | 是一個(gè)全局ID,針對(duì)具體某個(gè)dialog,在此dialog中,所有請(qǐng)求和響應(yīng)事務(wù)都具有此同一Call-ID。 | Call-ID | 是一個(gè)全局ID,針對(duì)具體某個(gè)dialog。 |
CSeq | 用來(lái)確認(rèn)事務(wù)和其事務(wù)的處理順序。在呼叫中,每個(gè)呼叫對(duì)象會(huì)維護(hù)自己的CSeq,并且會(huì)根據(jù)成功狀態(tài)會(huì)依次遞增。 | CSeq | 用來(lái)確認(rèn)事務(wù)和其事務(wù)的處理順序。在呼叫中,每個(gè)呼叫對(duì)象會(huì)維護(hù)自己的CSeq,并且會(huì)根據(jù)成功狀態(tài)會(huì)依次遞增。 |
Contact | 顯示一個(gè)SIP URI,表示在后續(xù)請(qǐng)求中可以使用這個(gè)SIP URI聯(lián)系到此agent。 | Contact | 顯示一個(gè)SIP URI,表示在后續(xù)請(qǐng)求中可以使用這個(gè)SIP URI聯(lián)系到此agent。 |
Allow | 此agent支持的一個(gè)methods 列表 | Allow | 此agent支持的一個(gè)methods 列表 |
Max-Forwards | 用來(lái)限定代理或者網(wǎng)關(guān)前轉(zhuǎn)到下一跳的最大數(shù)量,每經(jīng)過(guò)一個(gè)代理或者網(wǎng)關(guān)此值會(huì)遞減1,默認(rèn)推薦值為70. | ||
Content-Type | 描述在此應(yīng)用中的內(nèi)容,應(yīng)用,SDP類型。 | Content-Type | 描述在此應(yīng)用中的內(nèi)容,應(yīng)用,SDP類型。 |
Proxy-Authorization |
用來(lái)支持對(duì)proxy代理的安全信息。 | ||
Supported | 描述此agent支持的擴(kuò)展,例如100rel,timer,replaces 等等。 | ||
User-Agent | 表示具體的代理信息 | User-Agent | 表示具體的代理信息 |
Content-Length | 表示SDP消息體的長(zhǎng)度,以byte為單位。 | Content-Length | 表示SDP消息體的長(zhǎng)度,以byte為單位。 |
Record-Route | 代理插入的頭域值,強(qiáng)制在此dialog中的后續(xù)請(qǐng)求通過(guò)此代理路由 |
響應(yīng)中的Via,F(xiàn)rom,To,Call-ID,CSeq是完全從請(qǐng)求中拷貝過(guò)來(lái)的。
To,F(xiàn)rom不會(huì)在請(qǐng)求和響應(yīng)的交互中發(fā)生替換。
不同的服務(wù)提供商或者SIP終端發(fā)送的頭信息順序可能不同,這是符合規(guī)范的,例如CSeq和Call-ID的位置順序發(fā)生變化。
Supported/Reqiure的功能支持,客戶端通知服務(wù)器端需要支持的列表,服務(wù)器端返回require的功能列表。
關(guān)于以上問(wèn)題的詳解,讀者可以進(jìn)一步了解:
除了以上的關(guān)于SIP頭的一些介紹以外,在一些對(duì)帶寬非常敏感的網(wǎng)絡(luò)環(huán)境中,為了節(jié)省帶寬,SIP協(xié)議可以支持SIP頭的壓縮格式或者縮寫,具體的格式如下:
縮寫 | Header | 定義協(xié)議 | 原始含義 |
---|---|---|---|
a | Accept-Contact | draft-ietf-sip-callerprefs | -- |
b | Referred-By | -refer- | "by" |
c | Content-Type | RFC 3261 | |
e | Content-Encoding | RFC 3261 | |
f | From | RFC 3261 | |
i | Call-ID | RFC 3261 | |
k | Supported | RFC 3261 | "know" |
l | Content-Length | RFC 3261 | |
m | Contact | RFC 3261 | "moved" |
o | Event | -event- | "occurance" |
r | Refer-To | -refer- | |
s | Subject | RFC 3261 | |
t | To | RFC 3261 | |
u | Allow-Events | -events- | "understand" |
v | Via | RFC 3261 |
有時(shí),在某些比較特殊的部署環(huán)境中,我們可能會(huì)看到一些帶X前綴的拓展的頭參數(shù)值。例如,有時(shí)需要對(duì)每個(gè)終端的聲音增益進(jìn)行調(diào)整時(shí),可以通過(guò)其擴(kuò)展到X頭來(lái)調(diào)整。如果需要對(duì)話單用戶進(jìn)行定義時(shí),也可以通過(guò)X擴(kuò)展頭來(lái)定義。這樣操作帶來(lái)的問(wèn)題是,一些系統(tǒng)如果對(duì)X頭不支持的話,服務(wù)器端可能直接丟棄,并且拒絕解析這些字段,導(dǎo)致很多兼容性問(wèn)題。因此,RFC6684規(guī)范對(duì)X擴(kuò)展進(jìn)行了說(shuō)明,X頭將不再進(jìn)行支持。
除了X頭以外,P header是一個(gè)仍然普遍使用的頭域值。它一方面使用在計(jì)費(fèi)消息中,另外一方面主要使用在網(wǎng)絡(luò)穿越的環(huán)境設(shè)置中包括SBC用戶場(chǎng)景。例如,計(jì)費(fèi)使用的P-Charge-Info,在可信網(wǎng)絡(luò)環(huán)境中P-Asserted-Identity傳輸用戶認(rèn)證信息。特別在FCC強(qiáng)制要求美國(guó)運(yùn)營(yíng)商部署STIR/SHAKEN規(guī)范時(shí),P-Asserted-Identity是必要的頭之一。關(guān)于STIR/SHAKEN,讀者可以查閱:
關(guān)于SIP P擴(kuò)展頭的完整規(guī)范說(shuō)明,讀者可以查閱RFC3325和RFC3455規(guī)范。
4、總結(jié)
在本文章中,筆者主要介紹了SIP協(xié)議中的14個(gè)核心的methods,另外根據(jù)一般用戶場(chǎng)景,我們也介紹了請(qǐng)求和響應(yīng)中的SIP頭主要的頭域值介紹。筆者通過(guò)最常見的INVITE請(qǐng)求method結(jié)合其響應(yīng)碼為大家簡(jiǎn)單介紹了其頭值的具體內(nèi)容。另外,筆者也討論了頭值的狀態(tài)變化,在這些header頭值中,一些關(guān)鍵的頭值在交互中不會(huì)發(fā)生變化或者修改,這些問(wèn)題筆者也要注意。
除了RFC3261中一些標(biāo)準(zhǔn)的SIP頭以外,SIP支持其他的擴(kuò)展頭,包括X頭和P頭值擴(kuò)展,這些頭值可以進(jìn)一步完善具體或者特殊用戶場(chǎng)景多其他參數(shù)的支持。
雖然筆者盡量在討論中涵蓋SIP規(guī)范的關(guān)于SIP methods和響應(yīng)碼以及SIP擴(kuò)展頭的全部?jī)?nèi)容,但是,因?yàn)槠藓蛯?shí)際應(yīng)用示例非常繁多,用戶只能通過(guò)最常見的INVITE和響應(yīng)來(lái)為讀者解讀SIP核心概念,希望起到一個(gè)拋磚引玉的作用,其他的methods可以根據(jù)讀者提供的RFC規(guī)范線索做深入了解。
參考資料:
- https://datatracker.ietf.org/doc/html/rfc2976
- https://www.ietf.org/rfc/rfc3262.txt
- https://datatracker.ietf.org/doc/html/rfc3311
- https://www.ietf.org/rfc/rfc3428.txt
- https://datatracker.ietf.org/doc/html/rfc2976
- https://datatracker.ietf.org/doc/html/rfc3265
- https://www.ietf.org/rfc/rfc3903.txt
- https://datatracker.ietf.org/doc/html/rfc6648
- https://datatracker.ietf.org/doc/html/rfc3455