WO2006136054A1 - Procede de realisation d'un appel multipartie dans un reseau optique commute automatique et controleur d'appel pour ce procede - Google Patents

Procede de realisation d'un appel multipartie dans un reseau optique commute automatique et controleur d'appel pour ce procede Download PDF

Info

Publication number
WO2006136054A1
WO2006136054A1 PCT/CN2005/000893 CN2005000893W WO2006136054A1 WO 2006136054 A1 WO2006136054 A1 WO 2006136054A1 CN 2005000893 W CN2005000893 W CN 2005000893W WO 2006136054 A1 WO2006136054 A1 WO 2006136054A1
Authority
WO
WIPO (PCT)
Prior art keywords
call
sub
calling
party
controller
Prior art date
Application number
PCT/CN2005/000893
Other languages
English (en)
French (fr)
Inventor
Desheng Sun
Original Assignee
Zte Corporation
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 Zte Corporation filed Critical Zte Corporation
Priority to CN2005800475993A priority Critical patent/CN101112013B/zh
Priority to PCT/CN2005/000893 priority patent/WO2006136054A1/zh
Publication of WO2006136054A1 publication Critical patent/WO2006136054A1/zh

Links

Classifications

    • 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/56—Arrangements for connecting several subscribers to a common circuit, i.e. affording conference facilities

Definitions

  • the present invention relates to the field of optical networks, and in particular to an implementation method of a multiparty call in an automatic switched optical network and a call controller thereof. Background technique
  • Optical network such as OTN (Optical Transmission Network), WDMC Wavelength-division multiplexing, Wavelength Division Multiplexing (SDH), SDH (Synchronous Digital Hierarchy) or SONET (Synchronous Optical Network) transmission network, It has been widely used in the field of telecommunications.
  • OTN Optical Transmission Network
  • WDMC Wavelength-division multiplexing, Wavelength Division Multiplexing (SDH), SDH (Synchronous Digital Hierarchy) or SONET (Synchronous Optical Network) transmission network
  • ASON Automatic switched optical network
  • AS0N which is implemented by setting up a special Control Plane (CP).
  • CP Control Plane
  • ITU- TG. 7713 recommends an implementation framework for distributed calls and connections in AS0N networks, providing implementation specifications for the automatic establishment, modification and deletion of calls and connections.
  • G. 8080 requires the AS0N network to support both point-to-point and point-to-multipoint calls.
  • a point-to-multipoint call is also known as a multiparty call.
  • Peer-to-peer services are very common in the network, as shown in Figure 1, which involves only two-party users.
  • point-to-multipoint services such as broadcast services.
  • this type of service involves multiple recipient users of the service.
  • FIG. 4A and FIG. 4B are schematic diagrams showing the call implementation process of the point-to-point service of FIG. 3 traversing the domains of Domain 1 and Domain n
  • FIG. 4A is a call setup procedure
  • FIG. 4B is a call release procedure.
  • G.8080 proposes implementation requirements
  • Summary of the invention The technical problem to be solved by the present invention is to provide a method for implementing a multi-party call in an automatic switched optical network, which implements a point-to-multipoint service call in an AS0N network.
  • the present invention also provides a network call controller that can be used to implement the method.
  • the present invention provides a method for implementing a multi-party call in an automatic switched optical network, which includes the following steps:
  • each of the calling entities establishes a sub-call with the corresponding called user in a point-to-point manner. If the establishment is successful, the call establishment indication message is returned to the ingress network call controller, otherwise a failure message is returned;
  • the calling entity releases the sub-call with the corresponding called user in a point-to-point manner, and if the release is successful, returns a call release indication message to the ingress network call controller, otherwise returns a failure message;
  • the ingress network call controller when all the sub-calls return the call release indication message, the ingress network call controller returns a call release indication message to the calling user-side call controller, and deletes the call entity, and the multi-party call is successfully released, and ends. .
  • implementation method of the foregoing multi-party call may further have the following features: further comprising the steps of:
  • the ingress network call controller receives and recognizes the multi-party call modification request sent by the calling user-side call controller and adds N called users, creates N call entities, and then respectively goes to the N
  • the newly created calling entity initiates the establishment of a sub-call;
  • the N newly created calling entities establish a sub-call between the newly added called users in a point-to-point manner, and if the establishment is successful, return a call setup indication message to the ingress network call controller, otherwise return Failure message
  • implementation method of the foregoing multi-party call may further have the following features: further comprising the steps of:
  • the ingress network call controller receives and recognizes the multi-party call modification request sent by the calling user-side call controller to delete the M called users, the corresponding M call entities are found, and then respectively The M call entities initiate release of the sub-call;
  • the M call entities release the sub-calls corresponding to the called party in a point-to-point manner, and if the release is successful, return a call release indication message to the ingress network call controller, otherwise return a failure message;
  • the method for implementing the multi-party call may further have the following features: after the call entity returns a call setup indication message, the ingress network call controller further sends a call setup confirmation message to the call corresponding to the called user by the call entity. Controller.
  • the method for implementing the multi-party call may further have the following features: when at least one sub-call setup fails, the ingress network call controller returns a failure message to the calling-side user-side call controller, and the deletion is successful.
  • the established sub-call and its corresponding call entity when at least one sub-call setup fails, the ingress network call controller returns a failure message to the calling-side user-side call controller, and the deletion is successful.
  • the method for implementing the multi-party call may further have the following features: when at least one sub-call setup fails, the ingress network call controller returns an execution result of each sub-call setup to the calling-side user-side call controller. , retains the sub-call that has been successfully established and its corresponding call entity.
  • the implementation method of the foregoing multi-party call may further have the following features:
  • the ingress network call controller returns a failure message to the calling-side user-side call controller, and deletes the call entity corresponding to the sub-call that has been successfully released.
  • the automatic exchange optical network call controller for implementing multi-party call comprises a call request monitoring module, a message identification module and a single-party call processing module, and is characterized in that it further comprises a multi-party call processing module, wherein:
  • the message identification module is further configured to identify the multi-party call setup request and the multi-party call release request, and hand it to the multi-party call processing module for processing;
  • the multiparty call processing module further includes a multiparty call control unit, a multiparty call setup unit, a multiparty call release unit, and a multiparty call response unit, where:
  • the multi-party call control unit is configured to receive the identified message, and after the call setup request, specify the number of called users of the multi-party call as the number of call entities to be created, and then activate the call setup unit; After releasing the request, designating a calling entity associated with the multiparty call, and then activating the call release unit;
  • the multi-party call establishing unit is configured to create a specified number of call entities, respectively initiate establishment of sub-calls to the call entities, and control the call entities to establish sub-calls with corresponding called users in a point-to-point manner, and to make sub-calls. Establishing a successful indication message or failure message to notify the multi-party call response unit;
  • the multi-party call release unit is configured to separately initiate release of the sub-call to the designated call entity, and control the call entities to release the sub-call with the corresponding called user in a point-to-point manner, and notify the response that the successful indication message or failure message is released.
  • a multi-party call response unit configured to determine whether the designated call entity created or released returns a success indication message, and if yes, returns a success indication message to the calling user call controller, otherwise, returns a failure message or a sub-call execution result. information.
  • the above-mentioned automatic switching optical network call controller may further have the following feature: the message identification module is further configured to identify a multi-party call modification request, and the multi-party call control unit is further configured to: after receiving the call modification request, The number of added called users is specified as the number to be created. Call the number of entities, then activate the call setup unit or find the call entity corresponding to the called user, and then activate the call release unit.
  • the above-mentioned automatic switching optical network call controller may further have the following feature: the message identification module is further configured to identify a multi-party call setup confirmation message, and the multi-party call control unit is further configured to: after receiving the call setup confirmation message The call setup confirmation message is sent directly to the call controller of the called user through the relevant call entity.
  • the method of the present invention decomposes a complex multi-party call problem into multiple sub-call processing methods, and solves the problem that the AS0N network supports point-to-multipoint service, and has the advantages of simplicity and reliability.
  • Figure 1 is a schematic diagram of a peer-to-peer service in an AS0N network
  • FIG. 2 is a schematic diagram of a point-to-multipoint service in an AS0N network
  • FIG. 3 is a schematic diagram of a point-to-point service in which an AS0N network traverses two domains;
  • Figure 4A is a call setup procedure of the situation shown in Figure 3;
  • Figure 4B is a call release procedure of the situation shown in Figure 3;
  • FIG. 5A is a schematic diagram of networking of point-to-multipoint services of an AS0N network traversing different domains
  • FIG. 5B is a schematic diagram of networking of adding a called user to the service shown in FIG. 5A
  • FIG. 6A is a schematic diagram of an embodiment of the present invention for solving the situation of FIG.
  • FIG. 6B is a schematic diagram of a multi-party call release procedure according to an embodiment of the present invention for solving the situation of FIG. 5A
  • FIG. 6C is a schematic diagram of a multi-party call modification procedure of the embodiment of the present invention for solving the situation of FIG. 5B
  • FIG. 8 is a flowchart of multi-party call release according to an embodiment of the present invention.
  • Figure 10 is a flow diagram of an ingress network call controller handling a multiparty call in accordance with an embodiment of the present invention.
  • the core idea of the present invention is to decompose a point-to-multipoint multi-party call into multiple point-to-point calls according to the framework structure of the ASN network, and implement a multi-party call implementation process by implementing multiple point-to-point calls.
  • the following describes the process of establishing, releasing, and modifying multiparty calls.
  • the calling party A is connected to the called Z1 via the domain domain 1 and the domain domain n- 1, and is connected to another called Z2 through the domain domain1 and the domain domain n-2.
  • the present invention can be applied to any connection form, and the calling party and the called party can be connected to each other in one domain or through two or more domains.
  • Step 110 the ingress network call controller NCCu of the domain domain 1 receives and recognizes the caller side call controller.
  • Step 120 NCCu determines that the called user is ⁇ ⁇ 2 , creates two calling entities NCCw and NCCu- 2 , and decomposes the call setup request from CCC a into two sub-call setup requests, respectively NCC U - 2 initiates sub-calls to establish Call 1 and Call 2;
  • Step 130 NCCu- 2 establishes a sub-call with the called user ⁇ ⁇ 2 according to the point-to-point call setup procedure, and if the establishment is successful, returns a call setup indication message of the respective sub-call to the NCCH, otherwise returns a failure message;
  • the process of establishing two sub-calls in this step is basically the same as the process shown in FIG. 4A. The only difference is that the request originator is CCC A in Figure 4A, and the request originator of the two sub-calls in this step is NCC U .
  • Step 140 The NCC U monitors the execution of the two sub-call setup procedures. If the call setup indication message returned by the NCCu- ⁇ D NCC u - 2 is received, the next step is performed, if any of the NCC i and the NCC ti - 2 fails to return. The message or NCC U waits for a timeout, and step 160 is performed;
  • Step 150 The NCC U returns a call setup indication message to the CCC a , and decomposes the call setup confirmation message sent by the CCC a into a confirmation message of multiple sub-calls.
  • the NCCu-2 is sent to the called user call controller ccc z ⁇ n ccc z2 , and the multiparty call is successfully established and ends;
  • Step 160 The NCCu returns a call setup failure message to the CCC a , and deletes the sub-call and the corresponding call entity that have been successfully established, and the multi-party call setup fails and ends.
  • the NCCu may also be configured to return information about success or failure of each sub-call establishment to CCC a , retain the successfully established sub-call and its corresponding call entity, and call control to the called user corresponding to the sub-call.
  • the device sends a call setup confirmation message.
  • FIG 5A still networking, for example, assumed that the calling and called A ⁇ ⁇ ⁇ ⁇ 2 has established a call by, for example, multiparty call release procedure in the present embodiment shown in Figure 8 (refer to FIG. 6ss), comprising the steps of: Step 210: The ingress network call controller NCCu of the domain domain 1 receives and recognizes the multiparty call release request sent by the calling user side call controller CCC a ;
  • Step 220 the NCCH finds that the call related to the call actually decomposes the call release request into two sub-call release requests, respectively The child calls the release of Call 1 and Call 2;
  • Step 230 NCC u - 2 respectively releases the sub-calls with the called user ⁇ ⁇ 2 according to the point-to-point call release procedure, and if the release is successful, returns a call release indication message of the respective sub-call to the NCCu, otherwise a failure message is returned;
  • the release process of the two sub-calls in this step is basically the same as the process shown in FIG. 4B.
  • the only difference is that the request originator is CCC a in Figure 4B, and the request originator of the two sub-calls in this step is NCCu.
  • Step 240 The NCCu monitors the execution of the two sub-call release processes. If the call release indication message returned by the NCC U -i and NCCu- 2 is received, the next step is performed, if any one of the NCC U- ⁇ NCCH- 2 returns fails. The message or NCCu waits for a timeout, and step 260 is performed;
  • Step 250 ( ⁇ returns to 0 ( ⁇ returns an indication message for its call release request, and deletes the call entity The multiparty call is successfully released and ends;
  • Step 260 The NCdi returns a call release failure message to the CCC a . If there is a successful sub-call, the corresponding call entity is deleted, and the multi-party call release ends.
  • the user can initiate call release again according to the requirements, until all the sub-calls are cleared.
  • the process of the multi-party call modification in this embodiment is described by taking the networking of FIG. 5B as an example.
  • the receiver Z 3 of a call is added through the process. As shown in FIG. 9 (refer to FIG. 6C ), the process includes the following steps:
  • Step 310 the ingress network call controller of the domain domain 1 receives and identifies the multi-party call modification request sent by the calling user side call controller CCC a ;
  • Step 320 the NCCu knows that the call to be modified is a multiparty call with two called users , ⁇ ⁇ 2 , and the call modification request requires adding another called user ⁇ 3;
  • Step 330 NCdi creates a new calling entity NCC u - 3 , converts the call modification request from CCC a into a sub-call setup request, and initiates establishment of the sub-call Call 3 to NCC u - 3 ;
  • Step 340 NCC U — 3, according to the point-to-point call setup process, establish a sub-call with the called user Z 3 , if the establishment is successful, return a call setup indication message to the sub-call, otherwise return a failure message;
  • the process of establishing the sub-call is basically the same as the process shown in FIG. 4A. The only difference is that the request originator is CCC A in Figure 4A, and the request originator of the two sub-calls in this step is NCCu.
  • Step 350 ( ⁇ monitoring the execution of the sub-call setup process, if receiving the call setup indication message returned by the NCCu-3, performing the next step, if receiving the failure message returned by the NCCn- 3 or the NCCu waiting timeout, executing step 370 ;
  • Step 360 The NCCu returns an indication message for the call modification request to the CCC a , and sends a call setup confirmation message to the call controller CCC z3 of the called user side through the NCCu-3, and the multi-party call is successfully modified and ends;
  • step 370 the NCCu returns a call modification failure message to the CCC a , and the multi-party call modification fails and ends.
  • the NCCH When the call modification request is to delete a called user, the NCCH first determines the called user to be deleted, and then converts the call modification request from CCC a into one or more sub-call release requests to the call corresponding to the user to be deleted. The entity initiates the release of sub-calls, these entities After the point-to-point call release process releases the sub-call between its corresponding called user, the NCC returns a call release indication message or a failure message. If all the indication messages of the sub-call to be released are received, the NCCH returns the call modification to the cc. The message is indicated, and the corresponding call entity is deleted. Otherwise, the call modification failure message is returned, and the corresponding call entity is deleted for the partial call (if any) that has been successfully released, and the multi-party call modification ends.
  • FIG. 10 shows the flow chart of NCC for call processing.
  • the processing flow of the above-mentioned multi-party call setup, release, and modification request is described in the NCC from the perspective of service processing, and the process includes the following steps:
  • Step 410 The network call controller NCC monitors a call request from the user side call controller CCC;
  • Step 420 After receiving the call request from the CCC, the NCC determines its type. If it is a point-to-point request, it processes the point-to-point call already existing on the AS0N network, and returns to step 410 (step 420a); if it is a multi-party call setup request, the steps are performed. 430; If it is a multi-party call release request, step 440 is performed; if it is a multi-party call modification request and the called user is to be added, step 450 is performed; if it is a multi-party call modification request and a part of the called user is to be released, step 460 is performed; Call confirmation message, go to step 500;
  • Step 430 The NCC creates a call entity whose number is equal to the number of calls of the multiparty call, and then decomposes the multiparty call setup request into the same number of subcall setup requests, and initiates establishment of the subcalls to the created call entities. Establishing a sub-call with the corresponding called user in a point-to-point manner, and returning a success indication message or a failure message to the NCC, executing step 470;
  • Step 440 The NCC finds the created call entity corresponding to each called user, and then decomposes the multi-party call release request into the same number of sub-call release requests, and respectively initiates release of the sub-calls to the call entities, and the call entities press Deleting the sub-call with the corresponding called user in a point-to-point manner, and returning a success indication message or a failure message to the NCC, executing step 470;
  • Step 450 the NCC creates the same number of calling entities according to the number of called users to be added.
  • the call modification request is then converted into the same number of sub-call setup requests, and the establishment of the sub-calls is initiated to the newly created call entity.
  • the call entities establish a sub-call with the corresponding called user in a point-to-point manner and return to the NCC. Successfully indicating a message or a failure message, performing step 470;
  • Step 460 The NCC finds a corresponding call entity according to the called user to be deleted, and then converts the call modification request into the same number of sub-call release requests, and initiates release of the sub-calls to the call entities.
  • the call entities are in a point-to-point manner. Release the sub-call with the corresponding called user, and return a success indication message or a failure message to the NCC, and perform step 470; 'Step 470, NCC determines whether all sub-calls return a success indication message, and if yes, perform the next step. Otherwise, go to step 490; '
  • Step 480 The NCC returns a success indication message for the call request to the CCC, and returns to the step.
  • Step 490 the NCC returns a failure message for the call request to the CCC (may also be configured to return the execution result information of each sub-call), and deletes the call entity whose corresponding sub-call setup fails or is successfully released, and returns to step 410;
  • Step 500 The NCC decomposes the received call setup confirmation message into an acknowledgment message of multiple sub-calls, and sends the acknowledgment message to the call controller of each called user through each call entity, and returns to step 410.
  • an NCC having a structure including a call request monitoring module, a message identification module, a one-party call processing module, and a multi-party call processing module. among them:
  • a call request monitoring module configured to monitor a call request from the user side call controller CCC, and hand over the received call request and the call setup confirmation message to the message identification module;
  • the message identification module is configured to identify the type of the call request, and to the one-party call processing module for the point-to-point request or confirmation message, and to the multi-party call setup request and the multi-party call release request for the point-to-multipoint request or confirmation message. a multiparty call modification request and a multiparty call setup confirmation message, which are handed over to the control unit in the multiparty call processing module;
  • the single-party call processing module is configured to implement a one-party call according to an existing point-to-point call processing manner of the AS0N network; the multi-party call processing module further includes a multi-party call control unit, a multi-party call setup unit, a multi-party call release unit, and a multi-party call response unit, where:
  • the multi-party call control unit is configured to, after receiving the call setup request, designate the number of called users of the multi-party call as the number of call entities to be created, and then activate the call setup unit; after receiving the call release request, specify and The multiparty calls the related call entity, and then activates the call release unit; after receiving the call modification request, increases the called user's modification request, specifies the number of called users to be added as the number of call entities to be created, and then activates the call.
  • the multi-party call establishing unit is configured to create a specified number of call entities, respectively initiate the establishment of the sub-calls to the call entities, and control the call entities to establish a sub-call with the corresponding called users in a point-to-point manner, and successfully establish the sub-calls.
  • the indication message or the failure message notifies the multiparty call response unit;
  • a multi-party call release unit configured to separately initiate release of a sub-call to a designated call entity, and control an instruction message or a failure message that the call entity releases the sub-call with the corresponding called user in a point-to-point manner and releases the sub-call successfully. Notifying the multiparty call response unit;
  • a multi-party call response unit configured to determine whether the designated call entity that is created or released returns a success indication message, and if yes, returns a success indication message to the CCC, otherwise, returns a failure message or execution result information of each sub-call to the CCC, And delete the call entity that the sub-call setup failed or was successfully released.
  • the automatic switched optical network only needs to implement the establishment and release of multi-party calls without the need for processes and modules related to multi-party call modification.
  • the method of the present invention adopts a processing method for decomposing a multi-party call flow into multiple sub-calls, and solves the problem that the ASON network supports point-to-multipoint
  • the problem of business calling has the advantages of simplicity and reliability.
  • the invention can support point-to-multipoint service in the ASON network, and is simple and reliable.

Description

自动交换光网络中多方呼叫的实现方法及其呼叫控制器 技术领域
本发明涉及光网络领域，具体涉及自动交换光网络中多方呼叫的实现 方法及其呼叫控制器。 背景技术
光网络， 例如 OTN (Optical transmission network, 光传送网络）、 WDMCWavelength-division multiplexing,波分复用）、 SDH (Synchronous digital hierarchy, 同步数字系列） 或 SONET ( Synchronous optical network, 同步光网络）传送网， 在电信领域已经得到广泛应用。
自动交换光网络 (Automatic switched optical network,简称 ASON) 是近年来光网络领域的研究热点。 ITU-TG. 8080建议提出了 AS0N的概念， 通过设置专门的控制平面 （Control plane, 简称 CP) 完成 AS0N网络的 功能。 ITU- TG. 7713建议规定了 AS0N网络中分布式呼叫与连接的实现框 架， 为呼叫、 连接的自动建立、 修改和删除等提供了实现规范。
呼叫是用户之间实现通讯的基础。 G. 8080要求 AS0N网络支持点对 点和点对多点两种方式的呼叫。 点对多点呼叫又称为多方呼叫。
点对点业务在网络中非常常见，如图 1所示，这种业务只涉及两方用 户。 近年来， 快速增长的互连网业务推动了点对多点业务的需求， 例如 广播业务。 如图 2所示， 这种业务涉及业务的多个接收方用户。
ITU-TG.7713 建议对这种业务的呼叫过程给出了比较详细的实现流 程。 例如图 4A和 4B给出了图 3穿越 Domain 1和 Domain n两个域的点 对点业务的呼叫实现流程示意图， 图 4A是呼叫建立流程， 图 4B是呼叫 释放流程。 但对于点对多点业务， 虽然 G.8080提出了实现需求， 但目前 还没有涉及这种多方呼叫的实现方法。 发明内容 本发明要解决的技术问题是提供一种自动交换光网络中多方呼叫的 实现方法， 在 AS0N网络中实现点对多点的业务呼叫。 本发明还要提供一 种可用于实现该方法的网络呼叫控制器。
为了解决上述技术问题，本发明提供了一种自动交换光网络中多方呼 叫的实现方法， 包括以下步骤：
(a)入口网络呼叫控制器收到并识别出主叫用户侧呼叫控制器发送 的多方呼叫建立请求后， 根据被叫用户个数创建相同数目的呼叫实体， 然后向所述各个呼叫实体分别发起子呼叫的建立；
(b)所述各个呼叫实体按点对点的方式建立与对应被叫用户间的子 呼叫， 如果建立成功， 向所述入口网络呼叫控制器返回呼叫建立指示消 息， 否则返回失败消息；
( c)所述各个呼叫实体均返回呼叫建立指示消息时， 所述入口网络 呼叫控制器向所述主叫用户侧呼叫控制器返回呼叫建立指示消息， 多方 呼叫建立成功；
(d)所述入口网络呼叫控制器收到并识别出所述主叫用户侧呼叫控 制器发送的该多方呼叫的释放请求后， 分别向与该多方呼叫相关的呼叫 实体发起子呼叫的释放；
(e)所述呼叫实体按点对点的方式释放与对应被叫用户间的子呼叫， 如果释放成功， 向所述入口网络呼叫控制器返回呼叫释放指示消息， 否 则返回失败消息；
( f )所有子呼叫均返回呼叫释放指示消息时， 所述入口网络呼叫控 制器向所述主叫用户侧呼叫控制器返回呼叫释放指示消息， 并删除所述 呼叫实体， 多方呼叫释放成功， 结束。
进一步地，上述多方呼叫的实现方法还可具有以下特点:还包括步骤：
( i )所述入口网络呼叫控制器收到并识别出所述主叫用户侧呼叫控 制器发送的增加 N个被叫用户的多方呼叫修改请求后， 创建 N个呼叫实 体， 然后分别向这 N个新创建的呼叫实体发起子呼叫的建立； (j ) 所述 N个新创建的呼叫实体按点对点的方式建立与对应的新增 被叫用户间的子呼叫， 如果建立成功， 向所述入口网络呼叫控制器返回 呼叫建立指示消息， 否则返回失败消息；
(k) 所有新创建的呼叫实体均返回呼叫建立指示消息时， 所述入口 网络呼叫控制器向所述主叫用户侧呼叫控制器返回呼叫修改指示消息， 多方呼叫修改成功， 结束。
进一步地，上述多方呼叫的实现方法还可具有以下特点：还包括步骤:
(0) 所述入口网络呼叫控制器收到并识别出所述主叫用户侧呼叫控 制器发送的删除 M个被叫用户的多方呼叫修改请求后， 找到对应的 M个 呼叫实体， 然后分别向这 M个呼叫实体发起子呼叫的释放；
(p) 所述 M个呼叫实体按点对点的方式释放与对应被叫用户间的子 呼叫， 如果释放成功， 向所述入口网络呼叫控制器返回呼叫释放指示消 息， 否则返回失败消息；
(q) 所述 M个呼叫实体均返回呼叫释放指示消息时， 所述入口网络 呼叫控制器向所述主叫用户侧呼叫控制器返回呼叫修改指示消息， 并删 除该 M个呼叫实体， 多方呼叫修改成功， 结束。
进一步地，上述多方呼叫的实现方法还可具有以下特点： 当呼叫实体 返回呼叫建立指示消息后， 所述入口网络呼叫控制器还通过该呼叫实体 将呼叫建立确认消息发送到对应被叫用户的呼叫控制器。
进一步地，上述多方呼叫的实现方法还可具有以下特点： 当有至少一 个子呼叫建立失败时， 所述入口网络呼叫控制器向所述主叫用户侧呼叫 控制器返回失败消息， 并删除已成功建立的子呼叫和其对应的呼叫实体。
进一步地，上述多方呼叫的实现方法还可具有以下特点： 当有至少一 个子呼叫建立失败时， 所述入口网络呼叫控制器向所述主叫用户侧呼叫 控制器返回各个子呼叫建立的执行结果， 保留已成功建立的子呼叫和其 对应的呼叫实体。
进一步地，上述多方呼叫的实现方法还可具有以下特点： 当有至少一 个子呼叫释放失败时， 所述入口网络呼叫控制器向所述主叫用户侧呼叫 控制器返回失败消息， 并删除已成功释放的子呼叫对应的呼叫实体。
本发明提供的用于实现多方呼叫的自动交换光网络呼叫控制器包括 呼叫请求监测模块、 消息识别模块和单方呼叫处理模块， 其特点是， 还 包括多方呼叫处理模块， 其中：
所述消息识别模块还用于识别出多方呼叫建立请求和多方呼叫释放 请求， 交给所述多方呼叫处理模块处理；
所述多方呼叫处理模块进一步包括多方呼叫控制单元、多方呼叫建立 单元、 多方呼叫释放单元和多方呼叫响应单元， 其中：
所述多方呼叫控制单元，用于接收识别出的消息，对呼叫建立请求后， 将该多方呼叫的被叫用户个数指定为要创建的呼叫实体数， 然后激活呼 叫建立单元； 在收到呼叫释放请求后， 指定与该多方呼叫相关的呼叫实 体， 然后激活呼叫释放单元；
所述多方呼叫建立单元，用于创建指定数目的呼叫实体， 向这些呼叫 实体分别发起子呼叫的建立， 控制这些呼叫实体按点对点的方式建立与 对应被叫用户间的子呼叫， 并将子呼叫建立成功的指示消息或失败消息 通知所述多方呼叫响应单元；
多方呼叫释放单元， 用于向指定的呼叫实体分别发起子呼叫的释放， 控制这些呼叫实体按点对点的方式释放与对应被叫用户间的子呼叫， 并 将释放成功的指示消息或失败消息通知响应单元；
多方呼叫响应单元，用于判断所指定创建或释放的呼叫实体是否都返 回了成功指示消息， 如果是， 向主叫用户呼叫控制器返回成功指示消息， 否则， 返回失败消息或子呼叫的执行结果信息。
进一步地，上述自动交换光网络呼叫控制器还可具有以下特点：所述 消息识别模块还用于识别多方呼叫修改请求， 且所述多方呼叫控制单元 还用于在收到呼叫修改请求后， 将要增加的被叫用户数指定为要创建的 呼叫实体数， 然后激活呼叫建立单元或者， 找到要删除被叫用户对应的 呼叫实体， 然后激活呼叫释放单元。
进一步地，上述自动交换光网络呼叫控制器还可具有以下特点：所述 消息识别模块还用于识别多方呼叫建立确认消息， 且所述多方呼叫控制 单元还用于在收到呼叫建立确认消息后， 直接通过相关呼叫实体向被叫 用户的呼叫控制器发送呼叫建立确认消息。
由上可知，本发明方法采用将一个复杂的多方呼叫问题分解为多个子 呼叫处理的方法， 解决 AS0N网络支持点对多点业务的问题， 具备简洁、 可靠的优点。
附图概述
图 1是 AS0N网络点对点业务示意图；
图 2是 AS0N网络点对多点业务示意图；
图 3是 AS0N网络穿越两个域的点对点业务示意图；
图 4A是图 3所示情形的呼叫建立流程；
图 4B是图 3所示情形的呼叫释放流程；
图 5A是 AS0N网络穿越不同域的点对多点业务的组网示意图； 图 5B是图 5A所示业务增加一个被呼叫用户的组网示意图； 图 6A是解决图 5A情形的本发明实施例多方呼叫建立流程的示意图； 图 6B是解决图 5A情形的本发明实施例多方呼叫释放流程的示意图； 图 6C是解决图 5B情形的本发明实施例多方呼叫修改流程的示意图； 图 7是本发明实施例多方呼叫建立的流程图；
图 8是本发明实施例多方呼叫释放的流程图；
图 9是本发明实施例多方呼叫修改的流程图；
图 10是本发明实施例入口网络呼叫控制器处理多方呼叫的流程图。
本发明的最佳实施方式 本发明的核心思想是依据 AS0N网络的框架结构， 将点对多点的多方 呼叫分解为多个点对点的呼叫， 通过实现多个点对点的呼叫来完成多方 呼叫的实现流程。 下面对多方呼叫建立、 释放、 修改的流程加以说明。
以图 5A的组网为例， 主叫 A经域 domain 1、 域 domain n-l与被叫 Z1连接， 通过域 domainl、 域 domain n- 2与另一被叫 Z2连接。 但是本 发明可适用于任何连接形式， 主叫和被叫之间可以在一个域内， 也可以 通过二个以上的域相互连接。
本实施例多方呼叫建立的流程如图 7所示 （可同时参照图 6A ) ， 包 括以下步骤- 步骤 110， 域 domain 1的入口网络呼叫控制器 NCCu收到并识别出主 叫用户侧呼叫控制器 ccca发送的多方呼叫建立请求；
步骤 120， NCCu判断被叫用户为 Ζ^Π Ζ2， 创建两个呼叫实体 NCCw 和 NCCu— 2， 并将来自 CCCa的呼叫建立请求分解为两个子呼叫建立请求， 分 别向
Figure imgf000008_0001
NCCU-2发起子呼叫 Call 1和 Call 2的建立；
步骤 130，
Figure imgf000008_0002
NCCu-2分别按点对点的呼叫建立流程建立与被叫 用户 Ζ^Β Ζ2间的子呼叫， 如果建立成功， 向 NCCH返回各自子呼叫的呼叫 建立指示消息， 否则返回失败消息；
请参照图 6A，该步两个子呼叫的建立流程与图 4A所示流程基本相同。 唯一的区别是， 图 4A中请求发起方为 CCCA， 而本步骤两个子呼叫的请求 发起方为 NCCU。
步骤 140， NCCU监测两个子呼叫建立流程的执行情况， 如果接收到 NCCu-^D NCCu-2返回的呼叫建立指示消息， 执行下一步， 如果 NCC i和 NCCti—2中任何一个返回失败消息或 NCCU等待超时， 执行步骤 160;
步骤 150， NCCU向 CCCa返回呼叫建立指示消息， 并将 CCCa发送的呼 叫建立确认消息分解为多个子呼叫的确认消息，经
Figure imgf000008_0003
NCCu-2发送到 被叫用户呼叫控制器 cccz^n cccz2， 该多方呼叫建立成功， 结束；
步骤 160， NCCu向 CCCa返回呼叫建立失败消息， 将已经成功建立的 子呼叫和对应的呼叫实体删除， 该多方呼叫建立失败， 结束。 在上述步骤 170中， 也可以配置 NCCu向 CCCa返回各子呼叫建立成功 或失败的信息， 保留已成功建立的子呼叫和其对应的呼叫实体， 并向该 子呼叫对应的被叫用户呼叫控制器发送呼叫建立确认消息。
仍以图 5A的组网为例， 假定主叫 A和被叫 Ζ^Π Ζ2间呼叫已建立， 本 实施例多方呼叫释放的流程如图 8所示（参照图 6Β ) ， 包括以下步骤： 步骤 210， 域 domain 1的入口网络呼叫控制器 NCCu收到并识别出主 叫用户侧呼叫控制器 CCCa发送的多方呼叫释放请求；
步骤 220， NCCH找到与该呼叫相关的呼叫实 将呼 叫释放请求分解为两个子呼叫释放请求，分别向
Figure imgf000009_0001
子呼 叫 Call 1和 Call 2的释放；
步骤 230，
Figure imgf000009_0002
NCCu—2分别按点对点的呼叫释放流程释放与被叫 用户 Ζ^Π Ζ2间的子呼叫， 如果释放成功， 向 NCCu返回各自子呼叫的呼叫 释放指示消息， 否则返回失败消息；
请参照图 6B，该步两个子呼叫的释放流程与图 4B所示流程基本相同。 唯一的区别是， 图 4B中请求发起方为 CCCa， 而本步骤两个子呼叫的请求 发起方为 NCCu。
步骤 240， NCCu监测两个子呼叫释放流程的执行情况， 如果接收到 NCCU— i和 NCCu— 2返回的呼叫释放指示消息， 执行下一步， 如果 NCCU— ^口 NCCH-2中任何一个返回失败消息或 NCCu等待超时， 执行步骤 260 ;
歩骤 250， (^向 0 (^返回对其呼叫释放请求的指示消息， 并删除 呼叫实体
Figure imgf000009_0003
该多方呼叫释放成功， 结束；
步骤 260， NCdi向 CCCa返回呼叫释放失败消息， 若有释放成功的子 呼叫， 删除其对应的呼叫实体， 本次多方呼叫释放结束。
对于此次未能释放的子呼叫，用户根据需求，可以再次发起呼叫释放， 直至全部清除这些子呼叫。 下面以图 5B的组网为例， 说明本实施例多方呼叫修改的流程， 通过 该流程增加一个呼叫的接收方 Z3， 如图 9所示 （参照图 6C ) ， 该流程包 括以下步骤：
步骤 310， 域 domain 1的入口网络呼叫控制器 (^收到并识别出主 叫用户侧呼叫控制器 CCCa发送的多方呼叫修改请求；
步骤 320， NCCu获知要修改的呼叫为已有两个被叫用户 Ζ^Π Ζ2的多 方呼叫， 且该呼叫修改请求要求再增加一个被呼叫用户 Ζ3 ;
步骤 330， NCdi创建一个新的呼叫实体 NCCu-3， 将来自 CCCa的呼叫修 改请求转换为一个子呼叫建立请求， 向 NCCu-3发起子呼叫 Call 3的建立； 步骤 340， NCCU— 3按点对点的呼叫建立流程建立与被叫用户 Z3的子呼 叫， 如果建立成功， 向 (^返回该子呼叫的呼叫建立指示消息， 否则返 回失败消息；
请参照图 6C， 该子呼叫的建立流程与图 4A所示流程基本相同。 唯一 的区别是， 图 4A中请求发起方为 CCCA， 而本步骤两个子呼叫的请求发起 方为 NCCu。
步骤 350， (^监测该子呼叫建立流程的执行情况，如果接收到 NCCu-3 返回的呼叫建立指示消息， 执行下一步， 如果收到 NCCn-3返回的失败消息 或 NCCu等待超时， 执行步骤 370 ;
步骤 360， NCCu向 CCCa返回对其呼叫修改请求的指示消息， 并通过 NCCu-3将呼叫建立确认消息发送到被叫用户侧的呼叫控制器 CCCz3，该多方 呼叫修改成功， 结束；
步骤 370， NCCu向 CCCa返回呼叫修改失败消息， 该多方呼叫修改失 败， 结束。
对于呼叫修改时只有部分子呼叫建立成功的情况，也可配置为保留或 者释放已成功建立的子呼叫。
当呼叫修改请求是要删除一个被叫用户时， NCCH先确定需要删除的 被叫用户， 然后将来自 CCCa的呼叫修改请求转换为一个或多个子呼叫释 放请求， 向与要删除用户对应的呼叫实体发起子呼叫的释放， 这些实体 按点对点的呼叫释放流程释放与其对应被叫用户间的子呼叫后， 向 NCC„ 返回呼叫释放指示消息或失败消息， 如果收到所有要释放的子呼叫的指 示消息，则 NCCH向 cc 返回呼叫修改指示消息，并删除对应的呼叫实体， 否则， 返回呼叫修改失败消息， 删除已释放成功的部分子呼叫 （若有的 话） 对应的呼叫实体， 本次多方呼叫修改结束。
图 10所示是 NCC对呼叫处理的流程图。 从 NCC对业务处理的角度集 中地描述了对上述多方呼叫建立、 释放、 修改请求的处理流程， 该流程 包括以下步骤：
步骤 410，网络呼叫控制器 NCC监测来自用户侧呼叫控制器 CCC的呼 叫请求；
步骤 420， NCC收到来自 CCC的呼叫请求后， 判断其类型， 如果是点 对点的请求， 按 AS0N网络已有的点对点呼叫处理， 返回步骤 410 (步骤 420a) ； 如果是多方呼叫建立请求， 执行步骤 430; 如果是多方呼叫释放 请求， 执行步骤 440; 如果是多方呼叫修改请求且要增加被叫用户， 执行 步骤 450; 如果是多方呼叫修改请求且要释放部分被叫用户， 执行步骤 460； 如果是呼叫确认消息， 执行步骤 500;
步骤 430， NCC创建数目等于该多方呼叫被叫个数的呼叫实体， 然后 将该多方呼叫建立请求分解为同样数目的子呼叫建立请求， 向创建的各 呼叫实体发起子呼叫的建立， 这些呼叫实体按点对点的方式建立与对应 的被叫用户间的子呼叫， 并向 NCC返回成功指示消息或失败消息， 执行 步骤 470;
步骤 440， NCC找到已创建的对应于各个被叫用户的呼叫实体， 然后 将该多方呼叫释放请求分解为同样数目的子呼叫释放请求， 向这些呼叫 实体分别发起子呼叫的释放， 这些呼叫实体按点对点的方式释放与对应 被叫用户间的子呼叫， 并向 NCC返回成功指示消息或失败消息， 执行步 骤 470;
步骤 450，NCC根据要增加的被叫用户个数创建同样数目的呼叫实体， 然后将该呼叫修改请求转换为同样数目的子呼叫建立请求， 向新创建的 呼叫实体发起子呼叫的建立， 这些呼叫实体按点对点的方式建立与对应 被叫用户间的子呼叫， 并向 NCC返回成功指示消息或失败消息， 执行步 骤 470;
步骤 460， NCC根据要删除的被叫用户找到对应的呼叫实体， 然后将 该呼叫修改请求转换为同样数目的子呼叫释放请求， 向这些呼叫实体发 起子呼叫的释放， 这些呼叫实体按点对点的方式释放与对应被叫用户间 的子呼叫， 并向 NCC返回成功指示消息或失败消息， 执行步骤 470 ; ' 步骤 470， NCC判断是否所有子呼叫返回的都是成功指示消息， 如果 是， 执行下一步， 否则， 执行步骤 490 ; '
步骤 480， NCC向 CCC返回对其呼叫请求的成功指示消息， 返回步骤
410；
步骤 490， NCC向 CCC返回对其呼叫请求的失败消息 （也可以配置为 返回各个子呼叫的执行结果信息） ， 并删除其对应子呼叫建立失败或成 功释放的呼叫实体， 返回步骤 410 ;
步骤 500， NCC将收到的呼叫建立确认消息分解为多个子呼叫的确认 消息， 通过各个呼叫实体发送到各被叫用户侧的呼叫控制器， 返回步骤 410。
相应地， 可以用具有以下结构的 NCC来实现上述处理， 该 NCC包括 呼叫请求监测模块、 消息识别模块、 单方呼叫处理模块和多方呼叫处理 模块。 其中：
呼叫请求监测模块， 用于监测来自用户侧呼叫控制器 CCC 的呼叫请 求， 将收到的呼叫请求和呼叫建立确认消息交给消息识别模块；
消息识别模块，用于识别呼叫请求的类型，对于点对点的请求或确认 消息， 交给单方呼叫处理模块， 对于点对多点的请求或确认消息， 再分 为多方呼叫建立请求、 多方呼叫释放请求、 多方呼叫修改请求和多方呼 叫建立确认消息， 交给多方呼叫处理模块中的控制单元； 单方呼叫处理模块， 用于按 AS0N网络已有的点对点呼叫处理方式实 现单方呼叫； 多方呼叫处理模块进一步包括多方呼叫控制单元、 多方呼叫建立单 元、 多方呼叫释放单元和多方呼叫响应单元， 其中：
多方呼叫控制单元，用于在收到呼叫建立请求后，将该多方呼叫的被 叫用户个数指定为要创建的呼叫实体数， 然后激活呼叫建立单元； 在收 到呼叫释放请求后， 指定与该多方呼叫相关的呼叫实体， 然后激活呼叫 释放单元； 在收到呼叫修改请求后， 对增加被叫用户的修改请求， 将要 增加的被叫用户数指定为要创建的呼叫实体数， 然后激活呼叫建立单元， 对删除被叫用户的修改请求， 找到要删除被叫用户对应的呼叫实体， 然 后激活呼叫释放单元； 对于呼叫建立确认消息， 则直接通过相关呼叫实 体向被叫用户的呼叫控制器发送呼叫建立确认消息。
多方呼叫建立单元，用于创建指定数目的呼叫实体， 向这些呼叫实体 分别发起子呼叫的建立， 控制这些呼叫实体按点对点的方式建立与对应 被叫用户间的子呼叫， 并将子呼叫建立成功的指示消息或失败消息通知 多方呼叫响应单元；
多方呼叫释放单元， 用于向指定的呼叫实体分别发起子呼叫的释放， 控制这些呼叫实体按点对点的方式释放与对应被叫用户间的子呼叫， 并 将子呼叫释放成功的指示消息或失败消息通知多方呼叫响应单元；
多方呼叫响应单元，用于判断所指定创建或释放的呼叫实体是否都返 回了成功指示消息， 如果是， 向 CCC返回成功指示消息， 否则， 向 CCC 返回失败消息或各个子呼叫的执行结果信息， 并删除子呼叫建立失败或 已成功释放的呼叫实体。
在另一实施例中， 自动交换光网络只需实现多方呼叫的建立和释放， 无需与多方呼叫修改相关的流程和模块。
从上面具体实施方式和对比分析可知，本发明方法采用将一个多方呼 叫流程分解为多个子呼叫的处理方法， 解决了 ASON网络支持点对多点 业务呼叫的问题， 具备简洁、 可靠的优点。
工业实用性
本发明可以在 ASON网络中支持点对多点业务， 简洁、 可靠。

Claims

1、 一种自动交换光网络中多方呼叫的实现方法， 包括以下步骤：
( a) 入口网络呼叫控制器收到并识别出主叫用户侧呼叫控制器发送 的多方呼叫建立请求后， 根据被叫用户个数创建相同数目的呼叫实体， 然 后向所述各个呼叫实体分别权发起子呼叫的建立；
(b) 所述各个呼叫实体按点对点的方式建立与对应被叫用户间的子 呼叫，如果建立成功，向所述入口网络呼叫控制器返回呼叫建立指示消息， 否则返回失败消息；
( c) 所述各个呼叫实体均返回呼叫建立指示消息时， 所述入口网络 呼叫控制器向所述主叫用户侧呼叫控制器返回呼叫建立指示消息，多方呼 叫建立成功； 书
(d) 所述入口网络呼叫控制器收到并识别出所述主叫用户侧呼叫控 制器发送的该多方呼叫的释放请求后，分别向与该多方呼叫相关的呼叫实 体发起子呼叫的释放；
(e )所述呼叫实体按点对点的方式释放与对应被叫用户间的子呼叫， 如果释放成功， 向所述入口网络呼叫控制器返回呼叫释放指示消息， 否则 返回失败消息；
(f ) 所有子呼叫均返回呼叫释放指示消息时， 所述入口网络呼叫控 制器向所述主叫用户侧呼叫控制器返回呼叫释放指示消息，并删除所述呼 叫实体， 多方呼叫释放成功， 结束。
2、 如权利要求 1所述的多方呼叫的实现方法，
其特征在于， 还包括以下步骤：
( i ) 所述入口网络呼叫控制器收到并识别出所述主叫用户侧呼叫控 制器发送的增加 N个被叫用户的多方呼叫修改请求后，创建 N个呼叫实体， 然后分别向这 N个新创建的呼叫实体发起子呼叫的建立；
( j ) 所述 N个新创建的呼叫实体按点对点的方式建立与对应的新增 被叫用户间的子呼叫，如果建立成功， 向所述入口网络呼叫控制器返回呼 叫建立指示消息， 否则返回失败消息；
( k)所有新创建的呼叫实体均返回呼叫建立指示消息时， 所述入 口网络呼叫控制器向所述主叫用户侧呼叫控制器返回呼叫修改指示消 息， 多方呼叫修改成功， 结束。
3、 如权利要求 1或 2所述的多方呼叫的实现方法，
其特征在于， 还包括以下步骤：
(o )所述入口网络呼叫控制器收到并识别出所述主叫用户侧呼叫控 制器发送的删除 M个被叫用户的多方呼叫修改请求后，找到对应的 M个呼 叫实体， 然后分别向这 M个呼叫实体发起子呼叫的释放；
(p)所述 M个呼叫实体按点对点的方式释放与对应被叫用户间的子 呼叫，如果释放成功，向所述入口网络呼叫控制器返回呼叫释放指示消息， 否则返回失败消息；
(q)所述 M个呼叫实体均返回呼叫释放指示消息时， 所述入口网络 呼叫控制器向所述主叫用户侧呼叫控制器返回呼叫修改指示消息，并删除 该 M个呼叫实体， 多方呼叫修改成功， 结束。
4、 如权利要求 1或 2所述的多方呼叫的实现方法，
其特征在于， 当呼叫实体返回呼叫建立指示消息后， 所述入口网络呼 叫控制器还通过该呼叫实体将呼叫建立确认消息发送到对应被叫用户 的呼叫控制器。
5、 如权利要求 1所述的多方呼叫的实现方法，
其特征在于， 当有至少一个子呼叫建立失败时，所述入口网络呼叫控制器 向所述主叫用户侧呼叫控制器返回失败消息，并删除已成功建立的子呼叫 和其对应的呼叫实体。
6、 如权利要求 1所述的多方呼叫的实现方法，
其特征在于， 当有至少一个子呼叫建立失败时，所述入口网络呼叫控制器 向所述主叫用户侧呼叫控制器返回各个子呼叫建立的执行结果，保留已成 功建立的子呼叫和其对应的呼叫实体。
7、 如权利要求 1所述的多方呼叫的实现方法，
其特征在于， 当有至少一个子呼叫释放失败时， 所述入口网络呼叫控制器 向所述主叫用户侧呼叫控制器返回失败消息，并删除已成功释放的子呼叫 对应的呼叫实体。
8、 一种用于实现多方呼叫的自动交换光网络呼叫控制器， 包括呼叫 请求监测模块、 消息识别模块和单方呼叫处理模块，
其特征在于， 还包括多方呼叫处理模块， 其中：
所述消息识别模块还用于识别出多方呼叫建立请求和多方呼叫释放 请求， 交给所述多方呼叫处理模块处理；
所述多方呼叫处理模块进一步包括多方呼叫控制单元、多方呼叫建立 单元、 多方呼叫释放单元和多方呼叫响应单元， 其中：
所述多方呼叫控制单元，用于接收识别出的消息，对呼叫建立请求后， 将该多方呼叫的被叫用户个数指定为要创建的呼叫实体数，然后激活呼叫 建立单元； 在收到呼叫释放请求后， 指定与该多方呼叫相关的呼叫实体， 然后激活呼叫释放单元；
所述多方呼叫建立单元，用于创建指定数目的呼叫实体， 向这些呼叫 '实体分别发起子呼叫的建立，控制这些呼叫实体按点对点的方式建立与对 应被叫用户间的子呼叫，并将子呼叫建立成功的指示消息或失败消息通知 所述多方呼叫响应单元；
多方呼叫释放单元， 用于向指定的呼叫实体分别发起子呼叫的释放， 控制这些呼叫实体按点对点的方式释放与对应被叫用户间的子呼叫，并将 释放成功的指示消息或失败消息通知响应单元；
- 多方呼叫响应单元，用于判断所指定创建或释放的呼叫实体是否都返 回了成功指示消息， 如果是， 向主叫用户呼叫控制器返回成功指示消息， 否则， 返回失败消息或子呼叫的执行结果信息。
9、 如权利要求 8所述的自动交换光网络呼叫控制器， 其特征在于，所述消息识别模块还用于识别多方呼叫修改请求， 且所述多 方呼叫控制单元还用于在收到呼叫修改请求后，将要增加的被叫用户数指 定为要创建的呼叫实体数，然后激活呼叫建立单元或者， 找到要删除被叫 用户对应的呼叫实体， 然后激活呼叫释放单元。
10、 如权利要求 8所述的自动交换光网络呼叫控制器，
其特征在于，所述消息识别模块还用于识别多方呼叫建立确认消息， 且所 述多方呼叫控制单元还用于在收到呼叫建立确认消息后，直接通过相关呼 叫实体向被叫用户的呼叫控制器发送呼叫建立确认消息。
PCT/CN2005/000893 2005-06-21 2005-06-21 Procede de realisation d'un appel multipartie dans un reseau optique commute automatique et controleur d'appel pour ce procede WO2006136054A1 (fr)

Priority Applications (2)

Application Number Priority Date Filing Date Title
CN2005800475993A CN101112013B (zh) 2005-06-21 2005-06-21 自动交换光网络中多方呼叫的实现方法及其呼叫控制器
PCT/CN2005/000893 WO2006136054A1 (fr) 2005-06-21 2005-06-21 Procede de realisation d'un appel multipartie dans un reseau optique commute automatique et controleur d'appel pour ce procede

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/CN2005/000893 WO2006136054A1 (fr) 2005-06-21 2005-06-21 Procede de realisation d'un appel multipartie dans un reseau optique commute automatique et controleur d'appel pour ce procede

Publications (1)

Publication Number Publication Date
WO2006136054A1 true WO2006136054A1 (fr) 2006-12-28

Family

ID=37570079

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2005/000893 WO2006136054A1 (fr) 2005-06-21 2005-06-21 Procede de realisation d'un appel multipartie dans un reseau optique commute automatique et controleur d'appel pour ce procede

Country Status (2)

Country Link
CN (1) CN101112013B (zh)
WO (1) WO2006136054A1 (zh)

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP3160118B1 (en) * 2015-10-19 2019-12-04 Rebtel Networks AB System and method for setting up a group call
CN117478793A (zh) * 2022-07-22 2024-01-30 中兴通讯股份有限公司 语音通话方法、设备及存储介质

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2002051071A1 (en) * 2000-09-22 2002-06-27 Santera Systems Inc. System and method for distributed multi-party call control
CN1494302A (zh) * 2002-10-28 2004-05-05 深圳市中兴通讯股份有限公司 一种在软交换系统中实现多方呼叫业务的方法

Family Cites Families (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6647020B1 (en) * 1999-12-17 2003-11-11 Motorola, Inc. Methods for implementing a talkgroup call in a multicast IP network

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2002051071A1 (en) * 2000-09-22 2002-06-27 Santera Systems Inc. System and method for distributed multi-party call control
CN1494302A (zh) * 2002-10-28 2004-05-05 深圳市中兴通讯股份有限公司 一种在软交换系统中实现多方呼叫业务的方法

Also Published As

Publication number Publication date
CN101112013B (zh) 2012-05-30
CN101112013A (zh) 2008-01-23

Similar Documents

Publication Publication Date Title
USRE46273E1 (en) Method of establishing a connection on a communication network
JP4470963B2 (ja) ゲートウェイ装置、ｏｎｔ及びｐｏｎシステム
US6724876B2 (en) Method and apparatus for effecting telecommunications service features using call control information extracted from a bearer channel in a telecommunications network
JPH0936917A (ja) 個々の通信端末に調節可能な帯域幅を提供するためのマルチメディア会議呼出
US20070071202A1 (en) Server apparatus
EP1723770A1 (en) Method for establishing a call in a telecommunications network; telecommunications network; and controlling device for packet networks
EP1329054B1 (en) System and method for distributed multi-party call control
JP2006101528A (ja) ループ通信チャネルの検出
WO2006136054A1 (fr) Procede de realisation d'un appel multipartie dans un reseau optique commute automatique et controleur d'appel pour ce procede
US6925082B2 (en) ATM packet access gateway
WO2009059537A1 (fr) Procédé, dispositif et système pour commander un terminal mobile afin de transférer un appel
JP4343189B2 (ja) サーバ装置
EP1965579A1 (en) Method, exchange and system for reselecting route in Bearer-Independent Call Control Call Mediation Node
JP2001223746A (ja) ネットワークシステムの呼設定方法
JP4339160B2 (ja) Ｉｐ電話における呼び返しシステムおよび方法、プログラムおよび記録媒体
US7756260B2 (en) Method for providing features to the user of a telephone, a central unit and a telecommunication system therefor
JP3928926B2 (ja) テレコミュニケーションシステムにおけるエコー打消し装置の制御
BRPI0807169A2 (pt) Método, sistema e dispositivo de ligação de chamadas
JP2010087973A (ja) 呼制御方法、通信システムおよび情報処理装置
JP2008252815A (ja) ボタン電話装置
WO2007059646A1 (en) Protection restoration method for multicast service connection in the automatic switched optical network
KR100303642B1 (ko) 호 전환 시 경로최적화 방법
JP2878375B2 (ja) 通話リンク制御方式
EP1943825B1 (en) System and method for managing the replacement of an existing subscriber call connection by a call waiting party
EP2538645A1 (en) A telephone conference system with automatic recovery

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: 200580047599.3

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

122 Ep: pct application non-entry in european phase

Ref document number: 05759366

Country of ref document: EP

Kind code of ref document: A1