WO2011017957A1 - 应用服务器呼叫控制中呼叫继续的方法和装置 - Google Patents

应用服务器呼叫控制中呼叫继续的方法和装置 Download PDF

Info

Publication number
WO2011017957A1
WO2011017957A1 PCT/CN2010/072974 CN2010072974W WO2011017957A1 WO 2011017957 A1 WO2011017957 A1 WO 2011017957A1 CN 2010072974 W CN2010072974 W CN 2010072974W WO 2011017957 A1 WO2011017957 A1 WO 2011017957A1
Authority
WO
WIPO (PCT)
Prior art keywords
party
answer message
message
answer
application server
Prior art date
Application number
PCT/CN2010/072974
Other languages
English (en)
French (fr)
Inventor
高扬
Original Assignee
中兴通讯股份有限公司
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 中兴通讯股份有限公司 filed Critical 中兴通讯股份有限公司
Priority to EP10807902.1A priority Critical patent/EP2453629B1/en
Priority to US13/388,338 priority patent/US8965973B2/en
Priority to CA2771047A priority patent/CA2771047C/en
Publication of WO2011017957A1 publication Critical patent/WO2011017957A1/zh

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/10—Architectures or entities
    • H04L65/1063—Application servers providing network services
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/1066—Session management
    • H04L65/1083—In-session procedures
    • H04L65/1093—In-session procedures by adding participants; by removing participants

Definitions

  • the present invention relates to the field of communications, and in particular, to a method and apparatus for call continuation in application server call control. Background technique
  • the Third Party of Conversation Control refers to a third party controller establishing a session between the other two, and the controller is responsible for media negotiation between the two parties.
  • 3PCC is a very flexible control method, which can be divided into a 3PCC setup request message carrying a Session Description Protocol (SDP) message flow and a 3PCC setup request message not carrying an SDP message, where the SDP message includes the offer ( Offer ) Message and Answer ( Answer ) message.
  • SDP Session Description Protocol
  • the process of carrying the SPC message in the 3PCC setup request message exists in various services such as call forwarding, automatic station, and call forwarding.
  • the method includes:
  • Step 101 The first party has negotiated media with the application server (AS, Application Server).
  • AS Application Server
  • Step 102 The AS sends an offer message to the second party.
  • the Offer message may be carried in a call setup request message, which may be, but not limited to, an invite (INVITE) message.
  • a call setup request message which may be, but not limited to, an invite (INVITE) message.
  • Step 103 The second party receives the offer message and sends an Answer message to the AS.
  • the Answer message may be carried in a reliable transmission temporary response message, including but not limited to the 180 response message, the 181 response message, or the 183 response message.
  • the Answer message includes: a media type, a confirmation request for a first-party precondition, a transport protocol, and a media format.
  • the Precondition state It may be, but is not limited to, a QoS (Quality of Service) state, and a Precondition state requirement level is mandatory.
  • Step 104 The AS receives the Answer message and sends an Offer message to the first party.
  • the AS after receiving the reliable transmission temporary response message carrying the Answer message, the AS extracts the Answer message, and converts the extracted Answer message into an Offer message, and then sends the message to the first party in the update request message.
  • Step 105 The first party receives the Offer message and sends an Answer message to the AS.
  • the Answer message may be included in an update request response message, where the update request response message includes but is not limited to a 200 OK response message or a 183 response message.
  • the answer message includes: a media type, a first party acknowledgment response to the Precondition state, a transport protocol, and a media format, where the precondition state is mandatory.
  • the inventors have found that at least the following problems exist in the prior art: Since the second party needs the first party to confirm the Precondition status, the first party is in the step
  • the acknowledgment response of the Precondition state is sent to the AS in the Answer message, but the AS intercepts the Answer message, and the call cannot continue.
  • the problem to be solved by the present invention is to provide a method and apparatus for continuation of a call in an application server call control, which can solve the problem that the call cannot be continued in the prior art because the second party cannot obtain the acknowledgment response of the first party's Precondition status.
  • the problem is to provide a method and apparatus for continuation of a call in an application server call control, which can solve the problem that the call cannot be continued in the prior art because the second party cannot obtain the acknowledgment response of the first party's Precondition status.
  • the present invention provides a method and apparatus for call continuity in application server call control.
  • the technical solution is as follows:
  • a method for call continuation in application server call control including:
  • the application server sends an offer to the second party.
  • the application server determines whether the Answer message satisfies a conversion condition of the Answer message
  • the application server converts the Answer message into the Offer message and sends it to the second party.
  • the application server performs media negotiation with the first party, and the application server directly performs media negotiation with the first party;
  • a device for continuing call in an application server call control comprising:
  • a first sending module configured to send an offer message to the second party after the first party performs media negotiation
  • a first receiving module configured to receive a Answer message sent by the second party, where the Answer message carries a confirmation request for a first party Precondition status
  • a conversion module configured to convert the Answer message into the Offer message
  • a second sending module configured to send the Offer message converted by the converting module to the first party
  • a second receiving module configured to receive an Answer message sent by the first party, where the Answer The message carries an acknowledgement response of the first party to the Precondition state;
  • a determining module configured to determine whether the Answer message received by the second receiving module satisfies a conversion condition of the Answer message
  • the conversion module is further configured to: when the determination result of the determining module is satisfied, convert the Answer message into the Offer message;
  • the second sending module is further configured to send the Offer message converted by the converting module to the second party.
  • the technical solution provided by the present invention determines whether the Answer message carrying the Precondition state needs to be converted into an Offer message according to the transition condition of the Answer message, and if necessary, the converted Offer message is sent, so that the call can be continued, which is beneficial to the third party call control service.
  • the development of the Answer message if not required, can reduce unnecessary signaling, avoid media negotiation fluctuations, and improve service quality.
  • FIG. 1 is a flowchart of a 3PCC setup request message with an SDP message provided in the prior art
  • FIG. 2 is a flowchart of a method for continuation of a call in a 3PCC according to an embodiment of the present invention
  • FIG. 3 is a first party and an application server. Flow chart for direct negotiation
  • FIG. 4 is a flowchart of a first party negotiating with an application server as a proxy
  • Figure 5 is a flow diagram of a first party negotiating with an application server as a back-to-back user agent;
  • Figure 6 is a block diagram of an apparatus for call continuation in a 3PCC according to an embodiment of the present invention. detailed description
  • An embodiment of the present invention provides a method for continuation of a call in a 3PCC, as shown in FIG. 2, including:
  • Step 201 - Step 205 is similar to the content of step 101 - step 105.
  • the first party in step 201 has already negotiated media with the application server (AS, Application Server), specifically in the following manner:
  • FIG. 4 is a flowchart of a first party negotiating with an application server as a proxy.
  • the application server acts as a proxy (Proxy) of the other party (a remote other entity such as a user or a device, etc.), and the first party Media negotiation is performed, and after media negotiation, a corresponding media data stream is transmitted between the first party and the other party, and the media data stream does not pass through the application server.
  • FIG. 5 is a flowchart of a first party negotiating with an application server as a back-to-back user agent.
  • the application server serves as a back-to-back user agent of another party (a remote other entity such as a user or a device, etc.) (B2BUA, Back to Back User Agent ), media negotiation is performed with the first party, and after the media negotiation, the corresponding media data stream is transmitted between the first party and the other party, and the media data stream does not pass through the application server.
  • B2BUA Back to Back User Agent
  • Step 206 The AS receives the Answer message, determines whether the Answer message satisfies the transition condition of the Answer message, and if yes, performs step 207; if not, intercepts the Answer message.
  • the Precondition state takes the QoS state as an example, and the second party carries an acknowledgment request for the first party Precondition state in the SDP message in 203, and the acknowledgment request corresponds to the conf line of the SDP.
  • the Precondition state in the Answer message to be transparently transmitted that is, the QoS state needs to satisfy the state of the conf line of the SDP
  • the state may be a receiving state, a sending state, or a sending and receiving state.
  • the second conversion condition includes:
  • the Answer message In the Answer message to be transparently transmitted, the request for confirmation of the Precondition status is required, and the current Precondition status of the other party does not satisfy the Precondition status in the confirmation request. In this case, the Answer message needs to be converted into an Offer message.
  • the Answer message sent by the second party to the AS carries the Precondition state of the second party.
  • the Answer message sent by the AS in the first direction further includes a confirmation request for the second party Precondition status.
  • the AS judges that the Precondition state of the second party in 203 does not satisfy the Precondition state of the confirmation request in step 205.
  • the AS converts the Answer message into an Offer message.
  • Step 207 Convert the Answer message into an Offer message and send it to the second party.
  • the Offer message may be carried in an update request message, which may be, but is not limited to, an Update message or a RE-INVITE message.
  • the Offer message includes: The first party confirms the response to the Precondition status.
  • the second party can know the acknowledgment response of the first party to the Precondition state. At this time, the second party rings and the call continues. It can be seen from step 201 to step 207 that, according to the transition condition of the Answer message, it is determined whether the Answer message needs to be converted into an Offer message, and if necessary, the Answer message is converted into an Offer message and sent, so that the second party can learn the first party. The acknowledgment response of the Precondition state, whereby the second party rings and the call can continue. If not required, the Answer message is intercepted, which can reduce unnecessary signaling.
  • Step 208 The second party receives the Offer message and sends an Answer message to the AS.
  • the Answer message may be included in an update request response message, which may be, but is not limited to, a 200 OK response message or a 183 response message.
  • the Offer message includes: a media type, a second party's confirmation request for the Precondition status, a transport protocol, and a media format.
  • Step 209 The AS receives the Answer message, determines whether the Answer message satisfies the transition condition of the Answer message, and if yes, performs step 210; if not, intercepts the Answer message.
  • Step 210 After converting the Answer message into an Offer message, send the message to the first party.
  • the Offer message may be carried in an update request message, where the update request message includes, but is not limited to, an Update message and a RE-INVITE message.
  • the Offer message includes a description of the media type, the second party's confirmation response to the Precondition status, the transport protocol, and the media format.
  • step 206-step 207 and/or step 208-step 210 may find that, according to the transition condition of the Answer message, it is determined whether the Answer message needs to be converted into an Offer message, and if necessary, the Answer message is converted into an Offer message and sent, The party is informed of the acknowledgment response of the other party's Precondition state, whereby the call can be continued; if not, the Answer message is intercepted, which can reduce unnecessary signaling and avoid media negotiation oscillation, thereby improving service quality.
  • another embodiment of the present invention provides a device for continuing a call in a 3PCC, as shown in FIG. 3, including:
  • a first sending module configured to send an offer message to the second party after performing media negotiation with the first party
  • the first receiving module is configured to receive a response Answer message sent by the second party, where the Answer message carries a confirmation request for the first party Precondition status;
  • a conversion module configured to convert the Answer message into an Offer message
  • a second sending module configured to send an Offer message converted by the converting module to the first party, where the second receiving module is configured to receive an Answer message sent by the first party, where the Answer message carries a confirmation response of the first party to the Precondition state.
  • a determining module configured to determine whether the Answer message received by the second receiving module satisfies a conversion condition of the Answer message
  • the conversion module is further configured to convert the Answer message into an Offer message when the judgment result of the determining module is satisfied;
  • the second sending module is further configured to send the Offer message converted by the conversion module to the second party.
  • the device further includes:
  • the intercepting module is configured to intercept an Answer message sent by the first party when the judgment result of the determining module is not satisfied. Further, the second receiving module is further configured to receive an Answer message sent by the second party; the determining module is further configured to determine whether the Answer message sent by the second party satisfies a transition condition of the Answer message;
  • the conversion module is further configured to convert the Answer message sent by the second party into an Offer message
  • the second sending module is further configured to send the converted Offer message to the first party.
  • the intercepting module is further configured to intercept the Answer message sent by the second party when the judgment result of the determining module is not satisfied.
  • the conversion condition of the Answer message includes a first conversion condition and/or a second conversion condition.
  • the first conversion condition includes:
  • the first party and the second party negotiate a requirement level for the Precondition state as mandatory;
  • the second conversion condition includes:
  • the answer message to be converted has a confirmation request from the other party to the Precondition status, and the current Precondition status of the other party does not satisfy the previous message of the Answer message to be converted.
  • the Answer message in the Precondition state is converted into an Offer message. If necessary, the converted Offer message is sent, which can make the call continue, which is beneficial to the development of the third party call control service; if not, the Answer message can be intercepted, which can reduce Necessary signaling to avoid media negotiation and improve service quality.

Description

应用服务器呼叫控制中呼叫继续的方法和装置 技术领域
本发明涉及通信领域， 特别涉及一种应用服务器呼叫控制中呼叫继续 的方法和装置。 背景技术
第三方呼叫控制 （3PCC, the Third Party of Conversation Control )指的 是由第三方控制者在另外两者之间建立一个会话， 由控制者负责会话双方 的媒体协商。 3PCC是一种非常灵活的控制方式， 可以分为 3PCC建立请求 消息携带会话描述协议（ SDP , Session Description Protocol ) 消息的流程和 3PCC 建立请求消息不携带 SDP 消息的流程， 其中， SDP 消息包括提供 ( Offer ) 消息和应答 ( Answer ) 消息。
3PCC建立请求消息携带 SDP消息的流程在呼叫前转、 自动台和呼叫 转接等多种业务中都存在， 具体如图 1所示， 包括：
步骤 101 , 第一方已经与应用服务器（ AS , Application Server )进行了 媒体协商。
步骤 102 , AS向第二方发送 Offer消息。
其中， 该 Offer消息可以承载于呼叫建立请求消息中， 该呼叫建立请求 消息可以是但不限于邀请 ( INVITE ) 消息。
步骤 103 , 第二方接收到 offer消息， 并向 AS发送 Answer消息。
其中， 该 Answer消息可以承载于可靠传输临时响应消息中， 该可靠传 输临时响应消息包括但不限于 180响应消息、 181响应消息或 183响应消息。
其中， Answer消息包括： 媒体类型、对第一方前提条件（ Precondition ) 状态的确认请求、 传输协议和媒体格式等的描述。 其中， Precondition状态 可以是但不限于服务质量（QoS, Quality of Service )状态， Precondition状 态要求等级为强制 （ mandatory )。
步骤 104 , AS接收 Answer消息， 并向第一方发送 Offer消息。
其中， 该 Offer消息可以承载于更新请求消息中， 该更新请求消息包括 但不限于是更新 ( Update ) 消息和重新邀请 ( RE-INVITE ) 消息。
具体地， AS接收到携带有 Answer消息的可靠传输临时响应消息后， 提取出 Answer消息，并将提取的 Answer消息转换成 Offer消息后 载于更 新请求消息中发送给第一方。
步骤 105 , 第一方接收到 Offer消息， 并向 AS发送 Answer消息。
其中， 该 Answer消息可以 载于更新请求响应消息， 其中， 该更新请 求响应消息包括但不限于 200OK响应消息或 183响应消息。 其中， Answer 消息包括： 媒体类型、 第一方对 Precondition状态的确认响应、 传输协议和 媒体格式等的描述， 其中， Precondition状态的要求等级为 mandatory。
发明人在实现本发明的过程中， 发现现有技术至少存在如下问题： 由于第二方需要第一方对 Precondition状态确认响应， 第一方在步骤
105中会将 Precondition状态的确认响应承载于 Answer消息中发送给 AS, 但 AS会将该 Answer消息拦截， 从而导致呼叫无法继续。 发明内容
本发明要解决的问题是提供一种应用服务器呼叫控制中呼叫继续的方 法和装置， 可以解决现有技术中由于第二方由于不能获得第一方的 Precondition状态的确认响应而导致的呼叫无法持续的问题。
为了解决上述问题， 本发明提供了一种应用服务器呼叫控制中呼叫继 续的方法和装置， 所述技术方案如下：
一种应用服务器呼叫控制中呼叫继续的方法， 包括：
所述应用服务器在与第一方进行媒体协商后， 向第二方发送提供 Offer 消息；
所述应用服务器接收所述第二方发送的应答 Answer 消息， 将所述 Answer消息转换成所述 Offer消息后向所述第一方发送，所述 Offer消息携 带对第一方前提条件 Precondition状态的确认请求；
所述应用服务器接收所述第一方发送的 Answer消息， 所述 Answer消 息携带所述第一方对 Precondition状态的确认响应；
所述应用服务器判断所述 Answer消息是否满足 Answer消息的转换条 件；
如果满足， 所述应用服务器将所述 Answer消息转换成所述 Offer消息 后向所述第二方发送。
其中， 所述将 Answer消息转换成 Offer消息为： 将 Answer消息中的 Precondition状态相关信息承载于 Offer消息中。
所述应用服务器与第一方进行媒体协商为， 所述应用服务器直接与所 述第一方进行媒体协商；
或者，所述应用服务器作为代理 Proxy或背靠背用户代理 B2BUA与所 述第一方进行媒体协商。
一种应用服务器呼叫控制中呼叫继续的装置， 包括：
第一发送模块， 用于在于第一方进行媒体协商后， 向第二方发送 Offer 消息；
第一接收模块，用于接收所述第二方发送的 Answer消息，所述 Answer 消息携带对第一方 Precondition状态的确认请求；
转换模块， 用于将所述 Answer消息转换成所述 Offer消息；
第二发送模块，用于将所述转换模块转换的 Offer消息向所述第一方发 送；
第二接收模块，用于接收所述第一方发送的 Answer消息，所述 Answer 消息携带所述第一方对 Precondition状态的确认响应；
判断模块， 用于判断所述第二接收模块接收的 Answer 消息是否满足 Answer消息的转换条件；
所述转换模块， 还用于当所述判断模块的判断结果为满足时， 将所述 Answer消息转换成所述 Offer消息；
所述第二发送模块，还用于将所述转换模块转换的 Offer消息向所述第 二方发送。
本发明提供的技术方案根据 Answer消息的转换条件判断是否需要将携 带 Precondition状态的 Answer消息转换成 Offer消息，如果需要，则将转换 的 Offer消息发送， 可以使呼叫继续， 有利于第三方呼叫控制业务的发展； 如果不需要， 则将该 Answer消息拦截， 可以减少不必要的信令， 避免媒体 协商震荡， 提高业务质量。 附图说明
图 1是现有技术中提供的 3PCC建立请求消息带 SDP消息的流程图； 图 2是本发明的一个实施例提供的 3PCC中呼叫继续的方法的流程图； 图 3是第一方与应用服务器直接协商的流程图；
图 4是第一方与作为代理的应用服务器协商的流程图；
图 5是第一方与作为背靠背用户代理的应用服务器协商的流程图； 图 6是本发明的一个实施例提供的 3PCC中呼叫继续的装置的结构图。 具体实施方式
本发明的核心思想在于： 根据 Answer消息的转换条件判断是否需要将 携带 Precondition状态的 Answer消息转换成 Offer消息，如果需要，则将转 换的 Offer消息发送，可以使呼叫继续，有利于第三方呼叫控制业务的发展； 如果不需要， 则将该 Answer消息拦截， 可以减少不必要的信令， 避免媒体 协商震荡， 提高业务质量。
下面结合附图及优选实施方式对本发明技术方案进行详细说明。
本发明的一个实施例提供了一种 3PCC中呼叫继续的方法，如图 2所示， 包括：
步骤 201-步骤 205与步骤 101-步骤 105的内容类似， 其中， 步骤 201 中的第一方已经与应用服务器 （AS, Application Server )进行了媒体协商， 具体为下述方式的协商：
图 3是第一方与应用服务器直接协商的流程图， 如图 3所示， 第一方 与应用服务器之间直接进行媒体协商， 在媒体协商之后， 在第一方与应用 服务器之间传输相应的媒体数据流。
图 4是第一方与作为代理的应用服务器协商的流程图， 如图 4所示， 应用服务器作为另一方 （远端其他实体如用户或设备等） 的代理（Proxy ), 与第一方之间进行媒体协商， 在媒体协商之后， 在第一方与另一方之间传 输相应的媒体数据流， 媒体数据流不经过应用服务器。
图 5是第一方与作为背靠背用户代理的应用服务器协商的流程图， 如 图 5所示， 应用服务器作为另一方 （远端其他实体如用户或设备等） 的背 靠背用户代理（ B2BUA, Back to Back User Agent ) , 与第一方之间进行媒 体协商， 在媒体协商之后， 在第一方与另一方之间传输相应的媒体数据流， 媒体数据流不经过应用服务器。
步骤 206 , AS接收 Answer消息，判断该 Answer消息是否满足 Answer 消息的转换条件，如果满足，则执行步骤 207;如果不满足，则拦截该 Answer 消息。
其中， Answer消息的转换条件包括第一转换条件和 /或第二转换条件； 其中， 该第一转换条件包括：
( 1 )第一方和第二方协商对 Precondition状态的要求等级为强制； ( 2 )待透传 Answer消息的另一方在其上一条 Answer消息中，存在需 要对方对 Precondition 态的确认请求。
例如， Precondition状态以 QoS状态为例， 第二方在 203中的 SDP消 息中携带对第一方 Precondition状态的确认请求， 该确认请求对应 SDP的 conf行。
( 3 )待透传 Answer消息中 Precondition状态的确认响应需要满足确认 请求中的状态。
例如， 待透传 Answer消息中 Precondition状态， 即 QoS状态需要满足 SDP的 conf行的状态， 该状态可以是接收状态、 发送状态或是收发状态。
该第二转换条件包括：
( 4 )待透传的 Answer消息中存在需要对方对 Precondition状态的确认 请求， 且对方当前的 Precondition状态不满足确认请求中的 Precondition状 态， 此时， 需要将 Answer消息转换成 Offer消息。
例如， 在步骤 203中， 第二方发送给 AS的 Answer消息中携带第二方 的 Precondition状态， 在步骤 205中， 第一方向 AS发送的 Answer消息中 还包括对第二方 Precondition状态的确认请求， AS经过判断得知， 203中的 第二方的 Precondition状态并不满足步骤 205中确认请求的 Precondition状 态， 此时， AS将 Answer消息转换成 Offer消息。
步骤 207 , 将 Answer消息转换成 Offer消息后向第二方发送。
其中， 该 Offer消息可以承载于更新请求消息中， 该更新请求消息可以 但不限于是 Update消息或 RE-INVITE消息。 该 Offer消息包括： 第一方对 Precondition状态的确认响应。
由于 AS将第一方对 Precondition状态的确认响应发送给第二方，因此， 第二方可以得知第一方对 Precondition状态的确认响应，此时，第二方振铃， 呼叫继续进行。 通过步骤 201至步骤 207可知，根据 Answer消息的转换条件判断是否 需要将 Answer消息转换成 Offer消息，如果需要，则将 Answer消息转换成 Offer消息并发送， 可以使第二方得知第一方的 Precondition状态的确认响 应， 由此， 第二方振铃， 呼叫得以继续。 如果不需要， 则将 Answer消息拦 截， 可以减少不必要的信令。
但在实际应用中， 有可能会出现以下情况， 即在步骤 205 中， 第一方 在向 AS 发送 Answer 消息时， 会在 Answer 消息中携带对第二方的 Precondition状态的确认请求， 如果， 第一方无法得知第二方对 Precondition 状态的确认响应， 则第一方不振铃， 呼叫无法继续。 此时， 还有如下步骤： 步骤 208 , 第二方接收 Offer消息， 并向 AS发送 Answer消息。
其中， 该 Answer消息可以 载于更新请求响应消息中， 该更新请求响 应消息可以是但不限于 200OK响应消息或 183响应消息。 其中， 该 Offer 消息包括： 媒体类型、 第二方对 Precondition状态的确认请求、 传输协议和 媒体格式等。
步骤 209 , AS接收 Answer消息，判断该 Answer消息是否满足 Answer 消息的转换条件，如果满足，则执行步骤 210;如果不满足，则拦截该 Answer 消息。
具体内容可以参见步骤 206, 在此不再赘述。
步骤 210, 将 Answer消息转换成 Offer消息后向第一方发送。
其中， 该 Offer消息可以承载于更新请求消息中， 该更新请求消息包括 但不限于是 Update消息和 RE-INVITE消息。该 Offer消息包括：媒体类型、 第二方对 Precondition状态的确认响应、 传输协议和媒体格式等的描述。
由于 AS将第二方对 Precondition状态的确认响应发送给第一方，因此, 第一方可以得知第二方对 Precondition状态的确认响应，此时，第一方振铃 , 呼叫继续进行。 重复执行步骤 206-步骤 207和 /或步骤 208-步骤 210可以发现， 根据 Answer消息的转换条件判断是否需要将 Answer消息转换成 Offer消息，如 果需要， 则将 Answer消息转换成 Offer消息并发送， 可以使一方得知另一 方的 Precondition状态的确认响应， 由此， 呼叫得以继续； 如果不需要， 则 将 Answer消息拦截， 可以减少不必要的信令， 避免媒体协商震荡， 从而提 高了业务质量。
基于与方法实施例相同的发明构思， 本发明的另一个实施例提供了一 种 3PCC中呼叫继续的装置， 如图 3所示， 包括：
第一发送模块， 用于在与第一方进行媒体协商后， 向第二方发送提供 Offer消息；
第一接收模块，用于接收第二方发送的应答 Answer消息，所述 Answer 消息携带对第一方 Precondition状态的确认请求；
转换模块， 用于将 Answer消息转换成 Offer消息；
第二发送模块， 用于将转换模块转换的 Offer消息向第一方发送； 第二接收模块， 用于接收第一方发送的 Answer消息， 所述 Answer消 息携带第一方对 Precondition状态的确认响应；
判断模块，用于判断第二接收模块接收的 Answer消息是否满足 Answer 消息的转换条件；
转换模块， 还用于当判断模块的判断结果为满足时， 将 Answer消息转 换成 Offer消息；
所述第二发送模块， 还用于将转换模块转换的 Offer 消息向第二方发 送。
进一步地， 该装置还包括：
拦截模块， 用于当判断模块的判断结果为不满足时， 则拦截第一方发 送的 Answer消息。 进一步地， 第二接收模块， 还用于接收第二方发送的 Answer消息； 判断模块， 还用于判断第二方发送的 Answer消息是否满足 Answer消 息的转换条件；
转换模块， 还用于将第二方发送的 Answer消息转换成 Offer消息； 第二发送模块， 还用于将转换的 Offer消息向第一方发送。
进一步地， 拦截模块， 还用于当判断模块的判断结果为不满足时， 则 拦截第二方发送的 Answer消息。
其中， Answer消息的转换条件包括第一转换条件和 /或第二转换条件； 其中， 第一转换条件包括：
第一方和第二方协商对 Precondition状态的要求等级为强制；
待转换 Answer消息的上一条 Answer消息中 ,存在对方对 Precondition 状态的确认请求；
待转换 Answer消息中 Precondition状态满足所述确认请求中的状态。 第二转换条件包括：
待转换的 Answer消息中存在对方对 Precondition状态的确认请求， 且 对方当前的 Precondition状态不满足所述待转换的 Answer 消息的上一条
Answer消息的确认请求中的 Precondition状态。
在本发明实施例中，根据 Answer消息的转换条件判断是否需要将携带
Precondition状态的 Answer消息转换成 Offer消息， 如果需要， 则将转换的 Offer消息发送， 可以使呼叫继续， 有利于第三方呼叫控制业务的发展； 如 果不需要， 则将该 Answer消息拦截， 可以减少不必要的信令， 避免媒体协 商震荡， 提高业务质量。

Claims

权利要求书
1、 一种应用服务器呼叫控制中呼叫继续的方法， 其特征在于， 所述方 法包括：
所述应用服务器在与第一方进行媒体协商后， 向第二方发送提供
( Offer ) 消息；
所述应用服务器接收所述第二方发送的应答（Answer ) 消息， 将所述 第二方发送的 Answer消息转换成 Offer消息后向所述第一方发送， 所述转 换后的 Offer消息携带有对第一方前提条件（Precondition )状态的确认请求； 所述应用服务器接收所述第一方发送的 Answer消息，所述第一方发送 的 Answer消息携带有所述第一方对 Precondition状态的确认响应；
所述应用服务器判断所述第一方发送的 Answer消息满足 Answer消息 的转换条件时， 将所述第一方发送的 Answer消息转换成 Offer消息后发送 给所述第二方。
2、 根据权利要求 1所述的方法， 其特征在于， 所述方法还包括： 所述应用服务器判断所述第一方发送的 Answer消息不满足 Answer消 息的转换条件时， 拦截所述第一方发送的 Answer消息。
3、 根据权利要求 2所述的方法， 其特征在于， 所述应用服务器对所述 第一方发送的 Answer消息进行是否满足 Answer消息的转换条件的判断后， 所述方法还包括：
所述应用服务器再次接收所述第二方 /所述第一方发送的 Answer消息； 所述应用服务器再次判断所述第二方 /所述第一方发送的 Answer 消息 满足 Answer消息的转换条件时， 将该第二方 /该第一方发送的 Answer消息 转换成 Offer消息后向所述第一方 /所述第二方发送。
4、 根据权利要求 3所述的方法， 其特征在于， 所述方法还包括： 所述应用服务器再次判断所述第二方 /所述第一方发送的 Answer 消息 不满足 Answer 消息的转换条件时， 拦截所述第二方 /所述第一方发送的 Answer消息。
5、根据权利要求 1至 4任一项所述的方法， 其特征在于， 所述 Answer 消息的转换条件包括第一转换条件和 /或第二转换条件； 其中，
所述第一转换条件至少包括以下一种：
第一方和第二方协商对 Precondition状态的要求等级为强制；
待转换 Answer消息的上一条 Answer消息中 ,存在对方对 Precondition 状态的确认请求；
待转换 Answer消息中 Precondition状态满足所述确认请求中的状态； 所述第二转换条件包括：
待转换的 Answer消息中存在对方对 Precondition状态的确认请求， 且 对方当前的 Precondition状态不满足所述待转换的 Answer 消息的上一条 Answer消息的确认请求中的 Precondition状态。
6、 根据权利要求 5所述的方法， 其特征在于， 所述将 Answer消息转 换成 Offer消息为： 将 Answer消息中的 Precondition状态相关信息承载于 Offer消息中。
7、 根据权利要求 5所述的方法， 其特征在于， 所述应用服务器与第一 方进行媒体协商为， 所述应用服务器直接与所述第一方进行媒体协商； 或者， 所述应用服务器作为代理（ Proxy )或背靠背用户代理（ B2BUA ) 与所述第一方进行媒体协商。
8、 一种应用服务器呼叫控制中呼叫继续的装置， 其特征在于， 所述装 置包括：
第一发送模块， 用于在于第一方进行媒体协商后， 向第二方发送 Offer 消息；
第一接收模块，用于接收所述第二方发送的 Answer消息，所述 Answer 消息携带有对第一方 Precondition状态的确认请求；
转换模块， 用于将所述第二方发送的 Answer消息转换成 Offer消息； 第二发送模块，用于将所述转换模块转换的 Offer消息向所述第一方发 送；
第二接收模块，用于接收所述第一方发送的 Answer消息，所述 Answer 消息携带所述第一方对 Precondition状态的确认响应；
判断模块， 用于判断所述第二接收模块接收的 Answer 消息是否满足 Answer消息的转换条件；
所述转换模块， 还用于当所述判断模块的判断结果为满足时， 将所述 第二接收模块接收的 Answer消息转换成 Offer消息；
所述第二发送模块，还用于将由所述第二接收模块接收的 Answer消息 转换成的 Offer消息向所述第二方发送。
9、 根据权利要求 8所述的装置， 其特征在于， 所述装置还包括： 拦截模块， 用于在所述判断模块判断所述第二接收模块接收的 Answer 消息不满足 Answer消息的转换条件时， 拦截所述第一方发送的 Answer消 息。
10、 根据权利要求 9所述的装置， 其特征在于， 所述第二接收模块， 还用于再次接收所述第二方 /所述第一方发送的 Answer消息；
所述判断模块，还用于判断所述第二方 /所述第一方发送的 Answer消息 满足 Answer消息的转换条件时再次触发所述转换模块；
所述转换模块，还用于将所述第二方 /所述第一方发送的 Answer消息转 换成 Offer消息；
所述第二发送模块，还用于将由所述第二方 /所述第一方发送的 Answer 消息转换成的 Offer消息向所述第一方 /所述第二方发送。
11、 根据权利要求 10所述的装置， 其特征在于， 所述拉截模块， 还用 于当所述判断模块再次判断所述第二方 /所述第一方发送的 Answer 消息 Answer 消息的转换条件不满足时， 则拦截所述第二方 /所述第一方发送的 Answer消息。
12、根据权利要求 8至 11任一项所述的装置，其特征在于，所述 Answer 消息的转换条件包括第一转换条件和 /或第二转换条件；
所述第一转换条件至少包括以下一种：
第一方和第二方协商对 Precondition状态的要求等级为强制；
待转换 Answer消息的上一条 Answer消息中 ,存在对方对 Precondition 状态的确认请求；
待转换 Answer消息中 Precondition状态满足所述确认请求中的状态； 所述第二转换条件包括：
待转换的 Answer消息中存在对方对 Precondition状态的确认请求， 且 对方当前的 Precondition状态不满足所述待转换的 Answer 消息的上一条 Answer消息的确认请求中的 Precondition状态。
PCT/CN2010/072974 2009-08-14 2010-05-20 应用服务器呼叫控制中呼叫继续的方法和装置 WO2011017957A1 (zh)

Priority Applications (3)

Application Number Priority Date Filing Date Title
EP10807902.1A EP2453629B1 (en) 2009-08-14 2010-05-20 Method and apparatus for call proceeding in call control of application server
US13/388,338 US8965973B2 (en) 2009-08-14 2010-05-20 Method and apparatus for call proceeding in call control of application server
CA2771047A CA2771047C (en) 2009-08-14 2010-05-20 Method and apparatus for call proceeding in call control of application server

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN200910165676.5 2009-08-14
CN200910165676.5A CN101997848B (zh) 2009-08-14 2009-08-14 应用服务器呼叫控制中呼叫继续的方法和装置

Publications (1)

Publication Number Publication Date
WO2011017957A1 true WO2011017957A1 (zh) 2011-02-17

Family

ID=43585919

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2010/072974 WO2011017957A1 (zh) 2009-08-14 2010-05-20 应用服务器呼叫控制中呼叫继续的方法和装置

Country Status (5)

Country Link
US (1) US8965973B2 (zh)
EP (1) EP2453629B1 (zh)
CN (1) CN101997848B (zh)
CA (1) CA2771047C (zh)
WO (1) WO2011017957A1 (zh)

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP4089995A1 (en) * 2021-05-10 2022-11-16 Vodafone Group Services Limited Call management invoked by telephony api

Citations (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2007005070A2 (en) * 2005-06-30 2007-01-11 Motorola, Inc. Method and system for optimizing transcoder resources
CN101005511A (zh) * 2007-01-17 2007-07-25 华为技术有限公司 QoS资源预留方法、系统及会话建立和修改媒体的方法
US7382879B1 (en) * 2003-07-23 2008-06-03 Sprint Communications Company, L.P. Digital rights management negotiation for streaming media over a network
CN101247388A (zh) * 2007-02-15 2008-08-20 华为技术有限公司 对媒体进行协商的方法、系统和发送媒体描述信息的方法
CN101459897A (zh) * 2008-04-17 2009-06-17 中兴通讯股份有限公司 一种前转业务中的媒体协商方法
CN101491057A (zh) * 2006-07-14 2009-07-22 高通股份有限公司 服务质量感知的通信会话建立
WO2009089904A1 (en) * 2008-01-15 2009-07-23 Telefonaktiebolaget Lm Ericsson (Publ) Control of quality-of-service preconditions in an ip multimedia subsystem

Family Cites Families (15)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7509425B1 (en) * 2002-01-15 2009-03-24 Dynamicsoft, Inc. Establishing and modifying network signaling protocols
US6970547B2 (en) * 2003-05-12 2005-11-29 Onstate Communications Corporation Universal state-aware communications
EP1503558A1 (de) * 2003-08-01 2005-02-02 Siemens Aktiengesellschaft Verbindung von Teilnehmern in hybriden Kommunikationsnetzen
US7796603B1 (en) * 2005-01-14 2010-09-14 Acme Packet, Inc. Method and system for controlling media sessions in networks that use communication protocols with distinct signaling and media channels
DE102005050586B3 (de) * 2005-10-21 2006-11-02 Siemens Ag Verfahren zum Aufbau einer Videotelefonverbindung und/oder Multimediatelefonverbindung in einem Datennetz
US8369292B2 (en) 2006-06-30 2013-02-05 Industrial Technology Research Institute Method and apparatus for mobility management in communication networks
WO2008064565A1 (fr) * 2006-11-27 2008-06-05 Huawei Technologies Co., Ltd. Système, procédé et dispositifs pour réaliser la continuité de session multimédia
WO2008078458A1 (ja) * 2006-12-27 2008-07-03 Nec Corporation 電話中継システムおよび電話中継装置ならびに電話中継方法
US8804659B2 (en) * 2007-04-05 2014-08-12 Telefonaktiebolaget L M Ericsson (Publ) Communication terminal, method for controlling communication terminal
US8135117B2 (en) * 2007-11-07 2012-03-13 Nokia Corporation Charging split negotiation in IMS sessions
JP5173607B2 (ja) * 2008-06-03 2013-04-03 株式会社日立製作所 通信システム
US7979558B2 (en) * 2008-08-06 2011-07-12 Futurewei Technologies, Inc. Remote session control
US8144182B2 (en) * 2008-09-16 2012-03-27 Biscotti Inc. Real time video communications system
US8891388B2 (en) * 2008-12-08 2014-11-18 Zte Corporation Path node determining method, media path establishing method, and signaling media gateway
EP2387855B1 (en) * 2009-01-12 2023-12-20 Cisco Technology, Inc. Transferring sessions in a communications network

Patent Citations (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7382879B1 (en) * 2003-07-23 2008-06-03 Sprint Communications Company, L.P. Digital rights management negotiation for streaming media over a network
WO2007005070A2 (en) * 2005-06-30 2007-01-11 Motorola, Inc. Method and system for optimizing transcoder resources
CN101491057A (zh) * 2006-07-14 2009-07-22 高通股份有限公司 服务质量感知的通信会话建立
CN101005511A (zh) * 2007-01-17 2007-07-25 华为技术有限公司 QoS资源预留方法、系统及会话建立和修改媒体的方法
CN101247388A (zh) * 2007-02-15 2008-08-20 华为技术有限公司 对媒体进行协商的方法、系统和发送媒体描述信息的方法
WO2009089904A1 (en) * 2008-01-15 2009-07-23 Telefonaktiebolaget Lm Ericsson (Publ) Control of quality-of-service preconditions in an ip multimedia subsystem
CN101459897A (zh) * 2008-04-17 2009-06-17 中兴通讯股份有限公司 一种前转业务中的媒体协商方法

Also Published As

Publication number Publication date
CA2771047A1 (en) 2011-02-17
EP2453629A1 (en) 2012-05-16
US20120136938A1 (en) 2012-05-31
EP2453629A4 (en) 2017-07-26
CN101997848A (zh) 2011-03-30
CA2771047C (en) 2014-10-21
CN101997848B (zh) 2015-05-20
US8965973B2 (en) 2015-02-24
EP2453629B1 (en) 2020-06-17

Similar Documents

Publication Publication Date Title
JP3633546B2 (ja) シグナリング中継システムおよびシグナリング中継方法
JP4870475B2 (ja) 通信ネットワークシステム
US20090259758A1 (en) Method and system for session migration
JP4966972B2 (ja) 通信端末装置
JP2006525693A (ja) マルチメディア・ストリーミングにおけるクライアント速度機能のシグナリング方法
JP2011172265A (ja) ユーザ手動のハンドオフに基づく、セッション開始プロトコルＳＩＰ（ＳｅｓｓｉｏｎＩｎｉｔｉａｔｉｏｎＰｒｏｔｏｃｏｌ）
WO2010133148A1 (zh) 软交换架构下的编解码转换控制方法、媒体网关及系统
WO2010031230A1 (zh) 一种ip多媒体链路的媒体协商方法
WO2007019777A1 (fr) Méthode d’établissement de session et nœud de contrôle de session
WO2008003233A1 (fr) Procédé et dispositif d'interconnexion d'appels multimedia entre le domaine cs et le domaine ims
WO2007068179A1 (fr) Procédé, système de communication et entité pour envoi de code de chevauchement au moyen d'un protocole d'ouverture de session
JP2011029827A (ja) 呼制御装置、情報通信方法、情報通信プログラム、及び情報通信システム
WO2011017957A1 (zh) 应用服务器呼叫控制中呼叫继续的方法和装置
RU2446605C2 (ru) Способ, система и устройство для согласования службы данных сигнализации протокола инициации сеанса
WO2009026757A1 (fr) Système de gestion d'appels, procédé appliqué à des terminaux ims et terminal ims
JP2012090025A (ja) 通信装置
WO2008049371A1 (fr) Procédé et système pour transférer un événement de service
JP2008148019A (ja) Ｐｂｘ装置およびその呼制御方法
WO2011012013A1 (zh) 第三方呼叫控制中媒体协商的方法和装置
WO2015131466A1 (zh) 基于会话初始协议sip的数据业务处理方法及装置
KR100927936B1 (ko) 서로 다른 두 망간의 연동 장치
WO2012062104A1 (zh) 多页彩信的传输系统和方法、会话初始化协议终端以及彩信代理服务器
JP6549523B2 (ja) 要求先端末のオプション機能の非使用を整合する網間制御方法、ｓｉｐサーバ及びプログラム
WO2010031284A1 (zh) 用户终端、应用服务器以及呼叫建立方法
KR101305488B1 (ko) 실시간 호 전환 단말기 및 그 방법

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 10807902

Country of ref document: EP

Kind code of ref document: A1

WWE Wipo information: entry into national phase

Ref document number: 13388338

Country of ref document: US

WWE Wipo information: entry into national phase

Ref document number: 2010807902

Country of ref document: EP

WWE Wipo information: entry into national phase

Ref document number: 2771047

Country of ref document: CA

NENP Non-entry into the national phase

Ref country code: DE