SIP交换中的SDP及RTP的工作过程


 
下面是一个典型的SIP 会话
 



要传送媒体首先要建立一个媒体会话(Session )。建立媒体会话实际上就是通过SDP offer/answer 交换进行就会话的媒体参数进行协商的一个过程。但在SIP 中没有规定使用哪个SIP 消息来携带一个SDP offer answer )。理论上,任何SIP 消息的正文中都可以包含会话描述部分。但是,一个SIP 中的会话描述并不一定是一个offer 或一个answer, 只有符合在SIP 标准RFCs 中所描述的规则的会话描述才会被解释为一个offer 或一个answer offer/answer 模型定义会话的更新。在SIP 中,对话(dialog )用于将offer/answer 交换及其要更新的会话联系起来。换句话说,只有在某个SIP 对话中进行的offer/answer 交换,才能更新该对话所管理的会话。
SIP 消息中承载offer/answer 的规则定义在RFC 3261[1], RFC 3262 [2] 以及RFC 3311 [4] 中。在这些RFCs 中定义了 六种 SIP 消息中交换offer/answer 的模式。
模式1 和模式2 是在RFC3261 中定义 的,用于不支持可靠临时响应消息(1xx-rel )的SIP 实体之间的会话建立。
模式 1 UAC INVITE 请求中携带一个 offer, UAS 200 INVITE 响应中返回answer 。这是最常用的一种模式。
模式 2 UAC INVITE 请求中没有携带 offer UAS 200 INVITE 响应中携带一个offer UAC 通过ACK 返回answer 。这种模式通常用于3PCC 中。
模式3 、模式4 、模式5 都是在RFC3262 定义的,可用在支持100rel (可靠临时响应)扩展的SIP 实体之间。其中模式3 、模式4 可用于会话建立。模式5 只能用于会话参数更新。它们利用 1xx-rel 响应消息来携带offer answer 来建立会话。
模式 3 UAC INVITE 请求中携带一个offer, UAS 1xx-rel 响应中返回answer 。这样,在呼叫完成之前(UAC 没有收到200 INVITE 消息)会话已建立。此后,会话参数还可以被更新,具体见模式5 及模式6
4 UAC INVITE 请求中没有携带offer UAS 1xx-rel 可靠响应中携带一个offer UAC 通过PRACK 返回answer 。同样地, 在呼叫完成之前(UAC 没有收到200 INVITE 消息)会话已建立。此后,会话参数还可以被更新,具体见模式6
模式 5 UAC UAS 采用模式3 建立会话 后,呼叫并未完成(见模式3 )。之后,可以使用模式5 对已建立的会话参数进行更新:UAC PRACK 请求中携带一个新的offer, UAS 200 PRACK 响应中返回answer 。这样,会话参数便被更新。
模式6 RFC3311 中定义,主要用于在早期 对话中更新已建立的会话参数,会话可能是通过模式3 ,也可能是通过模式4 建立的。
模式6 还可以对会话进行多次更新。例如,之前已通过模 5 更新过的会话还可以使用模式6 更新;甚至通过模式6 更新过的会话还可以再次使用模式6 更新。
6 UAC (或UAS )发送 UPDATE 请求其中携带一个新的offer, AS (或UAC )在 200 UPDATE 中返回一个offer 。这样,会话参数便被更新。注意,UAS UAC 在发送UPDATE 进行会话更新之前,必须保证之前的会话更新过程已经 完成。也就是说,发出的offer 已经收到answer ,或者收到的offer 已经产生了answer
INVITE 方法提供了会话建立过程。
在没有100rel 选项时,会话建立过程非常简单,只能使用200INVITE 响应消息传送会话描述,这些会话描述可能是answer( 模式1), 也可能是 offer (模式2 )。无论使用何种模式,会话都只能呼叫完成后才能建立,在呼叫完成之前和呼叫完成之后只能有一个会话 用于最终通话的常规会话,因而,不能建立所谓的“早期媒体会话”。
在引入100rel 选项后,会话建立过程变得复杂,通过可靠的临时消 息消息也可以传送会话描述,这些会话描述可能是answer( 模式3), 也可能是offer (模式4 )。模式3 和模式4 都能够在呼叫完成前建立会话。并且 在呼叫完成之前,这些会话还可以被更新。这样就能够建立与常规会话不同的“早期媒体会话”,完成回铃音的产生等功能。
PRACK 方法可 用于更新已建立的会话的参数(模式5
UPDATE 方法可用于多次更新已建立的会话的参数(模式6 ),发起更新的可以是UAC 也可以是 UAS
 
 
 
SDP RTP 的工作过程:
一、SIP 协议告知对方UDP 端口号,协商媒体类型
1.1         主叫方发给被叫方的INVITE 请求
 

 
1.2         被叫方回给主叫方的183 消息
 
 
 
 
 

二、RTP 媒体流
2.1         主叫方发给被叫方的一个RTP 包,UDP 端口号是SDP 协商好的,包的序列号是28590


2.2         主叫方发给被叫方的下一个RTP 包,UDP 端口号是SDP 协商好的,包的序列号是28591
 
 
 
三、RTCP 媒体流
3.1         每发完一批RTP 包的时候,就发一个RTCP 包,告诉接收方我刚才发了多少RTP 包,多少个字节
 










本文转自:
https://wenku.baidu.com/view/854dd3e55ef7ba0d4a733bed.html




 
  • 10
    点赞
  • 52
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值