欧美,精品,综合,亚洲,好吊妞视频免新费观看,免费观看三级吃奶,一级a片女人自慰免费看

您當前的位置是:  首頁 > 資訊 > 國內(nèi) >
 首頁 > 資訊 > 國內(nèi) >

完整SIP/SDP媒體協(xié)商概論-SDP基礎(chǔ)-會話描述說明

2020-03-04 09:44:26   作者:james.zhu    來源:CTI論壇   評論:0  點擊:


  在上一章節(jié) SDP基礎(chǔ)-使用和要求的章節(jié)中,筆者討論了關(guān)于SDP的使用場景和一些SDP語法構(gòu)建。這里,我們根據(jù)SDP的規(guī)范說明,重點介紹SDP具體的會話描述和媒體描述參數(shù)。
  5、SDP規(guī)范標準
  總體來說,SDP會話描述的語法由五個核心部分構(gòu)成,它們分別是:會話元數(shù)據(jù),流媒體,服務(wù)保障,網(wǎng)絡(luò)和安全。
  Session metadata(會話元數(shù)據(jù))描述了會話本身所需要的數(shù)據(jù)標識,包括SDP協(xié)議版本,會話發(fā)起方描述,會話身份確認描述和會話活動時間。
  Stream description包含了媒體功能的描述細節(jié)和參數(shù)。
  QoS描述包含了所有媒體流性能參數(shù),它可能通過其他信息的調(diào)用對多媒體流打包支持帶寬和其他資源的優(yōu)化。
  Network description可能包括各種傳輸協(xié)議(TCP,UDP等)和網(wǎng)絡(luò)協(xié)議以便支持多媒體會議參與方之間的媒體收發(fā)。
  Security 描述包括了密鑰,簽權(quán),認證,不可否認性,完整性內(nèi)容。
  一個SDP會話描述通過媒體類型標識為:"application/sdp"。SDP會話描述完全是一種文本格式,其格式遵從UTF-8解碼規(guī)范。其基本的語法規(guī)范是:
  <type>=<value>
  這里,type必須是一個大小寫敏感的字符,value是一種具有一定結(jié)構(gòu)的文本,value的格式完全取決于type的取值。通常情況下,value可以是多個值域或者一個自由文本格式。如果value包含多個值域的話,通過單空格隔離。注意,“=”兩邊決定不能使用空格。
  SDP會話描述由會話級描述緊接著零或多個媒體級的描述構(gòu)成。其中,會話級描述以"v="行開始,一直繼續(xù)到第一個媒體級的"m="行之前結(jié)束。媒體級會話描述以"m="行開始,然后繼續(xù)到下一個媒體級或整個會話描述結(jié)束。通常來說,除非媒體級的值覆蓋默認設(shè)置,一般來說,對所有媒體來說,會話級的設(shè)置是默認的。會話描述行分為必要設(shè)置和可選設(shè)置兩個部分,其會話描述文本格式必須按照固定順序呈現(xiàn),這樣可以方便處理,避免語法錯誤。其中,可選會話描述設(shè)置帶一個"*"字符作為標識。
  v=(protocol version) // "v" 開始
  o=(originator and session identifier)
  s=(session name)
  i=* (session information), 可選
  u=* (URI of description)
  e=* (email address)
  p=* (phone number)
  c=* ( connection information -- not required if included in all media)
  b=* (zero or more bandwidth information lines)
  One or more time descriptions ("t=" and "r=" lines; see below)
  z=* (time zone adjustments)
  k=* (encryption key)
  a=* (zero or more session attribute lines)
  Zero or more media descriptions, 這里可能無媒體會話
  媒體描述示例:
  m=(media name and transport address) // "m" 開始
  i=* (media title)
  c=* (connection information -- optional if included at session level)
  b=* (zero or more bandwidth information lines)
  k=* (encryption key)
  a=* (zero or more media attribute lines)
  接下來,筆者重點介紹幾個常用的會話描述設(shè)置,主要包括會話級參數(shù),時間和媒體級參數(shù)設(shè)置。其他的會話描述在后續(xù)具體章節(jié)中再做闡述。
  Protocol Version ("v="),其語法格式為:
  v=0
  "v"定義了SDP版本。此規(guī)范定義的是0,沒有子版本。
  Origin ("o="),其語法格式為:
  o=<username> <sess-id> <sess-version> <nettype> <addrtype>
  <unicast-address>
  "o=" 定義了會話發(fā)起方名稱,sess-id 是一個數(shù)值字符串,通過用戶名稱,sess-id,nettype,addrtype,和unicast-address構(gòu)成了一個全局唯一認證ID,<sess-version>是此會話描述的版本號,<nettype>是一個文本字符串,表示網(wǎng)絡(luò)類型,初始設(shè)置是”IN"表示Internet。<addrtype>是一個文本字符串地址,表示是IP4或IP6,也可能使用其他的值。<unicast-address>,此地址是一個創(chuàng)建此會話的機器地址。
  Session Name ("s="), 其語法格式為:
  s=<session name>
  "s="定義了文本會話名稱,這里必須是僅一個會話名稱,此名稱不能為空,其字符串應(yīng)該包含ISO 10646字符。
  Session Information ("i="), 其語法格式為:
  i=<session description>
  "i=" 提供了關(guān)于此會話的文本信息,每個會話描述必須有一個"i=",一個媒體至少有一個"i="。如果出現(xiàn)了"a=charset"屬性的話,它會設(shè)定"i="的字符設(shè)置。如果沒有出現(xiàn)"a=charset"的話,"i="必須包含用UTF-8解碼的ISO 1646字符。單個"i="也可以使用在每個媒體定義中。在媒體定義中,"i="的主要目的是為了標注媒體流。因此,這種標注方式對單會話環(huán)境中有同一媒體類型,它需要支持完全不同的媒體流時非常有用。例如,兩個不同的白板功能,一個白板是支持自己的幻燈片播放,另外一個白板支持問題答疑和回復(fù)處理。
  URI ("u="),其語法格式為:
  u=<uri>
  URL是WWW用戶使用的處理方式,URL應(yīng)該指向一個針對此會話的其他另外資源地址。此描述是可選描述。但是,如果它出現(xiàn)的話,它必須出現(xiàn)在第一個媒體前面。在每個會話描述中不允許第二個URL出現(xiàn)。
  Email Address 和 Phone Number ("e=" 和 "p="),其語法格式為:
  e=<email-address>
  p=<phone-number>
  "e=" 和 "p="定義了負責(zé)會議的聯(lián)系人信息。是否包含"e=" 和 "p="是可選的。這兩個會話描述使用不是非常廣泛。但是,如果出現(xiàn)了郵箱和電話號碼的話,它們必須出現(xiàn)在第一個媒體域前面。一個會話可以支持一個或者多個郵箱或者電話號碼。電話號碼的格式必須按照ITU-T推薦格式來定義,號碼前加一個”+“前綴,并且使用”-“分離電話號碼,方便用戶閱讀。例如:
  p=+1 617 555-6011
  如果是電子郵件的話,兩種格式都可以支持:
  e=j.doe@example.com (Jane Doe)
  或者
  e=Jane Doe <j.doe@example.com>
  Connection Data ("c="), 其語法格式為:
  c=<nettype> <addrtype> <connection-address>
  它包含一些連接數(shù)據(jù)。在會話描述中,媒體描述必須至少包含一個"c="行,或者在會話級包含一個單個"c="行。在某些應(yīng)用場景中,預(yù)設(shè)的媒體設(shè)置可以覆蓋默認的設(shè)置會話級的參數(shù)。因此,在每個媒體會話中,"c="可以包含一個單個的會話級的"c="和其他另外的子"c="行。這里的<nettype>和<addrtype>值和前面介紹的一樣,讀者參考前面的介紹。<connection-address>是一個連接地址,在連接地址后可以增加另外的子項,這些子項取決于<addrtype>類型(是IP4還是IP6地址)。如果會話在多播方式做工作,連接地址必須是一個多播地址組,如果會話在單播方式工作,則廣播地址是單播地址。如果會話使用的是一個多播IP4類型的話,多播連接地址必須支持存活時間(TTL),TTL取值范圍在0-255之間(例如:c=IN IP4 224.2.36.42/127,TTL是127)。注意,IP6沒有使用TTL,因此也沒有TTL設(shè)置,TTL肯定不會出現(xiàn)在IP4中。IP6使用的是一種繼承或?qū)蛹壏绞絹韺崿F(xiàn)連接地址的處理(例如:c=IN IP6 FF15::101, 無TTL)。
  Bandwidth ("b="),其語法格式為:
  b=<bwtype>:<bandwidth>  // kilobits per second
  它是一個可選會話描述,表示對會話或者媒體建議使用的帶寬。帶寬類型子項是以字母方式表示(我們這里討論的是支持兩種類型:CT和AS,還有可能出現(xiàn)TIAS),針對后面的帶寬數(shù)值描述。CT和AS在創(chuàng)建使用上有明顯的不同。CT(Conference Total)表示多會話廣播中會話或者媒體使用的最大帶寬建議值,CT值相當于所有會話帶寬值。AS(Application-Specific)是指具體某個應(yīng)用程序所占用的總帶寬建議值,相當于最大應(yīng)用程序帶寬值,它僅值單媒體在單點所占用的帶寬。如果讀者對AS有興趣的話,可以閱讀RFC3550-6,RFC3556-2中的RS/PR收發(fā)帶寬修改機制和RFC3890關(guān)于Bandwidth Modifier的規(guī)范說明。
  Timing ("t="),其語法格式為:
  t=<start-time> <stop-time>
  它設(shè)置了啟動和停止會話的時間。如果在非正常周期時間段啟動會話,此會話需要增加多"t="行。每個"t="支持另外一個時間段表示會話在此時間段是活動狀態(tài)。如果會話使用在正常時間周期,"t="后面加了一個"r="行表示重復(fù)次數(shù)。這兩個時間標識使用的是NTP的十進制的方式表示,以秒為單位。此時間規(guī)范在RFC1305中有非常明確的發(fā)明,此時間不是UNIX定義的時間,用戶可以參考轉(zhuǎn)換方式來進一步了解如何轉(zhuǎn)換。 如果<stop-time>設(shè)置為0,則表示會話不受限,除非<start-time>后,此會話才會被啟動。如果<start-time>設(shè)置為0,則表示此會話是一個永久會話。通常情況下,規(guī)范不建議在用戶接口或者其他應(yīng)用控制界面設(shè)置這兩個時間取值,這樣會導(dǎo)致會話時間錯亂,會話控制失效。
  Repeat Times ("r="),其語法規(guī)則為:
  r=<repeat interval> <active duration> <offsets from start-time>
  它定義了對此會話的時間重復(fù)次數(shù)。"r="行的取值是根據(jù)前面的"t="決定的。
  Time Zones ("z="), 其語法格式為:
  z=<adjustment time> <offset> <adjustment time> <offset> …
  會話時差處理。為了對重復(fù)的會話(此會話貫穿一個白天晚上到標準時間的修改流程,或者相反處理)進行定時處理,有必要對標準時間設(shè)定一個偏移時間數(shù)值。這樣就要求針對不同的時間對應(yīng)不同的時間標準。每個國家可能都有自己的時差日期基準。因此,為了保證對同一會話在不同時期進行定時處理,必須對數(shù)據(jù)雙方雙方明確設(shè)定一個時間基準和偏移值。
  Encryption Keys ("k="),其語法結(jié)構(gòu)如下:
  k=<method>
  k=<method>:<encryption key>
  如果傳輸消息需要通過一個安全的傳輸方式進行的話,SDP可以用來傳輸密鑰。"k=" 行提供了一個簡單的密鑰交換機制。為什么說是簡單的交換機制?因為當初設(shè)計"k="行的主要目的是考慮和舊部署規(guī)范的兼容性支持,也不是規(guī)范所推薦的使用方式。"k="本身不具有拓展性,支持不了更多傳輸參數(shù)和密鑰管理功能,一些比較新的密鑰交換機制也逐步使用在了SDP會話描述中。"k="使用仍然在更新中,一些語法和內(nèi)容相對比較舊(例如缺少安全協(xié)議中要求的兩個密鑰的支持:confidentiality 和integrity),因此,筆者不打算在這里再展開討論。關(guān)于"k="具體的使用方式,用戶可以通過RFC 4567規(guī)范和RFC4568做更加詳細的理解,這兩個規(guī)范中增加了更多對SDP的拓展支持。這些交換機制和密鑰管理也會使用在一些新的應(yīng)用場景中。
  Attributes ("a="),其語法格式為:
  a=<attribute>
  a=<attribute>:<value>
  Attributes 表示拓展的SDP的基本含義,我們這里翻譯為特征屬性。特征屬性參數(shù)可以定義在會話級和媒體級。媒體描述中可以定義多個"a="行來定義具體的媒體特性。"a="可以出現(xiàn)在第一個媒體描述前,這是會話級的屬性參數(shù),這樣的屬性是針對整個會議會議定義的,不是針對單獨媒體定義的屬性。特征Attributes屬性可以支持兩種屬性格式:
  "a=<flag>."  // 例如:"a=recvonly."
  "a=<attribute>:<value>. // 例如 "a=orient: landscape."
  特征屬性的取值取決于使用的媒體工具。特征屬性的值除了0x00 (Null),0x0A (LF),和 0x0D (CR)以外,可以是任何octet字符串。默認取值解析為ISO-10646字符形式,通過UTF-8解碼取值。如果接收方不理解已接收的特征屬性值,接收方必須忽略此特征屬性值。
  Media Descriptions ("m="): 其語法格式為:
  m=<media> <port> <proto> <fmt> …
  一個會話描述中可以包含多個媒體描述。每個媒體描述以"m="開始,媒體描述結(jié)束以下一個媒體描述開始或者以會話描述結(jié)束來結(jié)尾。一個媒體描述包含幾個媒體描述子項:
  <media>,它表示媒體類型,目前定義的媒體類型包括語音,視頻,應(yīng)用程序,和消息。未來可能還有其他類型,用戶需要密切關(guān)注。
  <port>,它是一個傳輸端口,媒體發(fā)送到此端口。此端口依賴于"c="行定義的網(wǎng)絡(luò)傳輸協(xié)議。其他被媒體應(yīng)用程序使用的端口,例如RTCP端口需要根據(jù)其基準端口來設(shè)定相應(yīng)的端口,或者分開特征屬性設(shè)置。如果使用了非連續(xù)端口或者沒有遵從偶數(shù)-RTP端口,奇數(shù)-RTCP端口的規(guī)則處理的話,必須增加一個"a=rtcp:"行。應(yīng)用程序被發(fā)送到一個端口,此端口是一個奇數(shù)端口,并且出現(xiàn)"a=rtcp:"行時,此媒體一定不能從RTP端口減一,應(yīng)用程序必須發(fā)送RTP數(shù)據(jù)到<port>指定的端口,并且發(fā)送RTCP到"a=rtcp"屬性設(shè)定的端口。對于某些應(yīng)用程序,它們的媒體流通過層級解碼發(fā)送到單播地址時,它們有必要設(shè)定多個傳輸端口。使用語法和多播地址的方式類似: m=<media> <port>/<number of ports> <proto> <fmt> …這種場景中,使用的端口依賴于傳輸協(xié)議類型。一些讀者可能明白,通常默情況下,RTP使用偶數(shù)端口傳輸數(shù)據(jù),它的RTCP使用高一位數(shù)的奇數(shù)端口控制RTP會話。<number of ports>表示RTP會話數(shù)量。例如:
  m=video 49170/2 RTP/AVP 31
  這里,媒體會話將設(shè)定一個視頻媒體類型,端口從49170開始計算,包括兩對RTP媒體會話,其中第一對媒體會話是49170端 口(RTP)和 49171 端口(RTCP)。第二對是從49172(RTP)和49173端 口(RTCP)端口。RTP/AVP是傳輸協(xié)議,31是媒體格式(fmt,H261)。以上介紹的是默認環(huán)境中使 用的連續(xù)端口,如果端口使用的是非連續(xù)的端口,需要增加屬 性"a=rtcp:" 分開獨立的端口屬性。
  <proto>,它是傳輸協(xié)議。這里的傳輸協(xié)議依賴于"c="行定義的地址類型。目前支持的主要的幾個類型包括:UDP,RTP/AVP,RTP/SAVP。這里專門針對媒體格式設(shè)定不同的傳輸協(xié)議是因為同一網(wǎng)絡(luò)協(xié)議時,標準的媒體格式可以通過不同的傳輸協(xié)議來進行傳輸。這樣的設(shè)定可以支持不同的網(wǎng)絡(luò)傳輸和滿足不同檢測工具部署。
  <fmt>,它表示一種媒體格式描述。前面第四個子項或者其他后續(xù)子項都表示媒體格式。媒體格式描述的解析依賴于<proto>子項的值。如果<proto> 子項是"RTP/AVP"或者"RTP/SAVP,媒體格式描述會包含RTP payload 類型號碼。當給定了一個payload類型列表時(靜態(tài)方式,從96-127),這表示所有的媒體格式可以適用于此會話中,但是,通常列表中的第一個格式應(yīng)該作為此會話默認支持格式。如果payload類型列表是動態(tài)的payload類型列表的話,SDP使用"a=rtpmap:"屬性來執(zhí)行一個映射(從RTP payload 類型號碼到媒體解碼名稱),通過媒體類型號碼到媒體解碼名稱的對應(yīng)關(guān)系來確認payload格式。"a=fmtp:" 行可以用來設(shè)定具體的媒體格式參數(shù)。在很多應(yīng)用場景中,用戶可以看到動態(tài)payload不匹配導(dǎo)致的問題,例如Asterisk或者FreeSWITCH的運行環(huán)境中,我們經(jīng)?吹筋愃频腻e誤:
  Unsupported payload type received
  關(guān)于動態(tài)payload的規(guī)范定義,用戶可以查閱RFC3551-6。
  6、SDP屬性說明/IANA/ABNF
  除了我們前面介紹的會話描述和媒體描述說明以外,SDP以支持了特征屬性的拓展,通過拓展的屬性可以支持更多的屬性參數(shù)。SDP屬性支持了會話級和媒體級屬性兩種。會話級屬性顧名思義,它是針對會話層級的屬性。媒體級屬性針對媒體屬性設(shè)置所設(shè)置的屬性。大家經(jīng)常遇到的也是一些在應(yīng)用場景中常見的屬性設(shè)置,我們這里也不可能做一個非常完整的歸納。因此,因為篇幅所限,筆者只能介紹一下其基本的語法構(gòu)成:
  a=tool:<name and version of tool>
  具體在一般場景中看到的例如:
  a=ptime:<packet time>
  此特征屬性表示一個數(shù)據(jù)包中的媒體打包時長的特征屬性。如果使用RTP映射的話,使用的語法為:
  a=rtpmap:<payload type> <encoding name>/<clock rate> [/<encoding
  parameters>]
  另外,為了規(guī)范SDP會話描述中的語法格式,讀者也需要了解幾個相關(guān)的規(guī)范,這些規(guī)范定義了SDP的語法規(guī)則。IANA和ABNF是在SDP規(guī)范中需要了解的基本語法,其中,ABNF規(guī)定了一些基本的規(guī)則,包括空格,大小寫,分割行和各種會話描述,媒體描述以及特征屬性的完整說明。
  7、總結(jié)
  在本章節(jié)中,筆者重點介紹了關(guān)于SDP規(guī)范細節(jié)的會話描述部分以及相關(guān)的拓展屬性介紹。筆者通過三個子章節(jié)的篇幅,基本介紹了SDP的使用方式和要求,增加針對SDP會話描述和媒體描述的規(guī)范細節(jié)做了充分說明和拓展介紹,并且對SDP的特征屬性已經(jīng)IANA和ABFN做了一些簡單介紹。以上內(nèi)容都相對比較抽象,讀者需要在實際生產(chǎn)環(huán)境中不斷練習(xí),不斷解決排查問題,才能對這些內(nèi)容有進一步的了解。
  到此為止,筆者已經(jīng)完整介紹了SDP的基礎(chǔ)和核心語法。這些基礎(chǔ)的內(nèi)容為我們后續(xù)章節(jié)的介紹打下了一個比較好的基礎(chǔ)。在接下來的章節(jié)中,我們將首先完整介紹SDP的協(xié)商模式。
  再次說明,因為很多約定用語需要翻譯成中文的含義,本文中的翻譯風(fēng)格或者理解不同可能有一些出入,希望讀者諒解。
  參考鏈接:
  https://www.rfc-editor.org/rfc/rfc3556
  https://www.rfc-editor.org/rfc/rfc3890
  https://www.rfc-editor.org/rfc/rfc4567
  關(guān)注微信公眾號:asterisk-cn,獲得有價值的Asterisk行業(yè)分享
  Asterisk freepbx FreeSBC技術(shù)文檔: www.freepbx.org.cn
  融合通信/IPPBX商業(yè)解決方案:www.hiastar.com
  如何使用FreeSBC,qq技術(shù)分享群:334023047, www.freesbc.cn
【免責(zé)聲明】本文僅代表作者本人觀點,與CTI論壇無關(guān)。CTI論壇對文中陳述、觀點判斷保持中立,不對所包含內(nèi)容的準確性、可靠性或完整性提供任何明示或暗示的保證。請讀者僅作參考,并請自行承擔全部責(zé)任。

相關(guān)閱讀:

專題

CTI論壇會員企業(yè)