专利名称：一种ip多媒体子系统中的通话态转接系统及其转接方法
技术领域：
本发明涉及基于分组交换的话务台技术，尤其涉及一种IMS( IP Multimedia Core Network Subsystem, IP多媒体子系统)中的通话态转接
系统及其转接方法。
背景技术：
通话态转接是指话务台让被该话务台保持的 一路呼叫的对端和与 该话务台正在通话的一路呼叫的对端通过语音媒体的切换，成为一个呼 叫的两端进行通话。如用户A呼叫话务台B,话务台B保持该;洛A-B 呼叫，然后再呼叫C,与C通话后，再通过一些操作，让A与C直接 通话，这个过程就叫通话态转才妄。
对于不同的设备，IMS系统中话务台的通话态转接的实现方法虽不 尽相同，但均存在以下缺陷不能完全支持现有的标准、协议中规定的 功能，对于新推出的标准、协议的支持也不能有很好的扩展性，或者实 现流程过于复杂，与其他设备的兼容性不好。
目前，普通的IMS话务台转接主要有两种实现方式
一种是直接使用SDP ( Session Description Protocol,会话描述协i义) 消息分别通知对端媒体，这种方法虽然筒单，但由于不能支持资源预留 功能，对于移动用户，在对端申请无线信道失败时会导致々某体无法建立， 最终呼叫不通。
另 一种是通过REPLACE (见RFC3891 )或refer(参见RFC3515)等参数来通知与话务台要转接的两对端中的 一个对端，由该对端发起并实 现真正的转接流程。这种方法对于话务台本身来说，实现起来简单有效，
RFC3515)，而在VOIP网络中，各种型号、各种性能、各种生产日期的 网元都存在，显然，要求所有这些网元都支持REPLACE (见RFC3891 ) 或refer(参见RFC3515)是不现实的，因而此方法难以实现。
发明内容
本发明所要解决的技术问题是提供一种IP多媒体子系统中的通话 态转接方法，能够支持现有的规范和标准，具有良好的兼容性。
为解决上述技术问题，本发明是通过以下技术方案实现的
一种IP多媒体子系统中的通话态转接系统，包括IP多媒体子系 统设备、话务台服务器、话务台客户端；
所述IP多媒体子系统设备，与话务台服务器通过会话发起协议相 连，用于接入各种用户终端，建立用户终端与话务台^^务器的通信通道；
所述话务台客户端，与话务台服务器通过会话发起协议相连，用于 向话务台服务器发起呼叫转接请求；
所述话务台服务器，用于在收到呼叫转接请求时，先通知当前处于 保持状态的主叫用户和处于通话状态的被叫用户分别进行资源预留，预 留成功后再建立所述主叫用户和被叫用户的媒体连接。
一种如上所述的通话态转接系统的转接方法，该方法为话务台服 务器在接收到话务台客户端发送过来的转接请求消息时，采用会话发起 协议消息通过IP多媒体网络子系统设备与各用户终端进行通信，先通知当前处于保持状态的主叫用户和处于通话状态的被叫用户分别进行 资源预留，资源预留成功后再建立所述主叫用户和被叫用户的媒体连 接。
上述方法进一步包括
a、 所述话务台服务器向主叫用户发送重新邀请消息，主叫用户收 到后返回200 OK消息，其中携带本端所支持的全部媒体信息；
b、 所述话务台服务器向被叫用户发送重新邀请消息，其中携带主 叫用户所支持的媒体信息；被叫用户收到后返回183消息，其中携带本 端匹配的媒体信息；
c、 所述主叫用户根据所述183消息中的々某体信息进行资源预留， 预留成功后向话务台服务器发起重新邀请消息；
d、 所述话务台服务器向被叫用户发送更新消息，-陂叫用户收到后 对该消息进行响应，响应消息中携带本端已准备好的媒体信息；
e、 所述话务台服务器将被叫用户端已准备好的媒体信息发送给主 叫用户，之后，主叫用户与被叫用户建立+某体连接。
其中，所述步骤b和c之间还包括所述话务台服务器对所述183 消息的可靠性进行确认。
其中，所述方法还包括转接成功后，所述话务台服务器向话务台 客户端发送转接成功消息。
本发明具有以下有益效果
本发明主要是利用现有的SIP消息来实现通话态转接，且在转接前 进行了资源预留，因而对现有规范和标准有很好的支持，具有很好的扩展性，提高了呼叫接通率；而且，由于流程中使用的都是基本的消息和 参数，对其他系统和设备都有比较好的兼容性，且简单^易于实现。
图1是本发明的通话态转接系统的结构图； 图2是本发明的通话态转接方法流程图。
具体实施例方式
下面将结合附图及具体实施例对本发明作进一步详细的描述 请参阅图l,本发明的通话态转接系统包括以下部分 IMS系统设备，与话务台服务器通过SIP协议相连，用于接入各种
用户终端，建立用户终端与话务台服务器的通信通道；
话务台客户端，与话务台服务器通过SIP协议相连，用于向话务台
服务器发起呼叫转接请求；
话务台服务器，用于对话务台客户端进行集中管理；在收到呼叫转
接请求时，先通知当前处于保持状态的主叫用户和处于通话状态的被叫
用户分别进行资源预留，预留成功后再建立所述主叫用户和^t叫用户的
媒体连接。
请参阅图2，上述系统实现通话态转接的方法为
在转接前，应该有一路呼叫处于保持状态(简称此路呼叫的对端为 A)，此路呼叫在图2中用dialogl表示，并且还有一路呼叫处于与话务 台进行通话的状态(简称此路呼叫的对端为B),此路呼叫在图2中用 dialog2表示。
步骤201 ~ 202: opr client (话务台客户端)通过MESSAGE消息，向SERVER (话务台服务器)请求将当前处于保持状态的呼叫对端A 和当前处于通话状态的呼叫对端B进行转接；SERVER通过200 OK消 息通知opr client已经收到此消息。
步骤203 ~ 204: SERVER通过IMS系统设备给A端发送一个不带 媒体信息的re-invite (重新邀请)消息；按照RPC3261规定，A端直接 回应200 0K消息，且该消息中携带A端所支持的全部々某体。
步骤205: SERVER通过IMS系统设备向B端发送re-invite消息， 并把204中A端返回的媒体信息传递过去，同时增加如下参数 Session: Offer Supported: 100 Rel， precondition a=curr:qos local none 3=curr:qos remote none a=des:qos mandatory local sendrecv
a=des:qos optinal remote sendrecv 步骤206: B端通过IMS系统设备向SERVER发送183消息，将匹 配好的B端的i某体信息发送给SERVER,同时此消息中可以携带资源预 留参数，用于要求SERVER进行资源预留。对端媒体除了此以外，可能 有一个a二conf,但无论有没有这个参数，server都把预留参数修改为如 下
Session: Answer
Require: precondition , 100rel
a=curr:qos local none3=curr:qos remote noti6 a=des:qos mandatory local sendrecv a=des:qos optinal remote sendrecv 步骤207: SERVER向A端发送ACK消息，用于确认步骤204中 的200 OK消息，并将206中所携带的媒体信息传递给A端，媒体中填 写资源预留需要确认消息参数，目的是要求A端发起步骤210中的消息。 步骤208 209: SERVER通过给B端发送PRACK消息，对步骤206 中的183消息进行可靠性确i人；B端通过IMS系统i殳备返回200 OK消 息以确认收到PRACK消息。
步骤210: A端响应207中的资源预留需要确认消息参数，进行资 源预留，之后发起re-invite消息，携带A的本端々某体。SDP参数如下 Session: offer Support: precondition , 1 OOrel a=curr:qos local sendrecv a=curr:qos remote none a=des:qos mandatory local sendrecv a=des:qos optinal remote sendrecv 步骤211 212: SERVER通过给B端发送UPDATA (更新)消息， 对步骤206中的183消息中的资源预留要求进行实现，UPDATA消息中 携带已经准备好的媒体信息；B端通过IMS系统设备向SERVER发送 200 0K消息，对UPDATA进行响应，同时携带准备好的B端的媒体。 步骤213 214: SERVER给A端发送200 OK消息，作为步骤210中re-invite消息的一个响应，并4巴B端返回的4某体信息传递给A端；A 端发送ack消息作为步骤213中200 OK消息的确认。SDP参数如下
Session: offer
Support: precondition , 1 OOrel
a=curr:qos local sendrecv
a=curr:qos remote sendrecv
a=des:qos mandatory local sendrecv
a=des:qos optinal remote sendrecv 步骤215 216: B端通过IMS系统设备给SERVER发送200 OK消 息，作为步骤205中re-invite消息的响应；SERVER返回ACK消息作 为200 OK消息的确认。
步骤2n~2l8: SERVER通过MESSAGE消息，通知opr client转接 操作已经完成；opr client返回200 OK消息对此MESSAGE消息进行响 应。
以上所述仅为本发明的较佳实施例而已，并不用以限制本发明，凡 在本发明的精神和原则之内所作的任何修改、等同替换和改进等，均应 包含在本发明的保护范围之内。
权利要求
1. 一种IP多媒体子系统中的通话态转接系统，其特征在于，包括IP多媒体子系统设备、话务台服务器、话务台客户端；所述IP多媒体子系统设备，与话务台服务器通过会话发起协议相连，用于接入各种用户终端，建立用户终端与话务台服务器的通信通道；所述话务台客户端，与话务台服务器通过会话发起协议相连，用于向话务台服务器发起呼叫转接请求；所述话务台服务器，用于在收到呼叫转接请求时，先通知当前处于保持状态的主叫用户和处于通话状态的被叫用户分别进行资源预留，预留成功后再建立所述主叫用户和被叫用户的媒体连接。
2、 一种应用于权利要求1所述的通话态转接系统的转接方法， 其特征在于，该方法为话务台服务器在接收到话务台客户端发送过 来的转接请求消息时，釆用会话发起协议消息通过IP多媒体网络子 系统设备与各用户终端进行通信，先通知当前处于保持状态的主叫用 户和处于通话状态的被叫用户分别进行资源预留，资源预留成功后再 建立所述主叫用户和被叫用户的媒体连接。
3、 如权利要求2所述的通话态转接系统的转接方法，其特征在 于，所述方法进一步包括a、 所述话务台服务器向主叫用户发送重新邀请消息，主叫用户 收到后返回200 OK消息，其中携带本端所支持的全部媒体信息；b、 所述话务台服务器向被叫用户发送重新邀请消息，其中携带 主叫用户所支持的媒体信息；被叫用户收到后返回183消息，其中携带本端匹配的媒体信息；c、 所述主叫用户根据所述183消息中的媒体信息进行资源预留， 预留成功后向话务台服务器发起重新邀请消息；d、 所述话务台服务器向被叫用户发送更新消息，被叫用户收到 后对该消息进行响应，响应消息中携带本端已准备好的媒体信息；e、 所述话务台服务器将被叫用户端已准备好的媒体信息发送给 主叫用户，之后，主叫用户与被叫用户建立媒体连接。
4、 如权利要求3所述的通话态转接系统的转接方法，其特征在 于，所述步骤b和c之间还包括所述话务台服务器对所述183消息 的可靠性进行确认。
5、 如权利要求2所述的通话态转接系统的转接方法，其特征在 于，所述方法还包括转接成功后，所述话务台服务器向话务台客户 端发送转接成功消息。
全文摘要
本发明公开了一种IP多媒体子系统中的通话态转接系统及其转接方法，转接系统包括IP多媒体子系统设备、话务台服务器、话务台客户端，相应的转接方法为话务台服务器在接收到转接请求消息时，采用SIP消息通过IP多媒体网络子系统设备与各用户终端进行通信，先通知当前处于保持状态的主叫用户和处于通话状态的被叫用户分别进行资源预留，预留成功后再建立主叫用户和被叫用户的媒体连接。本发明利用现有的SIP消息来实现通话态转接，且在转接前进行了资源预留，因而对现有规范和标准有很好的支持，具有很好的扩展性，提高了呼叫接通率；由于使用的都是基本的消息和参数，对其他系统和设备都有比较好的兼容性，且简单易于实现。
文档编号H04L29/06GK101291328SQ200810067530
公开日2008年10月22日 申请日期2008年5月30日 优先权日2008年5月30日
发明者金凤昕 申请人:中兴通讯股份有限公司