深圳市宝安区华美居

0086-18665301040

完整SIP/SDP媒体协商概论-SDP基础-核心定义全解

完整SIP/SDP媒体协商概论-SDP基础-核心定义全解

在第一个章节中,笔者简单介绍了和SDP密切相关的两个控制协议:SIP/WebRTC,其目的是为了帮助读者在进行SDP学习之前,对SDP背景知识有一个简单的讨论,便于读者能够比较顺利地进行后期的学习。从第二章节开始,我们将逐步进入到真正的SDP的内容介绍。


在第二章节中,我们将会重点介绍RFC4655的参数属性,常用参数的定义说明,SDP的使用方式,SDP的要求和建议,SDP规范说明,SDP具体参数属性,语法结构和安全考虑等环节。

因为篇幅太长,为了方便读者阅读,笔者把整个内容分为两个部分来发布。此章节重点介绍第一部分的内容。此部分重点介绍关于SDP中的定义说明,笔者尽可能涵盖绝大部分的规范定义,所以称之为SDP定义全解。

1

SDP基本介绍

任何技术都是时代的产物,和当时的时代有非常紧密的相关性。我们讨论问题需要结合当时的大背景环境来讨论,否则,我们将失去基本的判断标准。在关于SDP的内容介绍中,我们也需要遵从这样的思考方式来讨论。

SDP协议经过了几个规范版本的演进,一些比较旧的规范已被弃用。RFC2327(1998年发布)和RFC3266(2002年发布)已经不再使用,根据以上两个规范演进出来的新规范RFC4566(2006年发布),它是我们现在使用的规范标准。


当用户发起一个媒体呼叫时,无论是电话会议,视频会议或其他的会话。为了完成这些业务功能,必须要求双方或对方参与者实现一些基本的要求。这个要求是需要系统传输媒体的细节,传输地址和其他会话描述所支持的元数据(Metadata)。SDP提供了这样一个标准的表达方式,能够支持这些媒体参数和元数据构成。其目的是提供一种常用规范,可以广泛使用在互联网环境和应用场景中。


基于以上定义,我们需要进一步说明,SDP仅是提供了这样一个数据表达的标准,支持会话描述的格式,它不涉及或者不关心数据是如何传输的,它借用或配合其他的传输协议来完成(这里,仅讨论针对SDP来说的传输协议)。关于传输方式的讨论,读者可以参考OSI模型学习。当前的环境中,SDP一般需要配合以下其他几个常用的传输协议来获得媒体数据:

  • Session Announcement Protocol(SAP):RFC2974

  • SIP:RFC3261

  • Real-Time Streaming Protocol (RTSP)(RFC 2326)

  • Internet Mail Extensions (MIME) extensions 拓展(电子邮件)

  • HTTP


下面,我们将具体介绍在RFC 4566中规定的定义,也包括了早期规范(RFC2327和RFC3266)的定义。


2

SDP常用参数定义全解

经过多年的发展,在SDP的概念中,除了最初的RFC2327和3266 规范以外,RFC4566增加了很多的功能概念和定义,同时还有一些最新的定义也可能在最近添加到SDP的规范中。以下介绍中将涵盖当前使用的大部分在SDP中核心概念和专有名词(65个定义)。其中一些专有名词很少使用,如果用户不了解的话,可以查阅相关规范做进一步学习,笔者这里尽可能归纳出当前完整的定义。另外提醒,其中一些定义和一般意义的SIP中的称谓有所不同,这些专有名词可能仅在SDP讨论中使用,所以读者一定要注意,避免产生歧义。


“m=” 行:SDP 消息体包含一个或多个媒体描述,每个媒体描述通过SDP在的一行”m=”定义。


5-tuple:简称为五元组,它有五种参数构成,包括源地址,源端口,目的地地址,目的地端口和传输层协议参数


Actual configuration:一个actual configuration指定了当前offer/answer模式下的SDP会话参数和媒体流模块的组合形式。在offer/answer模式下,如果使用了此种方式的话,将不再进行进一步的媒体协商。它是SDP能力协商模式的中四种模式的其中一种。读者可参考RFC5939和RFC6871获得具体细节。后续部分我们还有讨论另外两种配置形式。


Agent:这里的agent是一种在offer/answer模式中的协议部署方式,它包括offerer和answerer两种agents。读者可参考RFC 3264获得详情。


Aggressive nomination:Aggressive nomination:针对媒体流量,提取有效候选参数配对的一个过程,此过程在每个STUN请求中包含一个flag, 被选配对的参数将作为最高级配对测试。在部署过程中,Aggressive nomination相对比regular nomination处理更快一些,但是它和regular nomination相比,它缺乏灵活性。读者可参考RFC 5245获得相关规范。



Answer:一个SDP应答消息,它是由响应中的answerer发送的消息。


Answerer:它是一个agent,从另外一个agent接收会话描述,此agent说明了媒体通信期望的属性,并且对另外一个agent回应自己的会话描述。


Answerer BUNDLE address:使用在一个给定的BUNDLE组中,它是一个合并的IP地址和端口组合,answerer 用它来接收所有在每个“m=”行中指定的BUNDLE 同类组中媒体。


Answerer BUNDLE-tag:存在于一个answer 应答消息中,它是在一个给定的SDP“group:BUNDLE” 属性身份确认标签列表中的identification标签。


Base:它是服务端反射候选对象基础服务端,是可以实现自我学习的服务器本地候选人(host candidate)。host candidate也可以这样说,它自己本身也有一个base,这个base等同于自己,因为Server Reflexive Candidate(服务端反射候选对象)本身通过IP地址和端口的绑定,使用STUN或者TURN服务器自己学习。


Base attributes:出现在媒体块base configuration的约定SDP属性参数。


Base configuration:媒体配置环境,它通过所有能力协商属性独有的媒体部分来表示。在offer SDP中,此配置相当于前面介绍的actual configuration。


BUNDLE group:一个”m=” 行系列,它由一个SDP offer/answer 交互模式创建,此交互模式使用同样的BUNDLE address 接收媒体。


Bundled “m=” 行:一个 “m=” 行,在offer或者answer中,它的identification-tag 被置入到SDP的“group:BUNDLE” 属性identification-tag列表中。


Bundle-only “m=”行: bundled “m=” 行关联SDP中的“bundle-only” 属性设置。


Bundled media:所有在设定的BUNDLE group媒体。


Initial offer: 当SIP用来传输SDP时,在SDP会话中第一个offer消息,此offer消息指示它准备创建一个设定的BUNDLE group。


Candidate:一个传输地址,它是一个潜在的准备接收媒体的联系地址,它本身具有自己的属性:类型(server reflexive, relayed, or host), priority,foundation和base。


Candidate pair:候选配对包含本地候选和远端配对。


Check list:一个有序的候选配对列表,agent 将使用此列表生成check。


Check:check是从本地候选对象发送到候选配对的远端候选对象的过程。


Component:一个 component是一段媒体流,它要求一个单个传输地址。一个媒体流可能要求多个 components。它们中的每个component 都需要作为整体针对媒体流来工作。对于基于RTP的媒体流来说,每个媒体流包含两个component, 一个针对RTP流,另外一个针对RTCP流。


Controlled agent:一个ICE agent,等待controlling agent选择,controlling agent将从候选对象配对中选择出最后的选项。


Controlling agent:一个ICE agent,它负责从候选对象配对中选择出最终选项,然后通过STUN创建发起信令,如果需要的话,更新offer。注意,在任何会话中,一个agent总是控制方,另外一个是被控制方agent。


Conventional attribute:任何SDP属性除了通过一系列能力协商官方的属性以外的属性。


Conventional SDP: 一个SDP记录,此记录缺乏能力协商属性。


Core service platform (“core SPF”):它是一个宏定义的功能模块,提供一系列的功能接口,包括会话路由,高级服务接口和访问控制。它是是SDP的服务架构中的其中之一,负责SIP和SIP之间的接口连接。具体关于规范细节,读者可以查看SDP可选连接属性的规范来进一步了解服务架构(RFC6974)。

完整SIP/SDP媒体协商概论-SDP基础-核心定义全解


Data path border element (DBE):DBE 表示一个功能要素,它配置在IP通信管理domain之间的边界处(ITAD)。它负责解析从 用户代理接收到媒体数据流,然后转发到其他的DBE (媒体服务器,IVR服务器等)。例如,DBE作为一个媒体网关用来解析RTP流。


Signaling Border Element (SBE):以上图例也包括了SBE,它表示一个功能要素,它配置在IP通信管理domain之间的边界处(ITAD)。它负责解析从 用户代理接解析信令,然后转发到core SPF。一个SBE可控制一个或者多个DBE,SBE和DBE可部署在同一设备中或者各自独立分离工作。SBC就是一种典型的产品示例。用户可以查看笔者历史文章了解SBC功能和使用。SBE和DBE各自分离部署的更多讨论,读者可以查阅ALTC规范,RFC6947。


Decoding dependency:媒体层级之间都有一定的关系。此规范定义了解码依赖关系:layered coding 和 multiple description coding (MDC)。


Default destination/candidate:媒体流模块的默认目的地地址是传输地址,不是ICE aware的agent使用这个传输地址。对RTP模块来说,这个默认地址是标识在SDP的“c=”行,端口标识在SDP的“m=”行。对于RTCP来说,当默认目的地出现在rtcp属性中,当默认目的地没有出现时,此IP地址出现在 “c=” 行,端口加1,端口出现在“m=“行。一个模块的默认候选对象是它的传输地址匹配此模块的默认目的地地址。


File receiver:文件接收方,它愿意从发送方接收一个文件。


File selector:SDP offer的一个文件属性元组,它包含在SDP中以便在SDP answerer中选择一个文件。当发送方生成文件后,发送方必须明确无误地知道接收方的身份信息。RFC5547使用了File selector标识来处理这个问题。File selector主要目的是为对端提供足够的文件信息,确保本地和远端文件相关者能够使用的是同一文件。此定义涉及了很多的语法细节和具体的文件属性,因为篇幅关系,这里笔者不能展开讨论。关于File selector的规范说明,用户可以查看RFC5547-5章节。


File sender:文件发送方,它愿意从发送方对接收方发送一个文件。


Foundation:一个基础任意字符串,计算此值得规范是这样的。某种条件下,对于两个候选对象来说,基础字符串是是相同的。这两个候选对象必须具有同样的类型,base IP address和传输协议(UDP,TCP,等),和STUN或TURN服务器。如果它们中的其中任意一个不同,那么这个foundation将会不同。两个候选对象配对如果具有同样的foundation配对的话,这样的候选配对可能具有同样的网络特性。Foundations使用在Frozen algorithm中。Frozen algorithm的处理方式如下:

完整SIP/SDP媒体协商概论-SDP基础-核心定义全解

用户可以查看ICE创建的九个步骤来进一步学习:

http://www.jdrosen.net/uploads/1/5/0/0/15008848/ice-ietf-tutorial2.pptx


Full:一种ICE部署方式,它执行一系列本规范(RFC5245)定义的功能设置。解码SDP和候选对象处理都需要涉及到full implementation和lite implementation。关于两种部署方式的使用,读者需要查看RFC 5245-4.1,4.2和4.3章节。在此规范的以上章节中讨论了部分应用方式。


Lite:一种ICE部署方式,它忽略了某些功能支持能力,仅尽可能多为peer 部署提供支持。Lite implementations 不会维持任何状态机,并且也不产生connectivity checks。


Host candidate:本地主机候选对象是通过从主机的一个IP地址来绑定一个具体的端口实现的候选对象。此主机候选对象包括了物理网口的IP地址和逻辑地址,例如通过VPN获得的地址和RSIP地址(RFC 3102)。


Identification-tag:一个唯一标识值,它用来确认一个”m=”行。此SDP “mid” 属性关联一个”m=” 行,传输一个唯一的identification-tag。在每个”m=”后出现,通过SDP “group” 属性传输identification-tags列表,每个 “m=”行关联一个特别的分类组。group(RFC5888-5)的语法为:

group-attribute     = "a=group:" semantics *(SP identification-tag)

完整LS的语法如下(LS表示Lip Synchronization (LS),参考RFC5888-7):

mid-attribute      = "a=mid:" identification-tagidentification-tag = token示例:v=0o=Laura 289083124 289083124 IN IP4 one.example.comc=IN IP4 192.0.2.1t=0 0a=group:LS 1 2m=audio 30000 RTP/AVP 0a=mid:1m=video 30002 RTP/AVP 31a=mid:2

这里,读者需要注意,token是通过RFC4566-9规范定义的。在此规范中,因为媒体类型不同,token划分为不同的含义,其中,1表示语音,2表示视频,text或者其他的应用,例如语言支持等。


Latent configuration:latent configuration是一种潜在隐藏配置,它用来表示哪一种能力租户可以在将来的会话以及关联媒体的协商中使用。Latent configurations 既不准备现在使用,也不准备在当前offer/answer交互模式中的实际协商能力或潜在协商能力中使用。Latent configurations 仅通知实体可能支持的配置。这些潜在配置可以为后续的offer/answer交互模式提供一个指导建议,但是,潜在配置不能作为当前offer/answer 交互的一个部分。笔者可能觉得此概念非常迷惑,笔者通过一个简单示例来说明潜在配置的作用。例如,如果一方对另外一方创建了一个会话,并且发起一个语音呼叫时,同时,发起方可以对对方声明另外一个潜在支持能力,在同一会话中,通知对方,发起方也可以支持视频能力。对方获悉发起方还有一种潜在的能力(支持视频能力),这个潜在配置就是一种latent configuration。它必须包含一个”mt=”行。具体用法和规范参考RFC6871-3.3.5。本章节后续部分,笔者还将讨论另外一种潜在配置形式。


Layered coding dependency:它也称之为layered encoding schemes。它会把媒体解码成不同的层级。当所有媒体分区的依赖分区都在有效状态时,每个媒体分区才有用。因此,媒体分区之间的依赖关系创建了一个定向图示。注意,一般情况下,在一个层级编码中,使用更多的媒体分区,可能会取得更好效果。简单来说,接收方媒体的质量取决于收到的层级的数量。SDP提供了一种方式来同组不同多播地址传输的层级,通过”c=”行来定义:
 c=IN IP4 233.252.0.1/127/3

以上语法定义了三个层级,等同于以下语法(3个”c=”层级,不同的测试多播地址):

c=IN IP4 233.252.0.1/127c=IN IP4 233.252.0.2/127c=IN IP4 233.252.0.3/127


更多关于layered encoding schemes内容,读者可查阅RFC4566-5.7和RFC5888-8.5.2。


Local candidate:本地候选对象是一个agent,此agent已经获得,并且已经被包含在它发送的offer或answer消息中。


Media Bitstream:一种有效的,可解码的媒体,此媒体流包含所有的由解码器生成的媒体分区。媒体比特流通常遵从一个媒体解码标准。


Media capability:一系列能力合并组合,媒体能力关联这些媒体能力是通过声明一种媒体格式和其相关参数关联的方式来实现。


Media format capability:一种媒体格式,通常情况下所指一种媒体的子类型,例如 (PCM)的 μ-law 算法algorithm (PCMU),H263-1998或者T38传真算法等。


Media format parameter capability:在能力格式中设定的媒体参数,例如SDP约定中的”a=fmtp” 行。媒体能力参数和媒体格式能力关联。


Media partition:媒体比特流的子项,它的目的是实现传输相互关联。媒体分去掉整数号码构成了一个媒体比特流。在层级编码中,一个媒体分区表示一个或多个分层,它们各自表示一个或多个描述,通过绑定它们来组成一个单元(参考Layered coding dependency的”c=”行介绍)。


Media stream:一个 媒体流是一个单个媒体实例(例如,一个语音流,或者视频流,白板功能或者共享应用组)。在SDP中,媒体流是通过”m=”行和关联属性。


MDC dependency:MDC全称是Multiple Description Coding,其基本工作原理是把单个媒体流分片处理为n个子媒体流(n ≥ 2),携带其媒体描述。每个数据包携带其描述同时提供不同节点路由到目的地端。如果需要对此媒体流进行解码的话,可以使用任何一个描述来处理,但是,媒体质量的提升取决于同时收到的媒体描述数量。因此,在互联网环境中,多描述编码的依赖关系可以有效解决视频通信中数据丢包和网络拥塞的问题,因为使用MDC处理方式无需重传数据。N-out-of-M媒体分区是一种比较复杂的MDC类型,其中N和M的值取决于媒体比特流的属性。使用MDC时,所有针对Operation Point(操作点)的媒体流必须通过identification-tag和fmt-dependency确认。另外一种解码依赖处理方式是Layered decoding dependency,和MDC相比各有其优缺点。如果读者有兴趣的话,可以查阅RFC5583-7章节和参考资料的链接来学习。MDC的语法格式为:
depend-attribute =           "a=depend:" dependent-fmt SP dependency-tag              *(";" SP dependent-fmt SP dependency-tag) CRLF
dependency-tag = dependency-type *1( SP identification-tag ":" fmt-dependency *("," fmt-dependency ))
dependency-type = "lay" / "mdc" / token
dependent-fmt = fmt
fmt-dependency = fmt

MDC信令示例:

v=0o=mdcsrv 289083124 289083124 IN IP4 host.example.coms=MULTI DESCRIPTION VIDEO SIGNALING Seminart=0 0c=IN IP4 192.0.2.1/127a=group:DDP M1 M2 M3 // DDP:Decoding Dependencym=video 40000 RTP/AVP 104 // 依赖 M1a=mid:M1a=depend:104 mdc M2:105 M3:106 // 104 依赖 M2-105和M3-106m=video 40002 RTP/AVP 105a=mid:M2a=depend:105 mdc M1:104 M3:106m=video 40004 RTP/AVP 106a=mid:M3a=depend:106 mdc M1:104 M2:105
以上示例中,会话描述中支持了三种媒体描述。所有视频媒体使用MDC处理方式。每个媒体描述包含一个媒体格式。DDP 解码依赖组包含了三个M组。媒体格式描述104 依赖于媒体格式描述105和106。这里,媒体格式描述105和106用来优化媒体格式描述104的,但是它们可以不被解码(前面提到,多个描述可以帮助优化媒体质量)。


Nominated:如果一对有效的候选配对已经指定了flag标识设置,这表示ICE可能会选择此后续配对发送和接收媒体。


Offer:一个SDP消息,由offerer发送。


Offerer:一个agent,此agent生成一个会话描述来创建或者修改会话。


Offerer BUNDLE address:在一个给定的 BUNDLE group,offerer使用一个IP地址和端口组合接收所有的媒体,此媒体是通过在BUNDLE组中设定的每个”m=”行标识。


Offerer BUNDLE-tag:在offer消息中,给定SDP “group:BUNDLE”属性identification-tag列表中的第一个identification-tag。


Operation point:在分层编码(layered coding)中的一个操作节点,包含所有媒体分区的媒体比特流的子集,此子集为了在某些操作节点重构媒体质量,错误自适应和其他属性的,它不包含任何其他媒体分区。在MDC编码中,这些MDC的子集需要遵从MDC的编码标准。


Ordinary check:一种常规检测,是一种connectivity check,它由agent生成作为定时器的结果,此定时器定期触发,命令agent发送一个检查。注意,常规检测仅支持full implementations。RFC 5245-5.8有关于对常规检测定时说明,读者可以去做进一步了解。


Peer:在会话过程中,从其他agent角度看到的其中一个agent,它们的peer也是其他agent。具体来说,如果从offerer的角度看,它的peer就是一个answerer。反之亦然,如果从answerer的角度看,它的peer就是offerer。


Peer reflexive candidate:一个候选对象,此候选对象是这样定义的-当候选对象通过NAT对其peer发送一个STUN绑定请求时,NAT已经把候选对象的IP地址和端口绑定分配给一个agent。在RFC 5245的第七章中有关于如何发现Peer reflexive candidate和对Peer reflexive candidate的自我学习处理。


Potential configuration:一个潜在的配置,它表示会话和关联的构件所支持的媒体能力组合。此配置不能现在使用。但是,此配置可为当前的offer/answer交互提供未来可用的能力,它为当前的offer/answer交互提供了一种可选方式,可以替代实际配置。注意,笔者在前面介绍了Latent configuration,这里又介绍了potential configuration。如果我们简单从字面意思好像没有什么区别,事实上,它们之间存在根本区别。Latent configuration是一种潜在“隐藏”的能力,支持未来协商能力,而Potential configuration是本身“已具备”的能力,可以替代当前实际配置。关于Latent configuration的定义,笔者在前面内容已经有所介绍,笔者一定要注意这两种配置的使用场景。更多关于两种配置的规定说明,读者可以参考RFC 5939-3.1和RFC6871-2。


Pull operation:它是一种文件传输操作,在提取操作中,SDP offerer充当文件接收方角色,并且 SDP answerer充当文件发送方的角色。


Push operation:它是一种文件传输操作,在推送操作中,SDP offerer 充当文件发送方角色,并且SDP answerer充当文件接收方的角色。以上两个操作方式的规定在RFC5547 官方中定义。


Regular nomination:一个对媒体流提取有效候选配对的过程,此过程是通过一个STUN请求对配对进行验证,选择出有效候选配对,然后通过发送第二个STUN请求,在第二个STUN请求中携带一个标识来表示其提名。它和ICE使用的另外一种nomination-Aggressive Nomination的标识方式有所不同。后者处理速度比较快,但是缺乏灵活性,前者则具有更强的灵活性。这里,L表示本地,R表示远端,在第二个STUN请求中携带flag标识,表示其被提名。


完整SIP/SDP媒体协商概论-SDP基础-核心定义全解

Regular nomination 处理流程(RFC 5245-2.6)


Relayed candidate:它是一个候选对象,具体获得的方式是,通过从本地主候选对象对TURN 服务器发送一个TURN Allocate 请求而获得的对象。转发候选对象部署在TURN服务器,此TURN服务器然后转发数据返回到agent。


Remote candidate:一种候选对象,是agent从其peer发送的offer或者answer消息中收到的候选对象。


Selected pair, selected candidate:selected pair是由ICE选择的候选对象配对,它用来发送和接收媒体,候选对象中的每个candidate称之为。具体定义可参考RFC 5245。


Server reflexive candidate:它是一种候选对象,其IP地址和端口是一个绑定关系,当候选对象通过此NAT发送数据包到一个服务器时,绑定通过NAT分配给agent。Server reflexive candidates通过STUN 服务器使用Binding请求或者通过TURN服务器具进行学习。一旦Server reflexive candidate被分配以后,它们必须一直保持活动状态,直到ICE处理完成。对于通过绑定请求学习的Server reflexive candidate,绑定需要维持的话,Server reflexive candidate必须一直发送对服务器端额外的绑定请求。刷新请求同样也刷新Server reflexive candidate。具体的定义在RFC 5766-2章节。candidate本身有自己的类型和base。RFC5245中对type定义了4种方式,Server reflexive candidate就是其中一种,其他三种分别是host candidates,peer reflexive candidates和relayed candidates。这些类型我们在此文章中也做了介绍。获得这些candidates的方式有所不同,用户在理解这些对象是需要注意,同时要结合前面的介绍针对每个类型有一定的了解,这样可以帮助读者消化ICE处理的整个流程。关于如何获得这几种类型的candidate,读者可以阅读RFC5245-4.1.1部分章节。


Session:一个多媒体会话是一系列多媒体发送方和接收方,还包括从发送方到接收方的数据媒体处理流程。多媒体会议就是一个多媒体会话的实例。



Session description:会话描述是一种定义完整的消息格式,在多媒体会话中,它是用来传输有效信息,以便发现和参与会话流程。


Shared address:一个IP地址和端口的组合,在offer或answer消息中,它通过多个”m=” 行发生关联关系。


Subsequent offer:一种offer消息,它包含一个BUNDLE group,此BUNDLE group已经在在前面offer/answer交互中创建,是前面交互的一个部分。


Transport address:IP地址和传输协议(UDP或者TCP)的组合地址。


Triggered check: Triggered check(已触发的check)是一种 connectivity check,它的目的是作为一个从peer收到的connectivity check凭证的结果。更多关于此定义的说明包括Triggered check queue,读者可查阅RFC 5245-7.2.1.4章节的内容。


Unique address:此地址是一个IP地址和端口的组合,它通过在offer或者answer消息中的一个”m=”行关联。


Valid list:针对媒体流的一组有序候选对象配对,此列表已经由一个成功的STUN事务验证通过。



在本章节的接下来的内容中,笔者将继续讨论 SDP的使用方式,SDP要求和建议以及规范标准概览。为进一步了解SDP打好基础。



参考资料:

https://www.rfc-editor.org/rfc/rfc4566.html

https://www.rfc-editor.org/rfc/rfc5245

http://www.muonics.com/rfc/rfc2974.php

https://techcommunity.microsoft.com/t5/skype-for-business-blog/how-communicator-uses-sdp-and-ice-to-establish-a-media-channel/ba-p/618433

https://tools.ietf.org/html/draft-vitali-ietf-avt-mdc-lc-00

https://tools.ietf.org/html/draft-vitali-ietf-avt-mdc-lc-00

https://link.springer.com/chapter/10.1007/11848035_96

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


完整SIP/SDP媒体协商概论-SDP基础-核心定义全解
完整SIP/SDP媒体协商概论-SDP基础-核心定义全解



关注微信公众号:asterisk-cn,获得有价值的Asterisk行业分享
Asterisk freepbx FreeSBC技术文档: www.freepbx.org.cn
融合通信/IPPBX商业解决方案:www.hiastar.com
如何使用FreeSBC,qq技术分享群:334023047


联系电话-18665301040
客服-3
客服-2
客服-1