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

3PCC呼叫建立的错误处理与后继处理

1.引言

在前一篇文章“SIP中第三方呼叫控制（3PCC）建立流程”中，给出了SIP 3PCC的呼叫建立的四个常用流程，但是只给出了建立成功的情况，并且到呼叫建立完成为止。

实际上，3PCC呼叫建立经常会有失败的情况，并且呼叫建立后的后继处理也很重要，本文就这两个方面进行讨论。

2.3PCC呼叫建立的失败处理

3PCC呼叫建立失败的情况有很多种，这里讨论比较重要的两种。

试呼第2方失败

在3PCC呼叫建立流程中，都是先呼叫一方，成功后再试呼另一方。但是，在试呼另一方时会因为很多中原因失败，比如对方可能正忙、找不到公共的媒体能力、或者请求超时，等等。

当试呼另一方失败后，Controller应该先向之前已建立呼叫的一方发送BYE，其中的Reason头域携带错误响应的状态码，这将会告诉A准确的失败原因。这些信息从用户界面的角度看是非常重要的。

下面是一个这种类型的3PCC呼叫建立失败的流程举例。

这个流程是基于3pcc呼叫建立流程iv，说明如下

ü Controller首先呼叫A，并完成了呼叫建立（1～3）。其中Offer1中没有媒体，也就是说没有 m 行，这是合法的，这暗示了会话的媒体将会在之后通过re-INVITE建立。同样地，Answer1也没有媒体。

ü Controller接着向B发送INVITE，尝试建立到B的呼叫，但是由于B正忙，返回486响应，试呼失败（4～5）。

ü 由于试呼B失败，Controller向A发送BYE，其中中的Reason代码486会用于指示产生本地忙音信号，这样用户A便知道呼叫失败是由于用户B正忙了。

同抢

另外一种值得讨论的3PCC呼叫建立失败的情况是：在Controller呼叫一方成功，之后在试呼另一方的过程中，会话协商正在进行，尚未完成。此时，Controller却收到了之前已建立会话的一方发送的新的offer要求更新会话。这样就会形成所谓同抢。

下面是的流程举例。

流程说明如下：

ü Controller先建立了到A的对话（1～3）

ü 然后，Controller发送一个不带SDP的INVITE向B发起试呼，按着SIP中offer/answer的用法，之后需要等待B返回一个offer。（4～5）

ü 完成到B的呼叫需要一些时间，在这期间，A发送了一个re-INVITE，并提供一个新的offer，请求会话更新。然而，此时controller无法将此offer传递给B，因为之前与B的INVITE事务正在悬置。（6）

ü Controller只能拒绝这个请求，这里使用了491“Request Pending”响应来完成拒绝（7）。之后，在到B的呼叫未完成之间，A可能再次发送re-INVITE ，这时，controller应该回另一个491。

3.3PCC呼叫建立后的后继处理

呼叫建立过程是3PCC中最主要也是相对复杂的部分。但这并不不意味着呼叫建立完成后，3PCC过程就结束了。在呼叫建立之后，还有后继处理过程。后继处理可能是简单的拆线，也可能有其他复杂的操作。

一旦呼叫建立，两个通信方都认为它们处在一个点到点的呼叫中。但实际上，虽然是它们二者之间在直接交换媒体，从信令上却是间接的、通过controller的。这里Controller分别处在两个SIP对话中，作为controller是信令的中心点，因此它可以完全控制呼叫。

拆线

拆线通常是用户发起的，处理过程也比较简单：如果从一方收到拆线请求，Controller向另一方发送一个拆线请求，并发给另一方，结束呼叫。

下图是一个拆线的一个例子流程。

流程说明：

ü 用户A挂机，Controller收到收到一个BYE请求，Controller返回一个200 OK 响应（1～2）

ü Controller产生一个新的BYE请求，发给B。B返回一个200 OK 响应（3～4）。呼叫结束。

会话更新

会话更新通常也是由用户发起的，处理过程也同样比较简单：如果从一方收到re-INVITE请求，Controller可以将其转发给另一方。只是根据根据所使用的流程的具体情况，可能需要在转发之前对SDP进行一些处理。

下图给出一个更新会话的例子流程。

连接另一个用户

在前面的“拆线”和“会话更新”的处理过程中，controller 的角色非常简单，从信令上看，基本上是SIP消息的转发，这种行为类似于一个“proxy”。然而，controller并不是个“proxy”，它是个B2BUA，它可以根据自身需要，在每个对话上发起任何合法模式的信令交互。

例如，如果controller从A收到BYE请求，它可能会向新的一方C产生一个新的INVITE请求，并且将B与C连接起来

流程如下图，这里假设C代表一个用户而非自动设备。

注意，这实际上就是呼叫建立过程的流程IV。这里不再说明。

实际上，在3PCC呼叫建立后，不仅是上面所述的两种后继操作，在controller的控制下，新的一方可以被加入、移除、转接等等。

很多情况下，为了影响这些变化controller需要修改在各呼叫方之间交换的SDP。特别地，SDP中的version号在特定的情况下需要被controller修改。

还需要着重指出的是：在后继处理中给出的处理流程并不是限制应用于3pcc建立的呼叫，正常建立的呼叫中也可以应用这些流程（controller 作为B2BUA）。

4.结语

3PCC呼叫建立发起的流程是很关键的，它与普通（1PCC）的呼叫建立过程有很大的不同，也相对比较复杂。但是其错误处理和后继处理本质上讲与普通呼叫建立过程中的没有太大区别。

http://blog.sina.com.cn/s/blog_6b1025530101agt5.html

http://blog.sina.com.cn/s/blog_6b1025530101agt9.html