SIP中第三方呼叫控制（3PCC）建立流程

1.引言

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

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

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

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

2.流程1

说明如下：

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

针对流程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

流程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资源上来解决。