WO2006122446A1 - Methode de traitement de tonalites multiples de rappel dans une application de service vocal reposant sur sip fork - Google Patents

Methode de traitement de tonalites multiples de rappel dans une application de service vocal reposant sur sip fork Download PDF

Info

Publication number
WO2006122446A1
WO2006122446A1 PCT/CN2005/000693 CN2005000693W WO2006122446A1 WO 2006122446 A1 WO2006122446 A1 WO 2006122446A1 CN 2005000693 W CN2005000693 W CN 2005000693W WO 2006122446 A1 WO2006122446 A1 WO 2006122446A1
Authority
WO
WIPO (PCT)
Prior art keywords
softswitch
sdp
response
called
calling
Prior art date
Application number
PCT/CN2005/000693
Other languages
English (en)
French (fr)
Inventor
Jian Chen
Original Assignee
Utstarcom Telecom Co., Ltd.
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 Utstarcom Telecom Co., Ltd. filed Critical Utstarcom Telecom Co., Ltd.
Priority to PCT/CN2005/000693 priority Critical patent/WO2006122446A1/zh
Priority to US11/914,467 priority patent/US20080240375A1/en
Priority to CN2005800498302A priority patent/CN101180866B/zh
Publication of WO2006122446A1 publication Critical patent/WO2006122446A1/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/1066—Session management
    • H04L65/1101—Session protocols
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04M—TELEPHONIC COMMUNICATION
    • H04M3/00—Automatic or semi-automatic exchanges
    • H04M3/42—Systems providing special services or facilities to subscribers
    • H04M3/42017—Customized ring-back tones
    • 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/1101—Session protocols
    • H04L65/1104—Session initiation protocol [SIP]
    • 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/40—Support for services or applications
    • H04L65/401—Support for services or applications wherein the services involve a main real-time session and one or more additional parallel real-time or time sensitive sessions, e.g. white board sharing or spawning of a subconference
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04M—TELEPHONIC COMMUNICATION
    • H04M3/00—Automatic or semi-automatic exchanges
    • H04M3/42—Systems providing special services or facilities to subscribers
    • H04M3/42025—Calling or Called party identification service
    • H04M3/42085—Called party identification service
    • H04M3/42093—Notifying the calling party of information on the called or connected party
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04M—TELEPHONIC COMMUNICATION
    • H04M7/00—Arrangements for interconnection between switching centres
    • H04M7/006—Networks other than PSTN/ISDN providing telephone service, e.g. Voice over Internet Protocol (VoIP), including next generation networks with a packet-switched transport layer
    • H04M7/0075—Details of addressing, directories or routing tables
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04M—TELEPHONIC COMMUNICATION
    • H04M3/00—Automatic or semi-automatic exchanges
    • H04M3/42—Systems providing special services or facilities to subscribers
    • H04M3/58—Arrangements for transferring received calls from one subscriber to another; Arrangements affording interim conversations between either the calling or the called party and a third party

Definitions

  • the invention belongs to the field of communications.
  • the present invention relates to a method of processing multiple ring back tones in a SIP FOR based voice service application.
  • SIP Session Initiation Protocol, RFC3261
  • RFC3264 the offer/answer model
  • SDP Session Description Protocol, RFC23257
  • the calling party transmits the SDP message of the calling party to the called user through the session request message INVITE. After the called party answers, the called party sends back the response 200, and the called SDP is transmitted to the calling party after the negotiation.
  • SDP exchange satisfies the offer/response
  • the called party In a normal session, if the called party is idle after receiving the call setup request from the calling party, the called party will send an alert indication.
  • the ringback tone is played by the destination office switch to the calling user (Q764, Section 2.1.4.7).
  • the called party In a SIP network, due to the diversity of media information and user agents (UA), the called party does not play back ring tones to the calling party.
  • the calling party After receiving the a lert indication (180 response in SIP), the calling party can simulate a ring tone played locally on the PSTN network, or in other ways, such as text or animation.
  • the calling party After the SIP is introduced into the telecommunication network, if the called party is a SIP user, the calling party usually plays the ring back tone locally (called local play); if the called party is a PSTN user, the called party will play back the ringback. Tone (called remote playback).
  • local play if the called party is a PSTN user, the called party will play back the ringback. Tone (called remote playback).
  • remote playback In a simple two-party session, when the calling party is a SIP user, there is no problem whether it is played locally or remotely (Q1912, SIP5 stipulates, if there is no SDP in the 180 message, it means that the calling party plays the ringback locally.
  • SIP FORK-based voice services simplify the processing of SIP FORK early media. Regardless of the network where the called party is located, as long as there is a ringing of the called party, the ringing tone can be played locally by the calling side. (In practical applications, the application server can even indicate the calling side to play the ring back tone before FORK, which is for the string. Line-addressed FORK applications are especially important).
  • SIP PROXY routes all called 18X messages to the calling party before receiving the 200 response, where SIP PROXY masks all 18X messages on the called side, and itself generates a 180 message indicating the calling side.
  • the ringback tone is played locally (see Figure 1, quoted from the third part of the China Telecom SIP Specification (Signaling Process)).
  • the applicant believes that this point does not comply with RFC3261, but in the isomorphic network of PSTN, since the call progress indication is always represented by a ring back tone, it is desirable from an application point of view. Of course, some services may be missing, such as ring tones.
  • the above process only describes the signaling message, but it does not explain the more serious ear ly media.
  • the transmission of the media is independent of the signaling. Although the signaling is suppressed, the media (ringback tone or voice prompt) from different called parties can still reach the calling party. So relatively speaking, how to suppress ear ly media from multiple called is more important.
  • the media message can only be received after the calling user receives the 200 response message.
  • the 200 response message carries the called SDP information. Even if the media information is received, the DSP should discard (because the caller does not know the called address of the called party at this time).
  • the present invention proposes two methods based on protocol control, through a softswitch SW triggered by a service (Sof tswi tch,
  • the implementation can be SIP PROXY, B2BUA or a mixture of the two.
  • the signaling content and process are appropriately changed.
  • the backward channel on the media path cannot be completely established before the called party answers to avoid the calling user. Received ear ly media from different called parties.
  • a method for processing a multi-ringback tone in a SIP FORK-based voice service application including the steps of:
  • the softswitch receives the INVITE, triggers the FORK service, and checks the calling party's session description protocol SDP;
  • the destination office switch will play a ringback tone to the calling party, and the ringback tone ends in the interworking unit;
  • the softswitch receives an acknowledgment response, releases other unanswered calls, and acknowledges the response received.
  • the softswitch sends an INVITE message with the unaltered calling SDP to the called party to re-schedule the SDP negotiation;
  • the called party and the calling party establish a two-way media connection.
  • a method for processing a multi-ringback tone in a SIP FORK-based voice service application including the steps of:
  • the softswitch receives the INVITE, triggers the FORK service, and sends a prompt response with the rejecting media connection establishment to the calling party to reject the media channel establishment;
  • the calling party After receiving the above prompt response, the calling party closes the backward channel;
  • the softswitch sends an INVITE request containing the SDP information of the calling party to all the called parties;
  • the interworking unit IWU which is the intermediate office, receives the INVITE message, and connects to the media channel before and after;
  • the destination office switch will play a ringback tone to the calling party
  • the destination office sends a prompt response with the called SDP to the softswitch, and the softswitch receives and retains the called SDP; If a called party goes off-hook, the IWU will send an acknowledgment response to the softswitch, and the softswitch will release the other unanswered call after receiving the response.
  • the softswitch sends a response response to the calling party without SDP information
  • the softswitch sends an INVITE to the calling party to perform SDP negotiation.
  • the answer is sent back and the media channel is connected. At this time, the media path of the called party's called party is completely established.
  • FIG. 2 illustrates a method of processing a multi-ringback tone in a SIP FORK-based voice service application according to a first embodiment of the present invention
  • FIG. 3 illustrates a method of processing a multi-ring back tone in a SIP FORK-based voice service application according to a second embodiment of the present invention.
  • Embodiment 1 suppressing the establishment of the backward channel of the called side:
  • FIG. 1 shows a method for processing a multi-loop ring tone in a SIP FOR-based voice service application according to a first embodiment of the present invention, that is, a method for suppressing establishment of a backward channel on a called side.
  • the softswitch receives the caller side INVITE message (the calling party uses UAC, that is, the client user agent, including the SIP terminal, SIP PROXY, B2BUA or SIP/ISUP interworking unit) IWU)
  • UAC that is, the client user agent, including the SIP terminal, SIP PROXY, B2BUA or SIP/ISUP interworking unit
  • the softswitch must retain the calling SDP content.
  • the INVITE message is sent by the softswitch to all the called parties, and the INVITE message has the changed calling SDP.
  • the response is sent by the softswitch to the calling side.
  • the 180 response indicates that the calling side plays the ringback tone locally, and the response does not carry the SDP.
  • the interworking unit When the interworking unit receives the INVITE request, it checks the SDP information. Since the direction attribute of the media stream in the SDP is sendonly, the IWU as the intermediate station will not connect (t hrough-connect) the backward channel of the media (RFC3264, 8. 1 section), but will Connect the forward channel of the media (Q764, Section 2.1.2)
  • the destination office switch will play the ringback tone to the calling party. At this time, the back channel of the media is not fully established, and the ringing tone or voice notification will not reach the calling party.
  • the softswitch receives a ringing response 180 with SDP, and the softswitch does not process it.
  • the softswitch receives an acknowledgement response 200, which will release other unanswered calls and acknowledge the response received.
  • the softswitch sends an INVITE message to the called party to perform SDP negotiation.
  • the SDP carried in the INVITE is the reserved calling SDP.
  • the IWU After receiving the offer, the IWU sends a reply to the softswitch and connects to the backward channel. At this time, the backward channel on the media path is fully established, and the calling party can receive the called party media information.
  • the softswitch After receiving the IWU 200, the softswitch sends an acknowledgement response 200 to the calling party with the called SDP.
  • the calling side sends a response confirmation.
  • the signaling message is completed, the forward channel on the media path is completely established, and the called party can receive the media information of the calling party.
  • Embodiment 2 suppressing the establishment of the backward channel of the calling side:
  • FIG. 3 illustrates a method for processing a multi-loop ring tone in a SIP FORK-based voice service application according to a second embodiment of the present invention, that is, a method for suppressing establishment of a backward channel on a calling side.
  • the softswitch receives the calling side INVITE message and triggers the FORK service, responding to the calling side with a 180 response.
  • 180 includes SDP, which rejects the establishment of the calling media channel (RFC3264, Chapter 6, when rejecting a media stream, the port number in the corresponding media stream in the response SDP is set to 0).
  • the 183 can be used to carry the SDP to reject the media channel establishment, and the 180 only indicates that the calling party plays the ringback tone locally.
  • the back channel is closed.
  • the softswitch sends an INVITE request to all called parties, which contains the SDP information of the calling party.
  • the interworking unit After the interworking unit receives the INVITE message, the IWU acting as the intermediate station will connect the front and back media channels.
  • the called user is idle, and the destination office switch will play the ring back tone to the calling party.
  • the ringing tone or other voice notifications cannot reach the calling user.
  • the softswitch receives the called ringing response 180 with SDP, and the softswitch retains the called party.
  • the IWU When a called party picks up the phone, the IWU sends an acknowledgement response 200 to the softswitch, and the softswitch will release other unanswered calls after receiving the 200 message.
  • the softswitch sends an acknowledgement response to the calling side. 200, 200 There is no SDP information in the message.
  • the softswitch sends an INVITE to the calling side to perform SDP negotiation.
  • the SDP content is the reserved SDP information of the off-hook called.
  • the answer is sent back and the media channel is connected. At this time, the media path of the called party's called party is completely established.
  • the present invention is completely based on a standard protocol, and the control of the signaling flow is completely concentrated on the service trigger point, and is completely transparent to the calling party and the called party, thereby facilitating the promotion of services and the interconnection and interworking of devices of different manufacturers.
  • media negotiation needs to be resumed after the called party picks up the phone, the media may be lost.
  • media loss should be within acceptable limits.

Landscapes

  • Engineering & Computer Science (AREA)
  • Signal Processing (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Multimedia (AREA)
  • Business, Economics & Management (AREA)
  • General Business, Economics & Management (AREA)
  • Telephonic Communication Services (AREA)

Description

基于 SIP FORK的语音服务应用中多回铃音的一种处理方法 技术领域
本发明属于通信领域。 具体地， 本发明涉及对基于 SIP FOR 的 语音服务应用中多回铃音的一种处理方法。
背景技术
SIP (会话初始协议， RFC3261 )采用 offer/answer模型 ( RFC3264 ) 交换会话双方的 SDP (会话描述协议， RFC2327 ) , 包括所要创建媒体 流的各种属性， 如媒体流的 IP 地址和传输层端口， 所采用的编码等 等。 一般会话中主叫方通过会话请求消息 INVITE 将主叫的 SDP 消息 传送至被叫用户， 被叫用户应答后， 被叫方回送应答响应 200， 将协 商后被叫的 SDP 传送至主叫方。 SDP 的交换满足提议 /应答
( offer/answer ) 过程。 当 of f er方（如上述主叫方）发出 of f er后， 一般情况 offer 方便能接收相应的媒体信息 （RFC3264 , 第 5. 1 节） ， 这可以避免媒体消息的丢失 （media cl ipping ) ， 因为基于 SIP 的会 话信令和媒体的传愉是完全分离的， 信令往往要跨接若干代理
( PROXY ) ， 但媒体的传输往往是端到端的， 因此当被叫用户摘机后， 媒体信息一般先于应答响应 （ 200 ) 到达主叫用户。
一般会话中， 当被叫方收到主叫方的呼叫建立请求后如果被叫用 户空闲， 被叫方将发送 alert 指示。 在 PSTN 中， 由目的局交换机向 主叫用户播放回铃音 （Q764 , 第 2. 1. 4. 7节） 。 在 SIP 网络中， 由于 媒体信息及用户代理（UA)的多样性， 被叫方不会向主叫方播放回铃 音。 主叫方在收到 a lert 指示 （SIP 中为 180响应）后可以模拟 PSTN 网络本地播放一回铃音， 亦可采用其它方式， 如以文本或动画表示。 在将 S IP 引入电信网后， 如果被叫为 SIP 用户， 通常情况下主叫方 本地播放回铃音 （称之为本地播放） ； 如果被叫为 PSTN 用户时， 被 叫方将播放回铃音 （称之为远端播放） 。 在简单的两方会话中， 当主 叫为 SIP用户时，不管是由本地播放还是远端播放均没有问题（Q1912 , SIP5 规定， 如果 180消息中无 SDP, 表示由主叫方本地播放回铃音， 反之由远端播放） 。 但在 SIP FORK 应用中， 由于一个主叫对应多个 被叫（一个被叫用户， 但有多个访问地址， 如多个号码）， 当多个被叫 落于 PSTN 网络时， 由于媒体的端到端属性， 目的局交换机可以通过 互通单元 （IWU ) 直接向主叫播放回铃音。 在该情况下， 因为主叫方 无法混音， 用户常常听到莫名的噪声。
对于 SIP FORK应用中的 ear ly media 问题， G. Camar i l lo , H. Schul zr inne 认为 UAC ( UA cl ient )应从来自不同 UAS ( UA server ) 的 ear ly media 中选择其一而抑制其余， 但其并未阐述选择策略（见 draf t - ietf- s ipping- early - media- 02. txt ) 。 申请人认为选择其一而 抑制其余一方面可能选择错误。 另一方面由于处理的复杂度， 如 ear ly media 检测， 选择， 抑制， 恢复（被抑制的一方是最终的会话方， 此 时必须恢复媒体流） ， 在目前难以应用。
基于 SIP FORK的语音服务， 可简化 SIP FORK early media 的处 理。 不管被叫落于何网络， 只要有被叫振铃， 均可由主叫侧本地播放 回铃音 （实际应用中， 应用服务器甚至可在 FORK 之前先指示主叫侧 播放回铃音，这对于串行寻址的 FORK应用尤为重要）。不同于 RFC3261 规定 SIP PROXY 在收到 200 应答响应前所有被叫的 18X 消息均路由 到主叫方， 此处 SIP PROXY屏蔽所有被叫侧的 18X消息， 而其自身产 生一 180消息指示主叫侧本地播放回铃音（见图 1， 引自中国电信 SIP 规范第三部分（信令流程） ） 。 申请人认为此点虽不符合 RFC3261 , 但在 PSTN 这种同构网中， 由于呼叫进展指示总是由回铃音表示， 从 应用的角度看是可取的。 当然某些业务可能缺失， 如彩铃等。
上述流程仅对信令消息进行了说明， 但对更为严重的 ear ly media 却未能阐述。 媒体的传输独立于信令， 虽然信令被抑制了， 但来自不 同被叫的媒体 （回铃音或语音提示） 仍然可以到达主叫方。 因此相对 而言， 如何抑制来自多个被叫的 ear ly media 更为重要。 但目前对此 却未达成共识， 有的认为只有在主叫用户收到 200应答消息后才能接 收媒体信息， 还有的认为 DSP应具有包过滤功能， 在主叫用户收到 200 应答消息前（此处 200应答消息携带被叫的 SDP信息） ， 即使收到媒 体信息， DSP 也应丢弃（因为此时主叫并不知道被叫的发送地址） 。
但是不管那种方法，要么违反了 offer/answer的原则，要么对 DSP 有特许要求， 更有甚者影响了业务和呼叫控制的分离。
发明内容
为了解决以上所述现有技术中存在的问题， 本发明提出了两种基 于协议控制的方法， 通过由业务触发处的软交换 SW ( Sof tswi tch, 实 际实现可以是 SIP PROXY ， B2BUA 或二者的混合体） 适当改变信令内 容和流程， 在遵从协议规范的前提下使得媒体通路上后向通道在被叫 应答前不能完全建立从而避免主叫用户收到来自不同被叫的 ear ly media。
根据本发明的一方面， 提供了基于 SIP FORK 的语音服务应用中 多回铃音的一种处理方法， 包括步骤：
从主叫方向软交换发送会话请求消息 INVITE;
软交换接收所述 INVITE, 触发 FORK 业务， 并检查主叫方的会话 描述协议 SDP;
由软交换向所有的被叫方发送带有改变后的主叫 SDP 的 INVITE 消息， 并向主叫方发送用于指示主叫方本地播放回铃音的响应；
由作为中间局的互通单元 IWU接收所述 INVITE, 并连接媒体的前 向通道， 而不连接媒体的后向通道；
如果被叫用户空闲， 目的局交换机将向主叫方播放回铃音， 该回 铃音终结于互通单元；
如果某一被叫方摘机， 软交换会接收到应答响应， 将释放其它未 应答呼叫， 并确认所收到的应答响应；
软交换向被叫方发送带有未经改变的主叫 SDP 的 INVITE 消息， 以便重新进行 SDP协商；
被叫方和主叫方建立双向媒体连接。
根据本发明的另一方面， 提供了基于 SIP FORK 的语音服务应用 中多回铃音的一种处理方法， 包括步骤：
从主叫方向软交换发送会话请求消息 INVITE;
软交换接收所述 INVITE, 触发 FORK 业务， 并向主叫方发送带有 拒绝媒体连接建立的提示响应， 以拒绝媒体通道建立；
主叫方收到上述提示响应后， 关闭后向通道；
软交换向所有被叫发送包含主叫方的 SDP 信息的 INVITE 请求； 作为中间局的互通单元 IWU 收到 INVITE 消息后， 连接前、 后向 媒体通道；
如果被叫用户空闲， 目的局交换机将向主叫播放回铃音；
目的局向软交换发送带有被叫 SDP 的提示响应， 软交换接收并保 留该被叫的 SDP; 如果某一被叫摘机， IWU 将向软交换发送应答响应， 软交换收到 该应答响应后释放其它未应答呼叫；
软交换向主叫方发送不带 SDP信息的应答响应；
软交换向主叫方发送 INVITE重新进行 SDP协商；
主叫方收到 offer后， 回送 answer , 同时将连接媒体通道， 此时 主叫方被叫方的媒体通路完全建立。
附图说明
图 1 示出现有技术中基于 SIP FORK 的语音服务应用中多回铃音 的处理方法；
图 2 示出根据本发明第一实施例， 基于 SIP FORK 的语音服务应 用中多回铃音的处理方法； 以及
图 3 示出根据本发明第二实施例， 基于 SIP FORK 的语音服务应 用中多回铃音的处理方法。
具体实施方式
下面参考附图描述本发明的两个优选实施例。
实施例 1 , 抑制被叫侧后向通道建立：
图 1 示出根据本发明第一实施例， 基于 SIP FOR 的语音服务应 用中多回铃音的处理方法， 即： 抑制被叫侧后向通道建立的方法。
以被叫落在 PSTN网络为例， 当软交换收到主叫侧 INVITE消息（主 叫侧用 UAC表示，即客户端用户代理， 包括 SIP终端， SIP PROXY, B2BUA 或是 S IP/ ISUP 互通单元 IWU ) 并触发 FORK 业务时， 软交换 检查主 叫 SDP 。 如果媒体流方向属性为 a=sendrecv, 将之改为 a=sendonly (正常呼叫中， 主叫 SDP的媒体流方向属性为 a=sendrecv ) ， 表示主 叫侧只能发出媒体信息而不接收媒体信息。 软交换须保留主叫 SDP 内 容。
由软交换向所有的被叫发送 INVITE 消息， INVITE 消息带有改变 后的主叫 SDP。
由软交换向主叫侧发送 180 响应指示主叫侧本地播放回铃音， 该 响应不带 SDP。
当互通单元收到 INVITE 请求后， 检查 SDP 信息， 由于 SDP 中媒 体流的方向属性为 sendonly , 作为中间局的 IWU 将不会连接 ( t hrough- connect )媒体的后向通道 （RFC3264 , 第 8. 1 节） ， 但会 连接媒体的前向通道（Q764， 第 2. 1. 2节）
如果被叫用户空闲， 目的局交换机将向主叫播放回铃音， 此时由 于媒体的后向通道未完全建立， 回铃音或语音通知等 ear ly media 将 无法到达主叫用户。
软交换收到带有 SDP的振铃响应 180， 软交换不做处理。
如果某一被叫摘机， 软交换收到应答响应 200， 将释放其它未应 答呼叫， 并确认所收到的应答响应。
软交换向被叫发送 INVITE 消息重新进行 SDP协商， INVITE 中所 带的 SDP为其所保留的主叫 SDP。此时 SDP中的方向属性为 a=sendrecv
IWU 收到 offer 后， 向软交换回送 answer , 同时连接后向通道， 这时媒体通路上的后向通道以完全建立， 主叫方能够接收到被叫方媒 体信息。
软交换收到 IWU 的 200 后向主叫方发送应答响应 200, 并带有被 叫的 SDP。
主叫侧发送应答确认， 此时信令消息完成， 媒体通路上的前向通 道完全建立， 被叫方即可接收到主叫方的媒体信息。
实施例 2， 抑制主叫侧后向通道建立：
图 3 示出根据本发明第二实施例， 基于 SIP FORK 的语音服务应 用中多回铃音的处理方法， 即： 抑制主叫侧后向通道建立的方法。
以被叫落在 PSTN网络为例。 软交换收到主叫侧 INVITE 消息并触 发 FORK 业务， 向主叫侧回应 180响应。 180中包含 SDP， 该 SDP拒绝 主叫媒体通道的建立 （RFC3264 , 第 6 章， 当拒绝某一媒体流时， 回 应 SDP 中相应媒体流中的端口号置为 0 ) 。 为防止混淆， 可用 183携 带 SDP 以拒绝媒体通道建立， 180仅指示主叫方本地播放回铃音。
主叫方收到拒绝 answer 后， 将关闭后向通道。
软交换向所有被叫发送 INVITE请求， 该请求包含主叫方的 SDP信 息。
互通单元收到 INVITE 消息后， 作为中间局的 IWU 将连接前、 后 向媒体通道。
被叫用户空闲， 目的局交换机将向主叫播放回铃音， 此时由于主 叫侧媒体的后向通道未连接， 回铃音或其他语音通知等 ear ly media 无法到达主叫用户。 软交换收到带有 SDP的被叫振铃响应 180， 软交换保留该被叫的
SDP。
某一被叫摘机， IWU向软交换发送应答响应 200，软交换收到 200消 息后将释放其它未应答呼叫。
软交换向主叫侧发送应答响应 200， 200消息中无 SDP 信息。 软交换向主叫侧发送 INVITE重新进行 SDP协商， SDP内容为所保 留的摘机被叫的 SDP 信息。
主叫方收到 offer后， 回送 answer， 同时将连接媒体通道， 此时 主叫方被叫方的媒体通路完全建立。
根据以上描述， 本发明完全基于标准协议， 且信令流程的控制完 全集中于业务触发点， 对呼叫主被叫方完全透明， 因此有利于业务的 推广和不同厂家设备的互连互通。
此外， 因为需要在被叫摘机后重新进行媒体协商， 可能造成媒体 丟失的情况。 但由于重新协商的过程很快， 媒体的丢失应在可接受范 围内。
尽管以上参考具体实施例对本发明进行了描述， 但本领域的技术 人员应当理解， 在不背离本发明的精神和宗旨的前提下， 可以通过多 种不同的方式实现本发明。 因此， 本发明的范围不限于以上所描述的 实施例， 而由所附权利要求限定。

Claims

权 利 要 求
1. 一种基于 SIP FORK 的语音服务应用中多回铃音的处理方法， 包括步骤：
从主叫方向软交换发送会话请求消息 INVITE;
软交换接收所述 INVITE, 触发 FORK 业务， 并检查主叫方的会话 描述协议 SDP;
由软交换向所有的被叫方发送带有改变后的主叫 SDP 的 INVITE 消息， 并向主叫方发送用于指示主叫方本地播放回铃音的响应；
由作为中间局的互通单元 IWU接收所述 INVITE, 并连接媒体的前 向通道， 而不连接媒体的后向通道；
如果被叫用户空闲， 目的局交换机将向主叫方播放回铃音； 如果某一被叫方摘机， 软交换会接收到应答响应， 将释放其它未 应答呼叫， 并确认所收到的应答响应；
软交换向被叫方发送带有未经改变的主叫 SDP 的 INVITE 消息， 以便重新进行 SDP协商；
由被叫方接收来自主叫方的媒体信息。
2. 如权利要求 1 所述的处理方法， 其中所述检查主叫方的会话 描述协议 SDP的步骤包括：
如果媒体流方向属性为 a=sendrecv, 将之改为 a=sendonly, 表示 主叫方只能发出媒体信息而不接收媒体信息。
3. 如权利要求 1 或 2 所述的处理方法， 其中软交换在接收到所 述 INVITE后， 保留主叫 SDP内容。
4. 如权利要求 1 或 2 所述的处理方法， 其中所述重新进行 SDP 协商的步骤包括：
IWU收到来自软交换的提议 offer后， 向软交换回送应答 answer , 同时连接后向通道；
软交换收到 IWU 的应答后， 向主叫方发送带有被叫方 SDP的应答 响应；
主叫方发送应答确认。
5. 一种基于 SIP FORK 的语音服务应用中多回铃音的处理方法， 包括步驟： 从主叫方向软交换发送会话请求消息 INVITE;
软交换接收所述 INVITE, 触发 FORK 业务， 并向主叫方发送带有 拒绝媒体连接建立的提示响应， 以拒绝媒体通道建立；
主叫方收到上述提示响应后， 关闭后向通道；
软交换向所有被叫发送包含主叫方的 SDP 信息的 INVITE 请求； 作为中间局的互通单元 環 收到 INVITE 消息后， 连接前、 后向 媒体通道；
如果被叫用户空闲， 目的局交换机将向主叫播放回铃音； 目的局向软交换发送带有被叫 SDP 的提示响应， 软交换接收并保 留该被叫的 SDP;
如果某一被叫摘机， IWU 将向软交换发送应答响应， 软交换收到 该应答响应后释放其它未应答呼叫；
软交换向主叫方发送不带 SDP信息的应答响应；
软交换向主叫方发送 INVITE重新进行 SDP协商；
主叫方收到 offer后， 回送 answer , 同时将连接媒体通道， 此时 主叫方被叫方的媒体通路完全建立。
6. 如权利要求 5所述的处理方法， 其中所述提示响应携带 SDP以 拒绝媒体通道建立， 并且仅指示主叫方本地播放回铃音。
PCT/CN2005/000693 2005-05-19 2005-05-19 Methode de traitement de tonalites multiples de rappel dans une application de service vocal reposant sur sip fork WO2006122446A1 (fr)

Priority Applications (3)

Application Number Priority Date Filing Date Title
PCT/CN2005/000693 WO2006122446A1 (fr) 2005-05-19 2005-05-19 Methode de traitement de tonalites multiples de rappel dans une application de service vocal reposant sur sip fork
US11/914,467 US20080240375A1 (en) 2005-05-19 2005-05-19 Method Of Processing Multiple Ring Back Tone In Voice Service Application Based On Sip Fork
CN2005800498302A CN101180866B (zh) 2005-05-19 2005-05-19 基于sip fork的语音服务应用中多回铃音的一种处理方法

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/CN2005/000693 WO2006122446A1 (fr) 2005-05-19 2005-05-19 Methode de traitement de tonalites multiples de rappel dans une application de service vocal reposant sur sip fork

Publications (1)

Publication Number Publication Date
WO2006122446A1 true WO2006122446A1 (fr) 2006-11-23

Family

ID=37430920

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2005/000693 WO2006122446A1 (fr) 2005-05-19 2005-05-19 Methode de traitement de tonalites multiples de rappel dans une application de service vocal reposant sur sip fork

Country Status (3)

Country Link
US (1) US20080240375A1 (zh)
CN (1) CN101180866B (zh)
WO (1) WO2006122446A1 (zh)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2009026759A1 (fr) * 2007-08-30 2009-03-05 Zte Corporation Procédé et système pour le service de plusieurs terminaux avec un seul numéro sonnant simultanément

Families Citing this family (14)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP4874993B2 (ja) * 2005-01-11 2012-02-15 テレフオンアクチーボラゲット エル エム エリクソン（パブル） 通信システムにおける初期メディアの容易化
ATE428253T1 (de) * 2006-01-27 2009-04-15 Siemens Ag Verfahren zur zuordnung von zumindest einer nutzdatenverbindung zu zumindest einer multiplexverbindung
CN101026653B (zh) * 2006-02-24 2011-08-24 华为技术有限公司 一种实现彩像业务的系统及方法
KR101247985B1 (ko) * 2006-06-09 2013-03-27 에스케이텔레콤 주식회사 얼리 세션을 이용한 세션 설정 프로토콜 기반의 얼리미디어 서비스 제공 방법
JP2008302907A (ja) * 2007-06-11 2008-12-18 Takata Corp 伸縮性ウェビング、エアベルト、エアベルト装置
CN101764895B (zh) * 2008-12-23 2013-04-17 华为终端有限公司 一种实现被叫终端多媒体彩振的方法、服务器及系统
US8385326B2 (en) * 2008-12-29 2013-02-26 Microsoft Corporation Handling early media in VoIP communication with multiple endpoints
CN102404295B (zh) * 2010-09-15 2016-05-25 中兴通讯股份有限公司 会话中早媒体的播放方法及系统
CN103685200B (zh) 2012-09-24 2018-01-30 中兴通讯股份有限公司 接入协商、释放中服务质量承载资源控制的方法及系统
WO2015074683A1 (en) * 2013-11-20 2015-05-28 Telefonaktiebolaget L M Ericsson (Publ) Methods for handling a connection status
CN104836775B (zh) * 2014-02-08 2019-02-01 中兴通讯股份有限公司 振铃态下的呼叫放音方法及装置
GB2557350B (en) * 2016-12-08 2021-08-11 Metaswitch Networks Ltd Operating a network node
JP6912729B2 (ja) * 2018-04-12 2021-08-04 日本電信電話株式会社 Ｓｉｐプロキシサーバ、通信方法およびｓｉｐプロキシプログラム
CN110971766B (zh) * 2019-09-27 2021-01-05 华为技术有限公司 呼叫处理的方法和设备

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2003032585A1 (en) * 2001-10-09 2003-04-17 Nokia Corporation Transcoding arrangement in a session initiation
CN1514562A (zh) * 2003-05-15 2004-07-21 华为技术有限公司 一种码分多址系统中实现回铃音业务的方法
CN1604589A (zh) * 2004-10-28 2005-04-06 无锡三通科技有限公司 支持会话启动协议穿越的防火墙实现方法

Family Cites Families (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CA2348242A1 (en) * 2001-05-23 2002-11-23 Mediatrix Telecom Inc. Multi-protocol call manager
US7509425B1 (en) * 2002-01-15 2009-03-24 Dynamicsoft, Inc. Establishing and modifying network signaling protocols
US7366780B2 (en) * 2002-12-31 2008-04-29 Motorola, Inc. System and method for controlling and managing sessions between endpoints in a communications system
US7230930B2 (en) * 2004-03-23 2007-06-12 Motorola, Inc. Mode shifting communications system and method
US7529845B2 (en) * 2004-09-15 2009-05-05 Nokia Corporation Compressing, filtering, and transmitting of protocol messages via a protocol-aware intermediary node
US7664236B2 (en) * 2005-04-15 2010-02-16 Radziewicz Clifford J Forked-call ringback replacement system

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2003032585A1 (en) * 2001-10-09 2003-04-17 Nokia Corporation Transcoding arrangement in a session initiation
CN1514562A (zh) * 2003-05-15 2004-07-21 华为技术有限公司 一种码分多址系统中实现回铃音业务的方法
CN1604589A (zh) * 2004-10-28 2005-04-06 无锡三通科技有限公司 支持会话启动协议穿越的防火墙实现方法

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2009026759A1 (fr) * 2007-08-30 2009-03-05 Zte Corporation Procédé et système pour le service de plusieurs terminaux avec un seul numéro sonnant simultanément

Also Published As

Publication number Publication date
CN101180866B (zh) 2010-11-10
US20080240375A1 (en) 2008-10-02
CN101180866A (zh) 2008-05-14

Similar Documents

Publication Publication Date Title
WO2006122446A1 (fr) Methode de traitement de tonalites multiples de rappel dans une application de service vocal reposant sur sip fork
US8447019B2 (en) Method and system for providing call screening in a packet-switched network
US6771639B1 (en) Providing announcement information in requests to establish interactive call sessions
US7738644B2 (en) Methods, systems, and computer program products for flexible call jumping
US8949442B2 (en) Facilitating early media in a communications system
BRPI0614428A2 (pt) associação de uma chamada telefÈnica com um diálogo baseado em um protocolo de computador tal como sip
WO2007003093A1 (fr) Procédé de réalisation d'une communication de session entre la partie appelante et la partie appelée
CA2557089A1 (en) Method and apparatus for providing internet protocol call transfer in communication networks
WO2008064580A1 (fr) Procédé, système et serveur d'application pour éviter la diaphonie de signal de rappel couleur
WO2009086758A1 (zh) 一种在线彩铃或彩像业务的实现方法
WO2007093116A1 (fr) Procédé et système de fourniture de service de simulation et entité adaptative de signalisation d'accès
KR101069530B1 (ko) 차세대통신망에서 착신 통화로 제어 장치 및 그 방법과, 그를 이용한 멀티미디어 정보 서비스 시스템 및 그 방법
WO2013040832A1 (zh) 在总机业务中实现话务员插入通话的方法、装置和系统
WO2012151799A1 (zh) 一种在点击拨号业务中实现同振群呼的方法和系统
WO2013082894A1 (zh) 一种话务员呼叫转接的方法和总机业务应用服务器
WO2012003718A1 (zh) 一种实现随意播放彩铃铃音的方法和系统
CN100401692C (zh) 分组语音网络的监听方法
CN101764896B (zh) 多方会议中增加或者拆除会议参与方的方法、设备及系统
WO2009135375A1 (zh) 实现单对话彩铃业务的呼叫建立方法
WO2013029389A1 (zh) 一种ctd呼叫业务中彩铃业务实现方法及装置
WO2008049371A1 (fr) Procédé et système pour transférer un événement de service
JP2005159431A (ja) シグナリング方法並びにサーバ及びゲートウェイ端末
US20090003541A1 (en) Network-hosted server, a method of monitoring a call connected thereto and a network-hosted voicemail server
US20090296912A1 (en) Method and apparatus for forwarding of fax calls to a messaging service
WO2017054498A1 (zh) 一种在总机业务中实现用户替换的方法及装置

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application
WWE Wipo information: entry into national phase

Ref document number: 200580049830.2

Country of ref document: CN

NENP Non-entry into the national phase

Ref country code: DE

WWW Wipo information: withdrawn in national office

Country of ref document: DE

NENP Non-entry into the national phase

Ref country code: RU

WWW Wipo information: withdrawn in national office

Country of ref document: RU

WWE Wipo information: entry into national phase

Ref document number: 11914467

Country of ref document: US

122 Ep: pct application non-entry in european phase

Ref document number: 05752015

Country of ref document: EP

Kind code of ref document: A1