SIP協(xié)議及其在視頻監(jiān)控系統(tǒng)中的應(yīng)用.ppt

http SIP協(xié)議及其在視頻監(jiān)控系統(tǒng)中的應(yīng)用 SIP協(xié)議 什么是SIP SIP的設(shè)計原則SIP的架構(gòu)SIP的層次SIP的主要機制SIP的鑒權(quán)SIP的消息格式SIP的主要流程SIP事務(wù)SIP在視頻監(jiān)控系統(tǒng)中的應(yīng)用 什么是SIP SIP是一個應(yīng)用層的信令控制協(xié)議 用于創(chuàng)建 修改和釋放一個或多個參與者的會話 SIP可以邀請參與者加入一個已經(jīng)存在的一個會話中 例如一個多播會議 SIP可以動態(tài)的在會話中添加和刪除媒體數(shù)據(jù) SIP支持名字映射和重定向服務(wù) 什么是SIP SIP的會話控制功能會話維護會話協(xié)商內(nèi)容不作任何限制 比如終端的能力 終端的數(shù)據(jù)端口號等等 可以使用SDP或者其他的協(xié)議進行協(xié)商 這一點使得SIP有很好的擴展性 會話中可以承載的數(shù)據(jù)語音 視頻即時消息其他的自定義數(shù)據(jù)游戲SIP的名字映射功能SIP使用SIP邏輯地址來映射實際地址 這樣用戶發(fā)起呼叫時 不需要知道目標(biāo)的真正地址 就可以達到呼叫的目的 這樣可以很方便實現(xiàn)終端的移動性 SIP協(xié)議 什么是SIP SIP的設(shè)計原則SIP的架構(gòu)SIP的層次SIP的主要機制SIP的鑒權(quán)SIP的消息格式SIP的主要流程SIP事務(wù)SIP在視頻監(jiān)控系統(tǒng)中的應(yīng)用 SIP的設(shè)計原則 模仿HTTP1 1的風(fēng)格重用HTTP編碼 所有消息基于文本 便于開發(fā) 使用UTF 8字符集重用Internet尋址方案 使用RFC2369中定義的URI和URL格式 可以非常的靈活的和其他遵循這一定義的協(xié)議協(xié)作 對底層傳輸協(xié)議不做假設(shè)可以使用于多種協(xié)議 如UDP TCP TLS SCTP等等 雖然對底層傳輸協(xié)議不做假設(shè) 但是需要注意的是 它仍然將底層協(xié)議分為兩類 一類為不可靠的數(shù)據(jù)報傳輸協(xié)議 unreliabledatagramtransports 一類為流式的傳輸協(xié)議 stream orientedtransports 區(qū)分這兩類協(xié)議的主要目的在于 在是否重傳消息時需要區(qū)別對待 最常用的協(xié)議為UDP協(xié)議 SIP的設(shè)計原則 邏輯地址和聯(lián)系地址相分離邏輯地址用于標(biāo)志用戶聯(lián)系地址用于表明用戶當(dāng)前的位置 即當(dāng)前的實際地址 SIP協(xié)議 什么是SIP SIP的設(shè)計原則SIP的架構(gòu)SIP的層次SIP的主要機制SIP的鑒權(quán)SIP的消息格式SIP的主要流程SIP事務(wù)SIP在視頻監(jiān)控系統(tǒng)中的應(yīng)用 SIP的架構(gòu) 采用客戶端 服務(wù)器 C S 架構(gòu)主要單元用戶代理 UserAgent SIP服務(wù)器 Servers 代理服務(wù)器 Proxy 重定向服務(wù)器 Redirector 注冊服務(wù)器 Registar SIP的架構(gòu) 代理服務(wù)器 Proxy 用來接收請求 并尋找請求傳送的下一條地址 轉(zhuǎn)發(fā)請求 可以分為有狀態(tài)的和無狀態(tài)的 有狀態(tài)的代理服務(wù)器記住它接收的請求 回送的響應(yīng)以及它轉(zhuǎn)出的請求 無狀態(tài)的代理服務(wù)器則不記錄任何請求相關(guān)的信息 重定向服務(wù)器 Redirector 不轉(zhuǎn)發(fā)請求 而是向請求發(fā)出者發(fā)送重定向響應(yīng) 指示被呼叫方的地址 注冊服務(wù)器 Registar 完成用戶代理的注冊和注銷功能接收管轄范圍內(nèi)的用戶代理的注冊請求 并將用戶代理的真實地址記錄在定位服務(wù)器中 SIP協(xié)議 什么是SIP SIP的設(shè)計原則SIP的架構(gòu)SIP的層次SIP的主要機制SIP的鑒權(quán)SIP的消息格式SIP的主要流程SIP事務(wù)SIP在視頻監(jiān)控系統(tǒng)中的應(yīng)用 SIP的層次 語法和編碼層這層定義了SIP的語法和編碼格式SIP使用AugmentedBNF來定義所有的SIP消息格式SIP URI sip userinfo hostporturi parameters headers SIPS URI sips userinfo hostporturi parameters headers userinfo user telephone subscriber password user 1 unreserved escaped user unreserved user unreserved password unreserved escaped hostport host port 傳輸層 TransportLayer 這需要和SIP使用的何種傳輸協(xié)議相區(qū)分 定義如何選擇底層傳輸協(xié)議 如果數(shù)據(jù)包太大 需要使用可靠的流式協(xié)議 如TCP 定義在不同的傳輸協(xié)議下 如何發(fā)送請求和接收響應(yīng) SIP的層次 事務(wù)層 TransactionLayer 這層是SIP協(xié)議的核心層次 事務(wù)是SIP協(xié)議的核心元素 一個事務(wù)是由客戶端事務(wù)發(fā)送給服務(wù)器事務(wù)的請求 和對應(yīng)該請求的服務(wù)器事務(wù)發(fā)送回客戶機事務(wù)的所有響應(yīng)的組合 事務(wù)分為客戶端事務(wù) 和服務(wù)端事務(wù) 每一個事務(wù)都包含多個狀態(tài) 這些狀態(tài)之間的跳轉(zhuǎn)可以使用一個有限狀態(tài)機來描述 事務(wù)主要用來匹配請求和響應(yīng) 處理應(yīng)用層重傳 盡力的保證消息的可靠傳輸 維護應(yīng)用層超時 用戶代理 有狀態(tài)的代理服務(wù)器以及注冊服務(wù)器都包含事務(wù)層 無狀態(tài)的代理服務(wù)器不包含事務(wù)層 SIP的層次 事務(wù)用戶層 TU 事務(wù)用戶層工作在事務(wù)層之上 無狀態(tài)的代理服務(wù)器不包含事務(wù)層 所以也不包含事務(wù)用戶層 其他的SIP實體都包含事務(wù)用戶層 當(dāng)TU想要發(fā)送一個SIP請求時 創(chuàng)建一個客戶端事務(wù) 當(dāng)對應(yīng)的請求到達服務(wù)器 服務(wù)器產(chǎn)生一個對應(yīng)的服務(wù)端事務(wù) TU也可以產(chǎn)生一個CANCEL事務(wù)來取消一個客戶端事務(wù) CANCEL事務(wù)通過SIP的CANCEL消息來實現(xiàn) 它是一個單獨的事務(wù) 但它的目標(biāo)是被取消的事務(wù) 如果被取消的事務(wù)已經(jīng)完成了 那么這個CANCEL事務(wù)就完全不起作用 就因為這個原因 通常只有針對客戶端的INVITE事務(wù)使用CANCEL事務(wù) 因為其他的事務(wù)在正常情況下存在的時間都很短 而INVITE事務(wù)一般會牽涉到用戶的輸入 持續(xù)時間比較長 SIP協(xié)議 什么是SIP SIP的設(shè)計原則SIP的架構(gòu)SIP的層次SIP的主要機制SIP的鑒權(quán)SIP的消息格式SIP的主要流程SIP事務(wù)SIP在視頻監(jiān)控系統(tǒng)中的應(yīng)用 SIP的主要機制 地址分離機制SIP協(xié)議采用邏輯地址和聯(lián)系地址相分離的機制 邏輯地址用來標(biāo)識用戶 聯(lián)系地址用來表明用戶的當(dāng)前位置一個地址可以對應(yīng)多個聯(lián)系地址 聯(lián)系地址的選擇機制可以通過依據(jù)權(quán)重 或者并發(fā)的模式 注銷注冊機制這個機制用來實現(xiàn)邏輯地址向聯(lián)系地址的綁定 用戶通過注冊和注銷來實現(xiàn)這種綁定 告知當(dāng)前的實際位置 通過REGISTER命令來實現(xiàn)這個機制 目標(biāo)更新機制在會話中主動通知另一方 聯(lián)系地址的改變 SIP的主要機制 呼叫重定向機制當(dāng)用戶呼叫一個邏輯地址時 重定向服務(wù)器使用注冊注銷機制的結(jié)果 將邏輯地址翻譯成聯(lián)系地址 并將這一結(jié)果通知用戶 由用戶使用聯(lián)系地址重新發(fā)起呼叫呼叫協(xié)商機制通過會話建立過程中雙方攜帶的信息來確定雙方的能力 需要傳輸?shù)拿襟w等等 可以在會話中增加 減少以及改變會話中傳送的媒體 路由機制可以由客戶端選擇所需要經(jīng)過的路由節(jié)點 SIP協(xié)議 什么是SIP SIP的設(shè)計原則SIP的架構(gòu)SIP的層次SIP的主要機制SIP的鑒權(quán)SIP的消息格式SIP的主要流程SIP事務(wù)SIP在視頻監(jiān)控系統(tǒng)中的應(yīng)用 SIP的鑒權(quán) 采用和HTTP非常接近的認證方式 用RFC2617 HTTPBasicAndDigestAccessAuthentication中基于挑戰(zhàn)響應(yīng)的協(xié)議過程和消息結(jié)構(gòu) 禁止了不安全的 Basic 認證 使用 Digest 認證方式 基于用戶名和密碼的認證方式在網(wǎng)絡(luò)中不傳遞密碼明文服務(wù)器產(chǎn)生一個隨機數(shù)nonce給客戶端客戶端依據(jù)nonce加上密碼以及一些相關(guān)信息使用MD5算出一個hash值 將這個hash值傳遞回服務(wù)器 因為MD5算法在不可逆上的安全性 保證就算被不懷好意者截取以后 也很難得到真正的密碼 服務(wù)器根據(jù)同樣的算法計算出MD5hash值 將這個結(jié)果和客戶端傳遞來的值作比較 匹配則認證通過 一般使用在注冊和注銷過程中 SIP協(xié)議 什么是SIP SIP的設(shè)計原則SIP的架構(gòu)SIP的層次SIP的主要機制SIP的鑒權(quán)SIP的消息格式SIP的主要流程SIP事務(wù)SIP在視頻監(jiān)控系統(tǒng)中的應(yīng)用 SIP消息格式 一個SIP請求消息的例子INVITEsip 180062000265273827 10 18 34 73 5360SIP 2 0Route Via SIP 2 0 UDP10 18 34 104 5060 rport branch z9hG4bK4009098743From tag 1419225769To Call ID 829237863 10 18 34 104CSeq 20INVITEContact Max Forwards 5User Agent mediasip 2 0Subject MediaSipExpires 120Allow INVITE ACK UPDATE INFO CANCEL BYE OPTIONS REFER SUBSCRIBE NOTIFY MESSAGEContent Type application sdpContent Length 206 SIP消息格式 一個SIP消息回應(yīng)的例子SIP 2 0200OKRecord Route Via SIP 2 0 UDP10 18 34 104 5060 rport 5060 branch z9hG4bK4009098743From tag 1419225769To tag 1745846615Call ID 829237863 10 18 34 104CSeq 20INVITEContact Allow INVITE ACK OPTIONS CANCEL BYE SUBSCRIBE NOTIFY MESSAGE INFO REFER UPDATEContent Type application sdpContent Length 249 SIP消息格式 采用UTF 8編碼格式和HTTP協(xié)議基本相同SIP地址通常的格式為sip user password host port uri parameters headers uri parameters為附加的URL參數(shù) 格式為parameter name parameter value多個參數(shù)以分號分隔開 可擴展 SIP實體必須忽略不認識的URL參數(shù)headers為構(gòu)建請求時添加的附加頭域 這個部分通常不出現(xiàn)在SIP消息中 格式為hname hvalue多個參數(shù)以與號分隔開 SIP消息格式 每個消息由一個起始行 消息頭 一個空行 以及一個可選的消息體構(gòu)成generic message start line message headerCRLF message body 每個起始行和消息頭都是以回車加換行結(jié)束 CRLF 起始行只能占據(jù)一行消息頭域可以跨越多行 如果頭域部分某行是以空格 x20 或制表符 x09 開始 那么表示這一行是前一行的延續(xù) 可以把 CRLF 空格 或 CRLF 制表符 當(dāng)作一個空格來處理 這樣的序列被稱為LWS linearwhitespace SIP消息格式 起始行起始行分為請求起始行和應(yīng)答起始行start line Request Line Status Line請求起始行 Request Line 格式為 Request Line MethodSPRequest URISPSIP VersionCRLFMethod 請求的方法 RFC3261中定義的有REGISTER INVITE ACK CANCEL BYE OPTIONS 在別的SIP補充RFC中還定義了其他的方法 如RFC3248中定義了MESSAGE方法 Request URI 請求的目的地址 參見SIP地址的說明 SIP Version SIP的版本號 在RFC3261中定義為SIP 2 0應(yīng)答起始行 Status Line 格式為 Status Line SIP VersionSPStatus CodeSPReason PhraseCRLFSIP Version SIP的版本號 在RFC3261中定義為SIP 2 0Status Code 應(yīng)答的狀態(tài)碼 可以為如下值1xx 表示請求已經(jīng)收到 正在繼續(xù)處理請求 通常只針對INVITE請求發(fā)送這個響應(yīng) 2xx 成功響應(yīng) 表示請求已經(jīng)被接受并已經(jīng)被正確處理3xx 重定向響應(yīng) 表示請求需要被進一步的處理 通常是給出一個轉(zhuǎn)移地址 4xx 請求錯誤 通常是請求消息格式錯誤 或者不能滿足服務(wù)器的要求 5xx 服務(wù)器內(nèi)部錯誤 表示服務(wù)器不能處理這個正常的請求消息 6xx 全局出錯消息 表示所有的服務(wù)器都不能處理這個消息 Reason Phrase 應(yīng)答對應(yīng)的文字描述 SIP消息格式 消息頭格式為fieldname field value header paramsters大部分多個相同的頭域可以壓縮為一個 多個field value之間使用逗號 分隔開 例如 下面兩個是等價的Route Route Route 消息可以根據(jù)需要攜帶不同消息頭 有些消息頭是必須的 比如From To Call ID CSeq Max Forwards ViaFrom一般用來表示消息的發(fā)起者的邏輯地址 在REGISTER消息中表示注冊的發(fā)起者 響應(yīng)消息中的From頭和請求消息中的一樣 并不是變成了請求中的To頭 To一般表示消息的接收者的邏輯地址 在REGISTER消息中表示本次注冊的邏輯地址 在請求消息中不攜帶tag字段 在響應(yīng)中由回應(yīng)方分配 Call ID會話的標(biāo)志 和From To中的tag參數(shù)一起標(biāo)志一個會話 為保證唯一性Call ID的一般格式為 偽隨機數(shù) 主機名或IP地址 在同一個會話中的所有消息這三個字段必須相同 如果是會話之外消息 則沒有什么要求 CSeq會話中的消息的序號 消息方法名 用來區(qū)分一個會話中的不同消息請求 消息序號是一個遞增的值 會話外的消息對序號沒有要求 但是消息方法名要和請求起始行中相同 Max Forwards消息的最大轉(zhuǎn)發(fā)數(shù) 防止消息在網(wǎng)絡(luò)中因為不可知的原因產(chǎn)生環(huán)路以后 不會無限制的消耗網(wǎng)絡(luò)和服務(wù)器的資源 服務(wù)器在轉(zhuǎn)發(fā)請求時 先要將這個值減一再發(fā)送 SIP消息格式 Via用來記錄消息相應(yīng)的返回地址 branch參數(shù)按照RFC3261中的規(guī)定必須是唯一的 用來標(biāo)志一個SIP事務(wù) 但在老版本的SIP標(biāo)準 RFC2543 中并不是唯一的 為了區(qū)別這兩種情況 RFC3261中規(guī)定 branch參數(shù)的開始7個字符必須為 z9hG4bK 只有在兩種情況下可以不唯一 針對會話請求的非成功 non 2xx 響應(yīng)的ACK 它的branch字段需要和對應(yīng)的INVITE一樣 用來聯(lián)系這個ACK和INVITE 而對成功 2xx 響應(yīng)的ACK 它的branch字段和對應(yīng)的INVITE是不同的 CANCLE方法 它的branch字段需要和要取消的請求消息相同 用來標(biāo)志所要取消的事務(wù) Contact這個消息頭用來指示通訊方的實際地址 這個不同于From和To中記錄的的邏輯地址 在REGISTER中攜帶的Contact表示要綁定到邏輯地址 To 上的實際地址 User Agent標(biāo)識SIP代理程序Subject標(biāo)識一個會話的主題 通常只有INVITE消息才攜帶這個頭字段 Expires在INVITE中表示這次呼叫建立過程的最大時長 如果超過這個時間還沒有建立成功 呼叫就失敗了 發(fā)起者應(yīng)該發(fā)送CANCEL取消這次呼叫 而接受者應(yīng)該回應(yīng)一個487的錯誤 在REGISTER中 表示這次注冊綁定的有效時間 如果為0則表示注銷 SIP消息格式 Content Type指定消息體的媒體類型Content Length指定消息體的長度Route用來指定消息所要經(jīng)過的服務(wù)器 當(dāng)中間服務(wù)器在接收到消息時 需要根據(jù)是否攜帶lr參數(shù)來做不同的動作 如果攜帶lr參數(shù) 表示是根據(jù)RFC3261指定的路由 服務(wù)器只要檢查第一個Route頭是否為自己 如果為自己 將它從消息中移除 然后將消息發(fā)給下一個Route字段或者Request URI中的攜帶的地址 如果沒有l(wèi)r參數(shù) 表示是依據(jù)RFC2543指定的嚴格路由 在消息發(fā)送的時候發(fā)現(xiàn)第一個Route字段沒有l(wèi)r參數(shù) 需要將這個Route中的地址 填寫到Request URI中 而將Request URI作為一個Route字段添加在所有Route字段之后 遵照RFC3261的代理服務(wù)器收到一個請求時 需要檢查Request URI是否指向的是自己曾經(jīng)在Record Route填寫的內(nèi)容 如果是的話 需要從最后一個Route字段中恢復(fù)真正的Request URI 出現(xiàn)這個現(xiàn)象的原因可能是因為上一跳是一個遵從RFC2543的SIP服務(wù)器 Record Route如果中間服務(wù)器仍然需要出現(xiàn)在會話的后續(xù)請求中 那么它需要在響應(yīng)中在所有其他的Record Route字段之前添加這個字段 填上自己的地址 遵從RFC3261的中間服務(wù)器必須加上lr參數(shù) 會話的發(fā)起方在發(fā)送后續(xù)的請求中 需要將所有的Record Route頭字段依順序轉(zhuǎn)換成Route字段 Allow用來表示SIP實體可以接收處理的SIP方法 SIP協(xié)議 什么是SIP SIP的設(shè)計原則SIP的架構(gòu)SIP的層次SIP的主要機制SIP的鑒權(quán)SIP的消息格式SIP的主要流程SIP事務(wù)SIP在視頻監(jiān)控系統(tǒng)中的應(yīng)用 SIP的主要流程 一般的消息流程采用C S架構(gòu)客戶端發(fā)起請求服務(wù)器端給回應(yīng) SIP的主要流程 請求消息 以MESSAGE方法為例 MESSAGEsip 10 18 34 75 5065SIP 2 0Via SIP 2 0 UDP10 18 34 104 5060 rport branch z9hG4bK1495426073From tag 2717189648To Call ID 251252407810318334310450601031833431045060CSeq 1MESSAGEContact User Agent SIP NET1 0evaluationversionMax Forwards 70Content Type application global eye v10 xmlContent Length 312 回應(yīng)消息SIP 2 0200OKVia SIP 2 0 UDP10 18 34 104 5060 rport 5060 branch z9hG4bK1495426073From tag 2717189648To tag 980420199Call ID 251252407810318334310450601031833431045060CSeq 1MESSAGEMax forwards 70User agent SIP NET1 0evaluationversionAllow INVITE ACK OPTIONS CANCEL BYE SUBSCRIBE NOTIFY MESSAGE INFO REFER UPDATEContent Type application global eye v10 xmlContent Length 375 SIP的主要流程 注冊流程終端向注冊服務(wù)器發(fā)起第一個注冊請求 不攜帶任何鑒權(quán)信息如果注冊服務(wù)器不需要認證 那么 就直接返回200OK 否則返回401錯誤 并在響應(yīng)中攜帶服務(wù)器的認證挑戰(zhàn)信息 nonce 終端向注冊服務(wù)器發(fā)起第二個注冊請求 其中攜帶用來認證的用戶和密碼信息 密碼是以結(jié)合挑戰(zhàn)信息 nonce 用MD5加密之后傳遞的 注冊服務(wù)器使用終端同樣的算法計算結(jié)果 和請求中的值相比較 如果認證通過 那么記錄下請求中的地址綁定信息 SIP的主要流程 注冊請求一REGISTERsip 10 18 34 104 5900SIP 2 0Via SIP 2 0 UDP10 18 34 104 5900 rport branch z9hG4bK1525468063From tag 4224369265To Call ID 955142972 10 18 34 104CSeq 1REGISTERContact Max Forwards 5Expires 300Content Length 0401回應(yīng)SIP 2 0401UnauthorizedVia SIP 2 0 UDP10 18 34 104 5900 rport 5900 branch z9hG4bK1525468063From tag 4224369265To tag 3878116472Call ID 955142972 10 18 34 104CSeq 1REGISTERWWW Authenticate Digestrealm testrealm nonce 42385386681596732431151298277 opaque 42385386681596732431151298277 qop auth Allow INVITE ACK OPTIONS CANCEL BYE SUBSCRIBE NOTIFY MESSAGE INFO REFER UPDATEContent Length 0 SIP的主要流程 注冊請求二REGISTERsip 10 18 34 104 5900SIP 2 0Via SIP 2 0 UDP10 18 34 104 5900 rport 5900 branch z9hG4bK3241190465From tag 4224369265To Call ID 955142972 10 18 34 104CSeq 2REGISTERContact Authorization Digestusername test realm testrealm nonce 42385386681596732431151298277 uri sip 10 18 34 104 5900 response f7f90e49a7744311e51c001d6166ecc4 algorithm MD5 cnonce 0a4f113b opaque 42385386681596732431151298277 qop auth nc 00000001Max forwards 5Expires 300Content Length 0200OK回應(yīng)SIP 2 0200OKVia SIP 2 0 UDP10 18 34 104 5900 rport 5900 branch z9hG4bK3241190465From tag 4224369265To tag 2180340491Call ID 955142972 10 18 34 104CSeq 2REGISTERContact expires 300 q 1 0Allow INVITE ACK OPTIONS CANCEL BYE SUBSCRIBE NOTIFY MESSAGE INFO REFER UPDATEContent Length 0 SIP的主要流程 呼叫流程呼叫發(fā)起方發(fā)起呼叫 使用INVITE消息呼叫接受方返回1xx響應(yīng) 表示已經(jīng)收到請求 在進一步的處理 這時可能用振鈴提示用戶有呼叫呼入 用戶應(yīng)答以后 發(fā)送200OK響應(yīng) 表示接受呼叫 呼叫發(fā)起方發(fā)送ACK 用來確認呼叫的應(yīng)答已經(jīng)收到 對于呼叫發(fā)起方來說 收到200OK發(fā)送ACK之后 就認為呼叫已經(jīng)建立成功 如果長時間沒有收到回應(yīng) 可以使用CANCEL方法取消呼叫 而對于呼叫接受方來說 在收到ACK之后 才認為呼叫已經(jīng)建立成功 如果在發(fā)送200OK響應(yīng)之后長時間沒有收到ACK 可以使用BYE方法結(jié)束呼叫 取消流程取消請求只對呼叫發(fā)起方有效 接受方如果不能建立呼叫 要么直接發(fā)送錯誤響應(yīng) 3xx 6xx 要么在發(fā)送成功響應(yīng) 2xx 之后 用BYE方法結(jié)束會話 在INVITE發(fā)出之后和收到任何的1xx消息之間不可以發(fā)送 因為這時候如果發(fā)出 因為網(wǎng)絡(luò)的原因可能導(dǎo)致CANCEL消息先于INVITE到達接受方 在收到1xx消息后 可以發(fā)送CANCEL消息 呼叫接受方在收到CANCEL時如果還沒有對呼叫發(fā)送最終的響應(yīng) 那么應(yīng)該立即發(fā)送487響應(yīng) RequestTerminated 如果已經(jīng)發(fā)送了響應(yīng) 那么就不理睬這個CANCEL消息 如果發(fā)起方在發(fā)送CANCEL仍然收到了呼叫建立成功的響應(yīng) 如果這時仍然想結(jié)束呼叫 那么應(yīng)該使用BYE消息 這種情況通常是發(fā)生在CANCEL到達接受方之前 接受方發(fā)送了成功響應(yīng) 在收到最終響應(yīng)后 不可以發(fā)送CANCEL消息 SIP的主要流程 INVITE請求INVITEsip 180062000265273827 10 18 34 73 5360SIP 2 0Via SIP 2 0 UDP10 18 34 104 5060 rport branch z9hG4bK4009098743From tag 1419225769To Call ID 829237863 10 18 34 104CSeq 20INVITEContact Max Forwards 5User Agent mediasip 2 0Subject MediaSipExpires 120Allow INVITE ACK UPDATE INFO CANCEL BYE OPTIONS REFER SUBSCRIBE NOTIFY MESSAGEContent Type application sdpContent Length 206 1xx響應(yīng)SIP 2 0101DialogEstablishementVia SIP 2 0 UDP10 18 34 104 5060 rport 5060 branch z9hG4bK4009098743From tag 1419225769To tag 1745846615Call ID 829237863 10 18 34 104CSeq 20INVITEContact Allow INVITE ACK OPTIONS CANCEL BYE SUBSCRIBE NOTIFY MESSAGE INFO REFER UPDATEContent Length 0 SIP的主要流程 2xx響應(yīng)SIP 2 0200OKVia SIP 2 0 UDP10 18 34 104 5060 rport 5060 branch z9hG4bK4009098743From tag 1419225769To tag 1745846615Call ID 829237863 10 18 34 104CSeq 20INVITEContact Allow INVITE ACK OPTIONS CANCEL BYE SUBSCRIBE NOTIFY MESSAGE INFO REFER UPDATEContent Type application sdpContent Length 249 ACK確認ACKsip 180062000265273827 10 18 34 73 5360SIP 2 0Via SIP 2 0 UDP10 18 34 104 5060 rport branch z9hG4bK444599471From tag 1419225769To tag 1745846615Call ID 829237863 10 18 34 104CSeq 20ACKContact Max Forwards 5User Agent mediasip 2 0Content Length 0 SIP協(xié)議 什么是SIP SIP的設(shè)計原則SIP的架構(gòu)SIP的層次SIP的主要機制SIP的鑒權(quán)SIP的消息格式SIP的主要流程SIP事務(wù)SIP在視頻監(jiān)控系統(tǒng)中的應(yīng)用 SIP事務(wù) SIP事務(wù)的分類因為呼叫建立的過程和其他的消息過程相比較特殊 也要復(fù)雜一些 所以特別的將所有事務(wù)區(qū)分為INVITE事務(wù)和非INVITE事務(wù) 再加上客戶端和服務(wù)端的組合就分為如下四種 INVITE客戶端事務(wù) INVITEClientTransaction INVITE服務(wù)端事務(wù) INVITEServerTransaction 非INVITE客戶端事務(wù) non INVITEClientTransaction 非INVITE服務(wù)端事務(wù) non INVITEServerTransaction SIP事務(wù)中的定時器當(dāng)SIP使用不可靠的傳輸協(xié)議 如UDP SIP協(xié)議定義了一些列的定時器 來進行重傳和超時控制 盡可能的保證消息能夠可靠的傳輸 T1用來表示數(shù)據(jù)包的估計往返時間 默認值為500毫秒 T2用來表示非INVITE事務(wù)服務(wù)器的估計響應(yīng)時間 默認值為4秒 T4用來表示網(wǎng)絡(luò)中消息的估計存在時間 默認值為5秒 SIP事務(wù)中請求和響應(yīng)的匹配當(dāng)用響應(yīng)匹配請求時 規(guī)定使用Via字段的branch參數(shù)來區(qū)別 另外還要比較CSeq中的方法字段 以便區(qū)別是針對CANCEL還是針對被取消的請求 當(dāng)用請求匹配請求時如果branch字段的開始為 z9hG4bK 那么表示這個請求是依照RFC3261發(fā)出的 需要匹配branch 以及CSeq中的方法部分 ACK需要對應(yīng)INVITE 其它的請求方法必須相同 如果branch字段的開始不為 z9hG4bK 那么表示這個請求是按照RFC2543發(fā)出的 需要用Request URI Totag Fromtag Call ID CSeqnumber 以及第一個Via頭等等 SIP事務(wù) INVITE客戶端事務(wù)TimerA用來控制INVITE請求消息的重傳間隔 初始為T1 默認為500毫秒 每次重傳之后 就翻倍 TimerB用來控制INVITE在沒有收到任何響應(yīng)的情況下 最大的重傳總時間 為64倍的T1 那么在沒有收到任何響應(yīng)的情況下重傳間隔如下T1 2 T1 4 T1 8 T1 16 T1 32 T1TimerD用來控制收到錯誤響應(yīng)之后 對每個響應(yīng)回應(yīng)ACK的最大持續(xù)時間收到2XX以后 就到了結(jié)束狀態(tài) 并不包含ACK 因為對于不同的TU 在收到200OK響應(yīng)之后 可能會作不同的動作 對于客戶端來說 需要發(fā)送ACK回應(yīng) 而對于中間服務(wù)器來說 只需要轉(zhuǎn)發(fā)回應(yīng)就可以了 在Proceeding狀態(tài) 沒有任何的定時器來進行狀態(tài)跳轉(zhuǎn)的 這就出現(xiàn)了一個問題 如果服務(wù)器在發(fā)送1xx響應(yīng)之后 出錯了 不再發(fā)送后續(xù)的響應(yīng) 那么這時客戶端的呼叫就會一直保持在這個狀態(tài) 這就需要由TU來控制會話的最大建立時間 如果在這個時間到達之后 會話還沒建立成功 就取消呼叫請求 并釋放資源 SIP事務(wù) INVITE服務(wù)端事務(wù)TimerG用來控制錯誤響應(yīng)的重傳間隔 初始值為T1 每次重傳之后就翻倍 直到大于T2之后 就變成T2 TimerH用來控制錯誤響應(yīng)重傳總時長 值為64 T1 這樣由TimerG控制的錯誤響應(yīng)重傳時間間隔為 T1 2 T1 4 T1 T2 T2 T2 T2 T2 T2 T2TimerI用來吸收客戶端重傳的ACK確認包 在Proceeding和Completed狀態(tài)下 如果收到了INVITE請求消息 都需要重傳最后一個響應(yīng) 收到2xx消息時 和INVITE類似 立即轉(zhuǎn)到了Terminated狀態(tài) 后續(xù)的ACK響應(yīng)以及它的重傳都是由TU來控制的 同樣的和INVITE客戶端事務(wù)中的Proceeding狀態(tài)類似 也沒有任何的定時器來觸發(fā)狀態(tài)的跳轉(zhuǎn) 如果TU由于某種原因再也不發(fā)送響應(yīng) 那么呼叫資源就會一直占用 這里也需要呼叫最大建立時間的限制 SIP事務(wù) 非INVITE客戶端事務(wù)TimerE用來控制請求消息的重傳間隔 初始值為T1 每次重傳之后翻倍 直到大于T2之后 就使用T2 如果收到了零時響應(yīng) TimerE仍然存在 只不過將值直接置為T2 TimerF用來控制消息重傳的總時長 值為64 T1 這樣由TimerE控制在沒有零時響應(yīng)情況下的請求重傳時間間隔為 T1 2 T1 4 T1 T2 T2 T2 T2 T2 T2 T2TimerK用來吸收服務(wù)端重傳的響應(yīng) 值為T4 SIP事務(wù) 非INVITE服務(wù)端事務(wù)TimerJ用來吸收客戶端重傳的消息請求 值為64 T1 在Proceeding和Completed狀態(tài)下 如果收到了INVITE請求消息 都需要重傳最后一個響應(yīng) 和前面類似Trying和Proceeding兩個轉(zhuǎn)態(tài)下沒有任何的定時器來實現(xiàn)狀態(tài)跳轉(zhuǎn) 如果TU不發(fā)送任何的回應(yīng) 那么這個消息狀態(tài)就一直會存在下去 也需要有一個超時機制來釋放資源 SIP協(xié)議 什么是SIP SIP的設(shè)計原則SIP的架構(gòu)SIP的層次SIP的主要機制SIP的鑒權(quán)SIP的消息格式SIP的主要流程SIP事務(wù)SIP在視頻監(jiān)控系統(tǒng)中的應(yīng)用 SIP在視頻監(jiān)控系統(tǒng)中的應(yīng)用 使用SIP XML來傳遞信令消息使用MESSAGE方法 信令使用XML攜帶 采用SIP消息的重傳來盡力保證消息的可靠傳遞 使用SIP SDP來建立媒體會話使用INVITE方法來建立呼叫 使用SDP來協(xié)商媒體格式 傳輸?shù)刂?等等 使用OPTIONS信令來檢測會話雙方是否存在 使用標(biāo)準的SIP協(xié)議來建立呼叫 比較容易和別的系統(tǒng)融合 比如說和視頻會議系統(tǒng) IPTV系統(tǒng)等 SIP在視頻監(jiān)控系統(tǒng)中的應(yīng)用 視頻監(jiān)控的示意性流程 SIP在視頻監(jiān)控系統(tǒng)中的應(yīng)用 穿越NAT的原理什么是NAT NAT就是網(wǎng)絡(luò)地址轉(zhuǎn)換 主要是因為IPV4網(wǎng)絡(luò)地址的缺乏而采用的技術(shù) NAT內(nèi)的主機一般使用私網(wǎng)地址 如10 xxx xxx xxx 192 168 xxx xxx 訪問外