【正文】 以使用“ tel”的 URI 定義機制，有關(guān)“ tel”的 URI定義機制參見 RFC2806。REGISTER 消息用于發(fā)送注冊請求信息， INVITE、 ACK、 CANCEL 用于建立會話連接， BYE 用于終結(jié)會話連接， OPTIONS 用于查詢服務(wù)器能力。 請求（ Request） 請求消息的起始行為請求行（ RequestLine）。請求和響應(yīng)消息格式如下： SIP 消息＝起始行 *消息頭部（ 1 個或多個頭部） CRLF (空行 ) [消息體 ] YD — 2 起始行＝ 請求行 /狀態(tài)行 如上消息格式定義，“ *”表示該消息頭部可包含一個或多個，“ []”表示該參數(shù)為可選項。 SIP 協(xié)議消息分請求和響應(yīng)兩類，其中請求消息由客戶機發(fā)往服務(wù)器，響應(yīng)消息由服務(wù)器發(fā)往客戶機。 2 規(guī)范性引用文件 下列 文件中的條款通過本標(biāo)準(zhǔn)的引用而成為本標(biāo)準(zhǔn)的條款。 ? 應(yīng)當(dāng)（建議）實現(xiàn)：與應(yīng)當(dāng)（建議）類似，實現(xiàn)時不必要缺省使能。違反這樣的要求是原則性錯誤。 本標(biāo)準(zhǔn)由中國通信標(biāo)準(zhǔn)化協(xié)會提出并歸口。 ICS 中 華 人 民 共 和 國 通 信 行 業(yè) 標(biāo) 準(zhǔn) YD YD — 會話初始協(xié)議技術(shù)要求 第一部分 基本的會話初始協(xié)議 Technical Requirements for Session Initiation Protocol Part1 Basic Session Initiation Protocol （征求意見稿） 發(fā)布 實施 中華人民共和國信息產(chǎn)業(yè)部 發(fā)布 YD — I 前 言 .............................................................................. II 1 范圍 ................................................................................. 1 2 規(guī)范性引用文件 ....................................................................... 1 3 SIP 消息 .............................................................................. 1 4 用戶代理 (UA)的基本行為 ............................................................... 5 5 請求的取消 .......................................................................... 15 6 注冊（暫缺） ........................................................................ 17 7 查詢能力 ............................................................................ 17 8 對話（ dialog） ....................................................................... 19 9 會話發(fā)起過程 ........................................................................ 23 10 會話更改過程 ....................................................................... 24 11 會話結(jié)束過程 ....................................................................... 26 12 代理服務(wù)器 (代理服務(wù)器 )的行為 ........................................................ 26 13 SIP 事務(wù)層 .......................................................................... 43 14 傳輸 ............................................................................... 50 15 普通的消息成分 ..................................................................... 54 16 頭字段 ............................................................................. 62 17 響應(yīng)代碼 ........................................................................... 77 18 HTTP 鑒權(quán)的使用 .................................................................... 83 19 S/MIME ............................................................................ 88 20 SIP 協(xié)議的擴展 BNF .................................................................. 95 附 錄 A(標(biāo)準(zhǔn)性附錄 ) 安全：威脅模式和安全建議 ....................................... 107 附 錄 B(標(biāo)準(zhǔn)性附錄 ) IANA 考慮 ..................................................... 116 附 錄 C(標(biāo)準(zhǔn)性附錄 ) 與 RFC 2543 相比的改變 ......................................... 119 附 錄 D(標(biāo)準(zhǔn)性附錄 ) SIP 協(xié)議中臨時響應(yīng)的可靠性 ..................................... 123 附 錄 E(標(biāo)準(zhǔn)性附錄 ) 定位 SIP 服務(wù)器 ................................................. 129 附 錄 F(標(biāo)準(zhǔn)性附錄 ) SDP 的提供 /應(yīng)答模式 ............................................ 135 附 錄 G(標(biāo)準(zhǔn)性附錄 ) 特定事件的通知 ................................................. 146 附 錄 H(標(biāo)準(zhǔn) 性附錄 ) OPEN ISSUE ................................................... 160 附 錄 I(標(biāo)準(zhǔn)性附錄 ) SIP INFO ...................................................... 163 YD — II 前 言 本標(biāo)準(zhǔn)以 RFC3261 等文檔為依據(jù)，針對我國具體要求制定而成。 本標(biāo)準(zhǔn)起草單位： 本標(biāo)準(zhǔn)主要起草人： YD — 1 會話初始協(xié)議技術(shù)規(guī)范 第一部分 基本的會話初始協(xié)議 1 范圍 本標(biāo)準(zhǔn)規(guī)定了會話初始協(xié)議。 ? 必須實現(xiàn)：表示該要求必須實現(xiàn)，但不要求缺省使能。 ? 不應(yīng)當(dāng)（不建議）：表示在某些特定條件下存在所描述行為可接受或有效的理由，但實現(xiàn)該行為時必須仔細(xì)衡量。凡是注日期的引用文件，其隨后所有的修改單（不包括勘誤的內(nèi)容）或修訂版均不適用于本標(biāo)準(zhǔn)，然而，鼓勵根據(jù)本標(biāo)準(zhǔn)達成協(xié)議的各方研究是否可使用這些文件的最新版本。除選用的字符集以及語法定義外，請求和響應(yīng)消息均采用 RFC2822 定義的基本格式進行編碼。本規(guī)范規(guī)定起始行、每一個消息頭部以及空行都必須使用回車換行字符（ CRLF）來表示行終結(jié)，即使消息中未包含消息體可選項空行也不能省略。請 求行的格式如下所示，由方法名、請求 URL 和協(xié)議版本組成，各部分之間均用一個空格字符進行分隔。本協(xié)議規(guī)定方法名必須使用大寫字母。 SIP 實體可使用任何可選方法將非 SIP URL 翻譯成 SIP URI、 SIPS URI 或其他URI 定義。 1） StatusCode（狀態(tài)碼）：該參數(shù)為一個 3 位的十進制整數(shù)，用于指示請求消息的執(zhí)行響應(yīng)結(jié)果。 本協(xié)議共定義 6 類狀態(tài)碼，其中狀態(tài)碼的第 1 位數(shù)字用于指示響應(yīng)類型，后兩位數(shù)字表示具體響應(yīng)。 3） 3XX：重定向響應(yīng)，表示需采取進一步以完成該請求。 響應(yīng)分類描述以及具體的響應(yīng)碼參見本規(guī)范第 17 章。該規(guī)則同樣適用于本協(xié)議，但具體應(yīng)用時規(guī)則會有所不同。頭字段格式如下所示，頭字段名和字段值之間用字符“：”進行分隔。 Subject: I know you39。同理，多個相同字段名的字段行可以組成一個單一的字段行，其字段值為一個用“，”字符分隔的值列表。按照以上規(guī)則，以下兩個字段行是等價的。除此之外，頭字段還允許包含空格、破折號、分隔符和引號字符。如未特別指出，頭字段中所包含的字段參數(shù)值，參數(shù)名和參數(shù)值也對大小寫字符不敏感，除此之外，頭字段名中所包含的破折號“ ”字符對大小寫字符不敏感，但是引號字符內(nèi)的字符內(nèi)容對大小寫字符敏感。handling=optional contentdisposition: Session。 壓縮格式 本協(xié)議提供了一種壓縮機制用于將頭字段名相同的字段進行壓縮傳送，這種壓縮機制可以避免消息傳輸過程中產(chǎn)生大量消息拆分（例如，當(dāng)使用 UDP 進行傳輸時，如果消息的字節(jié)長度超過了 MTU，則需要對消息進行拆分傳送）。 消息實體 本協(xié)議規(guī)定 SIP 請求消息可包含消息實體部分，消息實體部分的解釋應(yīng)與消息請求方法相一致。否則，如果消息實體未采用了壓縮編碼方式，則“ ContentEncoding”字段的內(nèi)容應(yīng)被忽略。 SIP 消息可以包含二進制編碼的消息實體。 本協(xié)議規(guī)定 SIP 消息實體不能采用 中所定義的“ chunked”傳送編碼機制。 具體實現(xiàn)時，如果 SIP 消息采用面向流的方式進行傳送，則 SIP 消息起始行前的任何 CRLF 字符應(yīng)忽略。它包括兩部分，用戶代理客戶端 (UAC)和用戶代理服務(wù)器端 (UAS)，前者產(chǎn)生請求，后者產(chǎn)生對應(yīng)的響應(yīng)。 當(dāng) UAC 發(fā) 出 請求，請求消息會通過 一些 代理服務(wù)器 被 轉(zhuǎn)發(fā)到 UAS。關(guān)于對話定義參見本規(guī)范第 12 章。 UAC 基本行為 本節(jié)討論在 對 話之外的 UAC 行為。 在 對 話外發(fā)送的請求消息包括：用 INVITE消息建立起一個會話（參見本規(guī)范第 13 章），用 OPTIONS消息進行能力查詢（參見本規(guī)范第 11 章）等。 某些情況下，預(yù)設(shè)路由集的存在能影響到消息的 RequestURI。 當(dāng)存在預(yù)設(shè)路由集時， 必須遵循本規(guī)范 節(jié)中描述的過程來設(shè)置 RequestURI 和 Route 頭字段，其 RequestURI 作為遠(yuǎn)端目標(biāo) URI。本協(xié)議規(guī)定，所有的具體實現(xiàn)過程都必須支持 SIP URI方案，任何支持 TLS 的實現(xiàn)必須支持 SIPS URI 方案。用戶通常不會輸入一個完整的 URI，而只是提供一個由數(shù)字或字母組成的字符串（比如 ”bob”），由 UA 判斷并解釋該字符串。例如：一個來到機場的用戶可能登錄機場的外撥代理服務(wù)器并通過它發(fā)送請求，如果用戶輸入 ”411”（美國本地電話查號臺號碼），那么該號碼應(yīng)由機場的外撥代理服務(wù)器來分析和處理，而不是用戶的本地主域。 關(guān)于 To 頭字段參見本規(guī)范 節(jié)。由于不是邏輯名YD — 7 稱，因此 From URI 不包含 IP 地址或 UA 所在主機的全稱域名（ FQDN）。如果 UA 被多個用戶所共用，那么它可以有多個可切換的用戶配置文件，每一文件中含有某一用戶的URI。 關(guān)于 From 頭字段參見本規(guī)范 節(jié)。 tag=hyh8 CallID 頭字段 CallID 頭字段是用來將消息分組的唯一性標(biāo)識。所有的 SIP UA 都必須保證它所產(chǎn)生的 CallID 不會與其它 UA 所產(chǎn)生的相同。 CallID 對大小寫敏感，需逐字節(jié)的進行比較。下例是一個有效的 CallId： CallID： Cseq 頭字段 CSeq 頭字段用于標(biāo)識事務(wù)并對事務(wù)進行排序。只要符合以上規(guī)則，客戶端可以用任何方式來選擇 Cseq頭字段值。如果在請求消息到達目的地之前該值變?yōu)榱悖敲凑埱髮⒈痪芙^并返回一個 483（跳數(shù)過多）錯誤響應(yīng)消息。 Via 頭字段 Via 頭字段定義 SIP 事務(wù)的下層（傳輸層）傳輸協(xié)議，并標(biāo)識響應(yīng)