中國電信cdma2000核心網(wǎng)絡(luò)接口協(xié)議技術(shù)規(guī)范-SIP-I協(xié)議

中國電信cdma2000核心網(wǎng)絡(luò)接口協(xié)議技術(shù)規(guī)范-SIP-I協(xié)議中國電信cdma2000核心網(wǎng)絡(luò)接口協(xié)議技術(shù)規(guī)范―SIP-I協(xié)議規(guī)范PAGEPAGE4保密等級：公開發(fā)放中國電信集團公司發(fā)布2008-07-14實施2008-07-14發(fā)布中國電信cdma2000核心網(wǎng)絡(luò)接口協(xié)議技術(shù)規(guī)范―SIP-I協(xié)議規(guī)范TechnicalSpecificationof保密等級：公開發(fā)放中國電信集團公司發(fā)布2008-07-14實施2008-07-14發(fā)布中國電信cdma2000核心網(wǎng)絡(luò)接口協(xié)議技術(shù)規(guī)范―SIP-I協(xié)議規(guī)范TechnicalSpecificationofInterface&Protocolincdma2000CoreNetworkofChinaTelecom－SIP-I（V1.0）Q/CT 2032-2008中國電信集團公司技術(shù)標(biāo)準目錄前言 41 范圍 12 引用標(biāo)準 13 術(shù)語說明 24 ZZ接口涉及的網(wǎng)元及協(xié)議說明 35 通用要求 36 MSCe對SIP/SDP協(xié)議能力集的適配要求 47 音資源適配要求 47.1 總則要求 47.2 SIP消息對音資源行為的適配 57.3 提供EalryMedia實體的行為要求 67.4 接收Earlymedia實體的行為要求 67.4.1 基本信令適配 67.4.2 特殊約定說明 78 編碼協(xié)商說明 79 LMSD網(wǎng)絡(luò)對SIP協(xié)議重疊發(fā)碼的要求 710 會話建立后的周期更新（呼叫心跳） 711 MSCe基本信令行為說明 811.1 主叫側(cè)MSCe 811.2 被叫側(cè)網(wǎng)絡(luò)MSCe 912 切換行為說明 1012.1 總體說明 1012.2 定時器描述 1012.2.1 目標(biāo)局 1012.2.2 主控局 1012.3 切換過程實體行為說明 1012.3.1 主控局 1012.3.2 目標(biāo)局 1113 LMSD網(wǎng)絡(luò)中的路由心跳功能 1113.1 概述 1113.2 設(shè)備狀態(tài) 1213.2.1 State1狀態(tài) 1213.2.2 State2狀態(tài) 1313.3 消息格式 1314 其他 1314.1 二次撥號信息傳送 1314.2 SDP中Ptime參數(shù)約定說明 13附錄A：SIP幾個主要Method及參數(shù)要求（規(guī)范性附錄） 15A.1INVITE消息 15A.2ACK 15A.3BYE 16A.4CANCEL 16A.5OPTIONS 16A.6INFO 17A.7PRACK 17附錄BRFC3261：SessionInitiationProtocol（規(guī)范性附錄） 18附錄CRFC3262：ReliabilityofProvisionalResponsesintheSessionInitiationProtocol（規(guī)范性附錄） 29附錄DRFC3264：AnOffer/AnswerModelwiththeSessionDescriptionProtocol(SDP)[RFC3264]（規(guī)范性附錄） 30附錄ERFC2976：TheSIPINFOMethod（規(guī)范性附錄） 32附錄FRFC3311TheSessionInitiationProtocol(SIP)UPDATEMethod 33附錄GLMSD網(wǎng)絡(luò)中SIP重疊發(fā)碼程序技術(shù)實現(xiàn)（資料性附錄） 34附錄H信令流程示例（規(guī)范性附錄） 35H.1基本呼叫 35H.1.1成功呼叫建立 35H.1.2正常呼叫釋放 41H.1.3失敗呼叫 42H.2補充業(yè)務(wù) 45H.2.1呼叫前轉(zhuǎn)（無條件前轉(zhuǎn)） 45H.2.2呼叫前轉(zhuǎn)（無應(yīng)答前轉(zhuǎn)） 46H.2.3呼叫前轉(zhuǎn)（尋呼無響應(yīng)前轉(zhuǎn)） 46H.2.4呼叫前轉(zhuǎn)（遇忙前轉(zhuǎn)） 47H.2.5主叫號碼顯示 48H.2.6主叫號碼顯示限制 49H.3切換流程 50H.4會話建立后，呼叫周期更新 51H.5定時器 52H.5.1INVITE消息定時器 52H.5.2200消息的定時器（等待ACK消息） 53

前言本標(biāo)準是中國電信CDMA核心網(wǎng)絡(luò)接口協(xié)議系列技術(shù)標(biāo)準之一，該系列標(biāo)準的結(jié)構(gòu)及名稱預(yù)計如下：中國電信cdma2000核心網(wǎng)絡(luò)接口協(xié)議技術(shù)規(guī)范―1xA接口協(xié)議規(guī)范中國電信cdma2000核心網(wǎng)絡(luò)接口協(xié)議技術(shù)規(guī)范―移動應(yīng)用部分（MAP）中國電信cdma2000核心網(wǎng)絡(luò)接口協(xié)議技術(shù)規(guī)范―分組域協(xié)議中國電信cdma2000核心網(wǎng)絡(luò)接口協(xié)議技術(shù)規(guī)范―SIP-I協(xié)議規(guī)范中國電信cdma2000核心網(wǎng)絡(luò)接口協(xié)議技術(shù)規(guī)范―MNPGNPI接口協(xié)議規(guī)范中國電信cdma2000核心網(wǎng)絡(luò)接口協(xié)議技術(shù)規(guī)范―MNPGSPI接口協(xié)議規(guī)范中國電信cdma2000核心網(wǎng)絡(luò)接口協(xié)議技術(shù)規(guī)范―OMC北向接口協(xié)議規(guī)范中國電信cdma2000HRPDRev.A設(shè)備總體技術(shù)規(guī)范—A接口技術(shù)分冊本標(biāo)準是接口協(xié)議技術(shù)規(guī)范的第4部分，主要定義了cdma2000LMSD網(wǎng)絡(luò)ZZ接口上各SIP實體的基本行為及通用規(guī)則。本標(biāo)準主要依據(jù)《中國電信軟交換網(wǎng)絡(luò)SIP一協(xié)議規(guī)范—通用要求（2007版暫行）》編制而成。本標(biāo)準的附錄A、B、C、D、E、F、H為規(guī)范性附錄。本標(biāo)準的附錄G為資料性附錄。本標(biāo)準由中國電信集團公司提出并歸口。本標(biāo)準起草單位：中國電信股份有限公司廣州研究院本標(biāo)準主要起草人：張鵬生中國電信cdma2000核心網(wǎng)絡(luò)接口協(xié)議技術(shù)規(guī)范―SIP-I協(xié)議規(guī)范PagePAGE17ofNUMPAGES57范圍本規(guī)范適用于CDMA2000LMSD網(wǎng)絡(luò)。本規(guī)范定義了LMSD網(wǎng)絡(luò)中ZZ接口對SIP協(xié)議的通用要求。LMSD與他網(wǎng)（如軟交換網(wǎng)絡(luò)、PSTN網(wǎng)絡(luò)等）的互通要求，參見各互通技術(shù)規(guī)范。本規(guī)范當(dāng)前只考慮協(xié)議對語音業(yè)務(wù)的支持。附錄H示例了基本業(yè)務(wù)流程和幾個典型補充業(yè)務(wù)流程。引用標(biāo)準下列標(biāo)準所包含的條文，通過在本技術(shù)要求中引用而構(gòu)成本技術(shù)要求的條文。出版時，所示版本均為有效。所有標(biāo)準都會被修訂，使用本技術(shù)要求的各方應(yīng)探討使用下列標(biāo)準最新版本的可能性。YDN038-1997“國內(nèi)NO.7信令方式技術(shù)規(guī)范綜合業(yè)務(wù)數(shù)字網(wǎng)用戶部分（ISUP）”YDN038.1-1999“國內(nèi)NO.7信令方式技術(shù)規(guī)范綜合業(yè)務(wù)數(shù)字網(wǎng)用戶部分（ISUP）（補充修改件）”《中國電信ISUP信令流程和消息參數(shù)設(shè)置的相關(guān)要求》（2005年）《中國電信軟交換網(wǎng)絡(luò)SIP協(xié)議規(guī)范—通用要求（2007版暫行）》3GPP2X.S0025-0V1.0“LegacyMSDomainSetup2ITU-TQ.1912.5“SIP“InterworkingBetweenSessionInitiationProtocol(SIP)andBearerIndependentCallControlProtocolorISDNUserPart”IETFRFC2046“MultipurposeInternetMailExtensions(MIME)PartTwo:MediaTypes”IETFRFC2327“SDP:SessionDescriptionProtocol”IETFRFC2833“RTPPayloadforDTMFDigits,TelephonyTonesandTelephonySignals”IETFRFC2976“TheSIPINFOMethod”IETFRFC3204“MIMEmediatypesforISUPandQSIGObjects”IETFRFC3261“SIP:SessionInitiationProtocol”IETFRFC3262“ReliabilityofProvisionalResponsesintheSessionInitiationProtocol(SIP)”IETFRFC3264“AnOffer/AnswerModelwiththeSessionDescriptionProtocol(SDP)”IETFRFC3311“TheSessionInitiationProtocol(SIP)UPDATEMethod”IETFRFC3323“APrivacyMechanismfortheSessionInitiationProtocol(SIP)”IETFRFC3325“PrivateExtensionstotheSessionInitiationProtocol(SIP)forAssertedIdentitywithinTrustedNetworks”IETFRFC3326“TheReasonHeaderFieldfortheSessionInitiationProtocol(SIP)”IETFRFC4028“SessionTimersintheSessionInitiationProtocol(SIP)”RFC5009“PrivateHeader(P-Header)ExtensiontotheSessionInitiationProtocol(SIP)forAuthorizationofEarlyMedia術(shù)語說明在本規(guī)范中，以下術(shù)語具有特定意義：SIP-I：特指封裝ISUP信息的SIP消息。SIP消息封裝ISUP信息的方法參照《中國電信軟交換網(wǎng)絡(luò)SIP協(xié)議規(guī)范—通用要求（2007版暫行）》附錄F的要求。前向網(wǎng)絡(luò)/實體：相對本節(jié)點而言，前向網(wǎng)絡(luò)/實體特指位于本節(jié)點前一跳的實體。在信令方向上，當(dāng)前節(jié)點接受來之該實體發(fā)送的初始請求消息。后向網(wǎng)絡(luò)/實體：相對本節(jié)點而言，后向網(wǎng)絡(luò)/實體特指位于本節(jié)點下一跳的實體。在信令方向上，當(dāng)前節(jié)點向該實體發(fā)送初始請求消息LMSD（LegacyMobileStationDomain）：特指cdma2000體系中的傳統(tǒng)電路域。MSCe（MobileSwicthingCenteremmulation）：LMSD網(wǎng)絡(luò)中的移動交換中心，負責(zé)SIP信令、MAP等信令的處理。MGW（MediaGateway）：媒體網(wǎng)關(guān)設(shè)備，負責(zé)媒體流的處理。GMSCe（GatewayMSCe）：完成與非LMSD網(wǎng)絡(luò)互通時的MSCe設(shè)備。TMSCe（TandemMSCe）：匯接層面的MSCe設(shè)備。AnchorNetwork：在切換程序中，希望將呼叫切換出的網(wǎng)絡(luò)。本規(guī)范稱之為主控網(wǎng)絡(luò)。TargetNetwork：在切換程序中，負責(zé)接收切換請求的網(wǎng)絡(luò)。本規(guī)范稱之為目標(biāo)網(wǎng)絡(luò)。Earlymedia：被叫用戶摘機前，主叫側(cè)UA設(shè)備收到的語音資源，包括（后向提供的）表征振鈴的資源、表征尋址失敗的音資源（例如，被叫用戶忙等）。Regularmedia：被叫摘機后，主被叫用戶建立的真正音資源。ZZ接口涉及的網(wǎng)元及協(xié)議說明圖STYLEREF1\s2SEQ圖表\*ARABIC\s11：SIP協(xié)議在ZZ接口上的應(yīng)用注：圖2-1中的設(shè)備為邏輯設(shè)備。圖2-1只羅列了與ZZ接口相關(guān)的設(shè)備。ZZ接口適用于MSCe/TMSCEe/GMSCe之間。本規(guī)范要求ZZ接口采用SIP-I協(xié)議。SIP-I的定義及相關(guān)要求參見1.3部分的說明。如無特殊說明，本規(guī)范所述MSCe設(shè)備對SIP協(xié)議的適配將適用于所有類型的MSCe，包括TMSCe和GMSCe。注：TMSCe是否存在，或是否攜帶MGW，需參考具體網(wǎng)絡(luò)部署方案。GMSC是否需要攜帶MGW需參考具體網(wǎng)絡(luò)部署方案。通用要求LMSD網(wǎng)絡(luò)暫不考慮IETFRFC3312所定義的SIPPrecondition特性如MSCe收到的消息中存在的參數(shù)（包括頭部消息和消息體中的內(nèi)容）滿足語法規(guī)則，但MSCe不能識別時，MSCe不得由于該參數(shù)的存在而影響對于基本呼叫的正常處理。根據(jù)本規(guī)范第2章節(jié)的要求，MSCe之間將采用SIP-I協(xié)議進行通信。LMSD網(wǎng)內(nèi)的PSTN/ISDN補充業(yè)務(wù)信息將盡量通過SIP-I消息中的ISUP信息攜帶。當(dāng)MSCe收到SIP-I消息時，如其中的SIP頭部信息與ISUP信息出現(xiàn)沖突，MSCe應(yīng)以SIP頭部信息作為業(yè)務(wù)信息基準。被叫側(cè)MSCe在尋呼用戶時，只有當(dāng)空口資源已指配完成后，才向主叫側(cè)網(wǎng)絡(luò)發(fā)送振鈴消息（180消息）。LMSD用戶做被叫時，該用戶所在的MSCe+MGW將向主叫側(cè)網(wǎng)絡(luò)提供回鈴音資源（注，此處未考慮增值業(yè)務(wù)提供語音資源的情況）。相關(guān)要求參照本規(guī)范第5章節(jié)的說明。LMSD用戶做主叫時，該用戶所在的MSCe+MGW根據(jù)SIP消息的相關(guān)約定決定是否本地提供回鈴音。相關(guān)要求參照本規(guī)范第5章節(jié)的說明。MSCe對SIP/SDP協(xié)議能力集的適配要求根據(jù)業(yè)務(wù)或呼叫邏輯的需要，MSCe可能啟動UA、Proxy、B2BUA等功能。其對SIP能力集的要求應(yīng)滿足表4-1的要求。表STYLEREF1\s4SEQ圖表\*ARABIC\s11：各實體支持的SIP及相關(guān)能力集SIP能力集MSCe（包括GMSCe、TMSCe等）RFC2327必須RFC2046必須RFC2976必須RFC3261必須RFC3262必須RFC3264必須RFC3311必須RFC3325必須RFC3326必須RFC4028必須ITU-TQ.1912.5必須RFC5009條件支持（注1）注1：當(dāng)業(yè)務(wù)或網(wǎng)絡(luò)需要該實體支持本能力時，條件支持將轉(zhuǎn)變?yōu)椤氨仨殹?。?：本規(guī)范不約束MSCe具體采用何種邏輯實體實現(xiàn)業(yè)務(wù)。音資源適配要求總則要求LMSD網(wǎng)絡(luò)中的媒體流提供存在以下約定：底層媒體流的實際內(nèi)容應(yīng)與信令層面協(xié)商的一致。即，只有在信令協(xié)商完成的情況下，才能根據(jù)協(xié)商內(nèi)容發(fā)送媒體流”當(dāng)LMSD用戶做被叫時，該用戶所處網(wǎng)絡(luò)向主叫側(cè)網(wǎng)絡(luò)提供回鈴音資源當(dāng)LMSD用戶做主叫時，該用戶所在的MSCe+MGW根據(jù)SIP信令的指示，決定是否由本地提供回鈴音資源。SIP消息對音資源行為的適配當(dāng)表征被叫用戶處于振鈴狀態(tài)時，后向網(wǎng)絡(luò)向主叫側(cè)網(wǎng)絡(luò)發(fā)送180消息。并且，如之前未與前向網(wǎng)絡(luò)完成Offer/Answer，則本180消息中應(yīng)攜帶SDP信息（SDP信息為提供回鈴音資源的媒體設(shè)備信息）。如之前已完成Offer/Answer，則本180消息中無須攜帶SDP信息圖STYLEREF1\s5SEQ圖表\*ARABIC\s11：被叫側(cè)網(wǎng)絡(luò)向前向網(wǎng)絡(luò)提示被叫用戶處于振鈴狀態(tài)當(dāng)后向網(wǎng)絡(luò)（相對于接收音資源的設(shè)備）提供除振鈴音以外的其它資源時，例如表示呼叫處于失敗狀態(tài)的資源，則發(fā)送183消息。如之前該節(jié)點未與前向網(wǎng)絡(luò)完成Offer/Answer，則本183消息中應(yīng)攜帶SDP信息（（SDP信息為提供本次音資源的媒體設(shè)備信息）圖STYLEREF1\s5SEQ圖表\*ARABIC\s12：被叫側(cè)網(wǎng)絡(luò)向前向網(wǎng)絡(luò)提供其他（非振鈴行為）音資源網(wǎng)絡(luò)中提供音資源的某一實體，當(dāng)確認本實體需對先前完成的Offer/Answer進行修改時（未應(yīng)答之前），則向前向網(wǎng)絡(luò)發(fā)送UPDATE消息完成協(xié)商修改。網(wǎng)絡(luò)中接收音資源的實體，在被叫未應(yīng)答之前，如收到UPDATE消息，則應(yīng)根據(jù)Offer/Answer的要求進行準確響應(yīng)。提供EalryMedia實體的行為要求注：EarlyMedia的定義參照1.3章節(jié)的說明。如網(wǎng)絡(luò)中的某一實體向“前向SIP實體”提供音資源，其行為應(yīng)滿足5.2章節(jié)第1）、2）及3）（如存在）的要求。接收Earlymedia實體的行為要求基本信令適配如主叫側(cè)MSCe從后向網(wǎng)絡(luò)收到的第一個消息為180消息，且不帶SDP，則MSCe控制本地MGW向主叫用戶提供回鈴音，直到滿足以下場景的條件：場景1：收到第一個“帶有SDP的18*消息”。或，場景2：收到被叫應(yīng)答消息?；颍瑘鼍?：收到失敗消息。圖STYLEREF1\s5SEQ圖表\*ARABIC\s13：主叫側(cè)MSCe初始提供回鈴音如主叫側(cè)MSCe從后向網(wǎng)絡(luò)收到的第一個消息為18*消息，且?guī)в蠸DP，則MSCe只需告知MGW導(dǎo)通與后向網(wǎng)絡(luò)的媒體通道即可，無需提供回鈴音。圖STYLEREF1\s5SEQ圖表\*ARABIC\s14：主叫側(cè)MSCe確認被叫側(cè)網(wǎng)絡(luò)提供音資源特殊約定說明當(dāng)設(shè)備由“EarlyMedia”狀態(tài)轉(zhuǎn)為“RegularMedia”狀態(tài)的過程中，為保證業(yè)務(wù)的正常進行，要求“接收EarlyMedia的實體”通過同一IP地址+端口接收EarlyMedia和RegularMedia。注：EalryMedia與RegularMedia的定義參照1.3部分的說明。當(dāng)通話轉(zhuǎn)為Regularmedia狀態(tài)后，實體可根據(jù)業(yè)務(wù)需要進行端口的變化。編碼協(xié)商說明MSCe之間通過RFC3264所定義的Offer/Answer協(xié)商程序完成MGW之間的媒體編碼選擇。本規(guī)范對RFC3264的遵循請參照附錄D相關(guān)之規(guī)定。同時，本規(guī)范強調(diào)：建議Answer方盡量順從Offer方提供的各編解碼的優(yōu)先排列順序編碼選擇的最終決定權(quán)在于Answer方。Answer方發(fā)送的SDP信息中的編碼能力集的第一個編碼為當(dāng)前協(xié)商所選定的編碼。（注1）注1：如SDP中存在多個m行，且每個m行都協(xié)商成功，則每個m行中的第一個編碼為該m行所代表的業(yè)務(wù)選擇的編碼。當(dāng)存在多個有效的m=audio行時，要求選擇“第一個有效的audio行的第一個語音編碼”作為當(dāng)前語音業(yè)務(wù)所選擇的編碼。對于語音業(yè)務(wù)，不建議Offer方發(fā)送的SDP中帶有多個m=audio行LMSD網(wǎng)絡(luò)對SIP協(xié)議重疊發(fā)碼的要求LMSD網(wǎng)內(nèi)用戶發(fā)起的呼叫，無須考慮SIP協(xié)議重疊發(fā)碼程序的要求。對于固網(wǎng)用戶發(fā)起的呼叫，建議由互通單元（完成固網(wǎng)與LMSD網(wǎng)絡(luò)互通的實體）或互通單元之前的設(shè)備終結(jié)固定網(wǎng)絡(luò)的重疊發(fā)碼程序?；ネ▎卧獙⑼ㄟ^一次發(fā)碼（Enbloc）的形式向LMSD網(wǎng)絡(luò)中的MSCe設(shè)備發(fā)送初始請求。本規(guī)范強調(diào)，只有當(dāng)2）所描述的建議在實際網(wǎng)絡(luò)部署中不可實施時，LMSD網(wǎng)絡(luò)才考慮SIP協(xié)議重疊發(fā)碼的實現(xiàn)（局間采用SIP-I）。其實現(xiàn)要求參照附錄G的描述。會話建立后的周期更新（呼叫心跳）當(dāng)LMSD網(wǎng)絡(luò)中的UA設(shè)備支持會話周期更新時，要求UA行為需滿足RFC4028所定義的SessionTimer行為，并通過UPDATE（noSDP）消息對已建立的會話進行周期更新。本規(guī)范不建議UA設(shè)備通過發(fā)送re-INVITE進行會話的周期更新，但接收方UA設(shè)備（非主動發(fā)起會話更新請求的UA方）應(yīng)能同時支持他網(wǎng)（如其他運營商網(wǎng)絡(luò)）通過re-INVITE方式發(fā)起的會話更新行為。針對會話更新的定時器不應(yīng)設(shè)置過短（不小于90秒），30分鐘為系統(tǒng)默認時間，并可根據(jù)實際運營情況進行靈活調(diào)節(jié)。MSCe基本信令行為說明注：本章節(jié)只關(guān)注ZZ接口上各類MSCe的行為，MSCe與其它實體的交互，例如與媒體網(wǎng)關(guān)、基站、HLR等設(shè)備的交互，不在本規(guī)范的考慮范圍之內(nèi)。主叫側(cè)MSCe主叫側(cè)MSCe收到用戶呼叫請求時，確認需向下一跳SIP實體發(fā)送初始請求時，將生成初始INVITE消息然后發(fā)往下一跳，同時跳轉(zhuǎn)至步驟2）或3）或4）或5）。該消息中至少包括以下信息，攜帶SDP信息。SDP信息描述該MSCe所控制的媒體網(wǎng)關(guān)的相關(guān)信息。包括IP地址+端口、媒體編碼信息等消息中封裝基本的IAM信息（ISUP信息的封裝規(guī)則參照《中國電信軟交換網(wǎng)絡(luò)SIP協(xié)議規(guī)范—通用要求（2007版暫行）》附錄F的要求（以下涉及到封裝ISUP信息都有此要求）。此階段如涉及PSTN/ISDN補充業(yè)務(wù)，IAM信息中需體現(xiàn)。如收到的第一個消息為180消息（100Trying消息忽略，以下相同），且其中無SDP信息。MSCe將控制本地MGW向主叫用戶提供回鈴音。同時，跳轉(zhuǎn)至步驟6）MSCe需確認是否需要把其中封裝的ACM的相關(guān)信息傳送到主叫用戶側(cè)（以下對于接收到的ISUP信息的處理相同，不再贅述）。如收到的第一個消息為180消息，且?guī)в蠸DP信息。MSCe確認被叫側(cè)網(wǎng)絡(luò)提供回鈴音，MSCe通知MGW導(dǎo)通媒體通道。同時，跳轉(zhuǎn)至步驟7）或步驟8）或步驟9）。如收到的第一個消息為183消息，且?guī)в蠸DP信息。MSCe確認被叫側(cè)網(wǎng)絡(luò)提供音資源（除振鈴音資源外），MSCe通知MGW導(dǎo)通媒體通道。同時轉(zhuǎn)跳至步驟7）或步驟8）或步驟9）（可能會出現(xiàn)）或步驟12。如收到的第一個消息為183消息，且其中無SDP信息（無論是否帶有ISUP信息），MSCe+MGW不會向主叫用戶提供回鈴音或其他音資源。如后續(xù)收到的18*消息中帶有SDP信息，則MSCe通知MGW停止本地回鈴音的提供，同時要求MGW導(dǎo)通媒體通道，主叫用戶接收被叫側(cè)網(wǎng)絡(luò)提供的音資源。同時，跳轉(zhuǎn)至步驟7）或步驟8）或步驟9）完成Offer/Answer后，如在被叫應(yīng)答之前，收到帶有SDP的UPDATE消息（1個或多個）：則MSCe回送200消息（UPDATE）。要求其中的SDP信息應(yīng)與初始INVITE消息中的IP地址+端口號（SDP信息中）保持一致。跳轉(zhuǎn)至步驟8）或步驟9）如收到失敗消息，則釋放相應(yīng)資源。根據(jù)本地策略決定是否向主叫用戶提供相關(guān)的失敗音資源。收到被叫用戶應(yīng)答的200消息（INVITE），如MSCe之前控制MGW提供回鈴音，則應(yīng)停止。主、被叫用戶進入通話狀態(tài)。通話建立后，根據(jù)200（INVITE）消息中的約定，啟動會話更新功能。相關(guān)要求參照本規(guī)范第8部分的要求。通話建立后，如需發(fā)送拆線消息，則發(fā)送BYE消息（封裝REL信息），該消息中可選攜帶Reason頭域；或，針對拆線消息回送針對BYE消息的200響應(yīng)（封裝RLC信息）。對于早釋情況（收到被叫應(yīng)答消息之前，主叫側(cè)拆線），如未建立EarlyDialog，則MSCe發(fā)送CANCEL消息（無需封裝ISUP信息）；如EarlyDialog已建立，則可發(fā)送CANCEL消息，也可發(fā)送BYE消息。被叫側(cè)網(wǎng)絡(luò)MSCe收到初始INVITE消息后，尋呼用戶。當(dāng)為被叫用戶指配好空口資源后，MSCe發(fā)送180消息。MSCe控制MGW向主叫側(cè)網(wǎng)絡(luò)提供回鈴音資源。該消息中至少包括以下信息帶有SDP信息。SDP信息描述本MSCe所控制的媒體網(wǎng)關(guān)的相關(guān)信息。包括IP地址+端口、媒體編碼信息等消息中封裝基本的ACM信息（ISUP信息的封裝規(guī)則參照《中國電信軟交換網(wǎng)絡(luò)SIP協(xié)議規(guī)范—通用要求（2007版暫行）》附錄F的要求）。此階段如涉及PSTN/ISDN補充業(yè)務(wù)，ACM信息中需體現(xiàn)。（以下涉及到封裝ISUP信息都有此要求）被叫用戶摘機。MSCe發(fā)送200消息（INVITE）。同時，不帶SDP信息。消息中封裝ANM信息。通話建立后，根據(jù)200（INVITE）消息中的約定，啟動會話更新程序。相關(guān)要求參照本規(guī)范第8部分的要求。通話建立后，如需發(fā)送拆線消息，則發(fā)送BYE消息（封裝REL信息）；或，針對拆線消息回送響應(yīng)（封裝RLC信息）。當(dāng)被叫側(cè)網(wǎng)絡(luò)向主叫側(cè)提供失敗的語音資源時（未應(yīng)答之前），被叫側(cè)MSCe發(fā)送183消息，且?guī)в蠸DP信息。SDP信息描述本MSCe所控制的媒體網(wǎng)關(guān)的相關(guān)信息。包括IP地址+端口、媒體編碼信息等。封裝ACM信息，且必須帶有BCI參數(shù)、OBCI參數(shù)、Reason參數(shù)。其中BCI參數(shù)為“無指示”；OBCI中“帶內(nèi)信息表示語”為“帶內(nèi)信息或適當(dāng)?shù)拇a型目前可用”；Reason參數(shù)根據(jù)當(dāng)前失敗的原因進行取值。切換行為說明總體說明MSCe之間的切換需要同時完成兩個層面的信令協(xié)商，通過MAP和SIP協(xié)作來完成。關(guān)聯(lián)MAP和SIP請求消息通過vCIC，vCIC用于標(biāo)識切換時的IP承載，切換時的MAP消息和SIP消息使用同樣的vCIC值。vCIC在MAPFACDIR2請求中，以IMSCCID格式編碼。在SIPINVITE請求中，支持如下格式：INVITESIP:vCIC-0xAAAA@hostSIP/2.0其中，AAAA是用十六進制表示的IMSCCID，host為目標(biāo)局MSCe的IP地址。定時器描述目標(biāo)局對于一個成功的切換，目標(biāo)局需收到MAP（FACDIR2）和SIP（INVITE）消息。目標(biāo)局定義兩個定時器來控制切換的過程：MAP層面的MHST和SIP層面的SHST，兩個定時器的缺省值都為6秒。當(dāng)目標(biāo)MSCe收到其中一個請求時，需要啟動定時器等待另一個請求的到來。主控局同樣，主控MSCe在發(fā)送MAP或SIP的請求消息后，需等待兩個請求的響應(yīng)facdir2（MAP）或200OK（SIP），也分別需要定時器HOT和TB’，兩者定時器的缺省值為12秒。注：TB’是在切換程序環(huán)境下，發(fā)送INVTIE后等待200響應(yīng)的定時器，該定時器為應(yīng)用層定時器。與RFC3261所規(guī)定的TB定時器（發(fā)送初始請求，等待臨時響應(yīng)）存在不同。切換過程實體行為說明主控局選擇一個合適的vCIC，在FACDIR2和INVITE中進行編碼；設(shè)置MAP和SIP的定時器，當(dāng)在主控局接收到facdir2或200OK時，表示切換承載和切換設(shè)備建立已經(jīng)成功。使用定時器HOT和TB監(jiān)視這兩個響應(yīng)的返回。當(dāng)接收到MSONCH時，表示切換已經(jīng)成功，使用定時器MHOT監(jiān)視這個消息。目標(biāo)局當(dāng)目標(biāo)局收到具有有效vCIC的FACDIR2和INVITE消息時，啟動切換；如果目標(biāo)局收到的INVITE沒有vCIC，則INVITE將作為SIP的普通呼叫進行處理，不啟動等待FACDIR2的定時器；如果目標(biāo)局接收到FACDIR2沒有vCIC，則FACDIR2作為傳統(tǒng)的MAP請求，不啟動等待INVITE請求的定時器；如果INVITE和FACDIR2消息中都存在有效的vCIC，但是不匹配，則當(dāng)作如同MHST/SHST超時處理；如果SHST超時后，INVITE還未到達，則facdir2將返回錯誤。錯誤碼是“TrunckUnavailable”，解釋為“Requestedbearernotestablished”，其可能的原因是請求的中繼不可用、沒有中繼可用、請求的承載沒有成功建立等。如果MHST超時，F(xiàn)ACDIR2還沒有到達，則返回404NotFound。如果facdir2返回錯誤，作為致命的錯誤。目標(biāo)局已經(jīng)建立的相關(guān)的任何承載和分配的無線資源，都要釋放。主控局在收到響應(yīng)時，也需要釋放相關(guān)的資源。對于切換請求時的SIP錯誤，目標(biāo)局需要觸發(fā)4**響應(yīng)到主控局。當(dāng)收到4**消息時，主控局用正確的ack或錯誤通知發(fā)到MAP。這些錯誤也當(dāng)作致命的錯誤，任何已建立的資源在發(fā)送或接收方都需要被釋放掉。LMSD網(wǎng)絡(luò)中的路由心跳功能概述本章節(jié)定義LMSD網(wǎng)絡(luò)中MSCe之間的路由心跳功能。實體通過該功能可即時獲知指定的對端設(shè)備的存活狀態(tài)，從而決定本端到目的地址的尋址路由關(guān)系。本規(guī)范采用OPTIONS消息作為LMSD網(wǎng)絡(luò)中的路由心跳信息。同時，鑒于OPTIONS的特殊應(yīng)用，應(yīng)用于該場景下的OPTIONS消息，應(yīng)弱化OPTIONS查詢實體能力的功能，OPTIONS消息僅作為連接性信號發(fā)往對端實體。該功能獨立于某一次具體的呼叫，根據(jù)本端數(shù)據(jù)配置周期性的向指定對端發(fā)送。為區(qū)分事務(wù)層的T1、T2定時器，本規(guī)范在應(yīng)用層面定義2個定時器T100、T200用以規(guī)范實體發(fā)送OPTIONS消息的行為。默認情況下，T100=20秒，T200=10秒，同時T100和T200應(yīng)能根據(jù)實際網(wǎng)絡(luò)運營情況進行修改調(diào)整。為避開事務(wù)層原有的重發(fā)機制，作為心跳的OPTIONS消息應(yīng)避開事務(wù)層，由應(yīng)用層直接發(fā)送到傳送層。設(shè)備狀態(tài)遵循本規(guī)范發(fā)送路由心跳信息的各實體包括兩個狀態(tài)：State1和State2。State1:連接狀態(tài)。當(dāng)設(shè)備處于State1時，本端設(shè)備認為到對端設(shè)備的路由處于正常狀態(tài)，后續(xù)呼叫可基于該路由進行。State2:故障狀態(tài)。當(dāng)設(shè)備處于State2時，本端設(shè)備認為到對端設(shè)備的路由處于故障狀態(tài)。本端應(yīng)禁止利用該路由進行尋址。圖11-1為設(shè)備狀態(tài)遷移示意圖。圖STYLEREF1\s11SEQ圖表\*ARABIC\s11：狀態(tài)遷移圖在圖11-1中，T100用于連接狀態(tài)下心跳機制的應(yīng)用層定時器，而T200用于故障狀態(tài)下心跳機制的應(yīng)用層定時器。在State1狀態(tài)時，設(shè)備以T100的周期發(fā)送OPTIONS消息；在State2狀態(tài)時，設(shè)備以T200的周期發(fā)送OPTIONS消息。本規(guī)范強調(diào)：不同周期的OPTIONS消息為非重發(fā)關(guān)系。State1狀態(tài)當(dāng)設(shè)備處于State1時：應(yīng)用層指示傳輸層（避開事務(wù)層）發(fā)送OPTIONS請求，并啟動定時器T100如果定時器T100終了前沒有收到針對當(dāng)前OPTIONS請求的200OK響應(yīng)消息，則計數(shù)器加1；如果收到，計數(shù)器清0；定時器T100終了時，若計數(shù)器的值小于3（要求次數(shù)能夠配置，默認情況下為3），應(yīng)用層指示傳輸層發(fā)送OPTIONS請求，并重新啟動定時器T100；否則轉(zhuǎn)到第4）步。若連續(xù)3次（即計數(shù)器的值為3）發(fā)送的OPTIONS請求消息無響應(yīng)，則遷入State2，Status參數(shù)置為“故障狀態(tài)”。State2狀態(tài)當(dāng)設(shè)備處于State2時：應(yīng)用層指示傳輸層（避開事務(wù)層）發(fā)送OPTIONS請求，并啟動定時器T200定時器T200終了前若收到針對當(dāng)前OPTIONS請求的200OK響應(yīng)，則計數(shù)器加1；若沒有收到，則計數(shù)器清0；定時器T200終了時，若計數(shù)器的值小于3（要求次數(shù)能夠配置，默認情況下為3），應(yīng)用層指示傳輸層發(fā)送OPTIONS請求，并重新啟動定時器T200；否則goto4）。若連續(xù)3次（即計數(shù)器的值為3）發(fā)送的OPTIONS請求消息收到了200OK響應(yīng)，則遷入State1，Status參數(shù)置為“連接狀態(tài)”。消息格式當(dāng)OPTIONS消息作為路由心跳時，消息結(jié)構(gòu)如下所示：OPTIONS<request_uri>Via:To:From:Call-ID:CSeq:1OPTIONSContent-Length:0其他二次撥號信息傳送本規(guī)范暫不考慮在LMSD網(wǎng)絡(luò)內(nèi)通過SIP信令傳送二次撥號信息。要求各UA設(shè)備必須支持RFC2833所定義的內(nèi)容、通過帶內(nèi)方式傳送二次撥號信息。SDP中Ptime參數(shù)約定說明完成Offer/Answer協(xié)商的雙方，需按照對端設(shè)備在SDP中的Ptime參數(shù)約定進行打包。如對端設(shè)備在Offer或Answer中并未指定Ptime值，則本端按照本地策略進行打包。附錄A：SIP幾個主要Method及參數(shù)要求（規(guī)范性附錄）當(dāng)前LMSD網(wǎng)絡(luò)應(yīng)至少支持以下幾個基本的SIPMethod：INVITE、PRACK、BYE、ACK、INFO、OPIONS、UPDATEA.1INVITE消息INVITE頭域必選取值必選頭域Call-idContactCseqFromP-Asserted-identityMax-forwordToViaSupported100rel、timerAllowUPDATE常用可選頭域AcceptAuthorizationContent-lengthContent-typeRecord-route如實體采用Proxy邏輯功能，則在初始的INVITE消息中必須加上Record-route域RouteRequireProxy-AuthorizationProxy-requireP-asserted-identityP-prefered-identityPrivacyA.2ACKACK頭域備注必選參數(shù)Call-idCseqFromMax-forwordToVia常用可選參數(shù)Content-lengthContent-typeRouteA.3BYEBYE頭域備注必選參數(shù)Call-idCseqFromMax-forwordToVia常用可選參數(shù)Content-lengthContent-typeRouteReasonA.4CANCELCANCEL頭域備注必選參數(shù)Call-idCseqFromMax-forwordToVia常用可選ReasonA.5OPTIONSOPTIONS頭域備注必選參數(shù)Call-idCseqFromMax-forwordToVia常用可選參數(shù)AcceptAllowSupportedA.6INFOINFO頭域備注必選參數(shù)Call-idCseqFromMax-forwordToVia常用可選參數(shù)Content-typeContent-lengthRouteA.7PRACKPRACK頭域備注必選參數(shù)Call-idCseqFromMax-forwordToViaRack常用可選參數(shù)Content-typeContent-lengthPagePAGE53ofNUMPAGES57附錄BRFC3261：SessionInitiationProtocol（規(guī)范性附錄）如無特殊說明，本附錄的要求適用于LMSD網(wǎng)絡(luò)中的所有MSCe實體如與RFC3261的要求存在差異，將以“說明欄”的內(nèi)容為實現(xiàn)基準。否則，本附錄遵循RFC3261相關(guān)之規(guī)定。章節(jié)標(biāo)題說明1Introduction2OverviewofSIPFunctionality3Terminology4OverviewofOperation5StructureoftheProtocol6Definitions7SIPMessages7.1Requests7.2Responses7.3HeaderFields7.3.1HeaderFieldFormat7.3.2HeaderFieldClassification7.3.3CompactForm7.4Bodies7.4.1MessageBodyType7.4.2MessageBodyLength7.5FramingSIPmessages8GeneralUserAgentBehavior8.1UACBehavior8.1.1GeneratingtheRequestRequest-URITo當(dāng)采用SIP-URI時，建議格式為userinfo@host，user=phone的方式。無特殊業(yè)務(wù)需求時，網(wǎng)絡(luò)實體不應(yīng)改變初始請求中to域的SIPURI中的userinfo部分的內(nèi)容。From當(dāng)采用SIP-URI時，建議建議格式為userinfo@host，user=phone的方式。無特殊業(yè)務(wù)需求時，網(wǎng)絡(luò)實體不應(yīng)改變初始請求中From域的SIPURI中的userinfo部分的內(nèi)容。Call-IDCseqMax-ForwardsViaContact當(dāng)設(shè)備基于B2BUA邏輯實體實現(xiàn)業(yè)務(wù)時，該實體收到用戶初始請求的Invite消息向下轉(zhuǎn)發(fā)時，Contact地址（username@host）中的“host”部分應(yīng)當(dāng)變成B2BUA的地址（除非有特殊業(yè)務(wù)需求）B2BUA回應(yīng)200消息或18*消息時，如果此時響應(yīng)消息中帶有contact域，此時的contact的地址（username@host）中的

“host”部分應(yīng)當(dāng)變成B2BUA的地址（除非有特殊業(yè)務(wù)需求）SupportedandRequire0AdditionalMessageComponents8.1.2SendingtheRequest8.1.3ProcessingResponsesTransactionLayerErrorsUnrecognizedResponsesViasProcessing3xxResponsesProcessing4xxResponses8.2UASBehavior8.2.1MethodInspection8.2.2HeaderInspectionToandRequest-URIMergedRequestsRequire8.2.3ContentProcessing8.2.4ApplyingExtensions8.2.5ProcessingtheRequest8.2.6GeneratingtheResponseSendingaProvisionalResponseHeadersandTags8.2.7StatelessUASBehavior8.3RedirectServers9CancelingaRequest9.1ClientBehavior1）如Invite消息導(dǎo)致earlydialog的建立，主叫側(cè)在此場景下如存在拆線需求，除可發(fā)送CANCEL消息外，還可以發(fā)送BYE消息9.2ServerBehavior10Registrations暫不要求10.1Overview10.2ConstructingtheREGISTERRequest10.2.1AddingBindingsSettingtheExpirationIntervalofContactAddressesPreferencesamongContactAddresses10.2.2RemovingBindings10.2.3FetchingBindings10.2.4RefreshingBindings10.2.5SettingtheInternalClock10.2.6DiscoveringaRegistrar10.2.7TransmittingaRequest10.2.8ErrorResponses10.3ProcessingREGISTERRequests11QueryingforCapabilities11.1ConstructionofOPTIONSRequest11.2ProcessingofOPTIONSRequest12Dialogs12.1CreationofaDialog12.1.1UASbehavior如Invite中帶有Record-route域，對于180消息：如帶有Contact域，則必須帶有Record-route域12.1.2UACBehavior12.2RequestswithinaDialog12.2.1UACBehaviorGeneratingtheRequestProcessingtheResponses12.2.2UASBehavior暫不要求網(wǎng)絡(luò)實體間的鑒權(quán)處理后續(xù)內(nèi)容中與之相關(guān)的內(nèi)容也采用相同的處理12.3TerminationofaDialog13InitiatingaSession13.1Overview13.2UACProcessing13.2.1CreatingtheInitialINVITE13.2.2ProcessingINVITEResponses1xxResponses3xxResponses4xx,5xxand6xxResponses2xxResponses13.3UASProcessing13.3.1ProcessingoftheINVITEProgressTheINVITEisRedirectedTheINVITEisRejectedTheINVITEisAccepted14ModifyinganExistingSession14.1UACBehavior14.2UASBehavior15TerminatingaSession15.1TerminatingaSessionwithaBYERequest15.1.1UACBehavior15.1.2UASBehavior16ProxyBehavior16.1Overview16.2StatefulProxy16.3RequestValidation16.4RouteInformationPreprocessing16.5DeterminingRequestTargets16.6RequestForwarding當(dāng)MSCe基于Proxy進行業(yè)務(wù)處理時OutboundProxy在處理初始invite消息時，必須增加record-route域，同時必須為Looserouter方式。其他消息根據(jù)業(yè)務(wù)需要而增加16.7ResponseProcessing16.8ProcessingTimerC16.9HandlingTransportErrors16.10CANCELProcessing16.11StatelessProxy16.12SummaryofProxyRouteProcessing16.12.1ExamplesBasicSIPTrapezoidTraversingastrict-routingproxyRewritingRecord-Routeheaderfieldvalues17Transactions17.1ClientTransaction17.1.1INVITEClientTransactionOverviewofINVITETransactionFormalDescriptionConstructionoftheACKRequest17.1.2Non-INVITEClientTransactionOverviewofthenon-INVITETransactionFormalDescription17.1.3MatchingResponsestoClientTransactions暫不要求支持多播（Multicast）。后續(xù)內(nèi)容中與之相關(guān)的內(nèi)容也采用相同的處理17.1.4HandlingTransportErrors17.2ServerTransaction17.2.1INVITEServerTransaction17.2.2Non-INVITEServerTransaction17.2.3MatchingRequeststoServerTransactions17.2.4HandlingTransportErrors18Transport18.1Clients18.1.1SendingRequests18.1.2ReceivingResponses18.2Servers18.2.1ReceivingRequests18.2.2SendingResponses18.3Framing18.4ErrorHandling19CommonMessageComponents19.1SIPandSIPSUniformResourceIndicators19.1.1SIPandSIPSURIComponents19.1.2CharacterEscapingRequirements19.1.3ExampleSIPandSIPSURIs19.1.4URIComparison19.1.5FormingRequestsfromaURI19.1.6RelatingSIPURIsandtelURLs19.2OptionTags19.3Tags20HeaderFields20.1Accept20.2Accept-Encoding20.3Accept-Language20.4Alert-Info暫不要求支持AbsoluteURI后續(xù)內(nèi)容中與之相關(guān)的內(nèi)容也采用相同的處理20.5Allow20.6Authentication-Info20.7Authorization20.8Call-ID20.9Call-Info20.10Contact20.11Content-Disposition20.12Content-Encoding20.13Content-Language20.14Content-Length20.15Content-Type20.16CSeq20.17Date20.18Error-Info20.19Expires20.20From20.21In-Reply-To20.22Max-Forwards20.23Min-Expires20.24MIME-Version20.25Organization20.26Priority20.27Proxy-Authenticate20.28Proxy-Authorization20.29Proxy-Require20.30Record-RouteProxy增加該域時，必須為looserouter方式20.31Reply-To20.32Require20.33Retry-After20.34Route20.35Server20.36Subject20.37Supported20.38Timestamp20.39To20.40Unsupported20.41User-Agent20.42Via20.43Warning20.44WWW-Authenticate21ResponseCodes21.1Provisional1xx21.1.1100Trying21.1.2180Ringing21.1.3181CallIsBeingForwarded21.1.4182Queued21.1.5183SessionProgress21.2Successful2xx21.2.1200OK21.3Redirection3xx21.3.1300MultipleChoices21.3.2301MovedPermanently21.3.3302MovedTemporarily21.3.4305UseProxy21.3.5380AlternativeService21.4RequestFailure4xx21.4.1400BadRequest21.4.2401Unauthorized21.4.3402PaymentRequired21.4.4403Forbidden21.4.5404NotFound21.4.6405MethodNotAllowed21.4.7406NotAcceptable21.4.8407ProxyAuthenticationRequired21.4.9408RequestTimeout21.4.10410Gone21.4.11413RequestEntityTooLarge21.4.12414Request-URITooLong21.4.13415UnsupportedMediaType21.4.14416UnsupportedURIScheme21.4.15420BadExtension21.4.16421ExtensionRequired21.4.17423IntervalTooBrief21.4.18480TemporarilyUnavailable21.4.19481Call/TransactionDoesNotExist21.4.20482LoopDetected21.4.21483TooManyHops21.4.22484AddressIncomplete21.4.23485Ambiguous21.4.24486BusyHere21.4.25487RequestTerminated21.4.26488NotAcceptableHere21.4.27491RequestPending21.4.28493Undecipherable21.5ServerFailure5xx21.5.1500ServerInternalError21.5.2501NotImplemented21.5.3502BadGateway21.5.4503ServiceUnavailable21.5.5504ServerTime-out21.5.6505VersionNotSupported21.5.7513MessageTooLarge21.6GlobalFailures6xx21.6.1600BusyEverywhere21.6.2603Decline21.6.3604DoesNotExistAnywhere21.6.4606NotAcceptable22UsageofHTTPAuthentication22.1Framework22.2User-to-UserAuthentication22.3Proxy-to-UserAuthentication22.4TheDigestAuthenticationScheme23S/MIME暫不要求支持S/MIME23.1S/MIMECertificates23.2S/MIMEKeyExchange23.3SecuringMIMEbodies23.4SIPHeaderPrivacyandIntegrityusingS/MIME:TunnelingSIP23.4.1IntegrityandConfidentialityPropertiesofSIPHeadersIntegrityConfidentiality23.4.2TunnelingIntegrityandAuthentication23.4.3TunnelingEncryption24Examples24.1Registration24.2SessionSetup25AugmentedBNFfortheSIPProtocol25.1BasicRules26SecurityConsiderations:ThreatModelandSecurityUsageRecommendations有關(guān)安全防范措施，涉及到實際的整個解決方案，各實體的行為應(yīng)當(dāng)順從LMSD網(wǎng)絡(luò)中與安全相關(guān)內(nèi)容的要求。26.1AttacksandThreatModels26.1.1RegistrationHijacking26.1.2ImpersonatingaServer26.1.3TamperingwithMessageBodies26.1.4TearingDownSessions26.1.5DenialofServiceandAmplification26.2SecurityMechanisms26.2.1TransportandNetworkLayerSecurity26.2.2SIPSURIScheme26.2.3HTTPAuthentication26.2.4S/MIME26.3ImplementingSecurityMechanisms26.3.1RequirementsforImplementersofSIP26.3.2SecuritySolutionsRegistrationInterdomainRequestsPeertoPeerRequestsDoSProtection26.4Limitations26.4.1HTTPDigest26.4.2S/MIME26.4.3TLS26.4.4SIPSURIs26.5Privacy27IANAConsiderations27.1OptionTags27.2Warn-Codes27.3HeaderFieldNames27.4MethodandResponseCodes27.5The"message/sip"MIMEtype27.6NewContent-DispositionParameterRegistrations28ChangesFromRFC254328.1MajorFunctionalChanges28.2MinorFunctionalChanges29NormativeReferences30InformativeReferencesATableofTimerValues附錄CRFC3262：ReliabilityofProvisionalResponsesintheSessionInitiationProtocol（規(guī)范性附錄）如無特殊說明，本附錄的要求適用于LMSD網(wǎng)絡(luò)中的所有MSCe實體如與RFC3262的要求存在差異，將以“說明欄”的內(nèi)容為實現(xiàn)基準。否則，本附錄遵循RFC3262相關(guān)之規(guī)定。章節(jié)標(biāo)題說明章節(jié)標(biāo)題1Introduction2Terminology3UASBehavior4UACBehavior5TheOffer/AnswerModelandPRACK6DefinitionofthePRACKMethod7HeaderFieldDefinitions7.1RSeq7.2RAck8IANAConsiderations8.1IANARegistrationofthe100relOptionTag8.2IANARegistrationofRSeqandRAckHeaders9SecurityConsiderations10CollectedBNF11Acknowledgements12NormativeReferences13InformativeReferences附錄DRFC3264：AnOffer/AnswerModelwiththeSessionDescriptionProtocol(SDP)[RFC3264]（規(guī)范性附錄）如無特殊說明，本附錄的要求適用于LMSD網(wǎng)絡(luò)中的所有MSCe實體如與RFC3264的要求存在差異，將以“說明欄”的內(nèi)容為實現(xiàn)基準。否則，本附錄遵循RFC3264相關(guān)之規(guī)定。章節(jié)標(biāo)題說明1Introduction2Terminology3Definitions4ProtocolOperation5GeneratingtheInitialOffer暫不要求支持多播5.1UnicastStreams5.2MulticastStreams6GeneratingtheAnswer6.1UnicastStreams對于編解碼方式的選擇，建議answer方盡量順從offer方編解碼方式的優(yōu)先權(quán)編碼選擇的最終決定權(quán)在于Answer方。Answer方發(fā)送的SDP信息中的編碼能力集的第一個編碼為當(dāng)前協(xié)商所選定的編碼。（注1）注1：如SDP中存在多個m行，且每個m行都協(xié)商成功，則每個m行中的第一個編碼為該m行所代表的業(yè)務(wù)選擇的編碼。6.2MulticastStreams7OffererProcessingoftheAnswer8ModifyingtheSession8.1AddingaMediaStream8.2RemovingaMediaStream8.3ModifyingaMediaStream8.3.1ModifyingAddress,PortorTransport8.3.2ChangingtheSetofMediaFormats8.3.3ChangingMediaTypes8.3.4ChangingAttributes8.4PuttingaUnicastMediaStreamonHold建議發(fā)起保持的一方將當(dāng)前媒體流屬性置為sendonly（如無特殊需求）被保持的一方同時應(yīng)兼容C=的方式9IndicatingCapabilities10ExampleOffer/AnswerExchanges10.1BasicExchange10.2OneofNCodecSelection11SecurityConsiderations12IANAConsiderations13Acknowledgements14NormativeReferences15InformativeReferences16Author'sAddresses17FullCopyrightStatement附錄ERFC2976：TheSIPINFOMethod（規(guī)范性附錄）如無特殊說明，本附錄的要求適用于LMSD網(wǎng)絡(luò)中的所有MSCe實體如與RFC2976的要求存在差異，將以“說明欄”的內(nèi)容為實現(xiàn)基準。否則，本附錄遵循RFC2976相關(guān)之規(guī)定章節(jié)標(biāo)題說明1Introduction1.1ExampleUses2INFOMethod2.1HeaderFieldSupportforINFOMethod2.2ResponsestotheINFORequestMethod2.3MessageBodyInclusion2.4BehaviorofSIPUserAgents2.5BehaviorofSIPProxyandRedirectServers2.5.1ProxyServer2.5.2ForkingProxyServer2.5.3RedirectionServer3.INFOMessageBodies4GuidelinesforextensionsmakinguseofINFO5SecurityConsiderations6References7Acknowledgments8Author'sAddress附錄FRFC3311TheSessionInitiationProtocol(SIP)UPDATEMethod如無特殊說明，本附錄的要求適用于LMSD網(wǎng)絡(luò)中的所有MSCe實體如與RFC3311的要求存在差異，將以“說明欄”的內(nèi)容為實現(xiàn)基準。否則，本附錄遵循RFC3311相關(guān)之規(guī)定章節(jié)標(biāo)題說明1Introduction2Terminology3OverviewofOperation4DeterminingSupportforthisExtension5UPDATEHandling5.1SendinganUPDATE5.2ReceivinganUPDATE5.3ProcessingtheUPDATEResponse6ProxyBehavior7DefinitionoftheUPDATEmethod8ExampleCallFlow9SecurityConsiderations10IANAConsiderations11NoticeRegardingIntellectualPropertyRights12NormativeReferences13Acknowledgements14Author'sAddress15FullCopyrightStatement附錄GLMSD網(wǎng)絡(luò)中SIP重疊發(fā)碼程序技術(shù)實現(xiàn)（資料性附錄）當(dāng)LMSD網(wǎng)絡(luò)中的MSCe設(shè)備必須支持SIP協(xié)議的重疊發(fā)碼程序時，其詳細內(nèi)容請參照《中國電信軟交換網(wǎng)絡(luò)SIP協(xié)議規(guī)范—通用要求（2007版暫行）》附錄G的要求。附錄H信令流程示例（規(guī)范性附錄）H.1基本呼叫H.1.1成功呼叫建立H.1.1.1移動用戶作主叫（被叫側(cè)提供回鈴音，無session屬性更改）圖HSEQ圖表\*ARABIC\s11:成功呼叫，移動用戶作主叫（被叫側(cè)提供回鈴音，無session屬性更改）流程說明：服務(wù)MSCe（主叫側(cè)）收到基站發(fā)送而來的呼叫請求，預(yù)占媒體資源，并向被叫側(cè)發(fā)送INVITE消息，消息頭的Request-uri填寫被叫用戶的路由號碼信息消息頭的To域拷貝Request-uri域中的信息消息頭中的From域填寫主叫用戶的號碼信息消息頭中的P-Asserted-Idendtity域填寫主叫用戶的號碼信息消息頭中帶有Supported域，包含取值：100rel,timer消息頭中可能帶有Session-Expires域消息體中帶有SDP信息，描述主叫側(cè)媒體網(wǎng)關(guān)的相關(guān)信息，例如支持的語音編解碼能力、IP地址信息等。消息體中帶有IAM（ISUP）信息；被叫側(cè)回應(yīng)100Trying;收到被叫側(cè)發(fā)送的180消息消息頭中帶有Require域，包含取值：100rel消息體中帶有SDP信息。意味著被叫側(cè)提供回鈴音，主叫側(cè)在本次呼叫中無需考慮回鈴音資源的提供。消息體中帶有ACM信息（ISUP）；主叫側(cè)MSCe確認該ACM信息是否包含了某些補充業(yè)務(wù)信息，同時決定是否需要傳送至主叫用戶。主叫側(cè)發(fā)送PRACK，對180消息進行確認；被叫回送針對PRACK消息的200OK消息。主叫用戶接收被叫側(cè)網(wǎng)絡(luò)提供的回鈴音資源；被叫用戶應(yīng)答。主叫側(cè)網(wǎng)絡(luò)收到針對INVITE的200消息。消息頭中包括Session-Expires域，描述：會話更新的周期、會話更新的發(fā)起方該消息中封裝ANM信息（ISUP）；主叫側(cè)MSCe發(fā)送針對200（INVITE）消息的ACK消息。H.1.1.2移動用戶作主叫（被叫側(cè)提供回鈴音，存在session屬性更改）圖HSEQ圖表\*ARABIC\s12:成功呼叫，移動用戶作主叫（被叫側(cè)提供回鈴音，存在session屬性更改）流程說明：本節(jié)描述了被叫側(cè)網(wǎng)絡(luò)提供回鈴音，且后向網(wǎng)絡(luò)發(fā)起針對當(dāng)前Session的屬性進行修改（在被叫用戶應(yīng)答之前）的場景。Session修改的場景可能包括：提供回鈴音資源的地址與被叫實際應(yīng)答地址存在不同。與H.1.1.1節(jié)相比，流程主要存在以下特殊說明。步驟6）處，主叫側(cè)MSCe收到帶有SDP的UPDATE消息步驟7）處，主叫側(cè)MSCe回送200消息，200消息中帶有主叫側(cè)媒體網(wǎng)關(guān)的SDP描述。根據(jù)本規(guī)范第5.4.2部分的要求，與初始INVITE消息相比，至少應(yīng)保證SDP中的IP地址+端口號保持不變。根據(jù)應(yīng)用場景的不同，步驟6）+步驟7）可能存在多個。H.1.1.3移動用戶作主叫（被叫側(cè)不提供回鈴音，主叫側(cè)本地提供）圖HSEQ圖表\*ARABIC\s13:成功呼叫，移動用戶作主叫（被叫側(cè)不提供回鈴音，主叫側(cè)本地提供）流程說明：本節(jié)描述了被叫側(cè)網(wǎng)絡(luò)不提供回鈴音，主叫側(cè)MSCe控制媒體網(wǎng)關(guān)向主叫用戶提供回鈴音的場景。與H.1.1.1節(jié)相比，流程主要存在以下特殊說明：步驟3）處的第一個180消息中無SDP信息。MSCe確認被叫側(cè)不提供回鈴音，將控制本地媒體網(wǎng)關(guān)向主叫用戶提供回鈴音。步驟6）處的200消息（INVITE）中帶有被叫側(cè)網(wǎng)絡(luò)的SDP信息。H.1.1.4移動用戶作主叫（主叫側(cè)初始提供回鈴音，發(fā)現(xiàn)被叫側(cè)網(wǎng)絡(luò)提供回鈴音后，停止提供回鈴音）圖HSEQ圖表\*ARABIC\s14:成功呼叫，移動用戶作主叫（主叫側(cè)初始提供回鈴音，發(fā)現(xiàn)被叫側(cè)提供回鈴音后，停止提供回鈴音）流程說明：本節(jié)描述了主叫側(cè)MSCe控制媒體網(wǎng)關(guān)向主叫用戶提供回鈴音，當(dāng)發(fā)現(xiàn)被叫側(cè)網(wǎng)絡(luò)能夠提供回鈴音時，將停止回鈴音的提供。與H.1.1.3相比，流程主要存在以下說明：步驟6）處，主叫側(cè)MSCe收到180消息。該消息中帶有SDP信息。意味著被叫側(cè)網(wǎng)絡(luò)此時能夠提供回鈴音，主叫側(cè)MSCe將指示媒體網(wǎng)關(guān)停止本地回鈴音的提供。在步驟8）與步驟9）之間可能存在一個或多個UPDATE消息。主叫側(cè)MSCe的行為請參照H.1.1.2處的步驟6）跟步驟7）的說明。H.1.1.5移動用戶作被叫圖HSEQ圖表\*ARABIC\s15:成功呼叫，移動用戶作被叫流程說明：服務(wù)MSCe（被叫側(cè)）收到主叫側(cè)網(wǎng)絡(luò)發(fā)送的INVITE請求消息。INVITE消息中的關(guān)鍵參數(shù)說明參照H.1.1.1中步驟1）處的說明。MSCe向主叫側(cè)回送100Trying，并向被叫側(cè)發(fā)送尋呼請求，收到尋呼響應(yīng)后，預(yù)占資源，完成無線資源的指配；MSCe（被叫側(cè)）向主叫側(cè)回送180