sip的基本原理與機制.pptVIP

1,SIP的基本原理與機制,2,總目錄,1.SIP協(xié)議體系的總體框架 2.請求 3.答復(fù) 4.頭域 5.消息體 6.各種硬件的行為 7.SIP的安全機制 參考文獻(xiàn),3,1. SIP協(xié)議體系的總體框架,1.1 SIP協(xié)議的通用性 1.2 SIP協(xié)議的中的硬件組成 1.3 請求、答復(fù)與SIP處理 1.4 SIP地址 1.5 頭域和消息體 1.6 其他重要概念,4,1. SIP協(xié)議體系的總體框架,SIP（Session Initiation Protocol初始會話協(xié)議）協(xié)議的功能是創(chuàng)建、修改及終止會話。在會話過程中，SIP只起到保持會話的作用，而會話本身則不是由SIP來完成的。,5,1. SIP協(xié)議體系的總體框架,1.1 SIP協(xié)議的通用性 會話可以是雙方會話，也可以是多方會話。 會話所采用媒體形式受設(shè)備的限制，而受SIP協(xié)議的限制，SIP協(xié)議只是在會話發(fā)起過程中，對通信各方的性能進(jìn)行勾通而已。 SIP協(xié)議的應(yīng)用要求與底層的傳輸協(xié)議無關(guān)。在SIP最低配置情況下，SIP協(xié)議至少要在TCP和UDP兩個協(xié)議體系下都能夠應(yīng)用。,6,1. SIP協(xié)議體系的總體框架,1.2 SIP協(xié)議的中的硬件組成 客戶端（UAC：user agent client） 服務(wù)器（server）： 用戶服務(wù)器（UAS：user agent server） 代理服務(wù)器（proxy server） 重定向服務(wù)器（redirect server） 注冊器（register） 注：“硬件”在這里等于功能實體,7,1. SIP協(xié)議體系的總體框架,1.2 SIP協(xié)議的中的硬件組成,8,1. SIP協(xié)議體系的總體框架,1.2 SIP協(xié)議的中的硬件組成 客戶端是發(fā)出請求（request）的功能實體 服務(wù)器接收、處理請求和答復(fù)，并在一定情況下也對請求做出答復(fù)（response）的功能實體（包括UAS） 用戶代理是SIP處理的實際參與者。（SIP處理后文介紹） 用戶是會話的實際參與者,9,1. SIP協(xié)議體系的總體框架,1.3 請求、答復(fù)與SIP處理 請求 客戶端通過發(fā)送請求最終實現(xiàn)與其他一個或多個用戶代理之間的創(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)碼（status code）分類，答復(fù)可以分為16六種類型。 一個請求的發(fā)出也可能引起一系列的答復(fù),11,1. SIP協(xié)議體系的總體框架,1.3 請求、應(yīng)答與SIP處理 臨時答復(fù)和最終答復(fù) 比如，當(dāng)請求發(fā)出以后，在請求尚未到達(dá)目的地之前或正在被處理的階段，首先與客戶端進(jìn)行通信的服務(wù)器就會向客戶端發(fā)出臨時答復(fù)（如100（Trying）答復(fù)）。 而當(dāng)請求被接受或拒絕時，服務(wù)器或被叫方發(fā)出的就是最終答復(fù)。,12,1. SIP協(xié)議體系的總體框架,1.3 請求、答復(fù)與SIP處理 發(fā)送和處理請求與答復(fù)就是SIP硬件的基本功能，所有的SIP操作都是由一系列的請求和答復(fù)的交互過程所組成的。 從一個SIP請求的產(chǎn)生到這個請求得到了最終答復(fù)的整個過程中，通信各方所產(chǎn)生的所有的請求與答復(fù)的總合稱為一個SIP處理（transaction）。,13,1. SIP協(xié)議體系的總體框架,1.4 SIP地址 URL（Uniform Resource Locator-統(tǒng)一資源定位） URL是用戶代理的地址，它的形式是userhost。其中，user是一個用戶名或電話號碼,而host則是一個域名或數(shù)字地址。為了與Internet地址形式相區(qū)別，在寫SIP地址時一定要加上“sip：”，即sip：userhost。 比如sip：,14,1. SIP協(xié)議體系的總體框架,1.4 SIP地址 用戶代理的URL的確定是通過客戶端向注冊器發(fā)送注冊請求來獲得的。 Request-URI（Uniform Resource Identify-統(tǒng)一資源標(biāo)識符） Request-URI指定了目標(biāo)用戶或服務(wù)器（請求將被發(fā)到的下一個hop）的地址。Request-URI可以是SIP URL，也可以是一般的URI。,15,1. SIP協(xié)議體系的總體框架,1.4 SIP地址 參數(shù) 如果把地址理解為可以與目的地取得聯(lián)系的必要信息的話，那么SIP協(xié)議中還有其他一些與地址有關(guān)的重要參數(shù)。比如： branch（分支）參數(shù)； tag參數(shù)等 參數(shù)可以出現(xiàn)在各種頭域中,16,1. SIP協(xié)議體系的總體框架,1.4 SIP地址 舉例（協(xié)議P57，協(xié)議P132） : From: “A. G. Bell“ From: sip:+12125551212 From: Anonymous To: Bob sip:; tag=376364382,17,1. SIP協(xié)議體系的總體框架,1.5 頭域和消息體 頭域 蟲形結(jié)構(gòu)圖,18,1. SIP協(xié)議體系的總體框架,1.5 頭域和消息體 頭域（header field） SIP是通過附加在請求或答復(fù)中若干頭域來傳遞和處理與會話相關(guān)的若干信息，如路由、呼叫標(biāo)識、安全機制、會話描述等 一個頭域中還會包含若干個參數(shù)。在特定SIP處理中，不是所有參數(shù)都必須給出。 舉例：From, To, Via;Call-ID, CSeq; Hide; Date,19,1. SIP協(xié)議體系的總體框架,1.5 頭域和消息體 消息體（message body） 除了頭域之外，請求和答復(fù)中還可能包含消息體，在不同的情況下，消息體包含不同的內(nèi)容。具體情況請參見第5章。 其余：請求與答復(fù)中信息的主要載體就是頭域和消息體，但也還有其余的內(nèi)容。如在答復(fù)中，狀態(tài)碼就寫在消息的頭一行，而不在任何頭域之內(nèi)。,20,1. SIP協(xié)議體系的總體框架,1.6 其他重要概念 Call leg Call leg并不是某個具體的頭域或參數(shù)，它是由Call-ID，F(xiàn)rom和To三個頭域中信息共同組成的。 實際上，可以這樣理解Call leg：Call leg唯一確定了一個會話（可能是雙方會話，也可能是多方會話。）中的一對連接。,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)加入了這個特定的會話，用戶服務(wù)器就會自動答復(fù)一個200（OK） 必須支持此方法的硬件有： 客戶端、用戶服務(wù)器、代理服務(wù)器、重定向服務(wù)器。,25,2.請求,2.2確認(rèn)（ACK） 確認(rèn)請求只與邀請請求伴隨而生，它表示主叫方收到了對其邀請請求的最終答復(fù)。（這個最終答復(fù)不一定來自被叫方，也不一定表示邀請成功） 必須支持此方法的硬件有： 客戶端、用戶服務(wù)器、代理服務(wù)器、重定向服務(wù)器。,26,2.請求,2.2確認(rèn) 注： 2答復(fù)表示成功 邀請失敗可以有多種原因，如：被拒絕或找不到被叫方等。,27,2.請求,2.3選擇（OPTION） 這個請求主要是讓通信各方能夠根據(jù)各種情況來確定如何通話或不通話。 必須支持此方法的硬件有： 客戶端、用戶服務(wù)器、代理服務(wù)器、重定向服務(wù)器、注冊器。,28,2.請求,2.4再見（BYE） 客戶端用再見請求來告知服務(wù)器它想結(jié)束此次呼叫 主叫方和被叫方都可以發(fā)出此請求 在客戶端發(fā)出再見請求之前，不可以釋放當(dāng)前呼叫（掛機）。 會話的參與各方在收到再見請求后應(yīng)立即停止對目標(biāo)發(fā)送任何媒體流。,29,2.請求,2.4再見（BYE） 若邀請請求中有Contact頭域，被叫方就要把再見請求發(fā)送到這個頭域中的地址，而不是發(fā)送到From頭域中的From地址。 必須支持此功能的硬件有： 客戶端、用戶服務(wù)器、代理服務(wù)器、重定向服務(wù)器。,30,2.請求,2.5取消（CANCEL） 取消請求把與其具有相同的Call-ID，To，F(xiàn)rom，CSeq頭域值的請求取消 取消請求只能用于取消那些懸而未決的請求。所謂“懸而未決”是指最終答復(fù)尚未發(fā)出 客戶端和代理客戶端(proxy client )都可以發(fā)出取消請求。,31,2.請求,2.5取消（CANCEL） 一旦用戶服務(wù)器收到一個取消請求，它就不能對原來的那個請求做出2XX的答復(fù) ,因為這個請求已經(jīng)被取消了 必須支持此方法的硬件有： 所有的硬件。,32,2.請求,2.6注冊（REGISTER） 客戶端通過注冊請求把自己的地址注冊到SIP 服務(wù)器。 一個客戶端通過向通用的 “all SIP servers”多播地址：“”(5)發(fā)送注冊請求來實現(xiàn)在本地服務(wù)器上注冊。 接收并處理注冊請求的任何服務(wù)器在接收注冊請求時就是注冊器（一般是代理服務(wù)器）,33,2.請求,2.6注冊（REGISTER） Request-URI則是給登記請求的目的地（發(fā)出請求的客戶端）命名。 Contact頭域在注冊請求中十分重要。如果注冊請求中含有Contact頭域，那么在未來有某個非注冊請求要被發(fā)送到To頭域中給出的地址時，那么這個請求將直接被發(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個數(shù)字中，第一個表示答復(fù)的種類，后兩個數(shù)字沒有特別的分類。它們的基本含義如下： 1XX：通知形收到請求，正在繼續(xù)處理請求。 2XX：表示成功動作被成功的接收、理解和操作。 3XX：重新進(jìn)行請求要完成請求還需要進(jìn)一步的信息和操作。,36,3.答復(fù),4XX：用戶方錯誤（由于用戶方問題無法完成操作）請求中包含錯誤的語法或不能被滿足的內(nèi)容。 5XX：服務(wù)方錯誤（由于服務(wù)方問題無法完成操作）對于一個明顯是有效的請求，服務(wù)器無法滿足。 6XX：全球錯誤該請求在任何服務(wù)器上都無法完成。,37,3.答復(fù),要完成基本的通信功能，參與通信的任何一方不必有能力理解所有的狀態(tài)碼，只需知道其種類也就可以進(jìn)行大部分工作了。當(dāng)其不理解XXX時，就按X00處理。 對于每一個具體狀態(tài)碼的功能和含義，在協(xié)議第4、7章有逐條的說明，不難理解。而答復(fù)的其他功能和處理則多與頭域有關(guān)。,38,4.頭域,4.1頭域概述 4.2重要頭域舉例,39,4.頭域,4.1頭域（header field或field）概述 頭域是SIP請求或答復(fù)中的一段內(nèi)容，不同的頭域有不同的主題和作用。 頭域分類1： 請求頭域 答復(fù)頭域 在請求和答復(fù)都可以使用的頭域,40,4.頭域,4.1頭域概述 頭域分類2： 一般（General）頭域 一般（General）頭域是頭域的通稱 Entity（實體）頭域 Entity頭域（是對消息體（message-body）或如果沒有消息體時被“請求”認(rèn)證（identified）的源的meta-information的解釋。在協(xié)議中，message body=entity,41,4.頭域,4.1頭域概述 頭域分類3： End-To-end頭域 End-To-end頭域不能被代理服務(wù)器修改， 如Call-ID、From Hop-by-hop頭域 Hop-by-hop頭域則有可能被代理服務(wù)器修改 ，如Via，MaxForward,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é)議（SIP Version of ”SIP/2.0”）,48,5.消息體,5.1消息體的內(nèi)容 所有的答復(fù)中都可能有消息體，請求的方法和答復(fù)的狀態(tài)碼決定了消息體的種類和說明 在1答復(fù)中，消息體包含對請求的進(jìn)一步詢問 在用2答復(fù)邀請請求時，消息體包含會話描述,49,5.消息體,5.1消息體的內(nèi)容 在3答復(fù)中，消息中可能包含目的地和服務(wù)的可選項的描述 在400以上的答復(fù)中，消息體包含對于失敗的附加的信息，這些信息用自然語言寫成，是人可讀的,50,5.消息體,5.2消息體的種類 編寫消息體所采用的媒體類型可能有多種，必須由ContentType頭域來說明 如果消息體被編碼（如壓縮），這種情況就一定要在ContentEncoding頭域中說明。除此以外，ContentEncoding頭域就必須被省略,51,5.消息體,5.3消息體的長度 消息體長度以byte為單位，由ContentLength頭域給出,52,6.各種硬件的行為,6.1客戶端與服務(wù)器的最小配置 6.2客戶端與服務(wù)器的基本行為 6.3呼叫方與被叫方的行為 6.4重定向服務(wù)器的行為 6.5用戶服務(wù)器的行為 6.6代理服務(wù)器的行為,53,6.各種硬件的行為,本章的內(nèi)容比較復(fù)雜，涉及到許多基本的操作，一兩句話說不清楚。為了講課簡潔明了，這里只講幾個重要的問題。至于具體操作與實現(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)碼（16），并依此做出反應(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的Table 6,58,6.各種硬件的行為,6.2客戶端與服務(wù)器的基本行為 客戶端與服務(wù)器對請求的處理： 服務(wù)器丟棄同態(tài)的請求，適當(dāng)重傳答復(fù)。 代理服務(wù)器收到取消請求時，可能會向所有的尚未發(fā)出最終答復(fù)的分支發(fā)出取消請求。 客戶端與服務(wù)器要檢查From、To頭域中的tag值，Call-ID、Cseq頭域等，以對請求與其它們的關(guān)系做出判斷,59,6.各種硬件的行為,6.2客戶端與服務(wù)器的基本行為 客戶端與服務(wù)器對答復(fù)的處理： 服務(wù)器在發(fā)送最終答復(fù)之前可能會發(fā)送若干臨時答復(fù) （1） 答復(fù)通過匹配To，F(xiàn)rom ，CallID，CSeq頭域及第一個Via頭中的branch參數(shù)被指向請求的發(fā)出者。答復(fù)會終止重傳請求,60,6.各種硬件的行為,6.2客戶端與服務(wù)器的基本行為 客戶端與服務(wù)器對答復(fù)的處理： 100（Trying ）答復(fù)不能被向前傳遞，其它1答復(fù)可以向前傳遞 一個代理服務(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有自己的可靠性機制，請求和答復(fù)都有一定的重傳規(guī)則。重傳所依據(jù)的基本參數(shù)是時間,62,6.各種硬件的行為,6.3呼叫方與被叫方的行為 會話的實際參與者是若干的用戶代理（客戶端與用戶服務(wù)器）上的用戶，也就是呼叫方和被叫方。服務(wù)器只是把客戶端連接起來。呼叫方和被叫方的行為才是會話建立、修改和終結(jié)的實際行為,63,6.各種硬件的行為,6.3呼叫方與被叫方的行為 會話過程主要有以下一些操作 呼叫方發(fā)出邀請請求 被叫方發(fā)出答復(fù) 呼叫方收到對最初請求的答復(fù) 呼叫方與被叫方產(chǎn)生一系列請求 接收一系列的請求,64,6.各種硬件的行為,6.4重定向服務(wù)器的行為 重定向服務(wù)器不會自己提出(issue)任何SIP請求。 重定向服務(wù)器收到一個請求（除取消請求之外）后，就收集其列表（list）中可選的位置信息，并返回一個3型的最終答復(fù)或拒絕該請求。 對于格式標(biāo)準(zhǔn)的取消請求，重定向服務(wù)器必須返回一個2型答復(fù)，該答復(fù)終止了該SIP處理。 重定向服務(wù)器負(fù)責(zé)維持整個SIP處理狀態(tài)。,65,6.各種硬件的行為,6.5用戶服務(wù)器的行為 用戶服務(wù)器的行為與重定向服務(wù)器的行為差不多，只是它也可以接受請求并回答2型答復(fù)。,66,6.各種硬件的行為,6.6代理服務(wù)器的行為 代理服務(wù)器是SIP服務(wù)器中行為最復(fù)雜，最為重要的一種服務(wù)器。實際上，重定向服務(wù)器