http SIP協議及其在視頻監控系統中的應用 SIP協議 什么是SIP SIP的設計原則SIP的架構SIP的層次SIP的主要機制SIP的鑒權SIP的消息格式SIP的主要流程SIP事務SIP在視頻監控系統中的應用 什么是SIP SIP是一個應用層的信令控制協議 用于創建 修改和釋放一個或多個參與者的會話 SIP可以邀請參與者加入一個已經存在的一個會話中 例如一個多播會議 SIP可以動態的在會話中添加和刪除媒體數據 SIP支持名字映射和重定向服務 什么是SIP SIP的會話控制功能會話維護會話協商內容不作任何限制 比如終端的能力 終端的數據端口號等等 可以使用SDP或者其他的協議進行協商 這一點使得SIP有很好的擴展性 會話中可以承載的數據語音 視頻即時消息其他的自定義數據游戲SIP的名字映射功能SIP使用SIP邏輯地址來映射實際地址 這樣用戶發起呼叫時 不需要知道目標的真正地址 就可以達到呼叫的目的 這樣可以很方便實現終端的移動性 SIP協議 什么是SIP SIP的設計原則SIP的架構SIP的層次SIP的主要機制SIP的鑒權SIP的消息格式SIP的主要流程SIP事務SIP在視頻監控系統中的應用 SIP的設計原則 模仿HTTP1 1的風格重用HTTP編碼 所有消息基于文本 便于開發 使用UTF 8字符集重用Internet尋址方案 使用RFC2369中定義的URI和URL格式 可以非常的靈活的和其他遵循這一定義的協議協作 對底層傳輸協議不做假設可以使用于多種協議 如UDP TCP TLS SCTP等等 雖然對底層傳輸協議不做假設 但是需要注意的是 它仍然將底層協議分為兩類 一類為不可靠的數據報傳輸協議 unreliabledatagramtransports 一類為流式的傳輸協議 stream orientedtransports 區分這兩類協議的主要目的在于 在是否重傳消息時需要區別對待 最常用的協議為UDP協議 SIP的設計原則 邏輯地址和聯系地址相分離邏輯地址用于標志用戶聯系地址用于表明用戶當前的位置 即當前的實際地址 SIP協議 什么是SIP SIP的設計原則SIP的架構SIP的層次SIP的主要機制SIP的鑒權SIP的消息格式SIP的主要流程SIP事務SIP在視頻監控系統中的應用 SIP的架構 采用客戶端 服務器 C S 架構主要單元用戶代理 UserAgent SIP服務器 Servers 代理服務器 Proxy 重定向服務器 Redirector 注冊服務器 Registar SIP的架構 代理服務器 Proxy 用來接收請求 并尋找請求傳送的下一條地址 轉發請求 可以分為有狀態的和無狀態的 有狀態的代理服務器記住它接收的請求 回送的響應以及它轉出的請求 無狀態的代理服務器則不記錄任何請求相關的信息 重定向服務器 Redirector 不轉發請求 而是向請求發出者發送重定向響應 指示被呼叫方的地址 注冊服務器 Registar 完成用戶代理的注冊和注銷功能接收管轄范圍內的用戶代理的注冊請求 并將用戶代理的真實地址記錄在定位服務器中 SIP協議 什么是SIP SIP的設計原則SIP的架構SIP的層次SIP的主要機制SIP的鑒權SIP的消息格式SIP的主要流程SIP事務SIP在視頻監控系統中的應用 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使用的何種傳輸協議相區分 定義如何選擇底層傳輸協議 如果數據包太大 需要使用可靠的流式協議 如TCP 定義在不同的傳輸協議下 如何發送請求和接收響應 SIP的層次 事務層 TransactionLayer 這層是SIP協議的核心層次 事務是SIP協議的核心元素 一個事務是由客戶端事務發送給服務器事務的請求 和對應該請求的服務器事務發送回客戶機事務的所有響應的組合 事務分為客戶端事務 和服務端事務 每一個事務都包含多個狀態 這些狀態之間的跳轉可以使用一個有限狀態機來描述 事務主要用來匹配請求和響應 處理應用層重傳 盡力的保證消息的可靠傳輸 維護應用層超時 用戶代理 有狀態的代理服務器以及注冊服務器都包含事務層 無狀態的代理服務器不包含事務層 SIP的層次 事務用戶層 TU 事務用戶層工作在事務層之上 無狀態的代理服務器不包含事務層 所以也不包含事務用戶層 其他的SIP實體都包含事務用戶層 當TU想要發送一個SIP請求時 創建一個客戶端事務 當對應的請求到達服務器 服務器產生一個對應的服務端事務 TU也可以產生一個CANCEL事務來取消一個客戶端事務 CANCEL事務通過SIP的CANCEL消息來實現 它是一個單獨的事務 但它的目標是被取消的事務 如果被取消的事務已經完成了 那么這個CANCEL事務就完全不起作用 就因為這個原因 通常只有針對客戶端的INVITE事務使用CANCEL事務 因為其他的事務在正常情況下存在的時間都很短 而INVITE事務一般會牽涉到用戶的輸入 持續時間比較長 SIP協議 什么是SIP SIP的設計原則SIP的架構SIP的層次SIP的主要機制SIP的鑒權SIP的消息格式SIP的主要流程SIP事務SIP在視頻監控系統中的應用 SIP的主要機制 地址分離機制SIP協議采用邏輯地址和聯系地址相分離的機制 邏輯地址用來標識用戶 聯系地址用來表明用戶的當前位置一個地址可以對應多個聯系地址 聯系地址的選擇機制可以通過依據權重 或者并發的模式 注銷注冊機制這個機制用來實現邏輯地址向聯系地址的綁定 用戶通過注冊和注銷來實現這種綁定 告知當前的實際位置 通過REGISTER命令來實現這個機制 目標更新機制在會話中主動通知另一方 聯系地址的改變 SIP的主要機制 呼叫重定向機制當用戶呼叫一個邏輯地址時 重定向服務器使用注冊注銷機制的結果 將邏輯地址翻譯成聯系地址 并將這一結果通知用戶 由用戶使用聯系地址重新發起呼叫呼叫協商機制通過會話建立過程中雙方攜帶的信息來確定雙方的能力 需要傳輸的媒體等等 可以在會話中增加 減少以及改變會話中傳送的媒體 路由機制可以由客戶端選擇所需要經過的路由節點 SIP協議 什么是SIP SIP的設計原則SIP的架構SIP的層次SIP的主要機制SIP的鑒權SIP的消息格式SIP的主要流程SIP事務SIP在視頻監控系統中的應用 SIP的鑒權 采用和HTTP非常接近的認證方式 用RFC2617 HTTPBasicAndDigestAccessAuthentication中基于挑戰響應的協議過程和消息結構 禁止了不安全的 Basic 認證 使用 Digest 認證方式 基于用戶名和密碼的認證方式在網絡中不傳遞密碼明文服務器產生一個隨機數nonce給客戶端客戶端依據nonce加上密碼以及一些相關信息使用MD5算出一個hash值 將這個hash值傳遞回服務器 因為MD5算法在不可逆上的安全性 保證就算被不懷好意者截取以后 也很難得到真正的密碼 服務器根據同樣的算法計算出MD5hash值 將這個結果和客戶端傳遞來的值作比較 匹配則認證通過 一般使用在注冊和注銷過程中 SIP協議 什么是SIP SIP的設計原則SIP的架構SIP的層次SIP的主要機制SIP的鑒權SIP的消息格式SIP的主要流程SIP事務SIP在視頻監控系統中的應用 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消息回應的例子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協議基本相同SIP地址通常的格式為sip user password host port uri parameters headers uri parameters為附加的URL參數 格式為parameter name parameter value多個參數以分號分隔開 可擴展 SIP實體必須忽略不認識的URL參數headers為構建請求時添加的附加頭域 這個部分通常不出現在SIP消息中 格式為hname hvalue多個參數以與號分隔開 SIP消息格式 每個消息由一個起始行 消息頭 一個空行 以及一個可選的消息體構成generic message start line message headerCRLF message body 每個起始行和消息頭都是以回車加換行結束 CRLF 起始行只能占據一行消息頭域可以跨越多行 如果頭域部分某行是以空格 x20 或制表符 x09 開始 那么表示這一行是前一行的延續 可以把 CRLF 空格 或 CRLF 制表符 當作一個空格來處理 這樣的序列被稱為LWS linearwhitespace SIP消息格式 起始行起始行分為請求起始行和應答起始行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應答起始行 Status Line 格式為 Status Line SIP VersionSPStatus CodeSPReason PhraseCRLFSIP Version SIP的版本號 在RFC3261中定義為SIP 2 0Status Code 應答的狀態碼 可以為如下值1xx 表示請求已經收到 正在繼續處理請求 通常只針對INVITE請求發送這個響應 2xx 成功響應 表示請求已經被接受并已經被正確處理3xx 重定向響應 表示請求需要被進一步的處理 通常是給出一個轉移地址 4xx 請求錯誤 通常是請求消息格式錯誤 或者不能滿足服務器的要求 5xx 服務器內部錯誤 表示服務器不能處理這個正常的請求消息 6xx 全局出錯消息 表示所有的服務器都不能處理這個消息 Reason Phrase 應答對應的文字描述 SIP消息格式 消息頭格式為fieldname field value header paramsters大部分多個相同的頭域可以壓縮為一個 多個field value之間使用逗號 分隔開 例如 下面兩個是等價的Route Route Route 消息可以根據需要攜帶不同消息頭 有些消息頭是必須的 比如From To Call ID CSeq Max Forwards ViaFrom一般用來表示消息的發起者的邏輯地址 在REGISTER消息中表示注冊的發起者 響應消息中的From頭和請求消息中的一樣 并不是變成了請求中的To頭 To一般表示消息的接收者的邏輯地址 在REGISTER消息中表示本次注冊的邏輯地址 在請求消息中不攜帶tag字段 在響應中由回應方分配 Call ID會話的標志 和From To中的tag參數一起標志一個會話 為保證唯一性Call ID的一般格式為 偽隨機數 主機名或IP地址 在同一個會話中的所有消息這三個字段必須相同 如果是會話之外消息 則沒有什么要求 CSeq會話中的消息的序號 消息方法名 用來區分一個會話中的不同消息請求 消息序號是一個遞增的值 會話外的消息對序號沒有要求 但是消息方法名要和請求起始行中相同 Max Forwards消息的最大轉發數 防止消息在網絡中因為不可知的原因產生環路以后 不會無限制的消耗網絡和服務器的資源 服務器在轉發請求時 先要將這個值減一再發送 SIP消息格式 Via用來記錄消息相應的返回地址 branch參數按照RFC3261中的規定必須是唯一的 用來標志一個SIP事務 但在老版本的SIP標準 RFC2543 中并不是唯一的 為了區別這兩種情況 RFC3261中規定 branch參數的開始7個字符必須為 z9hG4bK 只有在兩種情況下可以不唯一 針對會話請求的非成功 non 2xx 響應的ACK 它的branch字段需要和對應的INVITE一樣 用來聯系這個ACK和INVITE 而對成功 2xx 響應的ACK 它的branch字段和對應的INVITE是不同的 CANCLE方法 它的branch字段需要和要取消的請求消息相同 用來標志所要取消的事務 Contact這個消息頭用來指示通訊方的實際地址 這個不同于From和To中記錄的的邏輯地址 在REGISTER中攜帶的Contact表示要綁定到邏輯地址 To 上的實際地址 User Agent標識SIP代理程序Subject標識一個會話的主題 通常只有INVITE消息才攜帶這個頭字段 Expires在INVITE中表示這次呼叫建立過程的最大時長 如果超過這個時間還沒有建立成功 呼叫就失敗了 發起者應該發送CANCEL取消這次呼叫 而接受者應該回應一個487的錯誤 在REGISTER中 表示這次注冊綁定的有效時間 如果為0則表示注銷 SIP消息格式 Content Type指定消息體的媒體類型Content Length指定消息體的長度Route用來指定消息所要經過的服務器 當中間服務器在接收到消息時 需要根據是否攜帶lr參數來做不同的動作 如果攜帶lr參數 表示是根據RFC3261指定的路由 服務器只要檢查第一個Route頭是否為自己 如果為自己 將它從消息中移除 然后將消息發給下一個Route字段或者Request URI中的攜帶的地址 如果沒有lr參數 表示是依據RFC2543指定的嚴格路由 在消息發送的時候發現第一個Route字段沒有lr參數 需要將這個Route中的地址 填寫到Request URI中 而將Request URI作為一個Route字段添加在所有Route字段之后 遵照RFC3261的代理服務器收到一個請求時 需要檢查Request URI是否指向的是自己曾經在Record Route填寫的內容 如果是的話 需要從最后一個Route字段中恢復真正的Request URI 出現這個現象的原因可能是因為上一跳是一個遵從RFC2543的SIP服務器 Record Route如果中間服務器仍然需要出現在會話的后續請求中 那么它需要在響應中在所有其他的Record Route字段之前添加這個字段 填上自己的地址 遵從RFC3261的中間服務器必須加上lr參數 會話的發起方在發送后續的請求中 需要將所有的Record Route頭字段依順序轉換成Route字段 Allow用來表示SIP實體可以接收處理的SIP方法 SIP協議 什么是SIP SIP的設計原則SIP的架構SIP的層次SIP的主要機制SIP的鑒權SIP的消息格式SIP的主要流程SIP事務SIP在視頻監控系統中的應用 SIP的主要流程 一般的消息流程采用C S架構客戶端發起請求服務器端給回應 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 回應消息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的主要流程 注冊流程終端向注冊服務器發起第一個注冊請求 不攜帶任何鑒權信息如果注冊服務器不需要認證 那么 就直接返回200OK 否則返回401錯誤 并在響應中攜帶服務器的認證挑戰信息 nonce 終端向注冊服務器發起第二個注冊請求 其中攜帶用來認證的用戶和密碼信息 密碼是以結合挑戰信息 nonce 用MD5加密之后傳遞的 注冊服務器使用終端同樣的算法計算結果 和請求中的值相比較 如果認證通過 那么記錄下請求中的地址綁定信息 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回應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回應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的主要流程 呼叫流程呼叫發起方發起呼叫 使用INVITE消息呼叫接受方返回1xx響應 表示已經收到請求 在進一步的處理 這時可能用振鈴提示用戶有呼叫呼入 用戶應答以后 發送200OK響應 表示接受呼叫 呼叫發起方發送ACK 用來確認呼叫的應答已經收到 對于呼叫發起方來說 收到200OK發送ACK之后 就認為呼叫已經建立成功 如果長時間沒有收到回應 可以使用CANCEL方法取消呼叫 而對于呼叫接受方來說 在收到ACK之后 才認為呼叫已經建立成功 如果在發送200OK響應之后長時間沒有收到ACK 可以使用BYE方法結束呼叫 取消流程取消請求只對呼叫發起方有效 接受方如果不能建立呼叫 要么直接發送錯誤響應 3xx 6xx 要么在發送成功響應 2xx 之后 用BYE方法結束會話 在INVITE發出之后和收到任何的1xx消息之間不可以發送 因為這時候如果發出 因為網絡的原因可能導致CANCEL消息先于INVITE到達接受方 在收到1xx消息后 可以發送CANCEL消息 呼叫接受方在收到CANCEL時如果還沒有對呼叫發送最終的響應 那么應該立即發送487響應 RequestTerminated 如果已經發送了響應 那么就不理睬這個CANCEL消息 如果發起方在發送CANCEL仍然收到了呼叫建立成功的響應 如果這時仍然想結束呼叫 那么應該使用BYE消息 這種情況通常是發生在CANCEL到達接受方之前 接受方發送了成功響應 在收到最終響應后 不可以發送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響應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響應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協議 什么是SIP SIP的設計原則SIP的架構SIP的層次SIP的主要機制SIP的鑒權SIP的消息格式SIP的主要流程SIP事務SIP在視頻監控系統中的應用 SIP事務 SIP事務的分類因為呼叫建立的過程和其他的消息過程相比較特殊 也要復雜一些 所以特別的將所有事務區分為INVITE事務和非INVITE事務 再加上客戶端和服務端的組合就分為如下四種 INVITE客戶端事務 INVITEClientTransaction INVITE服務端事務 INVITEServerTransaction 非INVITE客戶端事務 non INVITEClientTransaction 非INVITE服務端事務 non INVITEServerTransaction SIP事務中的定時器當SIP使用不可靠的傳輸協議 如UDP SIP協議定義了一些列的定時器 來進行重傳和超時控制 盡可能的保證消息能夠可靠的傳輸 T1用來表示數據包的估計往返時間 默認值為500毫秒 T2用來表示非INVITE事務服務器的估計響應時間 默認值為4秒 T4用來表示網絡中消息的估計存在時間 默認值為5秒 SIP事務中請求和響應的匹配當用響應匹配請求時 規定使用Via字段的branch參數來區別 另外還要比較CSeq中的方法字段 以便區別是針對CANCEL還是針對被取消的請求 當用請求匹配請求時如果branch字段的開始為 z9hG4bK 那么表示這個請求是依照RFC3261發出的 需要匹配branch 以及CSeq中的方法部分 ACK需要對應INVITE 其它的請求方法必須相同 如果branch字段的開始不為 z9hG4bK 那么表示這個請求是按照RFC2543發出的 需要用Request URI Totag Fromtag Call ID CSeqnumber 以及第一個Via頭等等 SIP事務 INVITE客戶端事務TimerA用來控制INVITE請求消息的重傳間隔 初始為T1 默認為500毫秒 每次重傳之后 就翻倍 TimerB用來控制INVITE在沒有收到任何響應的情況下 最大的重傳總時間 為64倍的T1 那么在沒有收到任何響應的情況下重傳間隔如下T1 2 T1 4 T1 8 T1 16 T1 32 T1TimerD用來控制收到錯誤響應之后 對每個響應回應ACK的最大持續時間收到2XX以后 就到了結束狀態 并不包含ACK 因為對于不同的TU 在收到200OK響應之后 可能會作不同的動作 對于客戶端來說 需要發送ACK回應 而對于中間服務器來說 只需要轉發回應就可以了 在Proceeding狀態 沒有任何的定時器來進行狀態跳轉的 這就出現了一個問題 如果服務器在發送1xx響應之后 出錯了 不再發送后續的響應 那么這時客戶端的呼叫就會一直保持在這個狀態 這就需要由TU來控制會話的最大建立時間 如果在這個時間到達之后 會話還沒建立成功 就取消呼叫請求 并釋放資源 SIP事務 INVITE服務端事務TimerG用來控制錯誤響應的重傳間隔 初始值為T1 每次重傳之后就翻倍 直到大于T2之后 就變成T2 TimerH用來控制錯誤響應重傳總時長 值為64 T1 這樣由TimerG控制的錯誤響應重傳時間間隔為 T1 2 T1 4 T1 T2 T2 T2 T2 T2 T2 T2TimerI用來吸收客戶端重傳的ACK確認包 在Proceeding和Completed狀態下 如果收到了INVITE請求消息 都需要重傳最后一個響應 收到2xx消息時 和INVITE類似 立即轉到了Terminated狀態 后續的ACK響應以及它的重傳都是由TU來控制的 同樣的和INVITE客戶端事務中的Proceeding狀態類似 也沒有任何的定時器來觸發狀態的跳轉 如果TU由于某種原因再也不發送響應 那么呼叫資源就會一直占用 這里也需要呼叫最大建立時間的限制 SIP事務 非INVITE客戶端事務TimerE用來控制請求消息的重傳間隔 初始值為T1 每次重傳之后翻倍 直到大于T2之后 就使用T2 如果收到了零時響應 TimerE仍然存在 只不過將值直接置為T2 TimerF用來控制消息重傳的總時長 值為64 T1 這樣由TimerE控制在沒有零時響應情況下的請求重傳時間間隔為 T1 2 T1 4 T1 T2 T2 T2 T2 T2 T2 T2TimerK用來吸收服務端重傳的響應 值為T4 SIP事務 非INVITE服務端事務TimerJ用來吸收客戶端重傳的消息請求 值為64 T1 在Proceeding和Completed狀態下 如果收到了INVITE請求消息 都需要重傳最后一個響應 和前面類似Trying和Proceeding兩個轉態下沒有任何的定時器來實現狀態跳轉 如果TU不發送任何的回應 那么這個消息狀態就一直會存在下去 也需要有一個超時機制來釋放資源 SIP協議 什么是SIP SIP的設計原則SIP的架構SIP的層次SIP的主要機制SIP的鑒權SIP的消息格式SIP的主要流程SIP事務SIP在視頻監控系統中的應用 SIP在視頻監控系統中的應用 使用SIP XML來傳遞信令消息使用MESSAGE方法 信令使用XML攜帶 采用SIP消息的重傳來盡力保證消息的可靠傳遞 使用SIP SDP來建立媒體會話使用INVITE方法來建立呼叫 使用SDP來協商媒體格式 傳輸地址 等等 使用OPTIONS信令來檢測會話雙方是否存在 使用標準的SIP協議來建立呼叫 比較容易和別的系統融合 比如說和視頻會議系統 IPTV系統等 SIP在視頻監控系統中的應用 視頻監控的示意性流程 SIP在視頻監控系統中的應用 穿越NAT的原理什么是NAT NAT就是網絡地址轉換 主要是因為IPV4網絡地址的缺乏而采用的技術 NAT內的主機一般使用私網地址 如10 xxx xxx xxx 192 168 xxx xxx 訪問外