SIP協(xié)議原理及實(shí)例分析.ppt

SIP協(xié)議原理及實(shí)例分析,接入網(wǎng)產(chǎn)品導(dǎo)入部,Page2,學(xué)習(xí)目標(biāo),學(xué)習(xí)完此課程，您將會(huì)：了解SIP協(xié)議原理掌握SIP命令和消息掌握SIP協(xié)議的消息交互過程了解SIP業(yè)務(wù)基本故障分析處理方法,Page3,第1章SIP協(xié)議原理第2章SIP命令和消息第3章業(yè)務(wù)流程分析,Page4,SIP協(xié)議概念,SIP的前世,SIP的前世,有關(guān)SIP的完整定義最早出現(xiàn)在1999年公布的RFC2543中，當(dāng)前SIP詳細(xì)定義于RFC3261(June2002)。,Multi-PartyMultimediaWorkingGroup于1996年提出兩項(xiàng)關(guān)于在Internet中實(shí)現(xiàn)多媒體通信的建議：SessionInitiationProtocol(SIP)SimpleConferenceInvitationProtocol(SCIP)最終兩項(xiàng)建議統(tǒng)一于SessionInitiationProtocolSIP。,Page5,SIP協(xié)議概念,SIP是SessionInitializationProtocol（會(huì)話初始協(xié)議）的縮寫，用來建立、更改和終止一個(gè)或者多個(gè)參與者的會(huì)話。這些會(huì)話包括多媒體會(huì)議、網(wǎng)絡(luò)呼叫等。IETF制訂的多媒體通信系統(tǒng)框架協(xié)議之一，但是SIP單獨(dú)不能完成多媒體呼叫，必須要與其他協(xié)議一起才能組建完整的多媒體通信系統(tǒng)，與RTP/RTCP、SDP等協(xié)議配合共同完成多媒體會(huì)話過程。,Page6,SIP協(xié)議功能描述,用戶定位：確定參加通信的終端用戶的位置。用戶通信能力協(xié)商：確定通信的媒體類型和參數(shù)。用戶交互意愿：確定被叫加入通信的意愿。呼叫建立：建立主叫和被叫的會(huì)話參數(shù)。呼叫處理和控制：包括呼叫重定向、呼叫轉(zhuǎn)移、終止呼叫等。,Page7,SIP協(xié)議特點(diǎn),借鑒了其他internet標(biāo)準(zhǔn)和協(xié)議的設(shè)計(jì)思想，在風(fēng)格上遵循因特網(wǎng)一貫堅(jiān)持的簡練、開放、兼容和可擴(kuò)展等原則，并充分注意到因特網(wǎng)開放而復(fù)雜的網(wǎng)絡(luò)環(huán)境下的安全問題；充分考慮了對(duì)傳統(tǒng)公共電話網(wǎng)的各種業(yè)務(wù)，包括IN業(yè)務(wù)（Internet）和ISDN業(yè)務(wù)的支持；通過代理和重定向請(qǐng)求用戶當(dāng)前位置，以支持用戶的移動(dòng)性；獨(dú)立于傳輸層協(xié)議，可以承載在不同的傳輸協(xié)議上（UDP、TCP、SCTP、TLS），因此可以靈活方便地?cái)U(kuò)展其他附加功能；SIP協(xié)議獨(dú)立于業(yè)務(wù)，協(xié)議不限制具體業(yè)務(wù)范疇，只描述建立/更改/終止一個(gè)會(huì)話，并不描述會(huì)話的內(nèi)容，所以可以承載任何的會(huì)話內(nèi)容，如語音/視頻/游戲等。,Page8,SIP與H.248對(duì)比,Page9,SIP協(xié)議的應(yīng)用,SIP協(xié)議的典型應(yīng)用IP電話（VoIP）移動(dòng)游戲即時(shí)通信視頻與協(xié)調(diào)SIP擴(kuò)展應(yīng)用3GWCDMAIMS,Page10,SIP協(xié)議棧,在TCP/IP五層模型中屬于應(yīng)用層協(xié)議在OSI七層模型中屬于會(huì)話層協(xié)議,Page11,SIP協(xié)議在網(wǎng)絡(luò)中的位置,Page12,SIP協(xié)議在NGN中的實(shí)現(xiàn),SoftX3000,SoftPhone,SoftX3000,SoftPhone,SIP,SIP,SIP,IP,IP,IP,IP,IPCore,Page13,SIP在網(wǎng)絡(luò)中的主要實(shí)體,SIP在網(wǎng)絡(luò)中存在多種邏輯實(shí)體，不同實(shí)體作用互不相同：UA（UserAgent）ProxyserverRegistrarserverRedirectserverLocationserver不同的邏輯實(shí)體可以存在于同一個(gè)物理實(shí)體之上。,Page14,SIP在網(wǎng)絡(luò)中的主要實(shí)體,用戶助理（UserAgent）：用來發(fā)起或者接收請(qǐng)求的邏輯實(shí)體稱為UserAgent。用戶助理客戶（UserAgentClient）：發(fā)起請(qǐng)求的一方稱為UAC，SIPPhone就是UAC的一種實(shí)際形態(tài)；用戶助理服務(wù)器（UserAgentServer）：接收請(qǐng)求，產(chǎn)生響應(yīng)的一方稱為UAS，SoftX3000就是UAS的一種實(shí)際形態(tài)。UAC和UAS的劃分是針對(duì)一個(gè)事務(wù)而言的。代理服務(wù)器：作為一個(gè)邏輯網(wǎng)絡(luò)實(shí)體代表客戶端轉(zhuǎn)發(fā)請(qǐng)求或者響應(yīng)，可以同時(shí)作為客戶端和服務(wù)器端。主要功能有：路由、認(rèn)證鑒權(quán)、計(jì)費(fèi)控制、呼叫控制、業(yè)務(wù)提供等。它可以采取分支，循環(huán)，遞歸查詢等方式向多個(gè)地址嘗試轉(zhuǎn)發(fā)請(qǐng)求。SoftX3000兼任代理服務(wù)器的角色。它有三種形態(tài)：Stateless：其作用為一般的路由器TransactionStateful：關(guān)聯(lián)一次事務(wù)過程CallDialog：關(guān)聯(lián)一次會(huì)話過程,Page15,SIP在網(wǎng)絡(luò)中的主要實(shí)體,注冊(cè)服務(wù)器：接收注冊(cè)請(qǐng)求的服務(wù)器,需要將注冊(cè)請(qǐng)求中的地址映射關(guān)系保存到數(shù)據(jù)庫中，供后續(xù)的相關(guān)呼叫過程使用，同時(shí)可以提供定位服務(wù)。SoftX3000兼任注冊(cè)服務(wù)器的角色。重定向服務(wù)器：為所收到的請(qǐng)求返回一個(gè)或多個(gè)新的地址,客戶端直接向這些新的地址發(fā)起請(qǐng)求。重定向服務(wù)器并不接收或者拒絕呼叫，主要完成路由功能，與注冊(cè)過程配合可以支持SIP終端的移動(dòng)性。SoftX3000兼任重定向服務(wù)器的角色。定位服務(wù)器：提供被叫位置的服務(wù)器，SoftX3000兼任定位服務(wù)器的角色。,Page16,相關(guān)術(shù)語,呼叫：一個(gè)呼叫是由一個(gè)公共源端所邀請(qǐng)的在一個(gè)會(huì)議中的所有參加者組成，由一個(gè)全球唯一的Call-ID進(jìn)行標(biāo)識(shí)。例如：由同一個(gè)源邀請(qǐng)的一個(gè)會(huì)議的所有參加者構(gòu)成一個(gè)呼叫；點(diǎn)到點(diǎn)IP電話會(huì)話是一種最簡單的會(huì)話，它映射為單一的SIP呼叫。通常情況下，呼叫由主叫方創(chuàng)建，但是更一般說來，呼叫可由并不參與媒體通信的第三方創(chuàng)建，此時(shí)會(huì)話的主叫方和會(huì)話的邀請(qǐng)方并不相同。事務(wù)：SIP是一個(gè)客戶/服務(wù)器協(xié)議?？蛻艉头?wù)器之間的操作從第1個(gè)請(qǐng)求至最終響應(yīng)為止的所有消息構(gòu)成一個(gè)SIP事務(wù)。一個(gè)正常的呼叫一般包含三個(gè)事務(wù)。其中，呼叫啟動(dòng)包含兩個(gè)操作請(qǐng)求：邀請(qǐng)（Invite）和證實(shí)（ACK），前者需要回送響應(yīng)，后者只是證實(shí)已收到最終響應(yīng)，不需要回送響應(yīng)。呼叫終結(jié)包含一個(gè)操作請(qǐng)求：再見（Bye）。,Page17,相關(guān)術(shù)語,SIPURL：為了能正確傳送協(xié)議消息，SIP還需解決兩個(gè)重要的問題。一是尋址，即采用什么樣的地址形式標(biāo)識(shí)終端用戶；二是用戶定位。SIP沿用WWW技術(shù)解決這兩個(gè)問題。尋址采用SIPURL（UniformResourceLocators），按照RFC2396規(guī)定的URI導(dǎo)則定義其語法，特別是用戶名字段可以是電話號(hào)碼，以支持IP電話網(wǎng)關(guān)尋址，實(shí)現(xiàn)IP電話和PSTN的互通。,Page18,相關(guān)術(shù)語,SIPURL的一般結(jié)構(gòu)為：SIP：用戶名：口令主機(jī)：端口；傳送參數(shù)；用戶參數(shù)；方法參數(shù)；生存期參數(shù)；服務(wù)器地址參數(shù),“SIP”表示需采用SIP協(xié)議和所指示的端系統(tǒng)通信。,“用戶名”可以由任意字符組成，一般可取類似與E-mail用戶名形式，也可以是電話號(hào)碼（SoftX3000目前用戶名是電話號(hào)碼）。,“口令”可以置于SIPURL中，但一般不建議這樣做，因?yàn)槠浒踩允怯袉栴}的。,“主機(jī)”可為主機(jī)域名或IPv4地址。,“端口”指示請(qǐng)求消息送往的端口號(hào)，其缺省值為5060，即公開的SIP端口號(hào)。,“傳送參數(shù)”指示采用TCP還是UDP傳送，缺省值為UDP。,“用戶參數(shù)”，SIPURL的一個(gè)特定功能是允許主機(jī)類型為IP電話網(wǎng)關(guān)，此時(shí)，用戶名可以為一般的電話號(hào)碼。由于BNF語法表示無法區(qū)分電話號(hào)碼和一般的用戶名，因此，在域名后增加了“用戶參數(shù)”字段。該字段有兩個(gè)可選值：IP和電話，當(dāng)其設(shè)定為“電話”時(shí)，表示用戶名為電話號(hào)碼，對(duì)應(yīng)的端系統(tǒng)為IP電話網(wǎng)關(guān)。,“方法參數(shù)”指示所用的方法,“生存期參數(shù)”指示UDP多播數(shù)據(jù)包的壽命，僅當(dāng)傳送參數(shù)為UDP、服務(wù)器地址參數(shù)為多播地址時(shí)才能使用。,“服務(wù)器地址參數(shù)”指示和該用戶通信的服務(wù)器的地址，它覆蓋“主機(jī)”字段中的地址，通常為多播地址。,“傳送參數(shù)”、“方法參數(shù)”、“生存期參數(shù)”和“服務(wù)器地址參數(shù)”均屬于URL參數(shù)，只能在重定向地址，即后面所說的Contact字段中才能使用。,Page19,相關(guān)術(shù)語,下面給出若干個(gè)SIPURL的示例：Sip:5550020012;55500200為用戶名，12為IP電話網(wǎng)關(guān)的IP地址。Sip:5550020012:5061;User=phone;55500200為用戶名，12為主機(jī)的IP地址，5061為主機(jī)端口號(hào)。用戶參數(shù)為“電話”，表示用戶名為電話號(hào)碼。Sip:alice;method=REGISTER;Alice為用戶名，為主機(jī)域名。方法參數(shù)為“登記”。需要注意的是SoftX3000目前只支持用戶名是電話號(hào)碼，不支持這種形式的用戶名。Sips:123439SIPS表示安全的SIPURI，傳輸層使用的是基于安全的TLS協(xié)議。,Page20,問題,SIP有哪些網(wǎng)絡(luò)實(shí)體？它們的功能是什么？SIP協(xié)議的協(xié)議棧模型是怎樣的？,Page21,第1章SIP協(xié)議原理第2章SIP命令和消息第3章業(yè)務(wù)流程分析,Page22,SIP協(xié)議消息的分類,SIP消息采用文本方式編碼，分為兩類：請(qǐng)求消息和響應(yīng)消息。請(qǐng)求消息和響應(yīng)消息都包括SIP頭字段和SIP消息字段。請(qǐng)求消息和響應(yīng)消息在形式上的區(qū)別僅在消息的第一行，請(qǐng)求的第一行為請(qǐng)求行，響應(yīng)的第一行為狀態(tài)行。,Page23,請(qǐng)求消息,請(qǐng)求消息：客戶端為了激活按特定操作而發(fā)給服務(wù)器的SIP消息。RFC3261定義了六個(gè)基本方法，包括INVITE，ACK,OPTIONS,BYE,CANCEL,REGISTER。后續(xù)RFC擴(kuò)展了其他的請(qǐng)求方法，包括UPDATE，INFO，SUBSCRIBER，NOTIFY，MESSAGE，PRACK，REFER。,Page24,請(qǐng)求消息格式,請(qǐng)求消息由起始行、消息頭和消息體組成。通過換行符區(qū)分消息頭中的每一條參數(shù)行。對(duì)于不同的請(qǐng)求消息，有些參數(shù)可選。,Page25,響應(yīng)消息,響應(yīng)消息：用于對(duì)請(qǐng)求消息進(jìn)行響應(yīng)，指示呼叫的成功或失敗狀態(tài)。不同類的響應(yīng)消息由狀態(tài)碼來區(qū)分。狀態(tài)碼包含三位整數(shù)，狀態(tài)碼的第一位用于定義響應(yīng)類型，另外兩位用于進(jìn)一步對(duì)響應(yīng)進(jìn)行更加詳細(xì)的說明。,除1XX外其余都是最終響應(yīng)。,Page26,響應(yīng)消息格式,對(duì)于不同的響應(yīng)消息，有些參數(shù)可選。,Page27,消息的頭域,5個(gè)必須包含在每個(gè)SIP消息中的頭域：Call-IDFromToCSeqViaCall-ID：用于唯一標(biāo)識(shí)一次會(huì)話，一般格式為：Call-ID:本地標(biāo)識(shí)主機(jī)主機(jī)應(yīng)為全局域名或者全局IP地址，此時(shí)本地標(biāo)識(shí)可由在主機(jī)范圍內(nèi)唯一的URI字符組成。否則，本地標(biāo)識(shí)必須是全局唯一的，以保證Call-ID的全局唯一性。舉例：Call-Id:call-973636852-401,Page28,消息的頭域,From：用于標(biāo)識(shí)請(qǐng)求的發(fā)起者，服務(wù)器將此字段從請(qǐng)求消息中復(fù)制到響應(yīng)消息，一般格式為：From：顯示名；tagXXXX顯示名為用戶界面上顯示的字符，如果系統(tǒng)不予顯示，應(yīng)置顯示名為“匿名”。Tag稱為標(biāo)記，為16進(jìn)制數(shù)字串，中間可帶連字符“”。當(dāng)兩個(gè)共享同一SIP地址的用戶實(shí)例用相同的Call-ID發(fā)起呼叫時(shí)，就需用此標(biāo)記予以區(qū)分。標(biāo)記值必須全局唯一，用戶在整個(gè)呼叫期間應(yīng)保持相同的Call-ID和標(biāo)記值。舉例：From:123456;tag=a48s,Page29,消息的頭域,To：用于表示請(qǐng)求的接收者，其格式和From相同，僅第一個(gè)關(guān)鍵字不同;To：顯示名；tagXXXXTag可用于區(qū)分由同一SIPURL標(biāo)識(shí)的不同的用戶實(shí)例。由于代理服務(wù)器可以并行分發(fā)請(qǐng)求，同一請(qǐng)求可能到達(dá)用戶的不同實(shí)例，每個(gè)實(shí)例都可能響應(yīng)，因此需用標(biāo)記來區(qū)分來自不同實(shí)例的響應(yīng)。To字段中的標(biāo)記是由每個(gè)實(shí)例置于響應(yīng)消息中的。舉例：To:;tag=62beb3ca在SIP中，Call-ID、From和To三個(gè)字段標(biāo)識(shí)一個(gè)呼叫分支。在代理服務(wù)器并行分發(fā)請(qǐng)求時(shí)，一個(gè)呼叫可能會(huì)有多個(gè)呼叫分支。,Page30,消息的頭域,CSeq：用于表示請(qǐng)求的順序號(hào),UAC在每個(gè)請(qǐng)求中加入此字段，一般格式為：CSeq：序號(hào)消息名稱序號(hào)由UAC選定，在Call-ID范圍內(nèi)唯一確定，序號(hào)初值可為任意值，其后具有相同Call-ID值但不同命令名稱、消息體的請(qǐng)求，其CSeq序號(hào)應(yīng)加1。重發(fā)請(qǐng)求的序號(hào)保持不變。服務(wù)器將請(qǐng)求中的CSeq值復(fù)制到響應(yīng)消息中，用于將請(qǐng)求和其觸發(fā)的響應(yīng)關(guān)聯(lián)起來。ACK和CANCEL請(qǐng)求的CSeq值和對(duì)應(yīng)的INVITE請(qǐng)求相同，BYE請(qǐng)求的CSeq序號(hào)應(yīng)大于INVITE請(qǐng)求。由代理服務(wù)器并行分發(fā)的請(qǐng)求，其CSeq值相同。嚴(yán)格來說，CSeq對(duì)于任何可由BYE或CANCEL請(qǐng)求取消的請(qǐng)求以及客戶可連續(xù)發(fā)送多個(gè)具有相同Call-ID請(qǐng)求的情況都是需要的，其作用是判斷響應(yīng)和請(qǐng)求的對(duì)應(yīng)關(guān)系。舉例：CSeq:4711INVITE,Page31,消息的頭域,Via：用以指示請(qǐng)求歷經(jīng)的路徑，它可以防止請(qǐng)求消息傳送產(chǎn)生環(huán)路，并確保響應(yīng)和請(qǐng)求消息選擇同樣的路徑，以保證通過防火墻或滿足其他特定的選路要求。對(duì)于請(qǐng)求：每個(gè)SIP實(shí)體前傳請(qǐng)求時(shí)，都將自己的地址放到當(dāng)前的Via集的最上面，與此類推，當(dāng)請(qǐng)求到達(dá)UAS端時(shí)，在SIP消息中將會(huì)形成一個(gè)類似于堆棧的Via頭域集。對(duì)于響應(yīng)：UAS將請(qǐng)求中的Via地址原樣拷貝到響應(yīng)里面，當(dāng)Proxy接收到響應(yīng)時(shí)，檢查頂端的Via是否是自己，如果是，將頂端的Via刪除，并檢查下一個(gè)Via地址將響應(yīng)發(fā)送到下一個(gè)Via地址，如果沒有下一個(gè)Via地址，則表示這個(gè)響應(yīng)應(yīng)該到Proxy這兒終結(jié)。,Address:B,Address:C,Address:D,Via:A,Via:BVia:A,Via:CVia:BVia:A,Via:CVia:BVia:A,Via:BVia:A,Via:A,Request,Response,Address:A,Page32,消息的頭域,Via字段的一般格式：Via：發(fā)送協(xié)議發(fā)送方；隱藏參數(shù)；生存期參數(shù)；多播地址參數(shù)；接收方標(biāo)記，分支參數(shù)發(fā)送協(xié)議的格式為：協(xié)議名/協(xié)議版本/傳輸層協(xié)議。協(xié)議名和傳輸層協(xié)議的缺省值為SIP和UDP。發(fā)送方為發(fā)送方的域名或主機(jī)IP和端口號(hào)，如果采用默認(rèn)端口號(hào)5060，端口號(hào)可以缺省。隱藏參數(shù)表示該字段已由上有代理予以加密，以提供隱私服務(wù)。分支參數(shù)用于代理服務(wù)器并行分發(fā)請(qǐng)求時(shí)標(biāo)記各個(gè)分支，當(dāng)響應(yīng)達(dá)到時(shí)，代理可判定是哪一分支的響應(yīng)。舉例：Via:SIP/2.0/UDP;branch=z9hG4bKkjshdyffVia:SIP/2.0/UDP:5060;,Page33,其他重要消息頭域,Max-Forwards：用于定義一個(gè)請(qǐng)求達(dá)到其目的地所允許經(jīng)過的中轉(zhuǎn)站的最大值。請(qǐng)求每經(jīng)過一個(gè)中轉(zhuǎn)站，該值減1。如果該值為0時(shí)該請(qǐng)求還沒有達(dá)到其目的地，服務(wù)器將返回483響應(yīng)并終止這個(gè)請(qǐng)求。該字段的目的主要是為了出現(xiàn)環(huán)路時(shí)不會(huì)一直消耗代理服務(wù)器的資源，它的初始值為70。它的一般格式為：Max-Forwards：十進(jìn)制整數(shù)請(qǐng)求消息中必須包括Max-Forwards頭域。,Page34,其他重要消息頭域,Contact：用于INVITA、ACK和REGISTER請(qǐng)求以及成功響應(yīng)、呼叫進(jìn)展響應(yīng)和重定向響應(yīng)消息，其作用是給出其后和用戶直接通信的地址。INVITE和ACK請(qǐng)求中的Contact字段指示該請(qǐng)求發(fā)出的位置。它使被叫可以直接將請(qǐng)求（如BYE請(qǐng)求）發(fā)往該地址，而不必借助Via字段經(jīng)由一系列代理服務(wù)器返回。對(duì)INVITE請(qǐng)求的成功響應(yīng)消息可包含Contact字段，它使其后的請(qǐng)求（如ACK請(qǐng)求）可直接發(fā)往該字段給定的地址。該地址一般是被叫主機(jī)的地址。REGISTER請(qǐng)求中的Contact字段指明用戶當(dāng)前位置，REGISTER請(qǐng)求的成功響應(yīng)消息中的Contact字段返回該用戶當(dāng)前可達(dá)的所有位置。重定向響應(yīng)消息中的Contact字段給出供重試的其它地址，可用于對(duì)BYE、INVITE和OPTIONS請(qǐng)求的響應(yīng)消息。,Page35,其他重要消息頭域,Contact字段的一般格式為：Contact：地址；q參數(shù)；動(dòng)作參數(shù)；失效參數(shù)；擴(kuò)展屬性地址的表示形式和To，F(xiàn)rom字段相同。q參數(shù)的取值范圍為【0，1】，指示給定位置的相對(duì)優(yōu)先級(jí)，數(shù)值越大，優(yōu)先級(jí)越高。動(dòng)作參數(shù)僅用于REGISTER請(qǐng)求，它表明希望服務(wù)器對(duì)其后至該客戶的請(qǐng)求進(jìn)行代理服務(wù)還是重定向服務(wù)，如果未含此參數(shù)，則取決于服務(wù)器的配置。失效參數(shù)表示該注冊(cè)的失效時(shí)間。舉例：Contact:;q=0.7;,Page36,其他消息頭域,Authorization：包含某個(gè)終端的鑒權(quán)證書。它的一般格式為：Authorization：認(rèn)證方式USERNAME，REALM，NONCE，RESPONSE，URI，CNONCE，ALGORITHM認(rèn)證方式有DIGEST、BASIC、CHAP-PASSWORD、CARDDIGEST等認(rèn)證方式。DIGEST為HTTP-DIGEST認(rèn)證方式。目前SoftX3000只支持HTTP-DIGEST方式。USERNAME表示被認(rèn)證的用戶的用戶名。REALM用于標(biāo)識(shí)發(fā)起認(rèn)證過程的域。NONCE由發(fā)起認(rèn)證過程的實(shí)體產(chǎn)生的加密因子。RESPONSE終端在收到服務(wù)器的認(rèn)證請(qǐng)求后根據(jù)服務(wù)器端產(chǎn)生的NONCE、用戶名、密碼、URI等信息經(jīng)過一定的算法生成的一個(gè)字符串。該字符串中包含了經(jīng)過加密后的用戶密碼。（在認(rèn)證過程中除用戶密碼之外其他信息都會(huì)通過SIP消息以明文的方式在終端和服務(wù)器端進(jìn)行傳遞。）,Page37,其他消息頭域,URI為發(fā)起呼叫請(qǐng)求消息中的Request-URI。由于終端在收到認(rèn)證請(qǐng)求后需要重新向服務(wù)器端發(fā)起請(qǐng)求（其中帶有認(rèn)證響應(yīng)信息）。該請(qǐng)求消息在經(jīng)過網(wǎng)絡(luò)服務(wù)器時(shí)某些字段包括RequestURI都有可能被修改。認(rèn)證頭域的URI參數(shù)用于傳遞終端發(fā)起請(qǐng)求時(shí)原始消息的Request-URI用于對(duì)認(rèn)證信息進(jìn)行認(rèn)證，這樣才能保證認(rèn)證過程的正確性。CNONCE：如果在服務(wù)器端超時(shí)后終端才向服務(wù)器返回了帶有認(rèn)證響應(yīng)的新的請(qǐng)求消息，則服務(wù)器端需要重新產(chǎn)生NONCE重新對(duì)用戶進(jìn)行認(rèn)證。其中NONCE中帶有新的NONCE，老的NONCE會(huì)通過CNONCE參數(shù)返回給終端。舉例：Authorization:DIGESTUSERNAME=“6540012”,REALM=“”,NONCE=200361722310491179922,RESPONSE=b7c848831dc489f8dc663112b21ad3b6,URI=sip:0,Page38,其他消息頭域,Allow：給出代理服務(wù)器支持的所有請(qǐng)求消息類型列表。舉例：Allow:INVITE,ACK,OPTIONS,CANCEL,BYEContent-Length：表示消息體的大小，為十進(jìn)制值。如果消息中沒有消息體，則Content-Length頭字段值必須設(shè)為0。舉例：Content-Length:349，表示消息體的長度為349個(gè)字節(jié)Content-Type：表示發(fā)送的消息體的媒體類型。如果消息體不為空，則必須存在Content-Type頭字段。舉例：Content-Type:application/sdpSupported：SIP協(xié)議中定義的100類臨時(shí)響應(yīng)消息的傳輸是不可靠的，即UAS發(fā)送臨時(shí)響應(yīng)后并不能保證UAC端能夠接受到該消息。100rel擴(kuò)展為100類響應(yīng)消息的可靠傳輸提供了相應(yīng)的機(jī)制。如果UAC支持該擴(kuò)展，則在發(fā)送的消息中增加Supported:100rel頭域和字段。舉例：Supported:100rel,Page39,請(qǐng)求消息實(shí)例,INVITEsip:6650000210SIP/2.0From:;tag=1ccb6df3To:CSeq:1INVITECall-ID:20973e49f7c52937fc6be224f9e52543sx3000Via:SIP/2.0/UDP16:5061;branch=z9hG4bkbc427dad6Contact:Supported:100rel,100relMax-Forwards:70Allow:INVITE,ACK,CANCEL,OPTIONS,BYE,REGISTER,PRACK,INFO,UPDATE,SUBSCRIBE,NOTIFY,MESSAGE,REFERContent-Length:230Content-Type:application/sdpv:0o:HuaweiSoftX300010737418311073741831INIP416s:SipCallc:INIP45t:00m:audio30000RTP/AVP80418a:rtpmap:8PCMA/8000a:rtpmap0PCMU/8000a:rtpmap4G723/8000a:rtpmap18G729/8000,請(qǐng)求起始行。INVITE請(qǐng)求消息。請(qǐng)求URI，即被邀用戶的當(dāng)前地址為“sip:6650000210”。SIP版本號(hào)為2.0,From字段。指明請(qǐng)求發(fā)起方的地址為“”。標(biāo)記為“1ccb6df3”，用于共享同一SIP地址的不同用戶用相同的Call-ID發(fā)起呼叫邀請(qǐng)時(shí)，對(duì)用戶進(jìn)行區(qū)分。,To字段。指明請(qǐng)求接收方的地址為“”。從From和To字段，我們可以看出：IP地址為16的PROXY控制下的終端44510000撥打IP地址為10的PROXY控制下的66500002終端。終端類型可以為SIP、H.323、IAD/AG下掛的ESL等。,Cseq字段。用于將INVITE請(qǐng)求和其觸發(fā)的響應(yīng)、對(duì)應(yīng)的ACK、CANCEL請(qǐng)求相關(guān)聯(lián)。,Call-ID字段。該字段唯一標(biāo)識(shí)一個(gè)特定的邀請(qǐng)，全局唯一。Call-ID為“20973e49f7c52937fc6be224f9e52543sx3000”,sx3000為發(fā)起呼叫的SoftX3000的域名,20973e49f7c52937fc6be224f9e52543為本地標(biāo)識(shí)。,：Via字段。該字段用于指示該請(qǐng)求歷經(jīng)的路徑?！癝IP/2.0/UDP”表示發(fā)送的協(xié)議，協(xié)議名為“SIP”，協(xié)議版本為2.0，傳輸層為UDP；“16:5061”表示發(fā)送方SoftX3000IP地址為16，端口號(hào)為5061；“branch=z9hG4bkbc427dad6”為分支參數(shù),SoftX3000并行分發(fā)請(qǐng)求時(shí)標(biāo)記各個(gè)分支。,Contact字段。指示其后的請(qǐng)求（如BYE請(qǐng)求）可以直接發(fā)往，而不必借助Via字段。,100rel擴(kuò)展，該字段為100類響應(yīng)消息的可靠傳輸提供了相應(yīng)的機(jī)制,Max-Forwards字段。表示該請(qǐng)求到達(dá)其目的地址所允許經(jīng)過的中轉(zhuǎn)站的最大值為70。,Allow字段。給出IP地址為16的SoftX3000支持的請(qǐng)求消息類型列表。,Content-length字段，給出消息體的長度為230個(gè)字節(jié),Content-Type字段，表示消息中攜帶的消息體是單消息體且為SDP。,SDP協(xié)議版本號(hào)，目前為0版本。,會(huì)話擁有者/創(chuàng)建者和會(huì)話標(biāo)識(shí)，用于給出會(huì)話的發(fā)起者（其用戶名和用戶主機(jī)地址）以及會(huì)話標(biāo)識(shí)和會(huì)話版本號(hào)?！癏uaweiSoftX3000”為用戶名，用戶名是用戶在發(fā)起主機(jī)上的登錄名。第一個(gè)“1073741831”為會(huì)話標(biāo)識(shí)。第二個(gè)“1073741831”為版本號(hào)?！癐N”指網(wǎng)絡(luò)類型，目前規(guī)定的“IN”為Inernet?！癐P4”指地址類型，目前已定義的有“IP4”和“IP6”兩種?！?6”為創(chuàng)建會(huì)話的主機(jī)的IP地址。,會(huì)話名。每個(gè)會(huì)話描述必需有一個(gè)且只有一個(gè)會(huì)話名。,連接數(shù)據(jù)。網(wǎng)絡(luò)類型和地址類型目前的定義值僅限于IN和IP4。“5”為SoftX3000（IP地址：16）控制下的MG的IP地址（終端類型為IAD/AG下掛的ESL電話）或SIP、H.323終端的IP地址（終端類型為SIP、H.323電話）。,時(shí)間描述，給出會(huì)話激活的時(shí)間區(qū)段，允許會(huì)話周期性發(fā)生。,媒體級(jí)描述，“audio”表示媒體類型為音頻。目前定義的媒體類型有5種：音頻、視頻、應(yīng)用、數(shù)據(jù)和控制?！?0000”指明媒體流發(fā)往的傳送層端口，即MG的UDP端口號(hào)（終端類型為IAD/AG下掛的ESL電話）或SIP、H.323終端的UDP端口號(hào)（終端類型為SIP、H.323電話）?！癛TP/AVP”為傳送層協(xié)議，其值和“c”行中的地址類型有關(guān)，對(duì)于IP4來說，大多數(shù)媒體業(yè)務(wù)流都在RTP/UDP上傳送，已定義如下兩類協(xié)議：RTP/AVP，音頻/視頻應(yīng)用文檔，在UDP上傳送；Udp，UDP協(xié)議?！?0418”對(duì)于音頻和視頻來說，就是RTP音頻/視頻應(yīng)用文檔中定義的媒體靜荷類型。表示會(huì)話中所有這些格式都可能被用到，但第一個(gè)格式是會(huì)話的缺省格式。,rtpmap屬性行，指明從RTP靜荷類型至編碼的映射關(guān)系。該行的格式為：a:rtpmap:/。其中，指的就是音頻信道數(shù)，對(duì)于視頻信號(hào)尚無編碼參數(shù)。,Page40,問題,SIP協(xié)議定義了哪些基本請(qǐng)求消息，請(qǐng)求消息的格式是怎樣的？SIP請(qǐng)求消息中必須包含哪些頭域，它們的作用是什么？,Page41,第1章SIP協(xié)議原理第2章SIP命令和消息第3章業(yè)務(wù)流程分析,Page42,第3章業(yè)務(wù)流程分析第1節(jié)注冊(cè)流程第2節(jié)兩個(gè)UAC之間的呼叫流程,Page43,注冊(cè)流程,用戶每次開機(jī)時(shí)都需要向服務(wù)器注冊(cè)，當(dāng)SIPClient的地址發(fā)生改變時(shí)也需要重新注冊(cè)，注冊(cè)信息必須定期刷新，通常注冊(cè)服務(wù)器將注冊(cè)信息保存到定位服務(wù)器中。,Page44,注冊(cè)過程（實(shí)例）,REGISTERsip:1;transport=udpSIP/2.0Via:SIP/2.0/UDP5:5060;branch=z9hG4bK24d79975663f90c893883f21dRoute:Call-ID:2aff391ab79bf4cd9c762716949cd68eFrom:;tag=0589c28eTo:CSeq:1REGISTERContact:Expires:600Accept:application/sdp,application/mwi,application/reginfo+xml,application/simservs+xmlSupported:100rel,replaces,timer,privacyAccept-Encoding:identityAccept-Language:enAllow:INVITE,ACK,OPTIONS,BYE,CANCEL,REGISTER,INFO,PRACK,SUBSCRIBE,NOTIFY,UPDATE,MESSAGE,REFERMax-Forwards:70Content-Length:0,SIP/2.0200OKVia:SIP/2.0/UDP5:5060;branch=z9hG4bK24d79975663f90c893883f21dFrom:;tag=0589c28eTo:Call-ID:2aff391ab79bf4cd9c762716949cd68eCSeq:1REGISTERContact:;q=0.5;expires=599Content-Length:0,Page45,帶認(rèn)證請(qǐng)求的注冊(cè)流程,SoftX3000,SIPPhone,401Unauthorized,REGISTER,200OK,REGISTER,終端發(fā)起請(qǐng)求時(shí)如果服務(wù)器端需要對(duì)用戶進(jìn)行認(rèn)證，那么會(huì)在本地產(chǎn)生本次認(rèn)證的NONCE，并且通過認(rèn)證請(qǐng)求頭域（Authorization）將所有必要的參數(shù)返回給終端從而發(fā)起對(duì)用戶認(rèn)證過程。,終端收到認(rèn)證請(qǐng)求消息后根據(jù)服務(wù)器端返回的信息和用戶配置等信息采用特定的算法生成加密的RESPONSE，并且通過新的請(qǐng)求消息發(fā)送給服務(wù)器端。,服務(wù)器端在收到帶有認(rèn)證響應(yīng)的新的請(qǐng)求消息后首先檢查NONCE的正確性。如果NONCE不是本地產(chǎn)生，則直接返回失敗。否則如果NONCE是本地產(chǎn)生，但是認(rèn)證過程已經(jīng)超時(shí)，則服務(wù)器端會(huì)重新產(chǎn)生NONCE并重新發(fā)起對(duì)用戶的認(rèn)證過程。其中老的NONCE會(huì)通過CNONCE參數(shù)返回。NONCE驗(yàn)證通過后服務(wù)器端會(huì)根據(jù)NONCE、用戶名、密碼（服務(wù)器端可以根據(jù)本地用戶信息獲取用戶的密碼）、URI等采用和終端相同的算法生成RESPONSE，并且對(duì)此RESPONSE和請(qǐng)求消息中的RESPONSE進(jìn)行比較，如果二者一致則用戶認(rèn)證成功，否則認(rèn)證失敗。,Page46,帶認(rèn)證請(qǐng)求的注冊(cè)流程（實(shí)例）,SIP-Call:Alice,SIP-Call:D,REGISTERsip:0SIP/2.0From:sip:65400120;tag=16838c16838To:sip:65400120;tag=946e6f96Call-Id:1-reg51Cseq:2762REGISTERContact:sip:654001251Expires:100Content-Length:0Accept-Language:enSupported:sip-cc,si