sip的基本原理與機(jī)制.ppt

1 SIP的基本原理與機(jī)制 2 總目錄 1 SIP協(xié)議體系的總體框架2 請求3 答復(fù)4 頭域5 消息體6 各種硬件的行為7 SIP的安全機(jī)制參考文獻(xiàn) 3 1 SIP協(xié)議體系的總體框架 1 1SIP協(xié)議的通用性1 2SIP協(xié)議的中的硬件組成1 3請求 答復(fù)與SIP處理1 4SIP地址1 5頭域和消息體1 6其他重要概念 4 1 SIP協(xié)議體系的總體框架 SIP SessionInitiationProtocol 初始會話協(xié)議 協(xié)議的功能是創(chuàng)建 修改及終止會話 在會話過程中 SIP只起到保持會話的作用 而會話本身則不是由SIP來完成的 5 1 SIP協(xié)議體系的總體框架 1 1SIP協(xié)議的通用性會話可以是雙方會話 也可以是多方會話 會話所采用媒體形式受設(shè)備的限制 而受SIP協(xié)議的限制 SIP協(xié)議只是在會話發(fā)起過程中 對通信各方的性能進(jìn)行勾通而已 SIP協(xié)議的應(yīng)用要求與底層的傳輸協(xié)議無關(guān) 在SIP最低配置情況下 SIP協(xié)議至少要在TCP和UDP兩個(gè)協(xié)議體系下都能夠應(yīng)用 6 1 SIP協(xié)議體系的總體框架 1 2SIP協(xié)議的中的硬件組成客戶端 UAC useragentclient 服務(wù)器 server 用戶服務(wù)器 UAS useragentserver 代理服務(wù)器 proxyserver 重定向服務(wù)器 redirectserver 注冊器 register 注 硬件 在這里等于功能實(shí)體 7 1 SIP協(xié)議體系的總體框架 1 2SIP協(xié)議的中的硬件組成 8 1 SIP協(xié)議體系的總體框架 1 2SIP協(xié)議的中的硬件組成客戶端是發(fā)出請求 request 的功能實(shí)體服務(wù)器接收 處理請求和答復(fù) 并在一定情況下也對請求做出答復(fù) response 的功能實(shí)體 包括UAS 用戶代理是SIP處理的實(shí)際參與者 SIP處理后文介紹 用戶是會話的實(shí)際參與者 9 1 SIP協(xié)議體系的總體框架 1 3請求 答復(fù)與SIP處理請求客戶端通過發(fā)送請求最終實(shí)現(xiàn)與其他一個(gè)或多個(gè)用戶代理之間的創(chuàng)建 修改及終止會話 請求的方法 Method 主要有 邀請 INVITE 確認(rèn) ACK 選擇 OPTION 再見 BYE 取消 CANCEL 和注冊 REGISTER 10 1 SIP協(xié)議體系的總體框架 1 3請求 應(yīng)答與SIP處理 答復(fù)答復(fù)是服務(wù)器對請求的響應(yīng) 如果按照答復(fù)中的狀態(tài)碼 statuscode 分類 答復(fù)可以分為1 6 六種類型 一個(gè)請求的發(fā)出也可能引起一系列的答復(fù) 11 1 SIP協(xié)議體系的總體框架 1 3請求 應(yīng)答與SIP處理臨時(shí)答復(fù)和最終答復(fù)比如 當(dāng)請求發(fā)出以后 在請求尚未到達(dá)目的地之前或正在被處理的階段 首先與客戶端進(jìn)行通信的服務(wù)器就會向客戶端發(fā)出臨時(shí)答復(fù) 如100 Trying 答復(fù) 而當(dāng)請求被接受或拒絕時(shí) 服務(wù)器或被叫方發(fā)出的就是最終答復(fù) 12 1 SIP協(xié)議體系的總體框架 1 3請求 答復(fù)與SIP處理發(fā)送和處理請求與答復(fù)就是SIP硬件的基本功能 所有的SIP操作都是由一系列的請求和答復(fù)的交互過程所組成的 從一個(gè)SIP請求的產(chǎn)生到這個(gè)請求得到了最終答復(fù)的整個(gè)過程中 通信各方所產(chǎn)生的所有的請求與答復(fù)的總合稱為一個(gè)SIP處理 transaction 13 1 SIP協(xié)議體系的總體框架 1 4SIP地址URL UniformResourceLocator 統(tǒng)一資源定位 URL是用戶代理的地址 它的形式是user host 其中 user是一個(gè)用戶名或電話號碼 而host則是一個(gè)域名或數(shù)字地址 為了與Internet地址形式相區(qū)別 在寫SIP地址時(shí)一定要加上 sip 即sip user host 比如sip sales 14 1 SIP協(xié)議體系的總體框架 1 4SIP地址用戶代理的URL的確定是通過客戶端向注冊器發(fā)送注冊請求來獲得的 Request URI UniformResourceIdentify 統(tǒng)一資源標(biāo)識符 Request URI指定了目標(biāo)用戶或服務(wù)器 請求將被發(fā)到的下一個(gè)hop 的地址 Request URI可以是SIPURL 也可以是一般的URI 15 1 SIP協(xié)議體系的總體框架 1 4SIP地址參數(shù)如果把地址理解為可以與目的地取得聯(lián)系的必要信息的話 那么SIP協(xié)議中還有其他一些與地址有關(guān)的重要參數(shù) 比如 branch 分支 參數(shù) tag參數(shù)等參數(shù)可以出現(xiàn)在各種頭域中 16 1 SIP協(xié)議體系的總體框架 1 4SIP地址舉例 協(xié)議P57 協(xié)議P132 From A G Bell From sip 12125551212 From AnonymousTo Bobsip bob tag 376364382 17 1 SIP協(xié)議體系的總體框架 1 5頭域和消息體頭域蟲形結(jié)構(gòu)圖 18 1 SIP協(xié)議體系的總體框架 1 5頭域和消息體頭域 headerfield SIP是通過附加在請求或答復(fù)中若干頭域來傳遞和處理與會話相關(guān)的若干信息 如路由 呼叫標(biāo)識 安全機(jī)制 會話描述等一個(gè)頭域中還會包含若干個(gè)參數(shù) 在特定SIP處理中 不是所有參數(shù)都必須給出 舉例 From To Via Call ID CSeq Hide Date 19 1 SIP協(xié)議體系的總體框架 1 5頭域和消息體消息體 messagebody 除了頭域之外 請求和答復(fù)中還可能包含消息體 在不同的情況下 消息體包含不同的內(nèi)容 具體情況請參見第5章 其余 請求與答復(fù)中信息的主要載體就是頭域和消息體 但也還有其余的內(nèi)容 如在答復(fù)中 狀態(tài)碼就寫在消息的頭一行 而不在任何頭域之內(nèi) 20 1 SIP協(xié)議體系的總體框架 1 6其他重要概念CalllegCallleg并不是某個(gè)具體的頭域或參數(shù) 它是由Call ID From和To三個(gè)頭域中信息共同組成的 實(shí)際上 可以這樣理解Callleg Callleg唯一確定了一個(gè)會話 可能是雙方會話 也可能是多方會話 中的一對連接 21 2 請求 2 1邀請 INVITE 2 2確認(rèn) ACK 2 3選擇 OPTION 2 4再見 BYE 2 5取消 CANCEL 2 6注冊 REGISTER 22 2 請求 客戶端通過發(fā)送請求來觸發(fā)一次創(chuàng)建 修改及終止會話的SIP處理 請求的主要方法也就是以下這幾種 邀請 INVITE 確認(rèn) ACK 選擇 OPTION 再見 BYE 取消 CANCEL 注冊 REGISTER 23 2 請求 2 1邀請 INVITE 邀請請求是會話建立的第一步在邀請請求的消息體中 呼叫方要向被叫方提供會話描述被叫方對邀請請求的成功的答復(fù)應(yīng)當(dāng)包括被叫方可以接受的媒體類型和它希望發(fā)送的媒體類型 24 2 請求 2 1邀請 INVITE 被叫方可能收到相同或重復(fù)的請求 若該用戶已經(jīng)加入了這個(gè)特定的會話 用戶服務(wù)器就會自動答復(fù)一個(gè)200 OK 必須支持此方法的硬件有 客戶端 用戶服務(wù)器 代理服務(wù)器 重定向服務(wù)器 25 2 請求 2 2確認(rèn) ACK 確認(rèn)請求只與邀請請求伴隨而生 它表示主叫方收到了對其邀請請求的最終答復(fù) 這個(gè)最終答復(fù)不一定來自被叫方 也不一定表示邀請成功 必須支持此方法的硬件有 客戶端 用戶服務(wù)器 代理服務(wù)器 重定向服務(wù)器 26 2 請求 2 2確認(rèn)注 2 答復(fù)表示成功邀請失敗可以有多種原因 如 被拒絕或找不到被叫方等 27 2 請求 2 3選擇 OPTION 這個(gè)請求主要是讓通信各方能夠根據(jù)各種情況來確定如何通話或不通話 必須支持此方法的硬件有 客戶端 用戶服務(wù)器 代理服務(wù)器 重定向服務(wù)器 注冊器 28 2 請求 2 4再見 BYE 客戶端用再見請求來告知服務(wù)器它想結(jié)束此次呼叫主叫方和被叫方都可以發(fā)出此請求在客戶端發(fā)出再見請求之前 不可以釋放當(dāng)前呼叫 掛機(jī) 會話的參與各方在收到再見請求后應(yīng)立即停止對目標(biāo)發(fā)送任何媒體流 29 2 請求 2 4再見 BYE 若邀請請求中有Contact頭域 被叫方就要把再見請求發(fā)送到這個(gè)頭域中的地址 而不是發(fā)送到From頭域中的From地址 必須支持此功能的硬件有 客戶端 用戶服務(wù)器 代理服務(wù)器 重定向服務(wù)器 30 2 請求 2 5取消 CANCEL 取消請求把與其具有相同的Call ID To From CSeq頭域值的請求取消取消請求只能用于取消那些懸而未決的請求 所謂 懸而未決 是指最終答復(fù)尚未發(fā)出客戶端和代理客戶端 proxyclient 都可以發(fā)出取消請求 31 2 請求 2 5取消 CANCEL 一旦用戶服務(wù)器收到一個(gè)取消請求 它就不能對原來的那個(gè)請求做出2XX的答復(fù) 因?yàn)檫@個(gè)請求已經(jīng)被取消了必須支持此方法的硬件有 所有的硬件 32 2 請求 2 6注冊 REGISTER 客戶端通過注冊請求把自己的地址注冊到SIP服務(wù)器 一個(gè)客戶端通過向通用的 allSIPservers 多播地址 224 0 1 75 發(fā)送注冊請求來實(shí)現(xiàn)在本地服務(wù)器上注冊 接收并處理注冊請求的任何服務(wù)器在接收注冊請求時(shí)就是注冊器 一般是代理服務(wù)器 33 2 請求 2 6注冊 REGISTER Request URI則是給登記請求的目的地 發(fā)出請求的客戶端 命名 Contact頭域在注冊請求中十分重要 如果注冊請求中含有Contact頭域 那么在未來有某個(gè)非注冊請求要被發(fā)送到To頭域中給出的地址時(shí) 那么這個(gè)請求將直接被發(fā)送到Contact頭域給出的地址 34 3 答復(fù) 答復(fù)是服務(wù)器對請求的響應(yīng) 但服務(wù)器對請求的響應(yīng)不只是答復(fù) 答復(fù)中最重要的信息是狀態(tài)碼 status code 其他信息則包含在頭域和消息體中 狀態(tài)碼寫在答復(fù)消息的第一行 它是由3位整數(shù)數(shù)字組成 狀態(tài)碼指明了接收請求的一方嘗試?yán)斫夂蜐M足所收到的請求的結(jié)果 35 3 答復(fù) 3個(gè)數(shù)字中 第一個(gè)表示答復(fù)的種類 后兩個(gè)數(shù)字沒有特別的分類 它們的基本含義如下 1XX 通知形 收到請求 正在繼續(xù)處理請求 2XX 表示成功 動作被成功的接收 理解和操作 3XX 重新進(jìn)行請求 要完成請求還需要進(jìn)一步的信息和操作 36 3 答復(fù) 4XX 用戶方錯誤 由于用戶方問題無法完成操作 請求中包含錯誤的語法或不能被滿足的內(nèi)容 5XX 服務(wù)方錯誤 由于服務(wù)方問題無法完成操作 對于一個(gè)明顯是有效的請求 服務(wù)器無法滿足 6XX 全球錯誤 該請求在任何服務(wù)器上都無法完成 37 3 答復(fù) 要完成基本的通信功能 參與通信的任何一方不必有能力理解所有的狀態(tài)碼 只需知道其種類也就可以進(jìn)行大部分工作了 當(dāng)其不理解XXX時(shí) 就按X00處理 對于每一個(gè)具體狀態(tài)碼的功能和含義 在協(xié)議第4 7章有逐條的說明 不難理解 而答復(fù)的其他功能和處理則多與頭域有關(guān) 38 4 頭域 4 1頭域概述4 2重要頭域舉例 39 4 頭域 4 1頭域 headerfield或field 概述頭域是SIP請求或答復(fù)中的一段內(nèi)容 不同的頭域有不同的主題和作用 頭域分類1 請求頭域答復(fù)頭域在請求和答復(fù)都可以使用的頭域 40 4 頭域 4 1頭域概述頭域分類2 一般 General 頭域一般 General 頭域是頭域的通稱Entity 實(shí)體 頭域Entity頭域 是對消息體 message body 或如果沒有消息體時(shí)被 請求 認(rèn)證 identified 的源的meta information的解釋 在協(xié)議中 messagebody entity 41 4 頭域 4 1頭域概述頭域分類3 End To end頭域End To end頭域不能被代理服務(wù)器修改 如Call ID FromHop by hop頭域Hop by hop頭域則有可能被代理服務(wù)器修改 如Via Max Forward 42 4 頭域 4 1頭域概述99版本SIP協(xié)議中的頭域 Accept Accept Encoding Accept Language Accept Language Allow Authorization Call ID Contact Contact Contact Content Encoding Content Length Content Type CSeq Date Encryption Expires From Hide Max Forwards Organization 43 4 頭域 4 1頭域概述99版本SIP協(xié)議中的頭域 Proxy Authenticate Proxy Authorization Proxy Require Priority Require Retry After Retry After Response Key Record Route Record Route Route Server Subject Timestamp To Unsupported User Agent Via Warning WWW Authenticate 44 4 頭域 4 2重要頭域舉例第一組From To Via Route Record Route第二組Call ID CSeq User Agent第三組Accept Accept Encoding Accept Language Allow 45 4 頭域 4 2重要頭域舉例第四組Date Expires Timestamp第五組Hide Encryption Proxy Authenticate Proxy Authorization Authorization頭域的格式參見協(xié)議6 6節(jié) 46 5 消息體 5 1消息體的內(nèi)容5 2消息體的種類5 3消息體的長度請求和答復(fù)中還可能包含消息體 它在不同的情況下有不同的作用 47 5 消息體 5 1消息體的內(nèi)容請求一般來說包含消息體 只有再見請求中不能有消息體確認(rèn) 邀請和選擇請求中的消息體的內(nèi)容都是會話描述會話描述要遵循會話描述協(xié)議 SIPVersionof SIP 2 0 48 5 消息體 5 1消息體的內(nèi)容所有的答復(fù)中都可能有消息體 請求的方法和答復(fù)的狀態(tài)碼決定了消息體的種類和說明在1 答復(fù)中 消息體包含對請求的進(jìn)一步詢問在用2 答復(fù)邀請請求時(shí) 消息體包含會話描述 49 5 消息體 5 1消息體的內(nèi)容在3 答復(fù)中 消息中可能包含目的地和服務(wù)的可選項(xiàng)的描述在400以上的答復(fù)中 消息體包含對于失敗的附加的信息 這些信息用自然語言寫成 是人可讀的 50 5 消息體 5 2消息體的種類編寫消息體所采用的媒體類型可能有多種 必須由Content Type頭域來說明如果消息體被編碼 如壓縮 這種情況就一定要在Content Encoding頭域中說明 除此以外 Content Encoding頭域就必須被省略 51 5 消息體 5 3消息體的長度消息體長度以byte為單位 由Content Length頭域給出 52 6 各種硬件的行為 6 1客戶端與服務(wù)器的最小配置6 2客戶端與服務(wù)器的基本行為6 3呼叫方與被叫方的行為6 4重定向服務(wù)器的行為6 5用戶服務(wù)器的行為6 6代理服務(wù)器的行為 53 6 各種硬件的行為 本章的內(nèi)容比較復(fù)雜 涉及到許多基本的操作 一兩句話說不清楚 為了講課簡潔明了 這里只講幾個(gè)重要的問題 至于具體操作與實(shí)現(xiàn)請參閱 SIP協(xié)議99版總結(jié)與歸納20041014 及SIP協(xié)議本身 54 6 各種硬件的行為 6 1客戶端與服務(wù)器的最小配置硬件不一定非要有能力完成所有的SIP功能客戶端的最低配置是 要能發(fā)出邀請和確認(rèn)請求 能夠產(chǎn)生和分析Call ID Content Length Content Type CSeq From和To頭域 能分析需求頭 要能理解SDP 會話描述協(xié)議 55 6 各種硬件的行為 6 1客戶端與服務(wù)器的最小配置 能識別狀態(tài)碼 1 6 并依此做出反應(yīng) 在滿足最低配置之后 客戶端可以 依次 附加以下功能 Redirection Firewall friendly Negotiation Authentication 56 6 各種硬件的行為 6 1客戶端與服務(wù)器的最小配置服務(wù)器的最小配置 必須能理解邀請 確認(rèn) 選擇和再見請求 代理服務(wù)器還必須能理解取消請求 能分析和產(chǎn)生Call ID Content Length Content Type CSeq Expires From Maxforwards Require To和Via頭域等 57 6 各種硬件的行為 6 1客戶端與服務(wù)器的最小配置服務(wù)器的最小配置 須能在答復(fù)中重復(fù)CSeq和Timestamp頭域 它必須能在答復(fù)中加入Server頭域其它具體情況可以參見協(xié)議P135的Table6 58 6 各種硬件的行為 6 2客戶端與服務(wù)器的基本行為客戶端與服務(wù)器對請求的處理 服務(wù)器丟棄同態(tài)的請求 適當(dāng)重傳答復(fù) 代理服務(wù)器收到取消請求時(shí) 可能會向所有的尚未發(fā)出最終答復(fù)的分支發(fā)出取消請求 客戶端與服務(wù)器要檢查From To頭域中的tag值 Call ID Cseq頭域等 以對請求與其它們的關(guān)系做出判斷 59 6 各種硬件的行為 6 2客戶端與服務(wù)器的基本行為客戶端與服務(wù)器對答復(fù)的處理 服務(wù)器在發(fā)送最終答復(fù)之前可能會發(fā)送若干臨時(shí)答復(fù) 1 答復(fù)通過匹配To From Call ID CSeq頭域及第一個(gè)Via頭中的branch參數(shù)被指向請求的發(fā)出者 答復(fù)會終止重傳請求 60 6 各種硬件的行為 6 2客戶端與服務(wù)器的基本行為客戶端與服務(wù)器對答復(fù)的處理 100 Trying 答復(fù)不能被向前傳遞 其它1 答復(fù)可以向前傳遞 一個(gè)代理服務(wù)器收到2 答復(fù) 不可以向前傳非2 的答復(fù) 對于300以上的答復(fù) stateful 參見6 6節(jié) 代理服務(wù)器在收到確認(rèn)請求之前不斷重傳該答復(fù) 61 6 各種硬件的行為 6 2客戶端與服務(wù)器的基本行為盡管SIP協(xié)議是應(yīng)用層協(xié)議 要求與底層傳輸協(xié)議無關(guān) 但在使用TCP和UDP是 一些操作是不同的 硬件必須能面對這種不同 SIP有自己的可靠性機(jī)制 請求和答復(fù)都有一定的重傳規(guī)則 重傳所依據(jù)的基本參數(shù)是時(shí)間 62 6 各種硬件的行為 6 3呼叫方與被叫方的行為會話的實(shí)際參與者是若干的用戶代理 客戶端與用戶服務(wù)器 上的用戶 也就是呼叫方和被叫方 服務(wù)器只是把客戶端連接起來 呼叫方和被叫方的行為才是會話建立 修改和終結(jié)的實(shí)際行為 63 6 各種硬件的行為 6 3呼叫方與被叫方的行為會話過程主要有以下一些操作 呼叫方發(fā)出邀請請求 被叫方發(fā)出答復(fù) 呼叫方收到對最初請求的答復(fù) 呼叫方與被叫方產(chǎn)生一系列請求 接收一系列的請求 64 6 各種硬件的行為 6 4重定向服務(wù)器的行為重定向服務(wù)器不會自己提出 issue 任何SIP請求 重定向服務(wù)器收到一個(gè)請求 除取消請求之外 后 就收集其列表 list 中可選的位置信息 并返回一個(gè)3 型的最終答復(fù)或拒絕該請求 對于格式標(biāo)準(zhǔn)的取消請求 重定向服務(wù)器必須返回一個(gè)2 型答復(fù) 該答復(fù)終止了該SIP處理 重定向服務(wù)器負(fù)責(zé)維持整個(gè)SIP處理狀態(tài) 65 6 各種硬件的行為 6 5用戶服務(wù)器的行為用戶服務(wù)器的行為與重定向服務(wù)器的行為差不多 只是它也可以接受請求并回答2 型答復(fù) 66 6 各種硬件的行為 6 6代理服務(wù)器的行為代理服務(wù)器是SIP服務(wù)器中行為最復(fù)雜 最為重要的一種服務(wù)器 實(shí)際上 重定向服務(wù)器和注冊器一般都不獨(dú)