sdp协议详解.docx
- 文档编号:12967831
- 上传时间:2023-06-09
- 格式:DOCX
- 页数:15
- 大小:26.15KB
sdp协议详解.docx
《sdp协议详解.docx》由会员分享,可在线阅读,更多相关《sdp协议详解.docx(15页珍藏版)》请在冰点文库上搜索。
sdp协议详解
竭诚为您提供优质文档/双击可除
sdp协议详解
篇一:
sdp协议原理及应用
内部公开▲
sdp协议原理及应用
编者:
尚森
审核:
王高原
中兴通讯固网交换用服部
内部公开▲
修改记录
内部公开▲
目录
第1章sdp的协议原理............................................................................................................................1
1.1sdp的概述........................................................................................................................................1
1.2sdp协议字段....................................................................................................................................1
1.3说明...................................................................................................................................................3
第2章sdp的应用....................................................................................................................................4
2.1sdp在sip电话中的应用2.2sdp各type的详细解释2.3sdp在h.248的应用第3章sdp的实例应用.
3.1sdp的举例描述3.2h.248中sdp消息举例描述.
内部公开▲
第1章sdp的协议原理
1.1sdp的概述
sdp(sdp:
sessiondescriptionprotocol会话描述协议)是由ietF(interne工程任务组)作为RFc4566颁布,描述流媒体初始化参数的格式。
其目的就是在媒体会话中,传递媒体流信息,允许会话描述的接收者去参与会话。
定义了会话描述的统一格式,但并不定义多播地址的分配和sdp会话描述协议(sdp多媒体会话描述。
即用于将这种信息传输到接收端。
sdp完全是一种会话描述格式――适当的传输协议,包括会话通知协议(sapRtsp)、mime扩展协议的电子邮件以及超文本传输协议(
sdp播会话目录,但sdp在因特网组播骨干网(mbone这由完成。
sdp连接好会话后,传送足够的信息给会话参与者。
sdpsap),它周期性地组播通知数据包到已sap协议头和文本有效载荷(textpayloadsdp会话描述。
此,外信息也可以通过电子邮件或www(sdp
1.2sdp协议字段
sdp信息是文本信息,采用utF-8编码中的iso10646字符集。
sdp会话描述如下:
(标注*符号的表示可选字段):
sdp协议原理及应用内部公开▲
表1-1sdp会话描述
篇二:
sip协议详解中文版
1、sip协议介绍
internet的许多应用都需要建立和管理一个会话,会话在这里的含义是在参与者之间的数据的交换。
由于考虑到参与者的实际情况,这些应用的实现往往是很复杂的:
参与者可能是在代理间移动,他们可能可以有多个名字,他们中间的通讯可能是基于不同的媒介(比如文本,多媒体,视频,音频等)-有时候是多种媒介一起交互。
人们创造了无数种通讯协议应用于实时的多媒体会话数据比如声音,影像,或者文本。
本sip(会话初始协议)和这些协议一样,同样允许使用internet端点(用户代理)来寻找参与者并且允许建立一个可共享的会话描述。
为了能够定位精确的会话参与者,并且也为了其他的目的,sip允许创建基础的networkhosts(叫做代理服务器),并且允许终端用户注册上去,发出会话邀请,或者发出其他请求。
sip是一个轻形的,多用途的工具,可以用来创建,修改和终止会话,它独立运作于通讯协议之下,并且不依赖建立的会话类型。
2、sip协议功能概况
sip是一个应用层的控制协议,可以用来建立、修改、和终止多媒体会话(或者会议)例如internet电话。
sip也可以邀请参与者参加已经存在的会话,比如多方会议。
媒体可以在一个已经存在的会话中方便的增加(或者删除)。
sip显示的支持名字映射和重定向服务,这个用于支持个人移动业务-用户可以使用一个唯一的外部标志而不用关系他们的实际网络地点。
sip在建立和维持终止多媒体会话协议上,支持5个方面:
用户定位:
检查终端用户的位置,用于通讯。
用户有效性:
检查用户参与会话的意愿程度。
用户能力:
检查媒体和媒体的参数。
建立会话:
”ringing”,建立会话参数在呼叫方和被叫方。
会话管理:
包括发送和终止会话,修改会话参数,激活服务等等。
sip不是一个垂直集成的通讯系统。
sip可能叫做是一个部件更合适,它可以用作其他ietF协议的一个部分,用来构造完整的多媒体架构。
比如,这些架构将会包含实时数据传输协议(Rtp)(RFc1889)用来传输实时的数据并且提供qos反馈,实时流协议(Rstp)(RFc2326)用于控制流媒体的的传输,媒体网关控制协议(megaco)(RFc3015)用来控制到公共电话交换网(pstn)的网关,还有会话描述协议(sdp)(RFc2327)用于描述多媒体会话。
因此,sip应该和其他的协议一起工作,才能提供完整的对终端用户的服务。
虽然基本的sip协议的功能组件并不依赖于这些协议。
sip本身并不提供服务。
但是,sip提供了一个基础,可以用来实现不同的服务。
比如,sip可以定位用户和传输一个封装好的对象到对方的当前位置。
并且如果我们利用这点来通过sdp传输会话的描述,立刻,对方的用户代理可以得到这个会话的参数。
如果我们用这个像传输会话描述(sessiondescRiptionsd)一样呼叫方的照片,一个”呼叫id”服务很容易就建立了。
这个简单的例子说明了,sip作为一个基础,可以在其上提供很多不同的服务。
sip并不提供会议控制服务(比如议席控制或者投票系统),并且并没有建议会议应该则那样管理。
可以通过在sip上建立其他的会议控制协议来发起一个会议。
由于sip可以管理参与会议的各方的会话,所以会议可以跨异构的网络,sip并不能,也不打算提供任何形式的网络资源预留管理。
安全对于提供的服务来说特别重要。
要达到理想的安全程度,sip提供了一套安全服务,包括防止拒绝服务,认证服务(用户到用户,代理到用户),完整性保证,加密和隐私服务。
sip可以基于ipV4也可以基于ipV6
3、术语
在这个文档中,关键词”必须”,”不允许”,”要求”,”可以”,”不可以”,”应该”,”不应该”,”建议”,”不建议”,”可能”,”可选”是根据bcp14,RFc2119[2]的规范描述sip实现需要的不同层次
4、实施概览
这节通过简单的示例介绍了sip的基本实现。
本节是通过自然的而非正则的示例来介绍的。
第一个例子说明了sip的基本功能:
定位一个断点,发出通讯请求,通过协商会话参数建立会话,拆卸刚才建立的会话。
图一表示一个典型的alice和bob两个用户间的sip消息交易交换例子(.每一个消息采用字母”F”和一个用来指向正文的一个数字做标记)在这个例子里,alice在她的pc上使用一个sip的应用程序(比如说一个软的电话),呼叫bob在internet上的一个sip电话。
这个例子也掩饰了两个sip代理之间,怎样为alice和bob建立会话连接。
thistypical
arrangementisoftenreferredtoasthe"siptrapezoid"asshownbythegeometricshapeofthedottedlinesinFigure1.alice通过bob的sip标志“呼叫”bob,这个sip标志是统一分配的资源(uniformResourceidentifieruRi)称作sipuRi。
sipuRi在19.1节中定义。
它很像一个email抵制,典型的sipuRi包括一个用户名和一个主机名。
在这个范例中,sipuRi是sip:
bob@,是bob的sip服务提供商。
alice有一个sipuRi:
sip:
alice@。
alice可以输入bob的uRi,也可以直接在地址本的一个超级链接上点击一下bob的uRi。
sip也提供保密uRi,称作sipsuRi。
例如:
sips:
。
一个基于sipsuRi的通话保证这个通话是安全的,并且对呼叫者和被叫的所有的sip消息是加密传输的(叫做tls)。
在tls中,请求是通过加密方式传输给被叫方,但是这个加密机制是基于被叫方宿主服务器的实现的。
sip是基于一个类似http协议的请求应答的通讯模式。
每一个通讯都包含对某个功能的请求,并且起码需要一个应答。
在这个应答中,alice的软电话发送一个含有bbo的sipuRi抵制的inVite通讯请求。
inVite是一个sip请求的例子,表示请求方(alice)希望服务方(bob)应答。
inVte请求包含一系列的包头域(headerfields)。
包头中包含很多属性并且包含了传输消息的附加信息。
在inVite中有如下的字段:
呼叫的唯一标志,目的抵制,alice的地址,alice和bob建立会话的类型。
inVite请求(图1中的F1)可能看起来像这样的:
inVitesip:
bob@sip/2.0
Via:
sip/2.0/;branch=z9hg4bk776asdhdsmax-Forwards:
70
to:
bob
From:
alice;tag=1928301774
call-id:
a84b4c76e66710@cseq:
314159inVite
contact:
content-type:
application/sdpcontent-length:
142(alicessdpnotshown)
..
proxy
proxy
..
alice’s............................................bob’s
softphone|
||
|||
sipphone
||||||||||||||||||||
|inViteF1|--------------->| |inViteF2|--------------->| |100tryingF3|inViteF4|--------------->| |100tryingF5|180RingingF7
|180RingingF6
|180RingingF8| ackF12
------------------------------------------------->
mediasession
byeF13
|
200okF14
------------------------------------------------->
图一:
sip矩形表达的sip会话建立例子。
在文本消息的第一行,包含了请求的类型(inVite)。
在这行之后的是这个请求的头域。
这个例子中包含了最少需要的头域集合。
简单介绍一下:
Via域包含了alice接收发送请求的服务器地址()。
同样这个包含了一个分支参数来标志alice和这个服务器的会话事务。
to域包含了显示姓名(bob)和一个sip或者sipsuRi(sip:
bob@)请求将首先传输到这个uRi中。
显示姓名(displaynames)在RFc2822中描述。
From域也同样包含一个显示姓名(alice)和一个sip或者sipsuRi(sip:
alice@)这个uRi用来标志请求的原始发起者。
这个域也包含了一个tag参数,这个tag参数是一个随机字串(1928301774),是软电话(softphone)在uRi上增加的一个随机串。
用来做标志用途的。
call_id包含一个全局的唯一标志,用来唯一标志这个呼叫,通过随机字串和softphone的自己名字或者ip抵制混和产生的。
通过totag,FRomtag和call-id完整定义了alice和bob之间的端到端的sip关系,并且表示这个是一个对话性质的关系。
cseq或者commandsequence包含了一个整数和一个请求名字。
这个cseq数字是顺序递增的。
每当对话中发起一个新的请求都会引起这个数字的顺序递增。
contact域包含一个sip或者sipsuRi用来表示访问alice的直接方式,通常由用户名和一个主机的全名(FullyqualifieddomainnameFqdn)组成。
当Fqdn作为首选的时候,许多终端用户由于不会由名字登记(而导致不能访问alice的主机),所以ip地址是可选的。
Via域告诉大家本请求发送到哪里并且应答到哪里,contract域告诉大家将来的请求将发送到哪里(奇怪…不是alice发起的么,将来的请求应该是bob才对啊)。
max-Forwards:
最大转发数量限制了通讯中转发的数量。
它是由一个整数组成,每转发一次,整数减一。
content-type包含了消息正文的描述(消息正文在本范例中没有列出)
content-length:
包含消息正文的长度(字节数)
完整的sip包头域的定义在20节。
会话的细节,比如媒体的类型,codec,或者采样速率,没有通过sip来描述。
这个可以通过sip的消息正文来描述,可以通过其他定义的协议在正文中进行描述。
有一种是会话描述协议(sessiondescripotionprotocolsdp)(RFc2327[1])。
这个sdp消息(没有在例子中列出)通过sip的消息中传送,就像通过附件发送email一样,或者说通过http传输的网页一样。
由于softphone并不知道bob或者bob的sip服务器在哪里,所以softphone发送inVite请求到alice的sip服务器,。
这个sip服务器应该已经在alice的softphone中配置了,或者可以通过dhcp获得。
sip服务器是一台代理服务器。
代理服务器接收sip请求并且根据请求转发。
在这个例子中,代理服务器接收到inVite请求,并且回送一个100(trying)应答给alice的softphone。
100(trying)应答表示inVite请求已经收到,并且代理服务器正在转发inVite请求。
sip的应答是通过一个三位数的数字表示的。
sip应答同样包含to、FRom、call-id,cseq和在Via中的分支参数,这个参数使得alice的softphone可以把请求和应答关联起来。
代理服务器收到inVite请求之后,就去找可能通过dns服务来找提供这个的sip服务器。
这在[4]中有描述。
最后,转发inVite请求到或者能到达的代理服务器。
在转发请求之前,代理服务器会在via头上增加一个一段包含自己抵制的值(inVite已经包含了alice的的地址Via域)。
代理服务器收到这个inVite请求并且返回一个100(trying)应答给代理服务器标志这它已经收到这个请求并且正在处理这个请求。
这个代理服务器通过查询数据库,通常叫做地址服务,这个服务中包含了bob的当前ip地址。
(我们在下一节可以看到这个数据库是怎么回事)代理服务增加另一段包含自己地址的Via头域并且发送它到bob的sip电话。
bob的sip电话接收到inVite请求并且提醒bob有一个从alice的呼入,这样bob可以决定是否响应这个呼入。
这个意思就是:
bob的电话响了。
bob的sip电话发送一个180(Ringing)回应,这个回应减通过两个代理服务器原路返回给alice。
每一个代理服务器通过via头域决定该把这个应答发送给哪里,并且在发送之前把自己的地址从头上拿走。
虽然dns和定位服务在路由最初的inVite请求,180(ringing)响应可以简单返回给发起者而不需要查找发起者在哪里,并且不需要在代理服务器保留状态,同时,每一个转发inVite的代理也可以得到inVite的每一个应答,这样的特性也非常有用。
当alice的softphone收到180(Ringing)应答的时候,它提示alice,可能是通过一个回铃音,或者屏幕上的一个消息提示。
在这个例子中,bob决定响应这个呼叫。
当他拿起电话,他的sip电话发送200(ok)回应给发送者,表示这个电话已经接起来了。
这个200(ok)包含了一个消息体,这个消息体包含sdp媒体描述,这个媒体描述包含bob希望和alice建立何种媒体连接。
同样,sdp消息也是两段交换:
alice发送一个给bob,bob发送一个回给alice。
这个两段的交换提供基本的兼容性协商,并且基于简单的sdp提出/应答交换模型。
如果bob不想响应这个呼叫或者正在响应别的呼叫,一个错误的响应会代替正常的200(ok)回送出去,这样,就不会有连接建立。
sip完整的返回代码在21节有介绍。
bob发出的200(ok)(图一的F9消息)可能长得像这样的:
sip/2.0200ok
Via:
sip/2.0/
;branch=z9hg4bknashds8;received=192.0.2.3
Via:
sip/2.0/
;branch=z9hg4bk77ef4c2312983.1;received=192.0.2.2Via:
sip/2.0/
;branch=z9hg4bk776asdhds;received=192.0.2.1to:
bob;tag=a6c85cf
From:
alice;tag=1928301774
call-id:
a84b4c76e66710@cseq:
314159inVitecontact:
content-type:
application/sdpcontent-length:
131(bobssdpnotshown)
应答的第一行包含了应答代码(200)和原因(ok)。
剩下的行包含了包头域。
Via,to,FRom,call-id,cseq包头域是从inVite请求包中直接拷贝过来的。
(有三个Via域值-一个是alicesip电话增加的,一个是代理加的,一个是代理加的)。
bob的sip电话增加了一个tag参数。
这个tag参数会被参与对话的各方所使用,并且在以后的对话中被使用。
contract域包含了一个能直接联系到bob的uRi。
content-type和content_length域包含了消息体(没有在例子中体现),这个消息体里边是bob的sdp媒体信息。
除了dns和位置服务之外,代理服务器可以自主决定路由,也就是说自己决定应该向哪里转发请求。
比如,如果bob的sip电话返回一个486(电话正忙)信号,这个代理服务器可以转发这个inVite请求到bob的语音邮箱服务器。
一个代理服务器可以同时向n个地方发送inVite请求。
这种并发寻找就是传说中的分流(forking)。
在这个例子中,200(ok)应答通过两个代理并且发送到alice的softphone上,alice的softphone收到这个应答,停止振铃,并且标志电话bob已经接听。
最后,alice的电话发送一个确认消息,ack,到bob的sip电话来确认接收到了这个最后的200(ok)应答。
在这个例子中,ack信号是直接由alice的softphone发送到bob的sipphone上,跨过了两个代理服务器。
这是因为两个端点(alice和bob)通过inVite/200(ok)的请求应答包中的contact包头域都知道互相之间的地址了,这个地址是最开始发起inVite请求的时候所不知道的。
所以,不需要两个代理服务器再查找对方的地址了,所以代理服务器不参与接下来的通话流了。
这就完成了一个完整的使用inVite/200/ack三方握手来建立sip会话的过程。
会话建立过程中的细节描述再13节由描述。
现在,alice和bob的媒体会话开始了,他们通过发送刚才建立会话所交换的sdp包中约定的互相明白的媒体包来进行会话。
一般情况下,端到端的媒体包和sip信号控制包通过不同的通讯路径来发送。
在会话中,alice或者bob都可以改变他们自己的媒体会话属性。
这个可以通过发送一个包含新媒体属性描述的re-inVite请求来完成。
这个re-inVite是捆绑在一个现有的会话的,这样参与会话的对方可以明白这是要改变现有的会话属性而不是新建立一个会话。
对方收到这个re-inVite请求后,会发送一个200(ok)应答表示接受这个改变。
请求方通过一个ack来表示接受了对方的这个20
0(ok)应答。
如果对方不同意这个媒体属性变化,他会发送一个错误的应答比如488(暂时不能进行),这个也会收到发起者的一个ack响应。
不管怎样,就是是re-inVite的失败也不会影响到现有的会话-原有的会话还可以用上次的媒体会话属性继续。
可以在14节找到会话属性更改的细节说明。
在通话结束的时候,bob首先断开(挂机hangsup),并且发送一个bye的消息。
这个bye的消息将直接送到alice的softphone,同样是跳过代理的。
alice通过发送200(ok)应答来确认收到了这个bye消息,这个消息终止了会话并且应答了bye的请求。
ack在这里不需要发送-一个ack信号只在响应一个inVite的响应的时候被发送。
我们稍晚一点会讨论这个inVite的特别处理,但是基于sip的可靠性的机制,一个通话的时间可以认为包含电话振铃和挂机的时间(butrelatetothereliabilitymechanismsinsip,thelengthoftimeitcantakeforaringingphonetobeanswered,and
forking.)基于这样的原因,sip请求的处理通常根据是否inVite请求进行分类,inVite类和非inVite类请求分开处理。
结束会话的细节可以在15节查到。
24.2节描述了图1中使用的全部消息详细解释。
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- sdp 协议 详解
![提示](https://static.bingdoc.com/images/bang_tan.gif)