《中國移動CM-IMS會話初始協(xié)議(SIP)技術規(guī)范-第二部分：SIP的消息》由會員分享，可在線閱讀，更多相關《中國移動CM-IMS會話初始協(xié)議(SIP)技術規(guī)范-第二部分：SIP的消息（89頁珍藏版）》請在裝配圖網上搜索。

1、QB-╳╳-╳╳╳-╳╳╳╳ 撰寫人：___________日 期：___________ 中國移動通信企業(yè)標準 QB-C-018.2-2011 中國移動CM-IMS會話初始協(xié)議（SIP）技術規(guī)范 第二部分：SIP的消息 CM-IMS Specifications of Session Initiation Protocol (SIP) Part 2: SIP Messages SIP Protocol 版本號：1.0.0

2、 2011-7-27實施 2011-7-27發(fā)布 中國移動通信集團公司 發(fā)布 QB-C-018.2-2011 目 錄 前 言 VI 1. 范圍 1 2. 規(guī)范性引用文件 1 3. 術語、定義與縮略語 4 4. SIP消息概述 5 4.1. SIP消息起始行 5 4.2. SIP消息頭域 6 4.3. SIP消息體 7 4.4. SIP協(xié)議中的URI 8 4.4.1. SIP URI 8 4.4.2. SIPS URI 9 4.4.3. TEL URI 9 4.4.4. SIP U

3、RI與TEL URI的轉換 9 5. SIP請求消息 9 5.1. SIP請求消息格式 9 5.2. INVITE 10 5.3. ACK 11 5.4. BYE 11 5.5. CANCEL 11 5.6. REGISTER 12 5.7. SUBSCRIBE 13 5.8. PUBLISH 13 5.9. NOTIFY 13 5.10. UPDATE 13 5.11. MESSAGE 14 5.12. PRACK 14 5.13. INFO 14 5.14. REFER 14 5.15. OPTIONS 15 6. SIP響應消息 15 6.1. SIP

4、響應消息格式 15 6.2. 1xx臨時響應 16 6.2.1. 100 Trying 16 6.2.2. 180 Ringing 16 6.2.3. 181 Call is Being Forwarded 16 6.2.4. 182 Queued 16 6.2.5. 183 Session Progress 16 6.3. 2xx成功響應 16 6.3.1. 200 OK 17 6.3.2. 202 Accepted 17 6.4. 3xx重定向響應 17 6.4.1. 300 Multiple Choices 17 6.4.2. 301 Moved Permanen

5、tly 17 6.4.3. 302 Moved Temporarily 17 6.4.4. 305 Use Proxy 18 6.4.5. 380 Alternative Service 18 6.5. 4xx請求失敗響應 18 6.5.1. 400 Bad Request 18 6.5.2. 401 Unauthorized 18 6.5.3. 402 Payment Required 18 6.5.4. 403 Forbidden 19 6.5.5. 404 Not Found 19 6.5.6. 405 Method Not Allowed 19 6.5.7. 40

6、6 Not Acceptable 19 6.5.8. 407 Proxy Authentication Required 19 6.5.9. 408 Request Time-out 19 6.5.10. 410 Gone 20 6.5.11. 413 Request Entity Too Large 20 6.5.12. 414 Request URI Too Long 20 6.5.13. 415 Unsupported Media Type 20 6.5.14. 416 Unsupported URI Scheme 20 6.5.15. 420 Bad Extension

7、 20 6.5.16. 421 Extension Required 21 6.5.17. 422 Session Interval Too Small 21 6.5.18. 423 Interval Too Brief 21 6.5.19. 480 Temporarily Unavailable 21 6.5.20. 481 Call/Transaction Does Not Exist 21 6.5.21. 482 Loop Detected 21 6.5.22. 483 Too Many Hops 22 6.5.23. 484 Address Incomplete 22

8、 6.5.24. 485 Ambiguous 22 6.5.25. 486 Busy Here 22 6.5.26. 487 Request Terminated 22 6.5.27. 488 Not Acceptable Here 22 6.5.28. 489 Bad Event 23 6.5.29. 491 Request Pending 23 6.5.30. 493 Undecipherable 23 6.6. 5xx服務器失敗響 23 6.6.1. 500 Server Internal Error 23 6.6.2. 501 Not Implemented 23

9、6.6.3. 502 Bad Gateway 24 6.6.4. 503 Service Unavailable 24 6.6.5. 504 Server Time-out 24 6.6.6. 505 Version Not Supported 24 6.6.7. 513 Message Too Large 24 6.7. 6xx全局性失敗響應 24 6.7.1. 600 Busy Everywhere 25 6.7.2. 603 Decline 25 6.7.3. 604 Does Not Exist Anywhere 25 6.7.4. 606 Not Acceptabl

10、e 25 7. SIP消息頭域 25 7.1. Accept 25 7.2. Accept-Contact 26 7.3. Accept-Encoding 26 7.4. Accept-Language 26 7.5. Accept-Resource-Priority 27 7.6. Alert-Info 27 7.7. Allow 28 7.8. Allow-Events 28 7.9. Answer-Mode 28 7.10. Authentication-Info 29 7.11. Authorization 29 7.12. Call-ID 30 7.13.

11、 Call-Info 30 7.14. Contact 31 7.15. Content-Disposition 32 7.16. Content-Encoding 33 7.17. Content-Language 34 7.18. Content-Length 34 7.19. Content-Type 35 7.20. CSeq 36 7.21. Date 36 7.22. Encryption 36 7.23. Error-Info 37 7.24. Event 37 7.25. Expires 38 7.26. Flow-Timer 38 7.27. Fr

12、om 38 7.28. History-Info 39 7.29. Identity 39 7.30. Identity-Info 40 7.31. In-Reply-To 40 7.32. Join 40 7.33. Max-Breadth 41 7.34. Max-Forwards 41 7.35. MIME-Version 41 7.36. Min-Expires 41 7.37. Min-SE 42 7.38. Organization 42 7.39. P-Access-Network-Info 42 7.40. P-Answer-State 43 7.4

13、1. P-Asserted-Identity 43 7.42. P-Associated-URI 44 7.43. P-Called-Party-ID 44 7.44. P-Charging-Function-Addresses 44 7.45. P-Charging-Vector 45 7.46. P-DCS-Trace-Party-ID 45 7.47. P-DCS-OSPS 45 7.48. P-DCS-Billing-Info 46 7.49. P-DCS-LAES 46 7.50. P-DCS-Redirect 47 7.51. P-Early-Media 47

14、 7.52. P-Media-Authorization 48 7.53. P-Preferred-Identity 48 7.54. P-Profile-Key 48 7.55. P-Refused-URI-List 48 7.56. P-Served-User 49 7.57. P-User-Database 49 7.58. P-Visited-Network-ID 49 7.59. Path 50 7.60. Permission-Missing 50 7.61. Priority 50 7.62. Priv-Answer-Mode 51 7.63. Privac

15、y 51 7.64. Proxy-Authenticate 51 7.65. Proxy-Authorization 52 7.66. Proxy-Require 53 7.67. Rack 53 7.68. Reason 54 7.69. Record-Route 54 7.70. Refer-Sub 54 7.71. Refer-To 55 7.72. Referred-By 55 7.73. Reject-Contact 55 7.74. Replaces 56 7.75. Reply-To 56 7.76. Request-Disposition 56 7.

16、77. Require 57 7.78. Resource-Priority 57 7.79. Retry-After 57 7.80. Route 58 7.81. RSeq 58 7.82. Security-Client 58 7.83. Security-Server 59 7.84. Security-Verify 59 7.85. Server 59 7.86. Service-Route 60 7.87. Session-Expires 60 7.88. SIP-ETag 60 7.89. SIP-If-Match 60 7.90. Subject 61

17、 7.91. Subscription-State 61 7.92. Supported 62 7.93. Target-Dialog 62 7.94. Timestamp 62 7.95. To 62 7.96. Trigger-Consent 63 7.97. Unsupported 63 7.98. User-Agent 63 7.99. Via 64 7.100. Warning 64 7.101. WWW-Authenticate 65 8. SIP消息體 65 8.1. SDP 65 8.2. CPIM 66 8.3. XML 67 9. 編制歷史

18、67 附錄A SIP消息頭域可選性附錄 （標準性附錄） 68 附錄B SIP消息示例（資料性附錄） 72 附錄C 包含CM-IMS特殊要求的消息頭域（資料性附錄） 80 V 前 言 本標準依據(jù)IETF、3GPP以及ITU-T制定的相關標準，結合有關國內標準和中國移動相關企業(yè)標準，基于中國移動CM-IMS總體技術要求和實際需求而擬定，充分考慮了網絡的平滑演進能力，為中國移動CM-IMS的技術試驗、網絡建設和運行維護提供技術依據(jù)。 本標準規(guī)定了會話初始協(xié)議（SIP）所使用的消息、參數(shù)的基本功能、格式，主要包括SIP消息概述、請求消息、響應消息、頭域及參數(shù)。 本標準是CM-I

19、MS會話初始協(xié)議（SIP）系列標準之一，該系列標準的結構、名稱或預計的名稱如下： 序號 標準編號 標準名稱 [1] QB-C-018.1-2011 中國移動CM-IMS會話初始協(xié)議（SIP）規(guī)范第1部分：SIP的總體要求 [2] QB-C-018.2-2011 中國移動CM-IMS會話初始協(xié)議（SIP）規(guī)范第2部分：SIP的消息 [3] QB-C-018.3-2011 中國移動CM-IMS會話初始協(xié)議（SIP）規(guī)范第3部分：SIP的基本流程 [4] QB-C-018.4-2011 中國移動CM-IMS會話初始協(xié)議（SIP）規(guī)范第4部分：CM-IMS業(yè)務對 SIP的

20、要求 [5] QB-C-018.5-2011 中國移動CM-IMS會話初始協(xié)議（SIP）規(guī)范第5部分：SIP與BICC/ISUP的互通 本標準的附錄A為標準性附錄，附錄B、C為資料性附錄。 本標準由中移技﹝2011﹞220號印發(fā)。 本標準由中國移動通信集團公司計劃建設部提出，集團公司技術部歸口。 本標準起草單位：中國移動通信研究院 本標準主要起草人：宋月 陳旭 趙婷 孫強 73 1. 范圍 本標準規(guī)定了會話初始協(xié)議（SIP）的請求、響應消息、頭域及參數(shù)的基本功能和格式。供中國移動內部和廠商共同使用；適用于中國移動CM-IMS中包括Gm、Mw、ISC、Mg、

21、Mj在內的所有SIP接口；適用于中國移動CM-IMS核心網設備、接入設備及終端設備的研發(fā)、引入和運行維護。 2. 規(guī)范性引用文件 下列文件中的條款通過本標準的引用而成為本標準的條款。凡是注日期的引用文件，其隨后所有的修改單（不包括勘誤的內容）或修訂版均不適用于本標準，然而，鼓勵根據(jù)本標準達成協(xié)議的各方研究是否可使用這些文件的最新版本。凡是不注日期的引用文件，其最新版本適用于本標準。 序號 標準編號 標準名稱 發(fā)布單位 [1] RFC3261 SIP: Session Initiation Protocol IETF [2] RFC3262 Reliability of

22、 Provisional Responses in the Session Initiation Protocol IETF [3] RFC3263 Session Initiation Protocol (SIP): Locating SIP Servers IETF [4] RFC3264 An Offer/Answer Model with the Session Description Protocol (SDP) IETF [5] RFC3265 Session Initiation Protocol (SIP)-Specifi

23、c Event Notification IETF [6] RFC3310 Hypertext Transfer Protocol (HTTP) Digest Authentication Using Authentication and Key Agreement (AKA) IETF [7] RFC3311 The Session Initiation Protocol (SIP) UPDATE Method IETF [8] RFC3312 Integration of Resource Management

24、 and Session Initiation Protocol (SIP) IETF [9] RFC3323 A Privacy Mechanism for the Session Initiation Protocol (SIP) IETF [10] RFC3325 Private Extensions to the Session Initiation Protocol (SIP) for Asserted Identity within Trusted Networks IETF [11] RFC3326 The Reason He

25、ader Field for the Session Initiation Protocol (SIP) IETF [12] RFC3327 Session Initiation Protocol (SIP) Extension Header Field for Registering Non-Adjacent Contacts IETF [13] RFC3398 Integrated Services Digital Network (ISDN) User Part (ISUP) to Session Initiati

26、on Protocol (SIP) Mapping IETF [14] RFC3428 Session Initiation Protocol (SIP) Extension for Instant Messaging IETF [15] RFC3455 Private Header (P-Header) Extensions to the Session Initiation Protocol (SIP) for the 3rd-Generation Partnership Project (3GPP) IETF [16] RFC3515 The Session

27、 Initiation Protocol (SIP) Refer Method IETF [17] RFC3608 Session Initiation Protocol (SIP) Extension Header Field for Service Route Discovery During Registration IETF [18] RFC3665 Session Initiation Protocol (SIP) Basic Call Flow Examples IETF [19] RFC3666 Session Initiation

28、Protocol (SIP) Public Switched Telephone Network (PSTN) Call Flows IETF [20] RFC3725 Best Current Practices for Third Party Call Control (3pcc) in the Session Initiation Protocol (SIP) IETF [21] RFC3824 Using E.164 numbers with the Session Initiation Protocol (SIP) I

29、ETF [22] RFC3863 Presence Information Data Format (PIDF) IETF [23] RFC3891 The Session Initiation Protocol (SIP) "Replaces" Header IETF [24] RFC3903 Session Initiation Protocol (SIP) Extension for Event State Publication IETF [25] RFC3959 The Early S

30、ession Disposition Type for the Session Initiation Protocol (SIP) IETF [26] RFC3960 Early Media and Ringing Tone Generation in the Session Initiation Protocol (SIP) IETF [27] RFC3966 The Tel URI for Telephone Numbers IETF [28] RFC4032 Update to the Session

31、Initiation Protocol (SIP) Preconditions Framework IETF [29] RFC4244 An Extension to the Session Initiation Protocol (SIP) for Request History Information IETF [30] RFC4566 SDP: Session Description Protocol IETF [31] RFC4825 The Extensible Markup L

32、anguage (XML) Configuration Access Protocol (XCAP) IETF [32] RFC5009 Private Header (P-Header) Extension tothe Session Initiation Protocol (SIP) for Authorization of Early Media IETF [33] RFC5589 Session Initiation Protocol (SIP) Call Control - Transfer IETF [34] TS23.228

33、 IP Multimedia Subsystem (IMS);Stage 2 3GPP [35] TS24.229 IP multimedia call control protocol based on Session Initiation Protocol (SIP)and Session Description Protocol (SDP);Stage 3 3GPP [36] Q.1912.5 Interworking between Session Initiation Protocol (SIP) and Bearer Independent Call Contro

34、l protocol or ISDN User Part ITU-T 3. 術語、定義與縮略語 下列術語和縮略語適用于本規(guī)范。 詞語 解釋 B2BUA 背靠背用戶代理（B2BUA）是一個邏輯功能實體，它作為UAS接收請求消息并處理該消息，同時也作為UAC來發(fā)送請求消息，B2BUA也可分別作為UAC發(fā)起兩個會話.B2BUA需要維護兩個會話的對應關系 CPIM Common Presence and Instant Messaging，參見RFC3862 FQDN Full Qualified Domain Name，全稱域名 GRUU Globally Routable

35、 User agent URI，全局可路由用戶代理標識 iFC Initial Filter Criteria，初始過濾規(guī)則 IMPI IMS Private Identity，IMS用戶私有標識 IMPU IMS Public Identity，IMS用戶公有標識 IPSec 一種開放標準的框架結構，通過使用加密的安全服務以確保在IP網絡上進行保密而安全的通訊 PLMN Public Land Mobile Network，公共移動電話網 Proxy SIP邏輯實體，用于轉發(fā)SIP消息 PSI Public Service Identity，公共業(yè)務標識 PST

36、N Public Switched Telephone Network，公共交換電話網 SA Security Association，安全關聯(lián) SDP Session Description Protocol，會話描述協(xié)議 TLS Transport Layer Security，傳輸層安全 UA 用戶代理，SIP邏輯實體，是SIP消息的發(fā)起和終結方 UAC 用戶代理客戶端，SIP邏輯實體，產生SIP請求消息，并終結SIP響應消息。 UAS 用戶代理服務器，SIP邏輯實體，終結SIP請求消息，并返回SIP響應消息。 UE User Equipment，用戶設備

37、 URI Uniform Resource Identifier，統(tǒng)一資源標識符 XML eXtensible Markup Language，可擴展標記語言 對話 對話是兩個UA之間持續(xù)一段時間的點對點的SIP連接，它使UA之間的消息變得有序，同時給出請求消息的正確的路由 會話 會話是通信參與方及它們之間的媒體流的集合 4. SIP消息概述 SIP 協(xié)議是采用UTF-8 字符集來進行編碼的文本協(xié)議。 SIP 協(xié)議消息分請求和響應兩類，其中請求消息由UAC發(fā)往UAS，響應消息由UAS發(fā)往UAC。除選用的字符集以及語法定義外，請求和響應消息均采用RFC2822 定義的

38、基本格式進行編碼。請求和響應消息格式由一個起始行（Start-Line）、若干個頭域(Message-Header)，以及一個可選的消息體(Message-Body)組成。其中消息體為可選項，頭域與消息體之間用空行進行分隔，起始行分為請求行（Request-Line）和狀態(tài)行（Status-Line），分別用于SIP請求消息和響應消息。SIP消息統(tǒng)一格式如下： SIP message = Start-Line *Message-Header CRLF [Message-Body] Start-Line = Request-Line/Status-Line 如上消息格式定義，“*

39、”表示該消息頭域可包含一個或多個，“[]”表示該參數(shù)為可選項。本規(guī)范規(guī)定起始行、每一個消息頭域以及空行都必須使用回車換行字符（CRLF）來表示行終結，即使消息中未包含消息體空行也不能省略。除了以上字符集不同之外，SIP 消息和頭域語法定義與HTTP 1.1 的語法定義一致，HTTP/1.1 的語法定義參見RFC2612。消息語法定義與HTTP 類似， 但SIP 協(xié)議并不是HTTP 的擴展協(xié)議。 4.1. SIP消息起始行 SIP消息起始行位于SIP消息的最開始部分，所有的SIP消息都包含一個起始行。 SIP請求消息中的起始行稱為請求行。請求行包含請求消息的方法、Request URI（可

40、以包含其他參數(shù)，如傳送協(xié)議）以及SIP版本，其中SIP版本一般取值為”SIP/2.0”。Request URI中可以是SIP URI/SIPS URI/TEL URI。以一條INVITE消息的請求行為例： 圖4-1 SIP請求消息請求行格式示例 SIP響應消息中的起始行稱為狀態(tài)行。狀態(tài)行包含SIP版本，狀態(tài)碼以及與狀態(tài)碼相關的文字描述。以一條486響應消息的狀態(tài)行為例： 圖4-2 SIP響應消息狀態(tài)行格式示例 4.2. SIP消息頭域 SIP消息頭域（SIP Header，簡稱為SIP頭）是SIP消息的重要組成部分，可以用于會話路由、標識會話、傳遞會話過程中的控制信息等

41、功能。每條SIP消息都會包含多個SIP消息頭域，每個SIP消息頭域以”CRLF”結束，如： 每個SIP消息頭域由消息頭域的名稱和消息頭域的內容構成，消息頭域的名稱與內容之間以冒號（:）隔開，根據(jù)實際應用的需要，SIP消息頭域的內容當中還可以包含若干參數(shù)，參數(shù)與頭域內容之間，參數(shù)與參數(shù)之間，用分號隔開,如： 圖4-3 SIP消息頭域格式示例 SIP協(xié)議中有6個消息頭域是必選頭域，即SIP請求和響應消息中都必須包含這6個消息頭域： 表4-1 必選SIP消息頭域 SIP頭 備注 From To Call-ID 用于標識對話 CSeq 用于標識事務，以及標

42、識同一對話中請求消息的先后順序 Via 記錄請求消息路徑，用于響應消息路由 Max-Forwards 限制消息最大轉發(fā)次數(shù) 其他SIP頭域的可選性參見附錄A，為減少網絡資源開銷，應盡量避免在SIP消息中攜帶不必要的頭域。 4.3. SIP消息體 SIP消息體是SIP消息的凈荷部分，SIP消息體與最后一個SIP消息頭域之間以一個CRLF隔開。SIP消息體格式與SIP協(xié)議本身無關，SIP消息攜帶不同協(xié)議的消息體可以用于完成不同的功能，常用的有：SIP攜帶SDP，用于媒體協(xié)商；SIP攜帶XML，用于攜帶格式化的信息，如訂閱事件通知；SIP攜帶CPIM，用于即時消息。SIP消息體的格式通

43、過Content-Type頭的MIME格式指示。SIP消息體具體參見第8節(jié)。 SIP消息體舉例： 圖4-4 SIP消息體式示例 4.4. SIP協(xié)議中的URI 4.4.1. SIP URI SIP URI的格式遵從RFC 2396中的規(guī)定，其統(tǒng)一形式為： sip:user:password@host:port;uri-parameters?headers SIP URI以”sip:”開頭，其后各部分內容為： l user SIP URI的用戶部分標識了用戶身份信息。該部分可以是一個字符串，也可以是一個E.164電話號碼。當SIP URI指向的目的地沒有用戶身份或host部分就

44、是SIP URI所要指向的目的地時，SIP URI中不包含user、password部分，以及“@”字符。 l password 當訪問SIP URI指向的資源需要口令時，可以將口令放在password部分進行傳送。在一些情況下SIP消息會以明文傳送，這樣會泄露口令信息。 注：CM-IMS中暫不采用password部分 l host SIP URI指向的資源的歸屬域，該部分可以是一個FQDN或者是一個IPv4/IPv6地址。 l port 接收本條SIP消息的端口號。port參數(shù)為可選參數(shù)，本系列規(guī)范未對其使用方式進行規(guī)定。 l uri-parameters SIP URI的

45、其他參數(shù)。統(tǒng)一格式為： parameter-name ["=" parameter-value] 不同SIP URI參數(shù)之間用分號（;）隔開,可以根據(jù)實際需要定義參數(shù)，常用的參數(shù)有： n transport：表示向該URI發(fā)送消息需要使用的傳輸層協(xié)議，可取值為UDP、TCP、SCTP n user：用于區(qū)分URI中user部分的類型，可以取值為：phone、dialstring n lr：表示采取松散路由 n orig：用于標識主叫流程 n ODI：用于匹配B2BUA兩側的對話 n replaces：當URI出現(xiàn)在REFER消息的refer-to頭域時，replaces參數(shù)攜帶

46、需要替換的對話標識 l headers 當要求基于本條SIP消息生成另一條SIP消息包含某些頭域及相應取值時，可以通過SIP URI中的headers部分進行指示。headers參數(shù)為可選參數(shù)，本系列規(guī)范未對其使用方式進行規(guī)定。 SIP URI舉例： sip:+861052400481@ sip:+8613910001234_s@ sip: 4.4.2. SIPS URI SIPS URI以”sips:”開頭，其余格式及各組成部分與SIP URI相同，與SIP URI的區(qū)別在于SIPS URI要求SIP消息在傳輸過程中采用安全的傳輸機制。 4.4.3. TEL URI TE

47、L URI格式參照RFC 3966中的規(guī)定。 TEL URI舉例： tel:+861052400481 tel:52400481;phone-context=+8610 4.4.4. SIP URI與TEL URI的轉換 l TEL URI轉換為SIP URI 將TEL URI中除”tel:”以外的部分全部作為SIP URI的user部分，然后根據(jù)TEL URI內容或本地策略生成SIP URI的host部分。需要注意一點是TEL URI中的參數(shù)名不區(qū)分大小寫，而SIP URI中的參數(shù)名區(qū)分大小寫，因此從TEL URI轉換為SIP URI時，所有參數(shù)名必須轉換為小寫形式。 當從TE

48、L URI轉換為SIP URI時，SIP URI 中應包含user=phone參數(shù)。 5. SIP請求消息 5.1. SIP請求消息格式 請求消息的起始行為請求行。請求行的格式如下所示，由方法名（Method）、請求URL（Request-URI）和協(xié)議版本（SIP-Version）組成，各部分之間均用一個空格字符進行分隔。除此之外，請求行必須用回車換行（CRLF）字符表示行終結。 Request-Line = Method[ ] Request-URI [] SIP-Version CRLF 1） 方法名：本部分共定義了14 個方法，如表5-1所示。

49、 表5-1 SIP方法列表 方法名 應用場景 INVITE 用于會話的建立和會話屬性的修改。 ACK 用于對INVITE消息最終響應的確認。 BYE 用于會話的釋放。 CANCEL 用于取消之前發(fā)送的SIP請求消息。建議CANCEL消息僅用于取消INVITE請求。 REGISTER 用于注冊和注銷。 SUBSCRIBE 用于對事件的訂閱。 PUBLISH 用于發(fā)布網元狀態(tài)。 NOTIFY 用于對訂閱事件的通知。 UPDATE 用于會話媒體修改和會話刷新。 MESSAGE 用于即時消息。 PRACK 用于對臨時響應

50、消息的確認。PRACK消息及其成功響應可攜帶SDP進行媒體協(xié)商，通常用于與CS域互通。 INFO 用于在會話內傳送會話相關的控制信息。 REFER 用于通知第三方對會話進行控制。 OPTIONS 用于服務器能力查詢。也可用作心跳消息。 2） Request URI：指示被邀請用戶的當前地址，Request URI中不允許出現(xiàn)空格或其他控制字符且不能包含于“<>”符號之內，URI可以是sip、sips或tel格式。 3） 版本號：用于定義協(xié)議的當前版本號，本協(xié)議的版本號為SIP/2.0。 5.2. INVITE INVITE請求消息用于會話的創(chuàng)建和修改。如基本音視頻會話、會議

51、等。 在會話建立開始時，主叫UA發(fā)送INVITE消息（初始INVITE），請求行中的Request URI表示被叫URI，通常情況下初始INVITE消息中會攜帶主叫SDP信息。收到INVITE消息后，在一定時間內未發(fā)送最終響應或其他臨時響應則回送100響應表示已經接收到請求消息，正在對其進行處理。 在會話進行過程中，INVITE消息（Re-INVITE）可以用于會話屬性的修改，這種情況下的INVITE消息必須與初始INVITE消息處于同一會話當中。 INVITE消息關鍵頭域如下表所示： 表5-2 INVITE消息關鍵頭域 頭域 頭域含義 Contact 用于INVIT

52、E、ACK和REGISTER請求以及成功響應、臨時響應和重定向響應消息，其作用是給出后續(xù)和用戶直接通信的地址。但是，CANCEL請求不能直接發(fā)往該地址，必須沿原請求發(fā)送的路徑前傳。Contact的作用域是全局性的。這就是說，Contact頭域中包含的URI是UA能夠接收請求的。 Route 1.ODI參數(shù)：S-CSCF到AS的ISC接口中，次頂層的Route頭包含S-CSCF的SIP URI，并且有Original dialog identifier用于關聯(lián)觸發(fā)前后的請求。ODI參數(shù)由同一個S-CSCF添加和刪除，所以不對其具體格式進行規(guī)范。AS發(fā)起的獨立初始請求不應該攜帶本參數(shù)。 2.

53、orig參數(shù)：標識主叫流程，在主叫側網元間傳遞。 3.lr參數(shù)：表示松散路由 Record-Route 用于當前會話后續(xù)消息的路由。是proxy在請求中增加的，用來強制會話中的后續(xù)請求經過本proxy。 User-Agent User-Agent頭字段包含有發(fā)起請求的用戶終端的信息。 Supported 攜帶支持的能力擴展，如： 1.100rel值表示支持1XX響應的可靠傳輸 2.timer值用于Session timer特性，同時填寫Session-Expires頭域。 3.in-band-dtmf值用于DTMF收號。 4.precondition值表示支持資源預留機制

54、 P-Called-Party-ID 被叫IMPU，在被叫S-CSCF到UE之間傳遞。見RFC3455 P-Asserted-Identity 主叫IMPU。見RFC3325 P-Access-Network-Info 用戶接入網絡信息，比如P-Access-Network-Info: IEEE-802.11;"sbc-domain=";"ue-ip=10.10.10.69";"ue-port=5062"。 sbc-domain參數(shù)填寫為接入本地網信息，計費中心用于識別漫游。 History-Info 用于傳遞會話中前轉的歷史信息，包括原被叫地址信息等。其中要有hi-entr

55、y屬性，hi-targeted-to-Uri屬性(第一個為最初被叫的地址，第二個為被轉到的地址)和reason屬性，index屬性和cause屬性碼。見RFC4244。 如： History-Info: ;index=1 History-Info: ;index=1.1 5.3. ACK ACK消息是對INVITE消息的最終響應的確認。該消息僅和INVITE消息配套使用。包含Dialog信息、Via頭域中branch參數(shù)為事務信息。INVIT

56、E消息關鍵頭域如下表所示： 表5-3 ACK消息關鍵頭域 頭域 頭域含義 CSeq ACK消息中的CSeq頭中數(shù)字取值必須與相應的INVITE消息一致。 5.4. BYE 通話中任何一方掛機，則向對端發(fā)送BYE消息，指示其已掛機，通話結束。包含Dialog信息、Via頭域中branch參數(shù)為事務信息。 5.5. CANCEL 客戶端用來取消尚未完成的請求，請求UAS去終止上一個請求并且對上一個請求產生一個錯誤的響應（487）。對于已完成的請求（即已收到最終響應的請求）則沒有影響。CANCEL是一個逐跳傳輸?shù)恼埱?，因此CANCEL需要每一個有狀態(tài)的proxy節(jié)點進行處理和

57、響應。。CANCEL消息關鍵頭域如下表所示： 表5-4 CANCEL消息關鍵頭域 頭域 頭域含義 CSeq CANCEL消息中的CSeq頭中數(shù)字取值必須與建立會話的初始INVITE消息一致。 Via Via頭中的branch參數(shù)必須與建立會話的初始INVITE消息一致 5.6. REGISTER REGISTER消息用于用戶的注冊、注銷以及第三方注冊。REGISTER消息中Request-URI中填寫用戶歸屬域名，此處URI不能包含user部分和”@”。REGISTER消息的關鍵消息頭如下表所示： 表5-5 REGISTER消息關鍵頭域 頭域 頭域含義 To 被注冊

58、的用戶標識。 From 在用戶注冊時From頭與To頭內容相同；在第三方注冊時，F(xiàn)rom頭內容為第三方的URI Call-ID 重注冊、注銷消息中Call-ID應與初始注冊消息中Call-ID相同 Expires 表示注冊時長；當取值為0時表示注銷 Contact 用于INVITE、ACK和REGISTER請求以及成功響應、呼叫進展響應和重定向響應消息，其作用是給出后續(xù)和用戶直接通信的地址。但是，CANCEL請求不能直接發(fā)往該地址，必須沿原請求發(fā)送的路徑前傳。Contact的作用域是全局性的。這就是說，Contact頭域中包含的URI是UA能夠接收請求的。 REGISTER請

59、求中的Contact指明用戶可達位置。頭域中包含Expires參數(shù)標示超時時長。 Path P-CSCF到S-CSCF的REGISTER消息中攜帶，填寫P-CSCF的主機名。 Authorization UE-CSCF之間傳遞，包含某個終端的鑒權證書。 1.Authentication Scheme 為Digest，表明鑒權方式 2.user name用戶名，即IMPI 3.Nonce 只在401響應后的REGISTER消息中填寫，值同401響應 4. Realm歸屬網絡的域名，表明用戶受保護的域 5.Algorithm MD5鑒權結果的計算方法（該字段可選） WWW-Au

60、thenticate UE-CSCF之間傳遞，對應REGISTER請求的401響應消息。 1.Authentication Scheme為Digest，表明鑒權方式 2.Realm歸屬網絡的域名，表明用戶受保護的域 3.Algorithm為MD5，鑒權結果的計算方法 4.Nonce S-CSCF生產的字符串，用以計算Response P-Access-Network-Info 攜帶用戶接入地信息 5.7. SUBSCRIBE 對事件的訂閱，訂閱會創(chuàng)建一個對話。呈現(xiàn)業(yè)務中本消息由AS終結，AS的業(yè)務觸發(fā)數(shù)據(jù)中AS的默認處理應該為終結消息。 表5-6 SUBSCRIBE消息關鍵

61、頭域 頭域 頭域含義 Event 訂閱事件的類型，如presence表示狀態(tài)呈現(xiàn)，reg表示注冊狀態(tài) Expires 非0表示訂閱時長，0表示取消訂閱。 5.8. PUBLISH 呈現(xiàn)業(yè)務中用于發(fā)布狀態(tài)。該消息始于終端，由AS終結，因此該AS的業(yè)務觸發(fā)數(shù)據(jù)中AS的默認處理應該為終結消息。 表5-7 PUBLISH消息關鍵頭域 頭域 頭域含義 Event 發(fā)布事件，presence表示呈現(xiàn) Content-Type 消息體MIME格式，取值為application/pidf+xml 5.9. NOTIFY NOTIFY消息是通知訂閱者它訂閱的狀態(tài)發(fā)生了變化。

62、消息中Callid、to tag、from tag、Event與SUBSCRIBE創(chuàng)建的會話相同，route頭域路由路徑與SUBSCRIBE創(chuàng)建的Record-Route會話路徑相同。 表5-8 NOTIFY消息關鍵頭域 頭域 頭域含義 Event 訂閱事件，如presence表示呈現(xiàn)，reg表示注冊狀態(tài) Content-Type 消息體MIME格式，取值為application/pidf+xml Subscription-State 訂閱狀態(tài)，terminated表示結束，pending表示進行中，active表示訂閱成功。 5.10. UPDATE UPDATE消

63、息可以用于會話媒體修改，與INVITE消息的區(qū)別是UPDATE消息既能用于會話最終建立后的媒體修改，也能用于會話最終建立前的媒體修改，而INVITE消息只能用于會話最終建立后的媒體修改。 UPDATE消息可以用于會話刷新，在進行會話刷新時，為降低開銷，UPDATE消息通常不攜帶SDP消息體。 5.11. MESSAGE 通常用于消息類業(yè)務，如即時消息業(yè)務。對MESSAGE消息的成功響應為200 OK和202 Accepted，如果接收方為消息的最終接收者，則回復200 OK；如果接受方為存儲轉發(fā)服務器，則回復202 Accepted 表5-9 MESSAGE消息關鍵頭域 頭域 頭域

64、含義 User-Agent 在進行即時消息業(yè)務時，該頭域取值為”im” Content-Type 消息體MIME格式，取值為message/CPIM 5.12. PRACK 用于對臨時響應消息（18X）的確認。當收到本消息時應該發(fā)送200 OK確認響應。 SIP協(xié)議中定義的18X類臨時響應消息的傳輸是不可靠的，如果需要在該響應消息中攜帶媒體信息，那么就必須保證該消息能夠可靠的傳輸?shù)綄Χ?。PRACK是對18x臨時響應消息的確認請求消息，用于通知對端已經收到該臨時響應。 表5-10 PRACK消息關鍵頭域 頭域 頭域含義 Cseq PRACK與INVITE消息不在同一事

65、務當中，因此PRACK中Cseq應在INVITE消息基礎上遞增 5.13. INFO 會話內的請求通常用于傳送會話相關的控制信息，用于攜帶MRFC使用的音資源信息、DTMF信息、控制信息等。 表5-11 INFO消息關鍵頭域 頭域 頭域含義 消息體 dtmfinfo+xml中攜帶DTMF信息； vxml中攜帶錄音通知信息； xml中攜帶MSML腳本 5.14. REFER 通常是對話內的請求，用于通知對方對第三方進行會話控制。REFER請求也可以在對話外發(fā)送，此時REFER消息會創(chuàng)建一個對話。 表5-12 REFER消息關鍵頭域 頭域 頭域含義 Refer-t

66、o 用于攜帶轉移目的方地址 Refer-by 用于攜帶業(yè)務方地址 5.15. OPTIONS 用于查詢被叫的相關信息和功能，或者應用于網元間的心跳。 OPTIONS消息不會創(chuàng)建對話。 6. SIP響應消息 6.1. SIP響應消息格式 響應消息的起始行為狀態(tài)行（Status-Line），狀態(tài)行由協(xié)議版本（SIP-Version）、狀態(tài)碼（Status-Code）和與狀態(tài)碼相關的文本（Reason-Phase）描述組成，各個部分之間用一個空格字符進行分隔。狀態(tài)行的格式如下所示： Status-Line = SIP-Version [ ]Status-Code [ ] Reason-Phrase CRLF 除狀態(tài)行的尾部可使用回車換行CRLF 字符之外，狀態(tài)行內不允許出現(xiàn)CRLF 字符。 1） 狀態(tài)碼：該參數(shù)為一