中國移動CM-IMS會話初始協(xié)議(SIP)技術(shù)規(guī)范-第二部分：SIP的消息

QB-撰寫人：_日 期：_中國移動通信企業(yè)標準QB-C-018.2-2011中國移動CM-IMS會話初始協(xié)議（SIP）技術(shù)規(guī)范 第二部分：SIP的消息CM-IMS Specifications of Session Initiation Protocol (SIP) Part 2: SIP Messages SIP Protocol版本號：1.0.02011-7-27實施2011-7-27發(fā)布中國移動通信集團公司 發(fā)布QB-C-018.2-2011目錄前 言VI1.范圍12.規(guī)范性引用文件13.術(shù)語、定義與縮略語44.SIP消息概述54.1.SIP消息起始行54.2.SIP消息頭域64.3.SIP消息體74.4.SIP協(xié)議中的URI84.4.1.SIP URI84.4.2.SIPS URI94.4.3.TEL URI94.4.4.SIP URI與TEL URI的轉(zhuǎn)換95.SIP請求消息95.1.SIP請求消息格式95.2.INVITE105.3.ACK115.4.BYE115.5.CANCEL115.6.REGISTER125.7.SUBSCRIBE135.8.PUBLISH135.9.NOTIFY135.10.UPDATE135.11.MESSAGE145.12.PRACK145.13.INFO145.14.REFER145.15.OPTIONS156.SIP響應(yīng)消息156.1.SIP響應(yīng)消息格式156.2.1xx臨時響應(yīng)166.2.1.100 Trying166.2.2.180 Ringing166.2.3.181 Call is Being Forwarded166.2.4.182 Queued166.2.5.183 Session Progress166.3.2xx成功響應(yīng)166.3.1.200 OK176.3.2.202 Accepted176.4.3xx重定向響應(yīng)176.4.1.300 Multiple Choices176.4.2.301 Moved Permanently176.4.3.302 Moved Temporarily176.4.4.305 Use Proxy186.4.5.380 Alternative Service186.5.4xx請求失敗響應(yīng)186.5.1.400 Bad Request186.5.2.401 Unauthorized186.5.3.402 Payment Required186.5.4.403 Forbidden196.5.5.404 Not Found196.5.6.405 Method Not Allowed196.5.7.406 Not Acceptable196.5.8.407 Proxy Authentication Required196.5.9.408 Request Time-out196.5.10.410 Gone206.5.11.413 Request Entity Too Large206.5.12.414 Request URI Too Long206.5.13.415 Unsupported Media Type206.5.14.416 Unsupported URI Scheme206.5.15.420 Bad Extension206.5.16.421 Extension Required216.5.17.422 Session Interval Too Small216.5.18.423 Interval Too Brief216.5.19.480 Temporarily Unavailable216.5.20.481 Call/Transaction Does Not Exist216.5.21.482 Loop Detected216.5.22.483 Too Many Hops226.5.23.484 Address Incomplete226.5.24.485 Ambiguous226.5.25.486 Busy Here226.5.26.487 Request Terminated226.5.27.488 Not Acceptable Here226.5.28.489 Bad Event236.5.29.491 Request Pending236.5.30.493 Undecipherable236.6.5xx服務(wù)器失敗響236.6.1.500 Server Internal Error236.6.2.501 Not Implemented236.6.3.502 Bad Gateway246.6.4.503 Service Unavailable246.6.5.504 Server Time-out246.6.6.505 Version Not Supported246.6.7.513 Message Too Large246.7.6xx全局性失敗響應(yīng)246.7.1.600 Busy Everywhere256.7.2.603 Decline256.7.3.604 Does Not Exist Anywhere256.7.4.606 Not Acceptable257.SIP消息頭域257.1.Accept257.2.Accept-Contact267.3.Accept-Encoding267.4.Accept-Language267.5.Accept-Resource-Priority277.6.Alert-Info277.7.Allow287.8.Allow-Events287.9.Answer-Mode287.10.Authentication-Info297.11.Authorization297.12.Call-ID307.13.Call-Info307.14.Contact317.15.Content-Disposition327.16.Content-Encoding337.17.Content-Language347.18.Content-Length347.19.Content-Type357.20.CSeq367.21.Date367.22.Encryption367.23.Error-Info377.24.Event377.25.Expires387.26.Flow-Timer387.27.From387.28.History-Info397.29.Identity397.30.Identity-Info407.31.In-Reply-To407.32.Join407.33.Max-Breadth417.34.Max-Forwards417.35.MIME-Version417.36.Min-Expires417.37.Min-SE427.38.Organization427.39.P-Access-Network-Info427.40.P-Answer-State437.41.P-Asserted-Identity437.42.P-Associated-URI447.43.P-Called-Party-ID447.44.P-Charging-Function-Addresses447.45.P-Charging-Vector457.46.P-DCS-Trace-Party-ID457.47.P-DCS-OSPS457.48.P-DCS-Billing-Info467.49.P-DCS-LAES467.50.P-DCS-Redirect477.51.P-Early-Media477.52.P-Media-Authorization487.53.P-Preferred-Identity487.54.P-Profile-Key487.55.P-Refused-URI-List487.56.P-Served-User497.57.P-User-Database497.58.P-Visited-Network-ID497.59.Path507.60.Permission-Missing507.61.Priority507.62.Priv-Answer-Mode517.63.Privacy517.64.Proxy-Authenticate517.65.Proxy-Authorization527.66.Proxy-Require537.67.Rack537.68.Reason547.69.Record-Route547.70.Refer-Sub547.71.Refer-To557.72.Referred-By557.73.Reject-Contact557.74.Replaces567.75.Reply-To567.76.Request-Disposition567.77.Require577.78.Resource-Priority577.79.Retry-After577.80.Route587.81.RSeq587.82.Security-Client587.83.Security-Server597.84.Security-Verify597.85.Server597.86.Service-Route607.87.Session-Expires607.88.SIP-ETag607.89.SIP-If-Match607.90.Subject617.91.Subscription-State617.92.Supported627.93.Target-Dialog627.94.Timestamp627.95.To627.96.Trigger-Consent637.97.Unsupported637.98.User-Agent637.99.Via647.100.Warning647.101.WWW-Authenticate658.SIP消息體658.1.SDP658.2.CPIM668.3.XML679.編制歷史67附錄A SIP消息頭域可選性附錄 （標準性附錄）68附錄B SIP消息示例（資料性附錄）72附錄C 包含CM-IMS特殊要求的消息頭域（資料性附錄）80 V前 言本標準依據(jù)IETF、3GPP以及ITU-T制定的相關(guān)標準，結(jié)合有關(guān)國內(nèi)標準和中國移動相關(guān)企業(yè)標準，基于中國移動CM-IMS總體技術(shù)要求和實際需求而擬定，充分考慮了網(wǎng)絡(luò)的平滑演進能力，為中國移動CM-IMS的技術(shù)試驗、網(wǎng)絡(luò)建設(shè)和運行維護提供技術(shù)依據(jù)。本標準規(guī)定了會話初始協(xié)議（SIP）所使用的消息、參數(shù)的基本功能、格式，主要包括SIP消息概述、請求消息、響應(yīng)消息、頭域及參數(shù)。本標準是CM-IMS會話初始協(xié)議（SIP）系列標準之一，該系列標準的結(jié)構(gòu)、名稱或預(yù)計的名稱如下：序號標準編號標準名稱1QB-C-018.1-2011中國移動CM-IMS會話初始協(xié)議（SIP）規(guī)范第1部分：SIP的總體要求2QB-C-018.2-2011中國移動CM-IMS會話初始協(xié)議（SIP）規(guī)范第2部分：SIP的消息3QB-C-018.3-2011中國移動CM-IMS會話初始協(xié)議（SIP）規(guī)范第3部分：SIP的基本流程4QB-C-018.4-2011中國移動CM-IMS會話初始協(xié)議（SIP）規(guī)范第4部分：CM-IMS業(yè)務(wù)對 SIP的要求5QB-C-018.5-2011中國移動CM-IMS會話初始協(xié)議（SIP）規(guī)范第5部分：SIP與BICC/ISUP的互通本標準的附錄A為標準性附錄，附錄B、C為資料性附錄。本標準由中移技2011220號印發(fā)。本標準由中國移動通信集團公司計劃建設(shè)部提出，集團公司技術(shù)部歸口。本標準起草單位：中國移動通信研究院本標準主要起草人：宋月 陳旭 趙婷 孫強 731. 范圍本標準規(guī)定了會話初始協(xié)議（SIP）的請求、響應(yīng)消息、頭域及參數(shù)的基本功能和格式。供中國移動內(nèi)部和廠商共同使用；適用于中國移動CM-IMS中包括Gm、Mw、ISC、Mg、Mj在內(nèi)的所有SIP接口；適用于中國移動CM-IMS核心網(wǎng)設(shè)備、接入設(shè)備及終端設(shè)備的研發(fā)、引入和運行維護。2. 規(guī)范性引用文件下列文件中的條款通過本標準的引用而成為本標準的條款。凡是注日期的引用文件，其隨后所有的修改單（不包括勘誤的內(nèi)容）或修訂版均不適用于本標準，然而，鼓勵根據(jù)本標準達成協(xié)議的各方研究是否可使用這些文件的最新版本。凡是不注日期的引用文件，其最新版本適用于本標準。序號標準編號標準名稱發(fā)布單位1RFC3261SIP: Session Initiation ProtocolIETF2RFC3262Reliability of Provisional Responses in the Session Initiation Protocol IETF3RFC3263 Session Initiation Protocol (SIP): Locating SIP ServersIETF4RFC3264An Offer/Answer Model with the Session Description Protocol (SDP)IETF5RFC3265Session Initiation Protocol (SIP)-Specific Event NotificationIETF6RFC3310Hypertext Transfer Protocol (HTTP) Digest Authentication Using Authentication and Key Agreement (AKA)IETF7RFC3311The Session Initiation Protocol (SIP) UPDATE MethodIETF8RFC3312Integration of Resource Management and Session Initiation Protocol (SIP)IETF9RFC3323A Privacy Mechanism for the Session Initiation Protocol (SIP)IETF10RFC3325Private Extensions to the Session Initiation Protocol (SIP) for Asserted Identity within Trusted NetworksIETF11RFC3326The Reason Header Field for the Session Initiation Protocol (SIP)IETF12RFC3327Session Initiation Protocol (SIP) Extension Header Field for Registering Non-Adjacent ContactsIETF13RFC3398Integrated Services Digital Network (ISDN) User Part (ISUP) to Session Initiation Protocol (SIP) MappingIETF14RFC3428Session Initiation Protocol (SIP) Extension for Instant MessagingIETF15RFC3455Private Header (P-Header) Extensions to the Session Initiation Protocol (SIP) for the 3rd-Generation Partnership Project (3GPP)IETF16RFC3515The Session Initiation Protocol (SIP) Refer MethodIETF17RFC3608Session Initiation Protocol (SIP) Extension Header Field for Service Route Discovery During RegistrationIETF18RFC3665Session Initiation Protocol (SIP) Basic Call Flow ExamplesIETF19RFC3666Session Initiation Protocol (SIP) Public Switched Telephone Network (PSTN) Call FlowsIETF20RFC3725Best Current Practices for Third Party Call Control (3pcc) in the Session Initiation Protocol (SIP)IETF21RFC3824Using E.164 numbers with the Session Initiation Protocol (SIP)IETF22RFC3863Presence Information Data Format (PIDF)IETF23RFC3891The Session Initiation Protocol (SIP) "Replaces" HeaderIETF24RFC3903 Session Initiation Protocol (SIP) Extension for Event State PublicationIETF25RFC3959The Early Session Disposition Type for the Session Initiation Protocol (SIP)IETF26RFC3960Early Media and Ringing Tone Generation in the Session Initiation Protocol (SIP)IETF27RFC3966The Tel URI for Telephone NumbersIETF28RFC4032Update to the Session Initiation Protocol (SIP) Preconditions FrameworkIETF29RFC4244An Extension to the Session Initiation Protocol (SIP) for Request History InformationIETF30RFC4566SDP: Session Description ProtocolIETF31RFC4825The Extensible Markup Language (XML) Configuration Access Protocol (XCAP)IETF32RFC5009Private Header (P-Header) Extension tothe Session Initiation Protocol (SIP) for Authorization of Early MediaIETF33RFC5589Session Initiation Protocol (SIP) Call Control - TransferIETF34TS23.228IP Multimedia Subsystem (IMS);Stage 23GPP35TS24.229IP multimedia call control protocol based on Session Initiation Protocol (SIP)and Session Description Protocol (SDP);Stage 33GPP36Q.1912.5Interworking between Session Initiation Protocol (SIP) and Bearer Independent Call Control protocol or ISDN User PartITU-T3. 術(shù)語、定義與縮略語下列術(shù)語和縮略語適用于本規(guī)范。詞語解釋B2BUA背靠背用戶代理（B2BUA）是一個邏輯功能實體，它作為UAS接收請求消息并處理該消息，同時也作為UAC來發(fā)送請求消息，B2BUA也可分別作為UAC發(fā)起兩個會話.B2BUA需要維護兩個會話的對應(yīng)關(guān)系CPIMCommon Presence and Instant Messaging，參見RFC3862FQDNFull Qualified Domain Name，全稱域名GRUUGlobally Routable User agent URI，全局可路由用戶代理標識iFCInitial Filter Criteria，初始過濾規(guī)則IMPIIMS Private Identity，IMS用戶私有標識IMPUIMS Public Identity，IMS用戶公有標識IPSec一種開放標準的框架結(jié)構(gòu)，通過使用加密的安全服務(wù)以確保在IP網(wǎng)絡(luò)上進行保密而安全的通訊PLMNPublic Land Mobile Network，公共移動電話網(wǎng)ProxySIP邏輯實體，用于轉(zhuǎn)發(fā)SIP消息PSIPublic Service Identity，公共業(yè)務(wù)標識PSTNPublic Switched Telephone Network，公共交換電話網(wǎng)SASecurity Association，安全關(guān)聯(lián)SDPSession Description Protocol，會話描述協(xié)議TLSTransport Layer Security，傳輸層安全UA用戶代理，SIP邏輯實體，是SIP消息的發(fā)起和終結(jié)方UAC用戶代理客戶端，SIP邏輯實體，產(chǎn)生SIP請求消息，并終結(jié)SIP響應(yīng)消息。UAS用戶代理服務(wù)器，SIP邏輯實體，終結(jié)SIP請求消息，并返回SIP響應(yīng)消息。UEUser Equipment，用戶設(shè)備URIUniform Resource Identifier，統(tǒng)一資源標識符XMLeXtensible Markup Language，可擴展標記語言對話對話是兩個UA之間持續(xù)一段時間的點對點的SIP連接，它使UA之間的消息變得有序，同時給出請求消息的正確的路由會話會話是通信參與方及它們之間的媒體流的集合4. SIP消息概述SIP 協(xié)議是采用UTF-8 字符集來進行編碼的文本協(xié)議。SIP 協(xié)議消息分請求和響應(yīng)兩類，其中請求消息由UAC發(fā)往UAS，響應(yīng)消息由UAS發(fā)往UAC。除選用的字符集以及語法定義外，請求和響應(yīng)消息均采用RFC2822 定義的基本格式進行編碼。請求和響應(yīng)消息格式由一個起始行（Start-Line）、若干個頭域(Message-Header)，以及一個可選的消息體(Message-Body)組成。其中消息體為可選項，頭域與消息體之間用空行進行分隔，起始行分為請求行（Request-Line）和狀態(tài)行（Status-Line），分別用于SIP請求消息和響應(yīng)消息。SIP消息統(tǒng)一格式如下：SIP message = Start-Line*Message-HeaderCRLF Message-BodyStart-Line = Request-Line/Status-Line 如上消息格式定義，“*”表示該消息頭域可包含一個或多個，“”表示該參數(shù)為可選項。本規(guī)范規(guī)定起始行、每一個消息頭域以及空行都必須使用回車換行字符（CRLF）來表示行終結(jié)，即使消息中未包含消息體空行也不能省略。除了以上字符集不同之外，SIP 消息和頭域語法定義與HTTP 1.1 的語法定義一致，HTTP/1.1 的語法定義參見RFC2612。消息語法定義與HTTP 類似， 但SIP 協(xié)議并不是HTTP 的擴展協(xié)議。4.1. SIP消息起始行SIP消息起始行位于SIP消息的最開始部分，所有的SIP消息都包含一個起始行。SIP請求消息中的起始行稱為請求行。請求行包含請求消息的方法、Request URI（可以包含其他參數(shù)，如傳送協(xié)議）以及SIP版本，其中SIP版本一般取值為”SIP/2.0”。Request URI中可以是SIP URI/SIPS URI/TEL URI。以一條INVITE消息的請求行為例：圖4-1 SIP請求消息請求行格式示例 SIP響應(yīng)消息中的起始行稱為狀態(tài)行。狀態(tài)行包含SIP版本，狀態(tài)碼以及與狀態(tài)碼相關(guān)的文字描述。以一條486響應(yīng)消息的狀態(tài)行為例：圖4-2 SIP響應(yīng)消息狀態(tài)行格式示例4.2. SIP消息頭域SIP消息頭域（SIP Header，簡稱為SIP頭）是SIP消息的重要組成部分，可以用于會話路由、標識會話、傳遞會話過程中的控制信息等功能。每條SIP消息都會包含多個SIP消息頭域，每個SIP消息頭域以”CRLF”結(jié)束，如：每個SIP消息頭域由消息頭域的名稱和消息頭域的內(nèi)容構(gòu)成，消息頭域的名稱與內(nèi)容之間以冒號（:）隔開，根據(jù)實際應(yīng)用的需要，SIP消息頭域的內(nèi)容當中還可以包含若干參數(shù)，參數(shù)與頭域內(nèi)容之間，參數(shù)與參數(shù)之間，用分號隔開,如：圖4-3 SIP消息頭域格式示例SIP協(xié)議中有6個消息頭域是必選頭域，即SIP請求和響應(yīng)消息中都必須包含這6個消息頭域：表4-1 必選SIP消息頭域 SIP頭備注FromToCall-ID用于標識對話CSeq用于標識事務(wù)，以及標識同一對話中請求消息的先后順序Via記錄請求消息路徑，用于響應(yīng)消息路由Max-Forwards限制消息最大轉(zhuǎn)發(fā)次數(shù)其他SIP頭域的可選性參見附錄A，為減少網(wǎng)絡(luò)資源開銷，應(yīng)盡量避免在SIP消息中攜帶不必要的頭域。4.3. SIP消息體SIP消息體是SIP消息的凈荷部分，SIP消息體與最后一個SIP消息頭域之間以一個CRLF隔開。SIP消息體格式與SIP協(xié)議本身無關(guān)，SIP消息攜帶不同協(xié)議的消息體可以用于完成不同的功能，常用的有：SIP攜帶SDP，用于媒體協(xié)商；SIP攜帶XML，用于攜帶格式化的信息，如訂閱事件通知；SIP攜帶CPIM，用于即時消息。SIP消息體的格式通過Content-Type頭的MIME格式指示。SIP消息體具體參見第8節(jié)。SIP消息體舉例：圖4-4 SIP消息體式示例4.4. SIP協(xié)議中的URI4.4.1. SIP URISIP URI的格式遵從RFC 2396中的規(guī)定，其統(tǒng)一形式為：sip:user:passwordhost:port;uri-parameters?headersSIP URI以”sip:”開頭，其后各部分內(nèi)容為：l userSIP URI的用戶部分標識了用戶身份信息。該部分可以是一個字符串，也可以是一個E.164電話號碼。當SIP URI指向的目的地沒有用戶身份或host部分就是SIP URI所要指向的目的地時，SIP URI中不包含user、password部分，以及“”字符。l password當訪問SIP URI指向的資源需要口令時，可以將口令放在password部分進行傳送。在一些情況下SIP消息會以明文傳送，這樣會泄露口令信息。注：CM-IMS中暫不采用password部分l hostSIP URI指向的資源的歸屬域，該部分可以是一個FQDN或者是一個IPv4/IPv6地址。l port接收本條SIP消息的端口號。port參數(shù)為可選參數(shù)，本系列規(guī)范未對其使用方式進行規(guī)定。l uri-parametersSIP URI的其他參數(shù)。統(tǒng)一格式為：parameter-name "=" parameter-value不同SIP URI參數(shù)之間用分號（;）隔開,可以根據(jù)實際需要定義參數(shù)，常用的參數(shù)有：n transport：表示向該URI發(fā)送消息需要使用的傳輸層協(xié)議，可取值為UDP、TCP、SCTPn user：用于區(qū)分URI中user部分的類型，可以取值為：phone、dialstringn lr：表示采取松散路由n orig：用于標識主叫流程n ODI：用于匹配B2BUA兩側(cè)的對話n replaces：當URI出現(xiàn)在REFER消息的refer-to頭域時，replaces參數(shù)攜帶需要替換的對話標識l headers當要求基于本條SIP消息生成另一條SIP消息包含某些頭域及相應(yīng)取值時，可以通過SIP URI中的headers部分進行指示。headers參數(shù)為可選參數(shù)，本系列規(guī)范未對其使用方式進行規(guī)定。SIP URI舉例：sip:+861052400481sip:+8613910001234_ssip:4.4.2. SIPS URISIPS URI以”sips:”開頭，其余格式及各組成部分與SIP URI相同，與SIP URI的區(qū)別在于SIPS URI要求SIP消息在傳輸過程中采用安全的傳輸機制。4.4.3. TEL URITEL URI格式參照RFC 3966中的規(guī)定。TEL URI舉例：tel:+861052400481tel:52400481;phone-context=+86104.4.4. SIP URI與TEL URI的轉(zhuǎn)換l TEL URI轉(zhuǎn)換為SIP URI將TEL URI中除”tel:”以外的部分全部作為SIP URI的user部分，然后根據(jù)TEL URI內(nèi)容或本地策略生成SIP URI的host部分。需要注意一點是TEL URI中的參數(shù)名不區(qū)分大小寫，而SIP URI中的參數(shù)名區(qū)分大小寫，因此從TEL URI轉(zhuǎn)換為SIP URI時，所有參數(shù)名必須轉(zhuǎn)換為小寫形式。當從TEL URI轉(zhuǎn)換為SIP URI時，SIP URI 中應(yīng)包含user=phone參數(shù)。5. SIP請求消息 5.1. SIP請求消息格式請求消息的起始行為請求行。請求行的格式如下所示，由方法名（Method）、請求URL（Request-URI）和協(xié)議版本（SIP-Version）組成，各部分之間均用一個空格字符進行分隔。除此之外，請求行必須用回車換行（CRLF）字符表示行終結(jié)。Request-Line = Method Request-URI SIP-Version CRLF1） 方法名：本部分共定義了14 個方法，如表5-1所示。 表5-1 SIP方法列表方法名應(yīng)用場景INVITE用于會話的建立和會話屬性的修改。ACK用于對INVITE消息最終響應(yīng)的確認。BYE用于會話的釋放。CANCEL用于取消之前發(fā)送的SIP請求消息。建議CANCEL消息僅用于取消INVITE請求。REGISTER用于注冊和注銷。SUBSCRIBE用于對事件的訂閱。PUBLISH用于發(fā)布網(wǎng)元狀態(tài)。NOTIFY用于對訂閱事件的通知。UPDATE用于會話媒體修改和會話刷新。MESSAGE用于即時消息。PRACK用于對臨時響應(yīng)消息的確認。PRACK消息及其成功響應(yīng)可攜帶SDP進行媒體協(xié)商，通常用于與CS域互通。INFO用于在會話內(nèi)傳送會話相關(guān)的控制信息。REFER用于通知第三方對會話進行控制。OPTIONS用于服務(wù)器能力查詢。也可用作心跳消息。2） Request URI：指示被邀請用戶的當前地址，Request URI中不允許出現(xiàn)空格或其他控制字符且不能包含于“<>”符號之內(nèi)，URI可以是sip、sips或tel格式。3） 版本號：用于定義協(xié)議的當前版本號，本協(xié)議的版本號為SIP/2.0。5.2. INVITEINVITE請求消息用于會話的創(chuàng)建和修改。如基本音視頻會話、會議等。在會話建立開始時，主叫UA發(fā)送INVITE消息（初始INVITE），請求行中的Request URI表示被叫URI，通常情況下初始INVITE消息中會攜帶主叫SDP信息。收到INVITE消息后，在一定時間內(nèi)未發(fā)送最終響應(yīng)或其他臨時響應(yīng)則回送100響應(yīng)表示已經(jīng)接收到請求消息，正在對其進行處理。在會話進行過程中，INVITE消息（Re-INVITE）可以用于會話屬性的修改，這種情況下的INVITE消息必須與初始INVITE消息處于同一會話當中。INVITE消息關(guān)鍵頭域如下表所示： 表5-2 INVITE消息關(guān)鍵頭域頭域頭域含義Contact用于INVITE、ACK和REGISTER請求以及成功響應(yīng)、臨時響應(yīng)和重定向響應(yīng)消息，其作用是給出后續(xù)和用戶直接通信的地址。但是，CANCEL請求不能直接發(fā)往該地址，必須沿原請求發(fā)送的路徑前傳。Contact的作用域是全局性的。這就是說，Contact頭域中包含的URI是UA能夠接收請求的。Route1.ODI參數(shù)：S-CSCF到AS的ISC接口中，次頂層的Route頭包含S-CSCF的SIP URI，并且有Original dialog identifier用于關(guān)聯(lián)觸發(fā)前后的請求。ODI參數(shù)由同一個S-CSCF添加和刪除，所以不對其具體格式進行規(guī)范。AS發(fā)起的獨立初始請求不應(yīng)該攜帶本參數(shù)。2.orig參數(shù)：標識主叫流程，在主叫側(cè)網(wǎng)元間傳遞。3.lr參數(shù)：表示松散路由Record-Route用于當前會話后續(xù)消息的路由。是proxy在請求中增加的，用來強制會話中的后續(xù)請求經(jīng)過本proxy。User-AgentUser-Agent頭字段包含有發(fā)起請求的用戶終端的信息。Supported攜帶支持的能力擴展，如：1.100rel值表示支持1XX響應(yīng)的可靠傳輸2.timer值用于Session timer特性，同時填寫Session-Expires頭域。3.in-band-dtmf值用于DTMF收號。4.precondition值表示支持資源預(yù)留機制P-Called-Party-ID被叫IMPU，在被叫S-CSCF到UE之間傳遞。見RFC3455P-Asserted-Identity主叫IMPU。見RFC3325P-Access-Network-Info用戶接入網(wǎng)絡(luò)信息，比如P-Access-Network-Info: IEEE-802.11;"sbc-domain=""ue-ip=10.10.10.69""ue-port=5062"。sbc-domain參數(shù)填寫為接入本地網(wǎng)信息，計費中心用于識別漫游。History-Info用于傳遞會話中前轉(zhuǎn)的歷史信息，包括原被叫地址信息等。其中要有hi-entry屬性，hi-targeted-to-Uri屬性(第一個為最初被叫的地址，第二個為被轉(zhuǎn)到的地址)和reason屬性，index屬性和cause屬性碼。見RFC4244。如：History-Info: <sip:+861088880043;user=phone>index=1History-Info: <sip:+861088880044;user=phone;cause=380>index=1.15.3. ACKACK消息是對INVITE消息的最終響應(yīng)的確認。該消息僅和INVITE消息配套使用。包含Dialog信息、Via頭域中branch參數(shù)為事務(wù)信息。INVITE消息關(guān)鍵頭域如下表所示：表5-3 ACK消息關(guān)鍵頭域頭域頭域含義CSeqACK消息中的CSeq頭中數(shù)字取值必須與相應(yīng)的INVITE消息一致。 5.4. BYE通話中任何一方掛機，則向?qū)Χ税l(fā)送BYE消息，指示其已掛機，通話結(jié)束。包含Dialog信息、Via頭域中branch參數(shù)為事務(wù)信息。5.5. CANCEL客戶端用來取消尚未完成的請求，請求UAS去終止上一個請求并且對上一個請求產(chǎn)生一個錯誤的響應(yīng)（487）。對于已完成的請求（即已收到最終響應(yīng)的請求）則沒有影響。CANCEL是一個逐跳傳輸?shù)恼埱?，因此CANCEL需要每一個有狀態(tài)的proxy節(jié)點進行處理和響應(yīng)。CANCEL消息關(guān)鍵頭域如下表所示：表5-4 CANCEL消息關(guān)鍵頭域頭域頭域含義CSeqCANCEL消息中的CSeq頭中數(shù)字取值必須與建立會話的初始INVITE消息一致。ViaVia頭中的branch參數(shù)必須與建立會話的初始INVITE消息一致5.6. REGISTERREGISTER消息用于用戶的注冊、注銷以及第三方注冊。REGISTER消息中Request-URI中填寫用戶歸屬域名，此處URI不能包含user部分和”。REGISTER消息的關(guān)鍵消息頭如下表所示：表5-5 REGISTER消息關(guān)鍵頭域頭域頭域含義To被注冊的用戶標識。From在用戶注冊時From頭與To頭內(nèi)容相同；在第三方注冊時，F(xiàn)rom頭內(nèi)容為第三方的URICall-ID重注冊、注銷消息中Call-ID應(yīng)與初始注冊消息中Call-ID相同Expires表示注冊時長；當取值為0時表示注銷Contact用于INVITE、ACK和REGISTER請求以及成功響應(yīng)、呼叫進展響應(yīng)和重定向響應(yīng)消息，其作用是給出后續(xù)和用戶直接通信的地址。但是，CANCEL請求不能直接發(fā)往該地址，必須沿原請求發(fā)送的路徑前傳。Contact的作用域是全局性的。這就是說，Contact頭域中包含的URI是UA能夠接收請求的。REGISTER請求中的Contact指明用戶可達位置。頭域中包含Expires參數(shù)標示超時時長。PathP-CSCF到S-CSCF的REGISTER消息中攜帶，填寫P-CSCF的主機名。AuthorizationUE-CSCF之間傳遞，包含某個終端的鑒權(quán)證書。1.Authentication Scheme 為Digest，表明鑒權(quán)方式2.user name用戶名，即IMPI3.Nonce 只在401響應(yīng)后的REGISTER消息中填寫，值同401響應(yīng)4. Realm歸屬網(wǎng)絡(luò)的域名，表明用戶受保護的域5.Algorithm MD5鑒權(quán)結(jié)果的計算方法（該字段可選）WWW-AuthenticateUE-CSCF之間傳遞，對應(yīng)REGISTER請求的401響應(yīng)消息。1.Authentication Scheme為Digest，表明鑒權(quán)方式2.Realm歸屬網(wǎng)絡(luò)的域名，表明用戶受保護的域3.Algorithm為MD5，鑒權(quán)結(jié)果的計算方法4.Nonce S-CSCF生產(chǎn)的字符串，用以計算ResponseP-Access-Network-Info攜帶用戶接入地信息5.7. SUBSCRIBE對事件的訂閱，訂閱會創(chuàng)建一個對話。呈現(xiàn)業(yè)務(wù)中本消息由AS終結(jié)，AS的業(yè)務(wù)觸發(fā)數(shù)據(jù)中AS的默認處理應(yīng)該為終結(jié)消息。表5-6 SUBSCRIBE消息關(guān)鍵頭域頭域頭域含義Event訂閱事件的類型，如presence表示狀態(tài)呈現(xiàn)，reg表示注冊狀態(tài)Expires非0表示訂閱時長，0表示取消訂閱。5.8. PUBLISH呈現(xiàn)業(yè)務(wù)中用于發(fā)布狀態(tài)。該消息始于終端，由AS終結(jié)，因此該AS的業(yè)務(wù)觸發(fā)數(shù)據(jù)中AS的默認處理應(yīng)該為終結(jié)消息。表5-7 PUBLISH消息關(guān)鍵頭域頭域頭域含義Event發(fā)布事件，presence表示呈現(xiàn)Content-Type消息體MIME格式，取值為application/pidf+xml5.9. NOTIFYNOTIFY消息是通知訂閱者它訂閱的狀態(tài)發(fā)生了變化。消息中Callid、to tag、from tag、Event與SUBSCRIBE創(chuàng)建的會話相同，route頭域路由路徑與SUBSCRIBE創(chuàng)建的Record-Route會話路徑相同。表5-8 NOTIFY消息關(guān)鍵頭域頭域頭域含義Event訂閱事件，如presence表示呈現(xiàn)，reg表示注冊狀態(tài)Content-Type消息體MIME格式，取值為application/pidf+xmlSubscription-State訂閱狀態(tài)，terminated表示結(jié)束，pending表示進行中，active表示訂閱成功。5.10. UPDATEUPDATE消息可以用于會話媒體修改，與INVITE消息的區(qū)別是UPDATE消息既能用于會話最終建立后的媒體修改，也能用于會話最終建立前的媒體修改，而INVITE消息只能用于會話最終建立后的媒體修改。UPDATE消息可以用于會話刷新，在進行會話刷新時，為降低開銷，UPDATE消息通常不攜帶SDP消息體。5.11. MESSAGE通常用于消息類業(yè)務(wù)，如即時消息業(yè)務(wù)。對MESSAGE消息的成功響應(yīng)為200 OK和202 Accepted，如果接收方為消息的最終接收者，則回復200 OK；如果接受方為存儲轉(zhuǎn)發(fā)服務(wù)器，則回復202 Accepted表5-9 MESSAGE消息關(guān)鍵頭域頭域頭域含義User-Agent在進行即時消息業(yè)務(wù)時，該頭域取值為”im”Content-Type消息體MIME格式，取值為message/CPIM5.12. PRACK用于對臨時響應(yīng)消息（18X）的確認。當收到本消息時應(yīng)該發(fā)送200 OK確認響應(yīng)。SIP協(xié)議中定義的18X類臨時響應(yīng)消息的傳輸是不可靠的，如果需要在該響應(yīng)消息中攜帶媒體信息，那么就必須保證該消息能夠可靠的傳輸?shù)綄Χ?。PRACK是對18x臨時響應(yīng)消息的確認請求消息，用于通知對端已經(jīng)收到該臨時響應(yīng)。表5-10 PRACK消息關(guān)鍵頭域頭域頭域含義CseqPRACK與INVITE消息不在同一事務(wù)當中，因此PRACK中Cseq應(yīng)在INVITE消息基礎(chǔ)上遞增5.13. INFO會話內(nèi)的請求通常用于傳送會話相關(guān)的控制信息，用于攜帶MRFC使用的音資源信息、DTMF信息、控制信息等。表5-11 INFO消息關(guān)鍵頭域頭域頭域含義消息體dtmfinfo+xml中攜帶DTMF信息；vxml中攜帶錄音通知信息；xml中攜帶MSML腳本5.14. REFER通常是對話內(nèi)的請求，用于通知對方對第三方進行會話控制。REFER請求也可以在對話外發(fā)送，此時REFER消息會創(chuàng)建一個對話。表5-12 REFER消息關(guān)鍵頭域頭域頭域含義Refer-to用于攜帶轉(zhuǎn)移目的方地址Refer-by用于攜帶業(yè)務(wù)方地址5.15. OPTIONS用于查詢被叫的相關(guān)信息和功能，或者應(yīng)用于網(wǎng)元間的心跳。OPTIONS消息不會創(chuàng)建對話。6. SIP響應(yīng)消息6.1. SIP響應(yīng)消息格式響應(yīng)消息的起始行為狀態(tài)行（Status-Line），狀態(tài)行由協(xié)議版本（SIP-Version）、狀態(tài)碼（Status-Code）和與狀態(tài)碼相關(guān)的文本（Reason-Phase）描述組成，各個部分之間用一個空格字符進行分隔。狀態(tài)行的格式如下所示：Status-Line = SIP-Version Status-Code Reason-Phrase CRLF除狀態(tài)行的尾部可使用回車換行CRLF 字符之外，狀態(tài)行內(nèi)不允許出現(xiàn)CRLF 字符。1） 狀態(tài)碼：該參數(shù)為一