<p id="l1pda"></p>
<track id="l1pda"></track>
      1. 您當前的位置是:  首頁 > 資訊 > 文章精選 >
         首頁 > 資訊 > 文章精選 >

        完整SIP/SDP媒體協商概論-SIP/WebRTC概要

        2020-02-17 10:46:41   作者: james.zhu   來源:Asterisk開源派   評論:0  點擊:


          Session Description Protocol(簡稱是SDP)全稱是會話描述協議,此協議用來創建一種協商機制,這種協商機制是由呼叫控制協議創建的介于兩個呼叫用戶之間的會話進行,協商機制支持的四大協商方式是:
        • 功能協商
        • 性能協商
        • 語音和視頻的安全設置協商
        • 在多媒體會議中的數據協商

          為了說明SDP的具體內容討論,我們首先需要明確呼叫控制協議的概念。目前,絕大部分的呼叫控制協議中,市場上主要使用SIP和WebRTC來實現呼叫控制。因為篇幅所限和當前實用性的考慮,我們僅介紹SIP協議和WebRTC協議。SIP協議已經部署了很多年,已經普遍使用在VoIP的絕大部分場景中。WebRTC是最近幾年比較熱門的實時通信協議,也逐漸進入了應用場景中。本章節,我們將先從呼叫控制協議介紹開始,介紹SIP協議基本內容和WebRTC協議的基礎知識。

          圖片來自于互聯網資源

          注意:如果一些讀者已經具備了基本的SIP協議和WebRTC協議的基礎,可以跳過本章節的基礎介紹。如果讀者想了解更多完整的SIP協議和WebRTC介紹文檔,可以查閱本公眾號歷史文檔來進一步學習。這里,僅為了為SDP協議的介紹做一個簡單的SIP和WebRTC的回顧介紹。

          1、呼叫控制協議

          我們知道,一個簡單的電話呼叫涉及了很多其他輔助功能,其目的是保證此呼叫功能正常,并且保證運營層面的業務監控也正常工作。呼叫控制協議是電話網絡環境中一個必不可少的環節,其主要功能大致包括呼叫數據流量路由控制,增值服務計費支撐,終端之間的連接性,可靠性傳輸機制,信令控制和媒體通信等功能。在傳統的或者現在的基礎網絡中,很多控制協議仍然是核心的協議,例如,Q.931和H323等具體協議。此概念將會涉及太多的底層細節的協議和歷史介紹,例如,PRI和SS7等相關協議。它們通過電路時隙或者通道實現信令控制和語音傳輸。因為篇幅和文章主題的關系,我們不再討論那些配置。有興趣的讀者可以查閱一些常用的文章來補充這方面的知識。通過以上簡單介紹,我們知道,如果實現一個簡單的,哪怕最簡單的呼叫都需要呼叫控制協議參與,否則沒有辦法發起呼叫,也沒有辦法對呼叫拆線執行掛機。在目前大家非常熟悉的VoIP環境中,SIP是一種非常常見的呼叫控制協議,基本上是目前主流的呼叫控制協議。另外,WebRTC也是我們正在逐步使用的呼叫控制協議。我們在本文章后續部分就重點回顧這兩種協議,為將來進一步深入討論SDP做一個準備工作。

          2、SIP協議概要

          SIP全稱是Session Initiation Protocol。它是我們重點介紹的一種呼叫信令控制協議,用來創建,修改和拆線基于網絡通信的會話,會話由語音視頻和多方視頻數據等構成,通過RFC3261的規定的請求實現。SDP作為消息體的在SIP交互中負責雙方媒體協商,支持能力的協商。另外,SIP使用RTP/RTCP的傳輸參數支持語,視頻和數據的參數。因此,SDP和RTP/RTCP是創建SIP媒體會話的最基本的要求。

          圖片來自于互聯網資源

          任何協議都有其規范的語法結構,SIP協議也是一樣的。它的基本語法結構和HTTP的HTML語法類似。其信令消息包括兩個部分:消息頭和消息體。通過各種語法參數設置來支持SIP協議中的支持能力,協商和應用層級的通信。SIP頭消息主要目的是對從呼叫方到被呼叫方的SIP消息進行路由管理,信令消息中包含一個Request-line,它由請求類型,目的地的SIP URL,或下一跳(next hop),還有SIP版本構成等。取決于消息體類型,SIP消息體是一個可選項。SIP消息中的消息頭和消息體通過空白行來加以區分。消息體構建有太多話題可以討論,如果讀者有興趣的話,可以參考RFC 3261-13.2.1章節。

          如果SIP請求中創建的會話中包含了會話描述的具體消息內容,會話描述中包含了雙方的媒體類型和編碼等,那么,消息體中將會作為SDP包含這些會話描述的消息內容。

          因為SDP消息包含了很多參數設置,涉及了太多SIP消息的頭和消息體設置,因此,關于SIP消息的內容,我們這里需要再花費一點時間做進一步的介紹,以便幫助讀者了解后續章節中的SDP內容討論。RFC3261規定了SIP協議的消息格式,根據官方的描述說明,雖然其語法和HTTP/1.1類似(客戶-服務器端協議架構),但是SIP協議是一種請求-響應機制的處理方式,通過雙方請求消息和對方響應消息來實現信令的協商。因此,其消息構成包括起始行,一個或者多個頭消息,空行(表示頭消息結束),最后,還有一個可選消息體構成。

          generic-message = start-line*message-headerCRLF[ message-body ]start-line = Request-Line / Status-Line

          具體關于SIP消息的語法結構,讀者可以參考RFC3261-7章節。提醒讀者,根據RFC3261的規定,無論是否有可選消息體存在,空行是必須保留的。在SIP消息底部的start-line部分,讀者可以看到,它可以支持Request-Line或者Status-Line。如果是從客戶端對服務器端發送請求的話,start-line就是Request-Line,它包含請求method名稱,請求URL,協議版本和CRLF,它們通過一個單倍行距隔開(SP字符)。沒有其他額外的空格或者其他字符。SIP消息中Request-Line具體用法格式為:

          Request-Line = Method SP Request-URI SP SIP-Version CRLF

          在以上語法中,SIP支持了以下Methods:

        • REGISTER:用戶注冊Method
        • INVITE,ACK,和CANCEL:用來呼叫和創建會話
        • BYE:結束會話
        • OPTIONS:查詢服務器端支持能力
        • MESSAGE:即時聊天
        • REFER:呼叫轉移
        • SUBSCRIBE和NOTIFY :SIP會話相關的事件管理
        • PUBLISH:發布SIP指定事件狀態
        • UPDATE :更新會話參數
        • INFO:支持mid-session 信息轉發
        • PRACK:類似請求確認

          除了我們提到的請求和以上的Request-Line中的method以外,服務器端回復響應消息來表示對請求的處理狀態。響應中的Status code是一個重要的標識。具體的狀態碼如下:

          在日常的排查活動中,系統技術人員需要以上狀態碼來判斷系統所處狀態。當然,在六大狀態分類中,還有其子分類,子分類中包含了更加詳細的說明。用戶可參考RFC 3261-13.2.2(處理INVITE響應)和21章節來學習,這里不再討論。

          當然,除了請求methods和響應狀態碼以外,因為消息體可能需要通過SIP代理/轉發服務器和注冊服務器的處理節點,因此消息體具有很強的靈活性,它可以被讀取,被修改,被移除或者重新處理,為了滿足多種場景的響應,消息體也可能增加一些必要的拓展,包括SIP可選tags標簽,修改的SIP標簽,同時它也可能增加支持Content type的頭域,以下這些頭域都可能添加到消息體中:Allow, Allow-Events, Content-Disposition, Content-Encoding, Content-Language, Content-Length和Content-Type。以上這些頭域值得介紹在RFC3261-20,此章節介紹了具體的定義。

          另外,在SIP消息中,讀者需要了解基本的消息格式,其中請求消息格式和響應消息告訴都有不同的語法結構。兩者的消息內容有明顯的區別:

        • 請求消息格式包括三個主要部分:Request-Line,Header和Message-Body。
        • 響應消息格式包括三個主要部分:Status-Line,Header和 Message-Body。

          請求消息格式和響應消息格式對比如下:


         請求消息格式規范

          響應消息格式規范

          關于消息體更多的規定,讀者可以參考RFC3261-7章節。

          接下來,我們討論一下關于SIP在網絡拓撲中和其他相關協議的關聯性。

          SIP是一種應用層的協議規范,和其他的前面所提到的協議同屬應用層的協議。它的目的是用來實現網絡媒體的創建服務,電話呼叫,電話會議,視頻會議,媒體共享等應用。在這些應用服務中,終端需要支持不同的數據形式,語音編碼,數據文件,視頻編碼等。在這些數據交換的過程中,用戶之間的通信可能通過UDP傳輸/TCP傳輸方式來傳輸RTP,也需要RTCP來對媒體流傳輸控制進行處理。因此,SIP協議協議配合其他的協議完成整個通信服務的處理,其相關協議如下示例圖所示:

          SIP和其他相關協議的關系

          通過以上圖例讀者可以看到,事實上,在一個普通的應用環境中,一個環境可能涉及了很多終端和服務器端以及各種應用程序的協商支持,通過確保雙方功能協商和性能能力的協商,確保雙方具有一系列共同確認的參數才能進行通信(例如,傳輸方式是否相同,端口是否一致,編碼是否支持)。因此,雙方都認可的,標準的,共同支持的協商機制是必不可少的。SDP就是SIP協議中進行協商的標準機制。

          通過以上對SIP以及基本語法的介紹,我們大概了解了SIP的消息和一些必要的請求響應消息體構成。接下來,筆者從宏觀的角度介紹一下SIP網絡技術環境中一些核心的實體構件,包括支持SIP場景的客戶端和服務器端的功能,以及SIP/SDP整體協商流程。

          如果我們從最基本的SIP網絡構成中討論的話,基本的SIP網絡構成包括以下幾個核心的模塊:各種UA,注冊服務器,轉發服務器,定位服務器和代理服務器,還有應用服務器等。如果實現完整的SIP媒體通信的話,SIP需要支持至少五種功能:

        • 定位服務:決定通信使用的最終終端系統。
        • 用戶有效性:決定被呼叫方是否有意愿加入到通信環境中。
        • 用戶媒體支持能力:決定雙方通信所需要的媒體和媒體參數
        • 會話創建:創建會話,啟動ring振鈴等。
        • 會話管理:轉接,修改會話參數,發起其他服務,結束會話等。

          通過以上五種功能的支持,SIP網絡中的核心構件才能成功工作。這些核心模塊負責以上五種能力的支持。當然,隨著當前SIP網絡的應用場景不斷變化和用戶業務需求的變化,SIP網絡中有可能各種服務器的部署不是固定的,因此此圖例不一定完全表示所有的應用場景。關于SIP服務器端的討論,用戶可以參考筆者歷史文章做進一步的學習。

          在以上圖例中,我們看到一些核心的模塊包括了SIP UA(User Agent),UA又可分為UAS和UAC,另外,UA是以客戶端-服務器端模式的模式工作的用戶,這表示一個UA實體,為了滿足SIP的邏輯實體的要求,它既可能是UAC,又可能是UAS,也是我們通常所的背靠背代理方式。如下示例說明了一個應用場景中兩個SIP終端通過兩個代理的呼叫流程:

          兩個UA通過不同代理進行呼叫整體協商流程

          兩個UA首先注冊到各自的服務器端,然后通過服務器呼叫另外一個終端。讀者需要注意,這里假設,Alice在F5 INVITE(標識部分)可能已經攜帶了本端SDP的媒體支持能力,而且,Bob收到服務器端通過F8 INVITE發送到請求,也回復了可接受的媒體支持能力。雙方都協商一致,然后開始語音媒體流發送(F19)。

          UA又根據具體呼叫控制角色不同,可能劃分為不同的UA使用角色,電話會議就是一個例子。RFC4579中定義了電話會議中的在SIP 構件中UA定義:

          Conference-unaware UA:最簡單的UA,參與電話會議,忽略了所有SIP相關消息。此UA可通過撥號加入會議或者被邀請加入會議。它僅支持RFC 3261規范。

          Conference-aware UA-此UA可以支持呼叫控制,另外可以支持SIP轉發處理,也可以訂閱消息等。

          Focus-控制發起會議,負責會議呼叫控制,包含一個Conference-aware UA。

          我們前面已經討論,SIP服務器類型支持了多種處理方式,并且都具有不同的處理流程。有時,這些服務器的功能定位可能互相交叉,因此一些讀者可能比較迷惑。如果讀者單純從定義上了理解的話,可能有引起很多誤解,讀者可以查閱筆者的歷史文檔來理解這些概念:IPPBX的工作模式SBC/B2BUA的處理方式

          深入理解SIP服務器的注冊和定位服務流程

          3、關于WebRTC基本介紹

          前面,我們簡單概述了SIP協議作為呼叫控制協議的基本內容,利用消息體中的SDP參數進行呼叫媒體協商。WebRTC也是一種呼叫控制協議,只是WebRTC利用的是瀏覽器的方式。這里,筆者不打算花費時間再介紹一次WebRTC,筆者以前發布過一篇關于WebRTC的概要,讀者通過此文章基本上可以理解WebRTC的基本要點:

          完整WebRTC技術及應用概要

          4、總結

          一個最基本的呼叫場景都至少需要兩個部分來完成。首先是呼叫控制協議的創建,然后才能實現SDP 媒體協商的流程。因此,在本章節中,我們介紹了呼叫控制協議的基本概念,接下來,筆者介紹了呼叫控制協議中的SIP協議和WebRTC協議。在SIP協議的概要介紹中,我們介紹了SIP消息的基本結構和核心模塊。通過這些基本的介紹,為我們后續關于SDP的深入討論打下一個基礎。在后續章節中,我們將逐步介紹SDP和其相關規范。

          再次說明,在本章節中,筆者針對SIP和WebRTC的介紹僅是為了在后續章節中為SDP討論做一個鋪墊作用,可能有一些內容不是讀者所希望了解的,望見諒。

          參考資料:

          https://www.ccexpert.us/network-design/call-control-and-transport-protocols.html

          https://ribboncommunications.com/company/get-help/glossary/call-control

          https://tools.ietf.org/html/rfc5589

          https://en.wikipedia.org/wiki/Skinny_Call_Control_Protocol

          https://www.itu.int/rec/T-REC-Q.1912.5-200403-S/en

          https://tools.ietf.org/html/rfc3261

          關注微信公眾號:asterisk-cn,獲得有價值的Asterisk行業分享

          Asterisk freepbx FreeSBC技術文檔: www.freepbx.org.cn

          融合通信/IPPBX商業解決方案:www.hiastar.com

          如何使用FreeSBC,qq技術分享群:334023047

         
        【免責聲明】本文僅代表作者本人觀點,與CTI論壇無關。CTI論壇對文中陳述、觀點判斷保持中立,不對所包含內容的準確性、可靠性或完整性提供任何明示或暗示的保證。請讀者僅作參考,并請自行承擔全部責任。

        相關熱詞搜索: SIP SDP WebRTC

        上一篇:安恒信息遠程辦公安全指南

        下一篇:最后一頁

        專題

        CTI論壇會員企業

        欧美性爱欧美
        <p id="l1pda"></p>
        <track id="l1pda"></track>