WO2007095837A1 - Procédé, dispositif et système de réception par un terminal d'un message de confirmation - Google Patents

Procédé, dispositif et système de réception par un terminal d'un message de confirmation Download PDF

Info

Publication number
WO2007095837A1
WO2007095837A1 PCT/CN2007/000424 CN2007000424W WO2007095837A1 WO 2007095837 A1 WO2007095837 A1 WO 2007095837A1 CN 2007000424 W CN2007000424 W CN 2007000424W WO 2007095837 A1 WO2007095837 A1 WO 2007095837A1
Authority
WO
WIPO (PCT)
Prior art keywords
terminal
request message
message
processing entity
specified resource
Prior art date
Application number
PCT/CN2007/000424
Other languages
English (en)
French (fr)
Inventor
Hao Lai
Xiao Wang
Original Assignee
Huawei Technologies 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 Huawei Technologies Co., Ltd. filed Critical Huawei Technologies Co., Ltd.
Publication of WO2007095837A1 publication Critical patent/WO2007095837A1/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/1083—In-session procedures

Definitions

  • the present invention relates to the field of communications technologies, and in particular, to a communication method based on a session initiation protocol, and in particular, to a method, an apparatus, and a system for implementing a negotiation message receiving terminal.
  • Session Initiation Protocol is one of the multimedia communication system framework protocols developed by the IETF. It is a text-based application layer control protocol, independent of the underlying protocol, used to establish, modify, and terminate. Two or multiple multimedia sessions on the IP network.
  • the SIP protocol introduces a REFER method for implementing a function of instructing a receiver to access a specified resource, and provides a mechanism for instructing the other party to initiate a session to a third party according to the provided information, for use in applications such as call deflection.
  • the REFER receiver sends a REFER message requesting the receiver to access the resources indicated in the REFER message, such as initiating a call to a third party; the REFER request also implicitly creates a subscription.
  • the REFER receiver receives the REFER request and returns 200/202 OK;
  • the REFER receiver sends a NOTIFY message according to the event notification framework, carrying the content information of the subscribed resource status;
  • the REFER sender After receiving the NOTIFY message, the REFER sender sends a 200 O response to the receiver, indicating that the NOTIFY message was successfully received.
  • the REFER receiver acts according to the instructions in the REFER method, such as initiating a call (INVITE). This action may also occur when returning a 200/202 OK to the REFER sender.
  • INVITE initiating a call
  • This action may also occur when returning a 200/202 OK to the REFER sender.
  • Checking and generating a forked network entity which is referred to as a forked processing entity, in the SIP domain, may be a REFER receiver proxy server, when a parallel fork occurs (parallel forked fork processing entity simultaneously sends a REFER message to each User terminal), there may be more than one terminal of the user's multiple terminals accepting the request to return 200/202 OK, and according to the indication action in the REFER method, such as initiating the INVITE, but the fork processing entity only accepts the obtained from the receiving terminal.
  • a successful response Since there is no mechanism to invalidate the successful response of other terminals, this causes the operation of the terminal response to be uncontrollable and causes waste of network resources. Therefore, it needs to be improved and developed. Summary of the invention
  • the embodiment of the invention provides a method, a device and a system for implementing a negotiation message receiving terminal, which are used for eliminating the fork of the REFER message.
  • An embodiment of the present invention provides a method for implementing a negotiation message receiving terminal, where a requesting message originating party and each terminal are instructed to access a specified resource, and a terminal processing entity is configured to perform the following steps: The message initiator sends a request message indicating that the specified resource is accessed. ;
  • the branching processing entity forwards the request message indicating the access to the specified resource received by the message originator to each terminal;
  • the fork processing entity receives the response of each user terminal and selects the user terminal to access the designated resource according to a predetermined policy.
  • the embodiment of the present invention is a device for receiving a negotiation message receiving terminal, including:
  • a sending unit configured to send, to each terminal, the request message indicating that the specified resource is accessed; the receiving unit receives and collects response information of each user terminal;
  • a selecting unit configured to receive, according to a pre-policy, the user terminal that indicates the request message for accessing the specified resource
  • the sending unit After the selecting unit determines the user terminal, the sending unit sends a request message indicating access to the designated resource to the selected terminal.
  • An embodiment of the present invention provides a system for negotiating a message receiving terminal, where the system is provided with A device for negotiating a message receiving terminal, the device comprising:
  • a sending unit configured to send, to each terminal, the request message indicating that the specified resource is accessed; the receiving unit receives and collects response information of each user terminal;
  • a selecting unit configured to receive, according to a predetermined policy, a user terminal that receives the request message for accessing a specified resource
  • the sending unit After the selecting unit determines the user terminal, the sending unit sends a request message indicating access to the specified resource to the selected terminal;
  • the apparatus selects a terminal that receives a request message indicating access to the designated resource according to a predetermined policy, and transmits a request message indicating access to the designated resource to the selected terminal.
  • a method for implementing a negotiation message receiving terminal is provided.
  • the bifurcation processing entity Based on the session initiation protocol domain, the bifurcation processing entity sends a notification to the terminal to access the specified resource. Requesting a message, and collecting a response of each user terminal, selecting a terminal that receives a request message indicating access to the specified resource according to a predetermined policy, thereby realizing the problem of eliminating the uncontrollable operation of the terminal in the case of a multi-user terminal in which parallel bifurcation occurs, and enhancing The stability of the system.
  • FIG. 2 is a flow chart of a method according to a first embodiment of the present invention.
  • FIG. 3 is a flow chart of a method according to a second embodiment of the present invention.
  • FIG. 4 is a flow chart of a method according to a third embodiment of the present invention.
  • Figure 5 is a flowchart of a method according to a fourth embodiment of the present invention.
  • FIG. 6 is a flow chart of a method according to a fifth embodiment of the present invention.
  • Figure 7 is a flowchart of a method according to a sixth embodiment of the present invention.
  • FIG. 8 is a schematic structural diagram of a device for negotiating a message receiving terminal according to an embodiment of the present invention. detailed description
  • the method for implementing the session initiation protocol domain negotiation message receiving terminal of the present invention can only receive the successful response to NOTIFY sent by the fork processing entity at the REFER receiving terminal. After that, the action indicated in the REFER is performed, such as sending an INVITE, etc., and if the failure response is not received or received, the action indicated in the REFER is not performed.
  • a fork processing entity is set in the system, and the REFER initiator sends a REFER message to the terminal 1 and the terminal 2 through the fork processing entity, and the steps include:
  • the REFER initiator sends a REFER message.
  • the terminal 1 returns a successful response 200 O and sends a NOTIFY message carrying the content information of the subscribed resource status.
  • Terminal 2 also returns a successful response and
  • the branch processing entity selects and accepts the response of the terminal 1 and NOTIFY, and sends the response and NOTIFY to the REFER initiator.
  • the fork processing entity sends 200 O: to the terminal 1.
  • the fork processing entity sends a 400 Bad Request to the terminal 2, and cancels the subscription and REFER request to the terminal.
  • the terminal 1 After receiving the 200 OK response sent by the fork processing entity, the terminal 1 performs an action indicated in the REFER, for example, sending an INVITE message.
  • the method of the present invention may first use other request messages, such as an OPTIONS message, to select a terminal that receives the REFER request, and then send the REFER message to the selected terminal.
  • request messages such as an OPTIONS message
  • the REFER message is only one embodiment of the request message indicating access to the specified resource, and those skilled in the art can obviously implement other functions by using other related messages.
  • the method of the present invention is that when the bifurcation processing entity receives the REFER message, it determines that the receiver has multiple terminals and parallel bifurcation occurs, and the fork processing entity sends a request message to each terminal, and each terminal returns its response.
  • the fork processing entity collects the response of each terminal, selects a terminal that receives the REFER message according to a certain policy; and may also pass the list of responding terminals
  • the redirect message is sent to the REFER sender, and the sender selects the terminal that receives the REFER message.
  • the bifurcation processing entity sends the request message to each terminal and selects the receiving terminal in three ways: First, the bifurcation processing entity simultaneously sends a request message to each terminal, and the request message carries an indication for querying the terminal information, and the query terminal supports the The method and the terminal capability information such as the current priority index of the terminal, according to a certain policy, for example, selecting a terminal that supports the REFER method and/or a priority index is used as the receiving terminal; second, the fork processing entity simultaneously sends a request message to each terminal, The first successfully responding terminal is selected as the receiving terminal.
  • the third is that the branching processing entity sequentially sends a request message to each terminal, and the first terminal that returns a successful response serves as the receiving terminal.
  • the branching processing entity simultaneously sends an OPTIONS-capability query request to each terminal, queries the method supported by the terminal, and the priority index of the terminal before, and directly selects the REFER method according to the result returned by the terminal and the priority index.
  • the larger terminal acts as the terminal that receives the REFER message.
  • the process of this embodiment includes the steps of:
  • the REFER initiator sends a REFER message, where the message carries an identifier of whether the entity needs to query the terminal to query the capability information of the terminal. Whether the bifurcation processing entity queries the terminal capability indication is carried by the fork-query parameter of the extended header field Fork-query or the extended Request-Disposition header field. When the fork-query parameter value is TRUE, it indicates that the bifurcation processing entity needs to query the terminal capability information.
  • the related parameters carried in the REFER message are as follows:
  • the bifurcation processing entity sends an OPTIONS request to the terminal 1, and queries the terminal capability information.
  • the information to be queried includes the method supported by the terminal supported by the terminal and the priority index (q value) of the terminal.
  • the bifurcation processing entity sends an OPTIONS request to the terminal 2 to query the terminal capability information, and the message example is the same as step 2.
  • the terminal 1 returns 200 OK, and carries the information of the terminal 1, including the REFER supported by the terminal, the contact address of the terminal, mike@pcl. example.com, and the current priority index (q value) 0.5.
  • terminal 1 returns 200 OK, carrying information of terminal 2, including terminal support
  • the branching processing entity selects the terminal 1 that supports the REFER method and has a large priority index as the terminal that receives the REFER message, and sends the REFER message to the terminal.
  • the Request URI in the REFER message fills in the contact address of the terminal 1, and the related parameters are as follows:
  • the bifurcation processing entity simultaneously sends an OPTIONS query request to each terminal, and selects the first successfully responding terminal as the terminal that receives the REFER message.
  • the specific implementation steps are shown in FIG. 4, including Steps:
  • the REFER initiator sends a REFER message.
  • the terminal 1 returns 200 OK and carries the contact address of the terminal.
  • terminal 2 returns 200 OK, and carries the contact address of the terminal
  • the bifurcation processing entity first receives the feedback of the terminal 1, and uses the terminal 1 as a terminal that receives the REFER message, and sends a REFER message to the terminal.
  • the Request U I in the REFER message fills in the contact address of the terminal 1, and the related parameters are as follows:
  • a third mode of the method of the present invention is that the bifurcation processing entity sends a query request to each terminal in sequence, and the first terminal that returns a successful response serves as the receiving terminal, and the bifurcation processing entity directly sends an RBFER message to the terminal.
  • the specific implementation steps are shown in Figure 5:
  • the REFER initiator sends a REFER message.
  • the fork processing entity sends an OPTIONS request to the terminal 1.
  • Terminal 2 returns 200 OK and carries the contact address of the terminal:
  • the fork processing entity continues to send an OPTIONS request to the terminal 2.
  • terminal 2 returns 200 OK, and carries the contact address of the terminal
  • the fork processing entity sends the REFER message to the terminal as the terminal receiving the REFER message because the terminal 1 successfully responds.
  • the Request URI in the REFER message fills in the contact address of the terminal 1.
  • the method of the present invention can also enable the fork processing entity to send to each terminal simultaneously or sequentially
  • the OPTIONS request collects the result of the terminal response according to a certain policy, for example, starts a timer, and the terminal that responds before the timer expires serves as the terminal that receives the REFER message, and sends the response terminal list to the REFER sender through the redirect message.
  • the terminal that receives the REFER message is selected by the sender.
  • the specific implementation manner includes the steps shown in FIG. 6:
  • the REFER initiator sends a REFER message, where the message carries an identifier of whether the bifurcation processing entity needs to query the terminal capability information; whether the bifurcation processing entity queries the terminal capability indication by extending the header i or the Fork-query or the extended Request-Disposition header i Or the parameter fork-query carries, and the fork-query parameter value is TRUE, which indicates that the entity processing terminal capability information needs to be forked.
  • the related parameters carried in the REFER message are as follows:
  • the branch processing entity sends an OPTIONS request to the terminal 1, and queries the terminal information.
  • the information to be queried includes the method supported by the terminal supported by the terminal and the priority index (q value) of the terminal.
  • Terminal-Info q-value ⁇ true
  • the fork processing entity sends an OPTIONS request to the terminal 2 to query the terminal capability information.
  • the message example is the same as step 2. '
  • the terminal 1 returns 200 OK, and carries the information of the terminal 1, including the REFER supported by the terminal, the contact address of the terminal mike@pcl.example.com, and the current priority index (q value) 0.5.
  • the terminal 1 returns 200 OK, and carries the information of the terminal 2, including the terminal support. REFER and other methods, the contact address of the terminal is mike@pc2.example.com and the current priority index (q value) is 0.3.
  • the branch processing entity sends the terminal capability information returned by each terminal to the REFER sender through the 302 redirection message, and the REFER sender selects the terminal that receives the REFER message.
  • Each terminal capability information is carried in the Contact header field list in the 302 message.
  • An example of the related content in the 302 message is as follows:
  • the REFER sender selects the terminal 1 as the terminal that receives the REFER message according to the received receiver terminal information. And send the REFER message directly to the terminal.
  • the request UI of the REFER message carries the public address of the receiver, and carries the contact address of the terminal 1 through the extended contact-addr parameter.
  • the fork processing entity After receiving the REFER message, the fork processing entity checks the validity of the contact address, and then checks the validity of the contact address. The REFER message is sent directly to the terminal 1.
  • the method of the present invention judges the receiver multi-terminal through the REFER initiator/bifurcation processing entity and parallel bifurcation occurs, and then The terminal sends a terminal capability inquiry message, and each terminal returns its own response.
  • the REFER Initiator/Branching Processing Entity Bifurcation Processing Entity collects the response of each terminal, selects the terminal that receives the REFER message according to a certain policy, and then sends a REFER request to the terminal.
  • the bifurcation processing entity may send the request message to each terminal and select the receiving terminal.
  • the method may be that the bifurcation processing entity simultaneously sends a request message to each terminal, and the request message carries an indication for querying the terminal information. Querying the terminal capability information such as the method supported by the terminal and the current priority index of the terminal, and selecting a terminal supporting the REFER method and/or a higher priority index as the receiving terminal according to a certain strategy; The request message is sent to each terminal, and the terminal that selects the first response is selected as the receiving terminal.
  • the third method is that the branching processing entity sequentially sends a request message to each terminal, and the first terminal that returns a successful response serves as the receiving terminal.
  • the implementation flow of the first method is shown in FIG. 7. The implementation flow of the other two methods can be obtained by referring to the embodiment of the first method and the corresponding embodiment in the first case, and details are not described herein again.
  • the specific implementation process includes the following steps:
  • the S70K fork processing entity sends an OPTIONS request to the terminal 1 to query the terminal information.
  • the information to be queried includes the method supported by the terminal supported by the terminal and the priority index (q value) of the terminal.
  • the bifurcation processing entity sends an OPTIONS request to the terminal 2 to query the terminal capability information.
  • the message example is the same as step 2.
  • the terminal 1 returns 200 OK, and carries the information of the terminal 1, including the terminal support.
  • the terminal 1 returns 200 OK, and carries the information of the terminal 2, including a method such as a REFER supported by the terminal, a contact address of the terminal mike@pc2.example.com, and a current priority index (q value) of 0.3.
  • the bifurcation processing entity selects the terminal 1 that supports the REFER method and has a large priority index as the terminal that receives the REFER message, and sends the REFER message to the terminal.
  • the Request URI in the REFER message fills in the contact address of the terminal 1.
  • an apparatus 800 for receiving a message receiving terminal is provided. As shown in FIG. 8, the method includes:
  • the sending unit 801 sends the request message indicating that the specified resource is accessed to each terminal.
  • the receiving unit 802 receives and collects response information of each user terminal.
  • the selecting unit 803 is configured to select, according to a predetermined policy, a user terminal that receives the request message indicating that the specified resource is accessed;
  • the transmitting unit 801 transmits a request message indicating access to the designated resource to the selected terminal.
  • the predetermined strategy includes -.
  • the device sends a query request message to each user terminal, and carries an indication for querying the terminal information capability, obtains a method supported by the terminal, and selects a request message method and/or a priority index that supports the indication of accessing the specified resource.
  • a large terminal acts as a receiving terminal.
  • a system for negotiating a message receiving terminal comprising the foregoing apparatus for negotiating a message receiving terminal, when the parallel branching occurs, the apparatus selects a terminal that receives a request message indicating access to a specified resource according to a predetermined policy, and then instructs access to the specified resource.
  • the request message is sent to the selected terminal.
  • the bifurcation processing entity may first pass through when the bifurcation occurs.
  • Each terminal sends a request for querying terminal information to obtain capability information of each user terminal, and then the terminal that receives the request message is selected by the fork processing entity or by the original request message initiator, and then the initial request message is sent to the designated terminal.

Landscapes

  • Engineering & Computer Science (AREA)
  • Business, Economics & Management (AREA)
  • General Business, Economics & Management (AREA)
  • Multimedia (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Mobile Radio Communication Systems (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Telephonic Communication Services (AREA)

Description

一种协商消息接收终端的实现方法、 装置及系统
本申请要求于 2006 年 02 月 22 日提交中国专利局、 申请号为 2006画 3974.5、发明名称为 "一种会话发起协议域协商消息接收终端的 实现方法" 的中国专利申请的优先权， 其全部内容通过引用结合在本申 请中。
技术领域
本发明涉及通信技术领域， 尤其涉及基于会话发起协议的通信方法， 具体地说， 涉及一种协商消息接收终端的实现方法、 装置及系统。' 背景技术
现有技术中，会话发起协议 ( SIP , Session Initiation Protocol )是 IETF 制定的多媒体通信系统框架协议之一， 它是一个基于文本的应用层控 制协议， 独立于底层协议， 用于建立、 修改和终止 IP网上的双方或多 方多媒体会话。
SIP协议为实现指示接收方访问指定资源的功能引入 REFER方法， 提供了一种指示对方依据所提供的信息向第三方发起会话的机制， 用于 呼叫偏转等应用中。
一个 REFER的筒单流程如图 1所示， 其包括步骤：
( 1 ) REFER发起方向 REFER接收方发送 REFER消息，请求接收方访 问 REFER消息中指示的资源， 如发起一个到第三方的呼叫； REFER请 求还会隐性创建一个订阅。
( 2 ) REFER接收方接收 REFER请求,返回 200/202 OK;
( 3 ) REFER接收方根据事件通知框架， 发送一个 NOTIFY (通知） 消息， 携带订阅的资源状态的内容信息；
( 4 ) REFER发送方收到 NOTIFY消息后，向接收方发送一个 200 O 响应， 表示成功接收了 NOTIFY消息。
( 5 ) REFER接收方根据 REFER方法中的指示动作， 如发起呼叫 ( INVITE )。 这个动作的发生也可能是在向 REFER发送方返回 200/202 OK时。 上述 REFER流程中， 在没有建立会话的情况下， 如果 REFER接收 方用户多终端 （用户有多个注册终端共享一个公有标识）， 则会在检查和 产生分叉（ forking )的网络实体上发生分叉。检查和产生分叉的网络实体， 后续简称分叉处理实体， 在 SIP域中可以是 REFER接收方代理服务器， 当发生并行分叉（并行分叉指分叉处理实体同时把 REFER消息发给每个 用户终端） 时， 用户的多个终端中可能有超过一个的终端接受请求返回 200/202 OK, 并根据 REFER方法中的指示动作， 如发起 INVITE, 但分 叉处理实体只接受从接收终端获得的一个成功响应。 由于没有机制使其 他终端的成功响应无效， 这样就造成了终端响应的操作不可控， 并造成 网络资源的浪费。 因此， 有待于改进和发展。 发明内容
本发明实施例提供一种协商消息接收终端的实现方法、 装置及系统， 用于消除 REFER消息的分叉。
本发明实施例提供一种协商消息接收终端的实现方法， 在指示访问 指定资源的请求消息发起方和各终端之间设置分叉处理实体， 包括步骤： 消息发起方发送指示访问指定资源的请求消息；
当有多个用户终端需要接收所述清求消息且发生并行分叉时， 所述 分叉处理实体将从消息发起方接收到的所述指示访问指定资源的请求消 息转发给各终端；
所述分叉处理实体接收各用户终端的响应， 并根据预定策略选择用 户终端访问指定资源。
本发明实施例 ^是供一种协商消息接收终端的装置， 包括：
发送单元， 向各终端发送所述指示访问指定资源的请求消息； 接收单元， 接收并收集各用户终端的响应信息；
选择单元， 根据预 策略选择接收所述指示访问指定资源的请求消 息的用户终端；
在所述选择单元确定用户终端后， 所述发送单元将指示访问指定资源的 请求消息发送给选定的终端。
本发明实施例提供一种协商消息接收终端的系统， 该系统中设置有 协商消息接收终端的装置， 该装置包括：
发送单元， 向各终端发送所述指示访问指定资源的请求消息； 接收单元， 接收并收集各用户终端的响应信息；
选择单元， 根据预定策略选择接收所述指示访问指定资源的请求消 息的用户终端；
在所述选择单元确定用户终端后， 所述发送单元将指示访问指定资 源的请求消息发送给选定的终端；
在发生并行分叉时， 所述装置根据预定策略选择接收指示访问指定 资源的请求消息的终端， 再将指示访问指定资源的请求消息发送给选定 的终端。
本发明实施例提供的方案中， 所提供的一种协商消息接收终端的实 现方法， 基于会话发起协议域， 通过设置分叉处理实体， 所述分叉处理 实体向各终端发送指示访问指定资源的请求消息， 并收集各用户终端的 响应， 根据预定策略选择接收指示访问指定资源的请求消息的终端， 从 而实现了在发生并行分叉的多用户终端情况下的消除终端操作不可控的 问题， 增强了系统的稳定性。
附图说明
图 1为现有技术的 REFER流程示意图；
图 2为本发明第一实施例的方法流程图；
图 3为本发明第二实施例的方法流程图；
图 4为本发明第三实施例的方法流程图；
图 5为本发明第四实施例的方法流程图；
图 6为本发明第五实施例的方法流程图；
图 7为本发明第六实施例的方法流程图；
图 8为本发明实施例中的协商消息接收终端的装置结构示意图。 具体实施方式
以下结合附图， 将对本发明的各较佳实施例进行更为详细的说明。 本发明的会话发起协议域协商消息接收终端的实现方法' 可以在 REFER接收终端只有收到分叉处理实体发送的对 NOTIFY的成功响应之 后， 才进行 REFER中指示的动作， 如发送 INVITE等, 而如果没有收到 或收到失败响应时则不进行 REFER中指示的动作。该实施例如图 2所示， 系统中设置一分叉处理实体， REFER发起方通过该分叉处理实体向所述 终端 1和终端 2发送 REFER消息， 其步骤包括：
S201、 REFER发起方发送 REFER消息；
S202〜S203、接收方用户多终端且发生并行分叉，分叉处理实体向各 终端同时发送 REFER请求。
S204- S207、 终端 1返回成功响应 200 O , 并发送一个 NOTIFY消 息， 携带订阅的资源状态的内容信息。 终端 2同样返回成功响应及
NOTIFY消息。
S208〜 S209、 所述分叉处理实体选择接受终端 1的响应和 NOTIFY, 并把该响应和 NOTIFY发送给 REFER发起方。
S210、 分叉处理实体向终端 1发送 200 O：。
S211、 分叉处理实体向终端 2发送 400 Bad Request, 取消向该终端 的订阅和 REFER请求。
S212、终端 1收到分叉处理实体发送的 200 OK响应后，进行 REFER 中指示的动作， 如发送 INVITE消息。
本发明方法在发生并行分叉时， 还可以先使用其他请求消息， 如 OPTIONS消息， 选择接收 REFER请求的终端， 之后再把 REFER消息发 送给选中的终端。 该实施例方案中包括两种情况， 一是分叉处理实体与 REFER发送方为不同的网络实体， 二是分叉处理实体与 REFER发送方 为同一个网络实体。
可以理解的是， 本发明实施例的技术方案中， REFER消息只是指示 访问指定资源的请求消息的一个实施例而已， 本领域技术人员显然可以 采用其他相关的消息来实现该功能。
对于情况一， 本发明方法是分叉处理实体在接收 REFER消息时， 判 断接收方多终端且会发生并行分叉， 则分叉处理实体向各个终端发送请 求消息， 各终端返回各自的响应， 分叉处理实体收集各终端的响应， 根 据某种策略选择接收 REFER消息的终端； 也可以把响应的终端列表通过 重定向消息发给 REFER发送方 , 由发送方选择接收 REFER消息的终端。 所述分叉处理实体向各终端发送请求消息并选择接收终端可以采用 三种方式： 一是分叉处理实体同时向各个终端发送请求消息， 请求消息中 携带查询终端信息的指示， 查询终端支持的方法和终端当前的优先级指数 等终端能力信息， 根据某种策略例如选择支持 REFER方法和 /或优先级指 数较大的终端作为接收终端； 二是分叉处理实体同时向各个终端发送请求 消息， 选择第一个成功响应的终端作为接收终端； 三是所述分叉处理实体 顺序向各个终端发送请求消息， 第一个返回成功响应的终端作为接收终 端。
具体的说，所述分叉处理实体同时向各个终端发送 OPTIONS即能力 查询请求， 查询终端支持的方法和终端当—前的优先级指数， 并根据终端 返回结果直接选择支持 REFER方法且优先级指数较大的终端做为接收 REFER消息的终端。
如图 3所示， 该实施例的流程包括步骤：
S301、 REFER发起方发送 REFER消息， 消息中携带是否需要分叉 处理实体查询终端能力信息的标识。 分叉处理实体是否查询终端能力指 示通过扩展头域 Fork-query或扩展 Request-Disposition头域的参数 fork-query携带， fork-query参数值为 TRUE时表示需要分叉处理实体查 询终端能力信息。 REFER消息携带的相关参数如下：
REFER: sip: mike@example.com
Request-Disposition: fork-directive=fork; fork-query=True
或'
REFER: sip: mike@example.com
Fork-query: fork-query=True
S302、分叉处理实体向终端 1发送 OPTIONS请求， 查询终端能力信 息。 查询的信息包括终端支持的终端支持的方法、 终端的优先级指数（q 值）。 OPTIONS消息中携带扩展的 Terminal-Info头域， 用来标识请求终 端的优先级指数 ( q-value=true )。
OPTIONS消息携带的相关参数示例如下： Terminal-Info： q-value=true
5303、分叉处理实体向终端 2发送 OPTIONS请求， 查询其终端能力 信息， 消息示例同步骤 2。
5304、 终端 1返回 200 OK, 携带终端 1的信息， 包括终端支持的 REFER等方法、终端的联系地址 mike@pcl. example .com和当前的优先级 指数（q值） 0.5。
200 OK消息中携带的相关参数示例如下：
Contact: mike@pcl.example.com; q=0.5
Allow: REFER, INVITE, OPTIONS, BYE, CANCEL S305、 终端 1返回 200 OK, 携带终端 2的信息， 包括终端支持的
REFER等方法、终端的联系地址 mike@pc2.example.com和当前的优先级 指数（q值） 0.3。
200 OK消息中携带的相关参数示例如下：
Contact: mike@pc2.example.com; q=0.3
Allow: REFER, INVITE, OPTIONS, BYE, CANCEL
S306> 分叉处理实体选择支持 REFER方法、 优先级指数大的终端 1 作为接收 REFER消息的终端， 把 REFER消息发给该终端。 REFER消息 中的 Request URI填写的是终端 1的联系地址， 相关参数示例如下：
REFER: sip: mike@pcl.example.com
终端 1接收 REFER消息之后的处理与现有技术相同 , 在此不再详细 描述。
本发明的第二实施例中， 所述分叉处理实体同时向各个终端发送 OPTIONS查询请求， 选择第一个成功响应的终端做为接收 REFER消息 的终端， 具体实施步骤见图 4所示， 包括步骤：
S401、 REFER发起方发送 REFER消息。
S402 ~ S403、 分叉处理实体向终端 1、 终端 2同时发送 OPTIONS请 求。
S404、 终端 1返回 200 OK, 并携带终端的联系地址
mike@pcl.example.com。 200 OK消息中携带的相关参数示例如下：
Contact: mike@pcl.example.com
5405、 终端 2返回 200 OK, 并携带终端的联系地址
mike@pc2.example.com。
200 OK消息中携带的相关参数示例如下：
Contact: mike @pc2. example . com
5406、 分叉处理实体因为首先收到终端 1的反馈， 把终端 1作为接 收 REFER消息的终端， 把 REFER消息发给该终端。 REFER消息中的 Request U I填写的是终端 1的联系地址， 相关参数示例如下：
REFER: sip: mike@pcl.example.com
本发明方法的第三种方式是， 分叉处理实体顺序向各个终端发送查 询请求， 第一个返回成功响应的终端作为接收终端， 分叉处理实体直接 发 RBFER消息发送给该终端。 该具体实施步骤参见如图 5所示：
S501、 REFER发起方发送 REFER消息。
5502、 分叉处理实体向终端 1发送 OPTIONS请求。
5503、 终端 2返回 200 OK, 并携带终端的联系地址：
mike@pcl , example.com。
200 OK消息中携带的相关参数示例如下：
Contact: mike@pcl.example.com
5504、 分叉处理实体继续向终端 2发送 OPTIONS请求。
5505、 终端 2返回 200 OK, 并携带终端的联系地址
mike@pc2. example . com。
200 OK消息中携带的相关参数示例如下：
Contact: mike@pc2. example. com
5506、 分叉处理实体因为终端 1成功响应， 所以把终端 1作为接收 REFER消息的终端，把 REFER消息发给该终端。 REFER消息中的 Request URI填写的是终端 1的联系地址， 相关参数示例如下：
REFER: sip: mike@pcl.example.com
本发明方法还可以使分叉处理实体同时或顺序向各个终端发送 OPTIONS请求，根据某种策略收集终端响应的结果，例如启动一定时器， 在定时器超时前响应的终端做为接收 REFER消息的终端， 并将响应终端 列表通过重定向消息发给 REFER发送方， 由发送方选择接收 REFER消 息的终端， 该具体实施方式如图 6所示包括步骤：
S60 所述 REFER发起方发送 REFER消息， 消息中携带是否需要 分叉处理实体查询终端能力信息的标识； 分叉处理实体是否查询终端能 力指示通过扩展头 i或 Fork-query或扩展 Request-Disposition头 i或的参数 fork-query携带， fork-query参数值为 TRUE表示需要分叉处理实体查询 终端能力信息。 REFER消息携带的相关参数如下：
REFER: sip: mike@example.com
Request-Disposition: fork-directive=fork; fork-query=True
REFER: sip: mike@example.com
Fork-query: fork-query=True
S602、 所述分叉处理实体向终端 1发送 OPTIONS请求， 查询终端信 息。 查询的信息包括终端支持的终端支持的方法、 终端的优先级指数（q 值）。 OPTIONS消息中携带扩展的 Terminal-Info头域， 用来标识请求终 端的优先级指数 ( q-value=true )。
OPTIONS消息携带的相关参数示例如下：
Terminal-Info： q-value^true
5603、分叉处理实体向终端 2发送 OPTIONS请求， 查询终端能力信 息。 消息示例同步骤 2。 '
5604、 终端 1返回 200 OK, 携带终端 1的信息， 包括终端支持的 REFER等方法、终端的联系地址 mike@pcl.example.com和当前的优先级 指数（q值） 0.5。
200 OK消息中携带的相关参数示例如下:
Contact: mike@pcl.example.com; q=0.5
Allow: REFER, INVITE, OPTIONS, BYE, CANCEL
5605、 终端 1返回 200 OK, 携带终端 2的信息， 包括终端支持的 REFER等方法、终端的联系地址 mike@pc2.example.com和当前的优先级 指数（q值） 0.3。
200 OK消息中携带的相关参数示例如下：
Contact: mike@pc2.example.com; q=0.3
Allow: REFER, INVITE, OPTIONS, BYE, CANCEL
5606、 分叉处理实体把各终端返回的终端能力信息， 通过 302重定 向消息发给 REFER发送方，由 REFER发送方选择接收 REFER消息的终 端。 各终端能力信息在 302消息中的 Contact头域列表中携带。 302消息 中的相关内容示例如下：
Contact: <si ： mike@pc 1. example. com>; q=0.5； expires=3600
<sip :mike@pc2. example .com>; q=0.3； expires=3600
5607、 REFER发送方根据收到的接收方终端信息， 选择终端 1做为 接收 REFER消息的终端。 并把 REFER消息直接发给该终端。 在 REFER 消息的 Request U I中除了携带接收方的公有用户标识， 还通过扩展的 contact-addr参数携带终端 1的联系地址，分叉处理实体收到 REFER消息 后， 检查联系地址的合法性， 之后把 REFER消息直接发给终端 1。
REFER: sip: mike@.example.com; contact-addr="
mike@pc 1.example.com"
对于情况二分叉处理实体与 REFER发送方为同一个网络实体时， 本 发明方法通过 REFER发起方 /分叉处理实体判断接收方多终端且会发生 并行分叉 , 则在发送 REFER之前先向各个终端发送终端能力查询消息， 各终端返回各自的响应。 REFER发起方 /分叉处理实体分叉处理实体收集 各终端的响应， 根据某种策略选择接收 REFER消息的终端， 然后向该终 端发送 REFER请求。
与情况一类似， 分叉处理实体向各终端发送请求消息并选择接收终 端也可以有三种方式， 方式一是分叉处理实体同时向各个终端发送请求 消息， 请求消息中携带查询终端信息的指示， 查询终端支持的方法和终 端当前的优先级指数等终端能力信息 , 根据某种策略选择支持 REFER方 法和 /或优先级指数较大的终端作为接收终端； 方式二是分叉处理实体同 时向各个终端发送请求消息， 选择第一个响应的终端作为接收终端； 方 式三是分叉处理实体顺序向各个终端发送请求消息， 第一个返回成功响 应的终端作为接收终端。 如图 7所示给出方式一的实施流程， 其他两种 方式的实施流程可以参考方式一的实施例以及情况一中的对应实施例得 到， 在此不再赘述。
如图 7所示， 具体实施流程包括步骤：
S70K 分叉处理实体向终端 1发送 OPTIONS请求， 查询终端信息。 查询的信息包括终端支持的终端支持的方法、终端的优先级指数（q值）。 OPTIONS消息中携带扩展的 Terminal-Info头域， 用来标识请求终端的优 先级指数 ( q-value=true )。
OPTIONS消息携带的相关参数示例如下：
Terminal-Info： q-value=true
S702、 分叉处理实体向终端 2发送 OPTIONS请求， 查询终端能力信 息。 消息示例同步骤 2。
S703、 终端 1返回 200 OK, 携带终端 1的信息， 包括终端支持的
REFER等方法、 终端的联系地址 mike@pcl .example.com和当前 的优先级指数（q值） 0.5。
200 OK消息中携带的相关参数示例如下：
Contact: mike@pcl.example.com; q=0.5
Allow: REFER, INVITE, OPTIONS, BYE, CANCEL
S704、 终端 1返回 200 OK, 携带终端 2的信息， 包括终端支持的 REFER等方法、终端的联系地址 mike@pc2.example.com和当前的优先级 指数（q值） 0.3。
200 OK消息中携带的相关参数示例如下：
Contact: mike@pc2.example.com; q=0.3
Allow: REFER, INVITE, OPTIONS, BYE, CANCEL
S705、分叉处理实体选择支持 REFER方法、优先级指数大的终端 1作为接收 REFER消息的终端， 把 REFER消息发给该终端。 REFER 消息中的 Request URI填写的是终端 1的联系地址，相关参数示例如下：
REFER: sip: mike(¾pcl .example.com 另夕 |、， 本发明实施例中还提供一种协商消息接收终端的装置 800， 如 图 8所示， 包括：
发送单元 801 , 向各终端发送所述指示访问指定资源的请求消息； 接收单元 802, 接收并收集各用户终端的响应信息；
选择单元 803，根据预定策略选择接收所述指示访问指定资源的请求 消息的用户终端；
在所述选择单元 803确定用户终端后， 所述发送单元 801将指示访 问指定资源的请求消息发送给选定的终端。
其中所述预定策略包括-.
所述装置向各个用户终端发送查询请求消息， 并在该请求消息中携 带查询终端信息能力的指示， 获取终端支持的方法， 并选择支持指示访 问指定资源的请求消息方法和 /或优先级指数较大的终端作为接收终端。
一种协商消息接收终端的系统， 包括前述的协商消息接收终端的装 置， 在发生并行分叉时， 所述装置根据预定策略选择接收指示访问指定 资源的请求消息的终端， 再将指示访问指定资源的请求消息发送给选定 的终端。
综上所述， 可以看出， 虽然本发明的各实施例给出的是 REFER发生 并行分叉的应用场景， 本发明提供的技术方案中， 分叉处理实体在发生 分叉时可以先通过向各终端发送查询终端信息的请求获得各用户终端的 能力信息， 之后由分叉处理实体或由最初的请求消息发起方选择接收请 求消息的终端， 然后把最初的请求消息发送给指定终端。
可以理解， 对本发明领域的普通技术人员来说， 本发明方法所给出 的协商请求消息接收终端的方法可以但不仅上述实施例的说明， 无须创 造性劳动的改变或替换， 都应属于本发明所附权利要求的保护范围。

Claims

权 利 要 求
1、 一种协商消息接收终端的实现方法， 其特征在于， 在指示访问指 定资源的请求消息发起方和各终端之间设置分叉处理实体， 包括步驟： 消息发起方发送指示访问指定资源的请求消息；
当有多个用户终端需要接收所述请求消息且发生并行分叉时， 所述 分叉处理实体将从消息发起方接收到的所述指示访问指定资源的请求消 息转发给各终端；
所述分叉处理实体接收各用户终端的响应， 并根据预定策略选择用 户终端访问指定资源。
2、 根据权利要求 1所述的方法， 其特征在于， 还包括：
当所述用户终端发送事件通知消息给分叉处理实体， 并收到成功响 应之后， 进行所述指示访问指定资源的清求消息中指示的动作， 包括发 送会话发起消息。
3、 一种协商消息接收终端的实现方法， 其特征在于， 在指示访问指 定资源的请求消息发起方和各终端之间设置分叉处理实体， 该方法包括: 在发生并行分叉时， 根据预定策略选择接收指示访问指定资源的请 求消息的终端， 再将指示访问指定资源的请求消息发送给选定的终端。
4、 根据权利要求 3所述的方法， 其特征在于， 所述分叉处理实体与 指示访问指定资源的请求消息发送方为不同的网络实体。
5、 根据权利要求 4所述的方法， 其特征在于， 还包括：
所述分叉处理实体向各个用户终端发送查询请求消息， 获取终端能 力信息和终端支持的方法；
各终端返回各自的响应， 分叉处理实体接收各终端的响应， 并把响 应的终端列表通过重定向消息发给所述指示访问指定资源的请求消息的 发送方；
所述发送方根据重定向消息中的指示选择接收终端， 并将指示访问 指定资源的请求消息发送给选定的终端。
6、 根据权利要求 4所述的方法， 其特征在于， 还包括：
由所述分叉处理实体向各个终端发送查询请求消息， 各终端返回各 自的响应， 分叉处理实体接收各终端的响应， 根据预定策略选择接收终 端， 并将指示访问指定资源的请求消息发送给选定的终端。
7、 根据权利要求 3所述的方法， 其特征在于， 当所述分叉处理实体 与指示访问指定资源的请求消息发送方为同一个网络实体，
所述指示访问指定资源的请求消息发起方 /分叉处理实体在发送指示 访问指定资源的请求消息之前先向各个终端发送查询请求消息， 各终端 返回各自的响应；
所述指示访问指定资源的请求消息发起方 /分叉处理实体分叉处理实 体收集各终端的响应， 根据预定策略选择接收终端， 并向该终端发送指 示访问指定资源的请求消息请求。
8、 根据权利要求 6或 7所述的方法， 其特征在于， 所述预定策略包 括 ··
所述分叉处理实体向各个用户终端发送查询请求消息 , 获取终端能 力信息和终端支持的方法， 并选择支持指示访问指定资源的请求消息方 法和 /或优先级较高的终端作为接收终端。
9、 根据权利要求 6或 7所述的方法， 其特征在于， 所述预定策略包 括：
所述分叉处理实体同时向各个终端发送查询请求消息， 选择第一个 成功响应的终端作为接收终端。
10、 根据权利要求 6或 7所述的方法， 其特征在于， 所述预定策略 包括：
所述分叉处理实体顺序向各个终端发送查询请求消息， 选择第一个 返回成功响应的终端作为接收终端。
11、 根据权利要求 5 所述的方法， 其特征在于， 所述查询请求消息 为 OPTIONS消息； 或 /和
所述获取终端能力信息的请求通过扩展 Terminal-Info头域携带； 或 / 和
所述重定向消息是 302 Moved temporarily消息。
12、 一种协商消息接收终端的装置， 其特征在于， 包括：
发送单元， 向各终端发送所述指示访问指定资源的请求消息； 接收单元， 接收并收集各用户终端的响应信息；
选择单元， 根据预定策略选择接收所述指示访问指定资源的请求消 息的用户终端；
在所述选择单元确定用户终端后， 所述发送单元将指示访问指定资 源的请求消息发送给选定的终端。
13、根据权利要求 12所述的装置， 其特征在于， 所述预定策略包括： 所述发送单元向各个用户终端发送查询请求消息， 所述接收单元获 取终端能力信息和终端支持的方法， 所述选择单元选择支持指示访问指 定资源的请求消息方法和 /或优先级较高的终端作为接收终端。
14、 一种协商消息接收终端的系统， 其特征在于， 该系统中设置有 协商消息接收终端的装置， 该装置包括：
发送单元， 向各终端发送所述指示访问指定资源的请求消息； 接收单元， 接收并收集各用户终端的响应信息；
选择单元， 根据预定策略选择接收所述指示访问指定资源的请求消 息的用户终端；
在所述选择单元确定用户终端后， 所述发送单元将指示访问指定资 源的请求消息发送给选定的终端； 在发生并行分叉时， 所述装置根据预 定策略选择接收指示访问指定资源的请求消息的终端， 再将指示访问指 ' 定资源的请求消息发送给选定的终端。
15、根据权利要求 14所述的系统， 其特征在于， 所述预定策略包括： 所述装置向各个用户终端发送查询请求消息， 获取终端能力信息和 终端支持的方法， 并选择支持指示访问指定资源的请求消息方法和 /或优 先级较高的终端作为接收终端。
PCT/CN2007/000424 2006-02-22 2007-02-07 Procédé, dispositif et système de réception par un terminal d'un message de confirmation WO2007095837A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN200610033974.5 2006-02-22
CN200610033974.5A CN101026618B (zh) 2006-02-22 2006-02-22 一种会话发起协议域协商消息接收终端的实现方法

Publications (1)

Publication Number Publication Date
WO2007095837A1 true WO2007095837A1 (fr) 2007-08-30

Family

ID=38436936

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2007/000424 WO2007095837A1 (fr) 2006-02-22 2007-02-07 Procédé, dispositif et système de réception par un terminal d'un message de confirmation

Country Status (2)

Country Link
CN (1) CN101026618B (zh)
WO (1) WO2007095837A1 (zh)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101977201A (zh) * 2010-11-05 2011-02-16 中国电信股份有限公司 扩展SIP消息中Call-Info头域携带业务信息的方法
JP2012515522A (ja) * 2009-01-16 2012-07-05 エービービー テクノロジー アーゲー 火花により閉じる機械スイッチによって冗長性スイッチングセルを備える電圧形変換器の故障保護

Families Citing this family (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN100542140C (zh) * 2006-12-15 2009-09-16 华为技术有限公司 一种访问用户数据的方法及用户档案管理服务器
CN102177696B (zh) * 2008-10-10 2015-06-24 诺基亚公司 用于在基于网络的通信系统中重新公布信息的系统和方法
FR2971659A1 (fr) * 2011-02-10 2012-08-17 France Telecom Procede et dispositif de gestion dynamique de la priorite de reception d'une communication d'un terminal
CN102833215B (zh) * 2011-06-14 2017-07-28 中兴通讯股份有限公司 一种增强sip forking呼叫功能的方法及设备
EP3170324B1 (en) * 2014-07-16 2019-05-22 Telefonaktiebolaget LM Ericsson (publ) Policy control in session initiation protocol forking

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN1469585A (zh) * 2003-06-26 2004-01-21 中国科学院计算技术研究所 基于会话启动协议的ip视频电话系统中会话和媒体授权方法
WO2004061543A2 (en) * 2003-01-03 2004-07-22 Nokia Corporation Method and apparatus for resolving protocol-agnostic schemes in an internet protocol multimedia subsystem

Family Cites Families (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
FI20011962A0 (fi) * 2001-10-09 2001-10-09 Nokia Corp Koodinmuunninjärjestely

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2004061543A2 (en) * 2003-01-03 2004-07-22 Nokia Corporation Method and apparatus for resolving protocol-agnostic schemes in an internet protocol multimedia subsystem
CN1469585A (zh) * 2003-06-26 2004-01-21 中国科学院计算技术研究所 基于会话启动协议的ip视频电话系统中会话和媒体授权方法

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2012515522A (ja) * 2009-01-16 2012-07-05 エービービー テクノロジー アーゲー 火花により閉じる機械スイッチによって冗長性スイッチングセルを備える電圧形変換器の故障保護
CN101977201A (zh) * 2010-11-05 2011-02-16 中国电信股份有限公司 扩展SIP消息中Call-Info头域携带业务信息的方法
CN101977201B (zh) * 2010-11-05 2015-08-19 中国电信股份有限公司 扩展SIP消息中Call-Info头域携带业务信息的方法

Also Published As

Publication number Publication date
CN101026618B (zh) 2011-04-20
CN101026618A (zh) 2007-08-29

Similar Documents

Publication Publication Date Title
JP5143125B2 (ja) ドメイン間情報通信のための認証方法、システム、およびその装置
CA2784453C (en) System and method for detecting and processing stale messages
JP5043392B2 (ja) Ｓｉｐ通信セッションをセットアップする方法、並びに、そのシステム及びコンピュータ・プログラム
KR101560601B1 (ko) Ｓｔｕｎ을 사용하여 생성된 세션의 정책 서비스 시스템 아키텍처
EP2131546B1 (en) Method, system, and apparatus for processing business message with a plurality of terminals
US8266203B2 (en) Method for obtaining device information of user terminals and communication service function entity
JP4955694B2 (ja) Ｉｐマルチメディアサブシステムにおけるメッセージハンドリング
JP5247709B2 (ja) 中間ノードが利用不可能な場合にｓｉｐメッセージを経路指定する方法
JP5173607B2 (ja) 通信システム
US20050213580A1 (en) System and method for enforcing policies directed to session-mode messaging
WO2007095837A1 (fr) Procédé, dispositif et système de réception par un terminal d&#39;un message de confirmation
WO2009137956A1 (zh) Diameter应用的端到端过载控制方法和网络单元
WO2010072103A1 (zh) 推送会话的建立方法、推送系统和相关设备
WO2007041937A1 (fr) Methode d&#39;envoi et de reception de message hors ligne, appareil client, serveur et systeme
JP2005339550A (ja) サーバプール使用時の効率のよいメッセージ経路指定
WO2009018755A1 (fr) Procédé de session multi-terminal, système de communication et dispositifs associés
WO2009015587A1 (fr) Procédé, système et appareil de routage soap
EP2453681A1 (en) System and method for routing session initiation protocol conversation
US9237587B2 (en) Method and system for implementing group message service based on converged service system
WO2007112640A1 (fr) Procédé et appareil de remplacement de l&#39;identification de session, serveur d&#39;application et procédé de remplacement de session
EP2082552A1 (en) Session based communication
TW200844767A (en) Pulling information from information sources via refer requests
EP2071806B1 (en) Receiving/transmitting agent method of session initiation protocol message and corresponding processor
WO2012013094A1 (zh) 基于对话关联标识的会话建立方法及系统
JP4677350B2 (ja) 呼制御信号転送装置、呼制御信号転送方法および呼制御信号転送プログラム

Legal Events

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

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 07702301

Country of ref document: EP

Kind code of ref document: A1