icecity0079 / 通信知识 / 3PCC浅析

分享

   

3PCC浅析

2018-08-14  icecity00...

     3PCC全称Third Party Call Control,中文即第三方电话呼叫控制,指的是由第三方控制者在另外两者之间建立一个会话,由控制者负责会话双方的媒体协商。3PCC是一种非常灵活的会话控制方式。在PSTN网中,第三方呼叫控制通常用于会议、接线业务(接线员创建一个连接另外双方的呼叫)。同样,使用SIP协议也可以借助3PCC来完成PSTN网中的一些相关业务,例如点击拨号、通话过程中放音等等,而且实现起来非常方便。RFC3264中定义了一种提供/应答模式,使两个实体之间可以使用SDP的提供/应答(offer/answer)模式进行会话协商。

      SIP消息可以携带SDP消息体。SDP(会话描述协议)是用来描述与媒体流相关的参数以及与会话相关的信息,其中包括对会话的描述以及媒体类型、数据发送到的端口、传输协议(例如RTP)以及媒体格式(例如RTP载荷格式)的描述。3PCC的实现关键就在于控制者如何在会话双方之间使用SDP消息协商即将建立的会话。

      需要说明的是,下面的所有flow讲解都省略了中间的部分服务器应答,如Trying、Ringing等应答,因为这些应答不是3PCC流程所控制的关键点。且下面的说明都是依据带有标号顺序的SIP消息为核心。

 

      根据SIP协议的整个协商处理机制,可以有下面四种方法实现3PCC(RFC 3725):
Flow 1:

    

     (1)是Controller向A发送一个不带SDP的INVITE请求,不带SDP即前面所说的,没有Message Body部分;

     (2)是A给Controller的200 OK应答,其中的offer指的是SDP消息,这其中描述与A有关媒体处理能力的相关数据,详见SDP协议;

     (3)是Controller向B发送INVITE请求,这其中带有A的SDP相关描述;

     (4)是B给Controller的200 OK应答,其中的answer指的是SDP消息,这其中描述与B有关的媒体处理能力的相关数据;

     (5)是Controller对B的ACK应答,不含任何SDP信息,因为在前面的INVITE中已经有了

     (6)是Controller对A的ACK应答,其中带有B的SDP相关信息,这其实就让媒体流在A和B之间传输了,而不用Controller去转发媒体流。

      Flow1是最简单的一种3PCC控制方式,不需要Controller对SDP做控制,但是有个典型的缺点就是,当B不及时对Controller的INVITE请求做200 OK的应答,会导致A周期性的向Controller发送200 OK的消息,最终可能会导致A认为呼叫失败,而主动去挂断电话。

 

Flow 2:

    

    (1)是Controller向A发送INVITE请求,该请求带一个bh SDP1。所谓的bh SDP1只是一个伪SDP描述,里面只有简单media、codec和connection信息,connection信息中的地址必须是0.0.0.0,port可以为不为0的任意数字,关于SDP的详细东西可以看RFC 4566;

    (2)是A给Controller的200 OK应答,里面带有的SDP2是一个完整的SDP描述;

    (3)是Controller向B发送的INVITE请求,和Flow 1中的(3)是完全一样的;

    (4)是Controller对(2)的简单应答;

    (5)是B给Controller的200 OK应答,里面带有与B相关的SDP描述;

    (6)是Controller对(5)的简单应答;

    (7)是Controller向A发起的re-invite请求,其中带有与B有关的SDP描述;

    (8)是B针对(7)做的200 OK应答;

    (9)是针对(8)做的简单应答。最终在A和B之间建立媒体流(当然这是理想状态,呵呵)

    Flow 2的优点是所有的最终响应都可以被立即确认,不会因超时而导致呼叫失败。缺点也是显而易见的,Controller必须预先知道本次呼叫所要使用的媒体类型来创建初始的“黑洞”SDP描述,同时“黑洞”是一种扩展机制,不是所有的UA都支持,最后就是要假设(8)中带有的SDP2和(2)中的完全一致,才不至于产生无限循环的re-invite请求。因此,Flow 2只是在理论上可行,实际操作过程中强烈建议不要使用。

 

    Flow 3:

   

   (1)和(2)的说明可以参见Flow 1(1)和(2)中的说明;

   (3)是Controller针对(2)的简单应答,这其中的SDP描述中关于connection部分全部被改为0.0.0.0,即所谓的“黑洞”SDP;

   (4)和(5)的说明可以参见Flow 1中的(3)和(4)说明;

   (6)是Controller向A发起的re-invite请求,其中的offer2是根据offer1和offer2之间所存在的共同的媒体处理能力由Controller生成的,但是其中connection与offer2中的一致,这样才能保证流媒体在A和B之间传输;

   (7)是A对re-invite的200 OK应答,其中的answer2是根据offer2做的重新调整,他与offer1已然不同;

   (8)是Controller针对(5)做的ACK应答,其中带有answer2所描述的SDP信息,这里只是为了区分A和B而写成answer2了;

   (9)是Controller针对(8)做的简单ACK应答;

   Flow 3的优点当然是,首先是所有的最终响应都能够被及时处理,不会产生超时和重传的问题;其次是Controller不需要预知本次会话的SDP媒体描述信息。

   Flow 3相对来说要复杂一点,他需要Controller去处理两者的SDP描述信息,为他们找到交集,当然他们也有可能不存在交集而导致最终的呼叫失败。

 

   Flow 4:

  

  Flow 4是针对Flow 3做的一个变通,降低了复杂度,其实际的SIP消息处理过程与Flow 3完全一致。这里我只对几个关键点做一下说明。

  在(1)中offer1 no media指的是SDP描述中不带m行,具体的含义参见SDP规范吧,:)

  其余的过程与Flow 3中完全一致。

 

  Flow 4相对于Flow 3的缺点是显而易见的,A中没有任何媒体描述,但是呼叫已经正常建立了。当从B得到的SDP描述时,发现A和B没有共同的媒体描述时,必须中断Controller与A和B之间的会话,但是这是A和B同Controller之间的会话已经正常建立了,A和B会因为听不到任何媒体流而感到奇怪。

 

  综上所述,Flow 3是最为合适的控制流程。

 

  注:理论往往会和现实有差距的,具体见我后面有关SIP Servlet中,我在实际的实现操作过程中遇到的问题吧,呵呵:)

    本站是提供个人知识管理的网络存储空间,所有内容均由用户发布,不代表本站观点。请注意甄别内容中的联系方式、诱导购买等信息,谨防诈骗。如发现有害或侵权内容,请点击一键举报。

    0条评论

    发表

    请遵守用户 评论公约

    类似文章 更多
    喜欢该文的人也喜欢 更多

    ×
    ×

    ¥.00

    微信或支付宝扫码支付:

    开通即同意《个图VIP服务协议》

    全部>>