SIP協議參數詳解

1.1  SIP消息分類
SIP協議是以層協議的形式組成的，就是說它的行為是以一套相對獨立的處理階段來描述的，每個階段之間的關系不是很密切。
SIP協議將Server和User Agent之間的通訊的消息分為兩類：請求消息和響應消息。
請求消息：客戶端為了激活特定操作而發給服務器的SIP消息，包括INVITE、ACK、BYE、CANCEL、OPTION和UPDATE消息。
SIP請求的6種方法：
　        1、 邀請（INVITE）——邀請用戶加入呼叫
　　2、 確認（ACK）——確認客戶機已經接收到對INVITE的最終響應
　　3、 可選項（OPTIONS）——請求關於服務器能力的信息
　　4、 再見（BYE）——終止呼叫上的兩個用戶之間的呼叫
　　5、 取消（CANCEL）
　　6、 注冊（REGISTER）——提供地址解析的映射，讓服務器知道其它用戶的位置

響應消息：服務器向客戶反饋對應請求的處理結果的SIP消息，包括1xx、2xx、3xx、4xx、5xx、6xx響應
1.2  SIP消息結構
請求消息和響應消息都包括SIP消息頭字段和SIP消息體字段；
SIP消息頭主要用來指明本消息是有由誰發起和由誰接受，經過多少跳轉等基本信息；
SIP消息體主要用來描述本次會話具體實現方式；
1.3  消息格式
1.3.1  請求消息格式
SIP請求消息的格式，由SIP消息頭和一組參數行組成，如圖3-1所示。通過換行符區分命令行和每一條參數行。

圖1-1 SIP請求消息結構
注意：參數行的順序不是固定的。對應的參數解釋見6.3  。
消息體定義：
Call-ID：頭字段是用來將消息分組的唯一性標識
　　From：頭字段是指示請求發起方的邏輯標識，它可能是用戶的注冊地址。From頭字段包含一個URI和一個可選的顯示名稱
　　CSeq：頭字段用於標識事務並對事務進行排序。它由一個請求方法和一個序列號組成，請求方法必須與對應的請求消息類型一致
　　Max-Fowords：頭字段限定一個請求消息在到達目的地之前允許經過的最大跳數。它包含一個整數值，每經過一跳，這個值就被減一。如果在請求消息到達目的地之前該值變為零，那么請求將被拒絕並返回一個483（跳數過多）錯誤響應消息。
　　Via：頭字段定義SIP事務的下層（傳輸層）傳輸協議，並標識響應消息將要被發送的位置。只有當到達下一跳所用的傳輸協議被選定后，才能在請求消息中加入Via頭字段值。
　　expires：參數指出了該值中包含的URI地址的有效期。這個參數的值是以秒為單位計算的。如果沒有提供該參數，那么URI地址的有效期由Expires頭字段值來確定。

SIP請求消息實例：
INVITE sip:0109@127.0.0.1:5060;User=phone SIP/2.0
Call-ID:01E04633512400000@127.0.0.1
Via:SIP/2.0/UDP 127.0.0.1:5061
From:<sip:010203@127.0.0.1:5061;User=phone>;tag=29005358336B534F610A000
To:<sip:0109@127.0.0.1:5060;User=phone>
Contact: sip:010203@127.0.0.1:5061
CSeq:1 INVITE
Max-Forwards:70
Content-Type: application/SDP
Content-Length:168

v=0
o=UserA 2890844526 2890844526 IN IP4 here.com
s=Session SDP
c=IN IP4 192.0.0.1
t=0 0
m=audio 49172 RTP/AVP 0 8
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=sendonly

INVITE消息是其中一種SIP請求消息。
第一行由消息頭和對端SIP實體的URI（通用資源標識）以及SIP版本號碼組成。
SIP URI是電話URI，附在IP地址上，表示對端和端點收發SIP消息的端口的域。
“From”、“To”和“Contact”這三個SIP消息頭屬於電話URI。
當背靠背用戶代理發出呼叫時，“From”消息頭中的URI填寫在“Via”消息頭里。
請求消息類型填寫在CSeq消息頭里，並且當該SIP端點發送一個請求，號碼就相應遞增。
SIP協議版本為SIP/2.0。其中SDP被加入到INVITE消息內容里，在消息頭里的Content-Length說明了SDP內容的長度。

INVITE請求消息詳解：
INVITE sip:[e-mail] SIP/2.0
　　<＝ 請求方法、請求地址（Request－URI）、SIP版本號（目前都是SIP/2.0）
　　<＝請求地址一般就是被叫方地址，跟MSN中好友eMail地址類似
　　Via: SIP/2.0/UDP lab.high-voltage.org:5060;branch=z9hG4bKfw19b
　　<＝SIP版本號（2.0）、傳輸類型（UDP）、呼叫地址、
　　<＝branch是一隨機碼，它被看作傳輸標識
　　<＝Via字段中地址是消息發送方或代理轉發方設備地址，一般由主機地址和端口號組成
　　<＝傳輸類型可以為UDP、TCP、TLS、SCTP
Max-Forwards: 70
　　<＝最大跳躍數，就是經過SIP服務器的跳躍次數，主要是防止循環跳躍
　　<＝每經過代理服務器，該整數減一
　　To: G. Marconi <sip:[e-mail]>
　　From: Nikola Tesla <sip:[e-mail]>;tag=76341
　　<＝表示請求消息的發送方和目標方
　　<＝如果里面有用戶名標簽，地址要求用尖括號包起來
　　<＝對於INVITE消息，可以在From字段中包含tag，它也是個隨機碼
　　Call-ID:[e-mail]
　　<＝呼叫ID是由本地設備生成的，全局唯一值。每次呼叫該值唯一不變
　　<＝對於用戶代理發送INVITE消息，本地將生成From tag和Call-ID全局唯一碼，被叫方代理則生成To tag全局唯一碼。這三個隨機碼做為整個對話中對話標識（dialog indentifier）在通話雙方使用。
　　CSeq: 1 INVITE
　　<＝CSeq，又叫命令隊列（Command Seqence），每發送一個新的請求，該數自動加1
　　* 以上幾個字段是所有SIP消息體所必須的，其它頭字段有些是可選的，有些在特定請求也是必須
　　Subject: About That Power Outage...
　　Contact: <sip:[e-mail]>
　　<＝Contact是INVITE消息所必須的，它用來路由到被叫設備地址，也稱為用戶代理（UA）
　　Content-Type: application/sdp
　　Content-Length: 158
　　<＝最后兩位附屬字段說明消息體類型以及字段長度
　　v=0   <＝SDP版本號，目前都是0
　　o=Tesla 28908445262890844526 INIP4 lab.high-voltage.org   <＝主叫源地址，類型等
　　s=Phone Call
1.3.2  響應消息格式
SIP響應消息的格式，由SIP響應消息頭和一組參數行組成，如圖3-2所示。通過換行符區分命令行和每一行參數。

SIP響應消息結構
注意：參數行的順序不是固定的。對應的參數解釋見6.3  。
SIP響應消息實例：
SIP/2.0 200 OK
Content-Type:application/SDP
Via:SIP/2.0/UDP 127.0.0.1:5061
Call-ID:01EF351F8140000000000@127.0.0.1
CSeq:1 INVITE
From:<sip:010203@127.0.0.1:5061;User=phone>;tag=29005358336B534F610A000
To:<sip:0109@127.0.0.1:5060;User=phone>;tag=5358336B534F2900CD1B0000
Contact:<sip:0109@127.0.0.1:55061>
Content-Length:156

v=0
o=HuaweiSoftX3000 1073741824 1073741824 IN IP4 127.0.0.1
s=Sip Call
c=IN IP4 110.111.112.113
t=0 0
m=audio 5060 RTP/AVP 0
a=rtpmap:0 PCMU/8000

200 OK消息是SIP響應消息的一種。
第一行由SIP版本號和200響應消息組成。
SIP URI是電話URI，附在IP地址上，表示對端和端點收發SIP消息的端口的域。
“From”、“To”和“Contact”這三個SIP消息頭屬於電話URI。
當背靠背用戶代理發出呼叫時，“From”消息頭中的URI填寫在“Via”消息頭里。
請求消息類型填寫在CSeq消息頭里，並且當該SIP端點發送一個請求，號碼就相應遞增。
SIP協議版本為SIP/2.0。把SDP加入到INVITE消息內容里，在消息頭里說明內容的長度。

第二章 SIP協議主要響應碼
2.1          響應碼分類
SIP響應消息用於對請求消息進行響應，指示呼叫的成功或失敗狀態。不同類的響應消息由狀態碼來區分，狀態碼包含三位整數，狀態碼的第一位用於定義響應類型，另外兩位用於進一步對響應進行更加詳細的說明。響應消息的分類如下所示。
1）1XX：臨時響應，表示請求消息正在被處理。
2）2XX：成功響應，表示請求已被成功接收，完全理解並被接受。
3）3XX：重定向響應，表示需采取進一步以完成該請求。
4）4XX：客戶機錯誤，表示請求消息中包含語法錯誤信息或服務器無法完成客戶機請求。
5）5XX：服務器錯誤，表示服務器無法完成合法請求。
6）6XX：全局故障，表示任何服務器無法完成該請求。
上述消息中，臨時響應用於指示呼叫正在進行，其余最終響應用於結束請求消息。
2.2          1xx類消息（臨時響應）
1xx消息表示服務器或代理正在進行處理，還未得到確定的響應。客戶應該繼續等待服務器的響應。當服務器預測在200毫秒之內不能得到最終響應時，它應該發送一個1xx響應。服務器可以發送多個1xx響應。下面是常見的1xx類消息列表。
表1-1 常見的1xx類消息列表
100        試呼（Trying）正在進行與呼叫有關的操作（例如：訪問數據庫），但被叫用戶還沒有定位。
180        被叫振鈴（Ringing）被叫用戶代理已經得到被叫的位置，正在提醒被叫用戶。該響應也可以再發起一個本地回鈴
181        呼叫前轉（Call Is Being Forwarded）代理服務器可以用該狀態碼表示當前呼叫正被轉移到其它目的地。（呼叫正在轉發）
182        呼叫排隊（Queued）被叫暫時不可訪問，當前呼叫被排隊而不是被拒絕。當服務器有效時，可以繼續響應該呼叫。 該響應的"reason phrase"可以進一步給出排隊呼叫的信息，例如：“隊列中有5個呼叫，期望等待時間為15分鍾”。服務器可以發出多個182 響應來更新當前排隊呼叫的信息。
183        會話進度（session progress）應答用於提示建立對話的進度信息。Reason-Phrase（表達原因的句子）、頭域或者消息體可以用於提示呼叫進度的更新消息的信息。
2.3          2xx類消息（成功響應）
2xx消息表示請求已經被接收、處理並被成功接受；
200 ：OK－－－請求成功。
2.4  3xx類消息（重定向響應）
3xx消息表示響應給出有關用戶新位置或其它可選服務的信息。下面表4-3是常見的3xx類消息列表。
表1-2 常見的3xx類消息列表
300        多個選擇（Multiple Choice）請求中的地址被解析為多個位置，用戶可以將請求重定向到一個合適的地址。該響應應該包含可供用戶或用戶代理選擇的位置和資源列表，並且在Contact頭域中，列出可供選擇的地址。（網絡協議不兼容:會話描述中的一個或多個網絡協議不可用。）
301        永久離開（Moved Permanently）在請求中Request-URI所指的地址找不到用戶，客戶應該嘗試Contact頭域給出的新地址。主叫收到該響應后應該更新所有的本地目錄，地址簿，用戶位置緩存並將以后的請求重定向到新的地址。（網絡地址格式不兼容:會話描述中的一個或多個地址格式不可用。）
302        暫時離開（Moved Temporarily）客戶應該用Contact頭域給出的新地址嘗試呼叫。響應中Expire頭域指出該次重定向的有效期，如果沒有給出有效期，那么重定向只對當前呼叫有效。（傳送協議不兼容:會話描述中的一個或多個傳送協議不可用。）
303        帶寬單位不兼容:會話描述中的一個或多個帶寬度量單位不被理解。
304        媒體類型不可用:對話描述中的一個或多個媒體類型不可用。
305        使用代理（Use Proxy）客戶所請求的資源必須通過Contact頭域中給出的代理來訪問。Contact頭域給出代理的URI。該響應只能由用戶代理服務器發出。（媒體格式不兼容:對話描述中的一個或多個媒體格式不可用。）
306        媒體特征不被理解:對話描述中的一個或多個媒體特征不被支持。
307        對話描述參數不被理解:除上述幾種參數之外的參數不被理解。
330        組播不可用:用戶站點不支持組播。
331        單播不可用:用戶站點不支持單播通信(通常是由於防火牆的存在)
370        帶寬不足:對話描述中定義的或者媒體定義的帶寬超出可用帶寬。
380        使用其它服務（Alternate Service）呼叫不成功，但是可選其它的服務（如：電子郵件，語音信箱）。該響應的消息體給出可選服務的描述。
399        混合告警:該告警表示用戶存在的任意一種錯誤，收到該告警的系統不可以采取任何自動的動作
2.5  4xx類消息(客戶機錯誤)
4xx消息表示請求消息中包含語法錯誤或者SIP服務器不能完成對該請求消息的處理。下面表4-4是常見的4xx類消息列表。
表1-3 常見的4xx類消息列表
400        無效請求（Bad Request）請求語法有誤，不能被服務器理解。
401        未授權（Unauthorized）請求需要用戶認證。
402        要求付費（Payment Required）該響應為將來使用保留。
403        禁止（Forbidden）服務器理解請求，但拒絕完成。客戶不應該再次發請求。
404        未找到用戶（Not Found）請求中Request-RUL給出的地址上沒有要呼叫的用戶。當Request-RUL給出的地址與服務器管理的域不匹配時，服務器也發送該響應。
405        方法不允許（Method Not Allowed）請求行中指定的方法不被允許。該響應必須包含Allow頭域，列出服務器支持的方法。
406        不可接受（Not Acceptable）根據請求中的Accpe頭域，由請求給出的資源產生的響應實體里面的內容字符不可接受。
407        需要代理認證（Proxy Authentication Required）該響應與401（未授權）類似，但它指示用戶必須首先向代理認證自己。
408        請求超時（Request Timeout）服務器不能在請求的Expire頭域指定的時間內產生響應。客戶可以過一段時間重發請求。
409        沖突（Conflict）客戶的請求與資源的當前狀態沖突，不能完成請求。當REGISTER請求的action參數與現存的注冊沖突時返回該響應。
410        無可用資源（Gone）服務器上沒有所請求的資源，也不知道進一步聯系的地址。這種情況被認為是永久的。如果服務器不能確定該情況是否是永久的，它應該發送404（被叫未找到）響應。
411        需要消息體長度（Length Required）服務器拒絕接受沒有包含Content-Length頭域的請求。客戶何以在加入一個表示消息體長度的Cotent-Length頭域后重發請求。
413        請求實體過長（Request Entity Too Large）服務器拒絕處理過長的消息實體。如果這種情況是暫時的，服務器應該在響應中包含Retry-After頭域指示客戶何時重發請求。
414        Request-URI過長（Request-URI Too Long）服務器不能解析過長的Request-URI。
415        媒體類型不支持（Unsupported Media Type）服務器不支持請求消息體的格式。服務器應該在響應中用Accept，Accept-Encoding 和Accept-Language頭域列出它支持的格式。
416        不支持的URI方案（unsupported url scheme）服務器由於不支持Request-URI中的URI方案而終止處理這個請求。
420        錯誤的擴展（Bad Extension）服務器不理解請求中Require頭域指定的協議擴展。
421        需要擴展支持（extension required）UAS需要特定的擴展來處理這個請求，但是這個擴展並沒有在請求的Supported頭域中列出。具有這個應答碼的應答必須包含一個Require頭域列出所需要的擴展。
UAS不應當使用這個應答除非它真的不能給客戶端提供有效的服務。相反，如果在Support頭域中沒有列出需要的擴展，服務器應當根據基准的SIP兼容的方法和客戶端支持的擴展來進行處理。
423        間隔太短（interval too brief）服務器因為在請求中設置的資源刷新時間（或者有效時間）過短而拒絕請求。這個應答可以用於注冊服務器來拒絕那些Contact頭域有效期過短的注冊請求。
480        暫時不可訪問（Temporarily Unavailable）被叫的終端系統已經成功連接，但用戶暫時不可訪問（例如：用戶未登錄，或登錄為免打擾）。服務器可以在Retry-After頭域中另外指定一個訪問時間。
481        呼叫支路/事務不存在（Call leg/Transaction Does Not Exist）在兩種情況下服務器返回該響應：服務器收到一個BYE請求但找不到匹配的呼叫支路；或是收到一個CANCEL請求但找不到匹配的事務；或是收到與原來TAG標志不一樣的INVITE請求。（對於無匹配的ACK請求，服務器直接將它丟棄，不響應）。
482        檢測到循環呼叫（Loop Detected）請求消息的Via頭域中包含接收服務器自身的地址。
483        跳數過多（Too Many Hop）請求的Via頭域包含的條目數（跳數）超過Max-Forwards頭域指定的值。
484        地址不全（Address Incomplete）請求的To或Request-RUL所指的地址不全。
485        地址不明確（Ambiguous）請求中提供的被叫地址不明確。該響應可以在Contact頭域中列出不明確的地址。
486        被叫忙（Busy Here）被叫的終端系統已經成功連接，但用戶暫時不願意或不能夠接收更多的呼叫。服務器可以在響應的Retry-After頭域中另外指定一個訪問時間。客戶也可能通過其它方式訪問，如：語音郵箱，因此該響應並不終止一個查詢。如果我們知道沒有其他終端系統能夠接聽這個呼叫，那么應當返回一個狀態碼600（Busy Everywhere）。
487        請求被拒絕（Request Cancelled）原來的請求消息被一個CANCEL請求所取消。
488        此處請求不接受（not acceptable here）這個應答和606（Not Acceptable）有相同的含義，但是只是應用於Request-URI所指出的特定資源不能接受，在其他地方請求可能可以接受。 包含了媒體兼容性描述的消息體可以出現在應答中，並且根據INVITE請求中的Accept頭域進行規格化（如果沒有Accept頭域，那么就是application/sdp）。這個應答就像給OPTIONS請求的200(OK)應答的消息體一樣。
491        未決請求（request pending）在同一個對話中，UAS接收到的請求有一個依賴的請求正在處理。
493        無法解密（undecipherable）不可辨識，UAS接收到了一個請求，包含了一個加密的MIME,並且不知道或者沒有提供合適的解密密鑰。這個應答可以包含單個包體，這個包體包含了合適的公鑰，這個公鑰用於給這個UAS通訊中加密包體使用的。
2.6  5xx類消息（服務器錯誤）
5xx消息表示SIP服務器故障不能完成對正確消息的處理。下面表4-5是常見的5xx類消息列表。
表1-4 常見的5xx類消息列表
500        服務器內部錯誤（Server Internal Error）服務器出現異常情況，不能處理請求。
501        功能未實現（Not Implemented 不可執行）服務器不支持完成請求所必需的功能。
502        網關錯誤（Bad Gateway）作為網關或代理的服務器在處理請求時從其它服務器接收到一個無效響應。
503        服務不可用（Sevice Unavailable）由於臨時超載或正在維護，服務器當前不能處理請求。
504        網關超時（Gateway Timeout / service Time-out 服務器超時）作為網關的服務器在處理呼叫的過程中沒有及時收到其它服務器（例如：定位服務器）的響應。
505        版本不支持（Version Not Supported）服務器不能或拒絕支持請求消息所用的版本。
513        消息過大（message too large）
2.7  6xx類消息（全局錯誤）
6xx消息表示請求不能在任何SIP服務器上實現。下面表4-6是常見的5xx類消息列表。
表1-5 常見的5xx類消息列表
600         全忙（Busy Everywhere）被叫的終端系統已經成功連接，但用戶正忙，不願夠接受當前呼叫。服務器可以在響應的Retry-After頭域中另外指定一個訪問時間。該響應僅用於客戶不能通過其它方式（如：語音郵箱）訪問的情況。如果用戶可通過其它方式訪問，則應返回486（Busy Here）響應。
603        拒絕（Decline）被叫的終端系統已經成功連接，但用戶明確不願接受當前呼叫。服務器可以在響應的Retry-After頭域中另外指定一個訪問時間。
604         被叫不存在（Does Not Exist Anywhere）請求的To頭域指定的用戶不存在。
606        不可接受（Not Acceptable）用戶代理已經成功連接，但某些會話描述如媒體類型、帶寬或地址風格不能接受。該響應表示用戶希望建立通信，但不能充分支持請求所描述的會話。