zoukankan      html  css  js  c++  java
  • SIP中第三方呼叫控制(3PCC)建立流程

    1.引言

    在传统的电话网环境中,第三方呼叫控制允许一个实体(这里称为控制器- controller) 建立并管理另外的两方或多方之间的通信关系,而其本身并不参与通信。

    第三方呼叫控制经常用于运营商业务 (运营商常常会建立一个呼叫将两个用户连接起来)和会议。

    同样地,许多SIP业务都可能通过3PCC实现。这包括从PSTN继承的传统的业务,也包括新的业务,例如点击拨号(click-to-dial)。点击拨号允许用户在他们想与客服代表通话时点击一个Web页面上的链接,之后web服务器便会创建一个用户与客服代表之间的呼叫。这个呼叫可以是Phone2Phone、PC2Phone、或者PC2PC的。

    仅使用RFC 3261中的机制,便可以实现3PCC。实际上有多种不同的呼叫流程都是可行的,每种都能在遵从SIP的用户代理上正确的工作。当然,每种流程都有其优点和缺陷。

    2.流程1

    clip_image002

    说明如下:

    1. Controller向B发送INVITE,且不携带SDP,B收到INVITE发现其中未含SDP。

    2. B向Controller回200响应,其中含有SDP,作为offer。

    3. Controller向B发送INVITE,其中携带来自B前面所回的200响应中的SDP作为offer。

    4. A分析offer产生answer,并在200响应中返回Controller

    5. Controller将answer放在ACK中发送给B

    6. Controller向A发送ACK。

    这个流程非常简明,Controller 无需处理SDP,可以应用于在任何两端支持的媒体类型。

    但是这个流程可能会存在严重的超时问题:如果A不能立即应答呼叫的话,Controller将不能马上向B发送ACK。这会导致B在一定时间内周期性重发200 OK响应(根据RFC 3261 的规定这个时间的时长为64*T1)。如果这段时间之后,ACK仍未到达B,那么这个呼叫就回被认为失败了。

    这个流程适用于控制者知道A将会立即应答INVITE消息的场景。通常A为媒体服务器上提供的种自动服务。

    3.流程2

    clip_image004

    针对流程1中的超时问题,流程2进行了改进。

    流程2在在流程1的基础上增加消息1~3,用于解决B上的超时问题:C先与A建立了会话(媒体未激活),这保证了之后的(re)INVITE(6)的200(7)响应会立即返回C,使得ACK能够马上发给B,有效避免了超时问题。

    流程2中,Controller需要对SDP进行处理。Answer1由Controller生成,是一个所谓黑洞(black hole)SDP,其连接地址为0.0.0.0。Offer2是由Controller基于offer2得来的,可能需要对其中的媒体行进行重组或裁剪。例如,如果offer1含有一个audio和一个video行,但是offer2只含有一个audio行,Controller需要在offer2中加一个video行(将其端口设为0),生成offer2‘。类似地,Controller会基于answer2‘生成answer2,发给B。

    4.流程3

    clip_image006

    流程3是在流程2上变化而来,并降低了复杂性。实际的SIP消息流程完全一样,只是在SDP放置和处理上有所不同。

    在消息1~3中,与流程2的不同在于:这里,Offer1中根本没有媒体,也就是说没有 m 行。这是合法的,这暗示了会话的媒体将会在之后通过re-INVITE建立。同样地,Answer1也没有媒体。

    之后的流程与流程III的完全一样,但需要进行的处理,即offer2到offer2‘的转换,answer2’到answer2的转换,会简单得多。实际上,这里根本不需要媒体处理,要改变的仅仅是修改origin行,以便offer2‘ 中的origin行之与offer1中的值是合法的 (合法性要求version值增加1,其他参数保持不变)。

    关于这个流程也有一些限制。首先,用户A在任何媒体都不建立的情况下被振铃,这意味着用户A将不能根据其媒体构成来接受或拒绝呼叫;其次,A和B都会最终在不知道是否有兼容的媒体之前就应答了呼叫 (例如产生200响应)。这样,如果实际上没有共同的媒体能力,呼叫将会在之后通过一个BYE结束。然而,用户已经被振铃了,造成骚扰,并且还可能产生计费事件。

    5.总结

    流程1是最简单有效的流程。如果controller确定通信双方中的一方实际上是一个将会立即应答呼叫的自动设备,比如,媒体服务器、会议服务器、消息服务器,等等,那么就应该使用这个流程。可以想象,大多数情况下,3PCC建立的通信中会有一方是自动设备,因此这个流程会很常用。

    如果通信的双方都是真实的人,或者是未知类型的实体,推荐使用流程3;流程2也可以使用,但是不会提供更多的好处。

    在大多数情况下,包括在推荐的流程中,在完成到B呼叫的呼叫的时候,A会听到一段时间的静默。这会显的不太理想。对于这个问题,可以考虑在完成到B的呼叫的时候,将A连接到一个music-on-hold资源上来解决。

  • 相关阅读:
    【转】FIddler+Proxifer工具对windows PC客户端进行抓包
    Json提取器(Json Extractor)
    Json断言
    015-Zabbix自动发现和自动注册
    014-Zabbix的自动发现
    013-zabbix trapper方式监控
    012-zabbix主动模式
    011-通过安装percona插件监控MySQL
    010-监控windows主机
    009-通过jmx监控tomcat
  • 原文地址:https://www.cnblogs.com/luoyinjie/p/7219383.html
Copyright © 2011-2022 走看看