CN101340490B - Multi-part calling method and system thereof - Google Patents

Abstract

The invention relates to the communication field, and discloses a multiparty call method and system thereof, so that the interface between the bottom layer network and the upper layer application can support adding a call initiated from the network side to an existing multiparty call. In the present invention, when a call request from the network side is received, a leg is created for the party that initiates the call request in the underlying network, and if the call ID in the call request is the same as the existing call ID, then the created leg is added to the existing call ID. There is a call, and the upper layer application is notified that a new leg joins the existing call. The SCS may judge whether the call ID in the call request is the same as the existing call ID; or the upper layer application may judge whether the call ID in the call request is the same as the existing call ID. The created leg and the existing called leg can be located in the same or different SCS.

Description

Multi-party calling method and system thereof

technical field

The invention relates to the communication field, in particular to the multi-party calling technology.

Background technique

With the increasing demand for new services and the increasing proportion of calls involving intelligent services in telecommunication services, the bottleneck of traditional centralized intelligent network processing capabilities is becoming more and more prominent. In terms of scalability and rapid response It is increasingly unable to meet the growing business needs.

On the other hand, operators have increasingly strong demands for rapid service development, while traditional service development technologies are based on signaling protocols, and different vendors have defined their own different service development models. The uniqueness and professionalism of the technology make the service development technology too closed, and the services of different manufacturers cannot be transplanted, let alone open to third parties, so it cannot meet the needs of operators for rapid service development.

In order to solve the above problems, operators have introduced interfaces between the underlying network and upper-layer applications, such as open interfaces such as Parlay, so that various capabilities in the underlying network, such as call control capabilities, playback and number collection capabilities, and conference control Capabilities, etc., are opened in the form of abstract interfaces, and at the same time, various accesses can be effectively controlled, so as to further promote business development on the premise of ensuring network security. In this way, both operators and third-party service providers follow a set of unified standard interfaces to develop value-added services, so that the developed services can run on all platforms that follow open interface standards. The following uses the Parlay interface as an example for further description.

In the Parlay interface, the call control function is the most important function, multi-party call control (Multi-Party Call Control, referred to as "MPCC"), multimedia call control (Multi-MediaCall Control, referred to as "MMCC") and conference call control (Conference Call Control, referred to as "CCC") all involve scenarios involving multiple parties, and have considerable applications in the industry. The relationship between call control in the Parlay interface is shown in Figure 1. Generic Call Control (GCC for short) provides a basic call control interface that supports two-party calls; MPCC provides a multi-party call control interface that supports multiple parties MMCC adds media control capabilities on the MPCC interface; CCC adds the ability to support conferences on the basis of MMCC.

In the current Parlay specification, MPCC defines a set of interfaces that support multi-party calls, providing services with the ability to create and control multi-party calls. These key capabilities include:

(1) Notify the new call on the network side to the upper layer application, which corresponds to the reportNotification interface function call in the Parlay specification.

(2) Create a multi-party call, which corresponds to the function call of the createCall interface in the Parlay specification.

(3) Create a calling leg connected to one party (that is, an instance of the calling party in the underlying network), corresponding to the function call of the RouteReq interface in the Parlay specification.

(4) Release the call or release the call leg of one party, which corresponds to the function call of the release interface in the Parlay specification.

(5) The event reported by the network side of the call leg of one party is monitored, which corresponds to the function call of the eventReportReq interface in the Parlay specification.

(6) Start and stop the media connection of one party's call leg, which corresponds to the attachMediaReq and dettachMediaReq interface function calls in the Parlay specification.

Based on the existing Parlay MPCC interface standard, the service can realize two-party and multi-party call scenarios. Among them, the multi-party call scenario is shown in Figure 2. User A initiates a call on the network side, MPCC Service Capability Server (Service Capability Server, "SCS") creates a call legA and the call object call, and the application side executes the business logic, creating a call to The connection of user B calls legB, and the application side creates a connection to legC to establish a multi-party call.

However, the inventors of the present invention found that the current MPCC capability of Parlay does not support adding a call initiated from the network side to an existing call. For example, in the scenario shown in Figure 3, user A initiates a call on the network side, MPCC SCS creates a call legA and the call object call, and the application side executes business logic to create a connection call legB to user B. At this time, user C dials the access number, hoping to join the multi-party call between A and B, but the current MPCC capability cannot support this scenario.

In addition, the current MPCC capability does not consider how to support the situation that new call legs are allowed to be distributed in different SCSs in a distributed scenario.

Contents of the invention

The main technical problem to be solved by the embodiments of the present invention is to provide a multi-party call method and system thereof, so that the interface between the underlying network and the upper-layer application can support adding a call initiated from the network side to an existing multi-party call.

In order to solve the above-mentioned technical problem, the embodiment of the present invention provides a kind of multi-party calling method, comprises the following steps:

When a call request from the network side is received, an instance is created on the underlying network for the party that initiated the call request. If the call ID in the call request is the same as the existing call ID, the instance is added to the existing call and the upper layer is notified A new instance of the application joins the existing call.

Embodiments of the present invention also provide a multi-party call system, including:

The creation unit is used to create an instance for the party that initiates the call request on the underlying network when receiving a call request from the network side;

A judging unit, configured to judge whether the call identifier in the call request is the same as the existing call identifier;

The adding unit is used for adding the instance created by the creation unit to the existing call when the judging unit judges that the call identifier in the call request is the same as the existing call identifier;

The notification unit is used to notify the upper layer application that a new instance joins the existing call after the joining unit adds the instance to the existing call.

Compared with the prior art, the embodiment of the present invention has the main difference and its effects in that:

When a call request from the network side is received, an instance leg is created on the underlying network for the party that initiated the call request. If the call ID in the call request is the same as the existing call ID, the created leg is added to the existing call. And notify the upper application that there is a new leg joining the existing call. The interface between the bottom layer network and the upper layer application supports adding a call initiated from the network side to an existing multi-party call.

Description of drawings

FIG. 1 is a schematic diagram of a call control relationship of a Parlay interface in the prior art;

Fig. 2 is the scene schematic diagram of the interface standard of existing Parlay MPCC based on the multi-party call in the prior art;

FIG. 3 is a schematic diagram of adding a call initiated by the network side to an existing call in the prior art;

Fig. 4 is a flowchart of a multi-party call method according to the first embodiment of the present invention;

Fig. 5 is a schematic diagram of a multi-party calling method according to a first embodiment of the present invention;

Fig. 6 is a schematic diagram of a multi-party call method according to a second embodiment of the present invention;

Fig. 7 is a flowchart of a multi-party call method according to a third embodiment of the present invention;

Fig. 8 is a schematic diagram of a multi-party call method according to a third embodiment of the present invention;

Fig. 9 is a schematic diagram of a multi-party calling method according to a fourth embodiment of the present invention;

Fig. 10 is a schematic structural diagram of a multi-party call system according to a fifth embodiment of the present invention.

Detailed ways

In order to make the purpose, technical solution and advantages of the present invention clearer, the following will further describe the implementation of the present invention in detail in conjunction with the accompanying drawings.

The first embodiment of the present invention relates to a multi-party call method. For a multi-party call, the underlying network will create an instance for each party of the call, which is called a leg. In this embodiment, after the SCS in the underlying network creates an instance leg for the party that initiates the call request , to determine whether the call ID in the call request is the same as the existing call ID, if they are the same, add the created leg to the existing call, and notify the upper layer application that a new leg will join the existing call, the specific process is shown in the figure 4.

When receiving a call request from the network side, enter step 410 to create a call leg. Specifically, when receiving a call request from the network side, the SCS of the underlying network creates a leg for the party that initiates the call request.

Next, enter step 420, the SCS searches for the calling identifier. Specifically, the SCS looks up the call ID in the call request in the existing calls.

Then, enter step 430, the SCS judges whether this call identification already exists, promptly judges whether the call identification in the call request is identical with the existing call identification, if it is determined that the call identification in the call request is identical with the existing call identification, then enters Step 440, if it is determined that the call ID in the call request is different from the existing call ID, then go to step 460.

That is to say, in this embodiment, the SCS needs to save the existing call identifiers, for example, save the existing call identifiers in a form of a table. After the SCS creates a leg for the party that initiates the call request, it searches the table for the call identifier in the current call request. If the call identifier in the current call request is found in the table, it means that the call identifier in the current call request is The call ID is the same as the existing call ID, and enters step 440. If the call ID in the current call request is not found in the table, it means that the call ID in the current call request is different from the existing call ID, and enters step 460.

In step 440, the SCS associates the created leg with the existing call. Specifically, after the SCS determines that the call ID in the call request is the same as the existing call ID, it associates the leg created in step 410 with the found existing call that is identical to the call ID in the call request, The leg to be created joins the existing call. In this embodiment, the leg created in step 410 is located in the same SCS as the existing call leg. For example, as shown in Figure 5, the leg created in step 410 is leg A, the call ID in the call request is identical to that of existing call call 1, and both leg B and leg C have joined the existing call call 1. Then, in this step, the SCS needs to associate leg A with the existing call 1, and the leg A to be created will be added to the existing call 1.

The SCS can add the created leg to the existing call through the function call of the Parlay interface between the bottom layer network and the upper layer application. The function of the Parlay interface called in this step is further introduced below.

The function of the Parlay interface called in this step is used for internal communication between calls in the SCS. For example, the source call calls the interface of the target call, and the reference of the relevant leg is passed to the target call object, and the subsequent target call object manages this leg life cycle. Its method can be defined as: addParty(srcCallLeg: in IpCallLegRef): TpSessionID. Among them, the definition of each parameter is shown in Table 1.

parameter name Parameter Type note srcCallLeg IpCallLegRef reference to the transferred leg return value TpSessionID The identifier that the target call object reassigns to the leg

Table 1

Next, enter step 450, the SCS notifies the upper layer application that a new leg has joined the existing call, and the SCS can call the Parlay interface function between the underlying network and the upper layer application to notify the upper layer application that a new leg has joined the existing call . For the above case, the SCS notifies the upper layer application that the leg A is added to the existing call 1 through the function call of the Parlay interface between the underlying network and the upper layer application. The caller can be called SCS Call, and the called party can be called: App Call. The function of the Parlay interface called in this step is further introduced below.

The function of the Parlay interface called in this step is used to notify the upper layer application through this interface that a new leg is added to the call when a new leg is added in a call. Its method can be defined as: partyJoined(callSessionID : in TpSessionID, callLeg : in TpCallLegIdentifier, eventInfo: in TpJoinEventInfo): IpAppCallLegRef. Among them, the definition of each parameter is shown in Table 2.

parameter name Parameter Type Notes callSessionID TpSessionID The definition of the session identifier in the Parlay specification indicates that the source call

called session id callLeg TpCallLegIdentifier A reference to the new party leg eventInfo TpJoinEventInfo Additional information return value I pAppCallLegRef The object created by the business corresponding to the SCSleg

Table 2

If in step 430, the SCS determines that the call identifier in the call request is different from the existing call identifier, then it goes to step 460. In step 460, the SCS creates a new call, associating the leg created in step 410 with the new call.

Next, enter step 470, the SCS notifies the upper layer application that there is a new call.

It is not difficult to find that in this embodiment, if the call ID in the call request is the same as the existing call ID, the leg created for the requester can be directly added to the existing call, and the upper layer application will be notified that there is a new leg Join the existing call. Therefore, the Parlay interface between the bottom layer network and the upper layer application can support adding a call initiated from the network side to an existing multiparty call.

The second embodiment of the present invention relates to a multi-party call method. This embodiment is substantially the same as the first embodiment, the difference is that in the first embodiment, the leg created by the SCS is located in the same In the SCS, in this embodiment, the leg created by the SCS is located in a different SCS than the existing call leg, and the call identifier is the reference identifier of the object.

Specifically, in the original Parlay specification, the Session ID (session identifier) is usually used to identify the Call or Leg in the interface, but in a distributed scenario (that is, different Legs are distributed in different SCS nodes), often a Calls cannot be directed to this session directly via the session ID. Therefore, in this embodiment, the reference identifier of the object is used instead of the session identifier. The object may be a distributed object, and the session is directly located through the reference identifier.

As shown in Figure 6, when a call request from the network side is received, a new leg is created for the requester, called leg A, in SCS1, and the call ID in the call request is found to be the same as that of the existing call 1 The call IDs are the same (the SCS1 may need to exchange information with other SCSs, and it is found that the call ID in the call request is the same as the existing call ID), the existing call call 1 is created in SCS2, and there are currently leg B and Leg C joins the existing call call 1, and both leg B and leg C are located in SCS2.

Since the legA created by SCS 1 is located in a different SCS from the existing leg calling call 1 (that is, leg B and leg C), and in the scenario where different Legs are distributed in different SCS nodes, a call often cannot pass The session ID targets this session directly. Therefore, in this embodiment, the reference identifier of the object needs to be used instead of the session identifier, that is, the call is identified through the reference of the object, so as to locate the call in a different SCS.

It can be seen that the created leg and the existing call leg can be located in the same SCS or in different SCSs, and the call identifier is a reference to an object, so that the embodiment of the present invention can be applied to a wider range of scenarios.

The third embodiment of the present invention relates to a multi-party calling method. In this embodiment, the SCS in the underlying network creates a new call after creating an instance leg for the party that initiates the call request, and connects the created leg with the new associated with the new call, and notify the upper application of the new call. After receiving the notification of a new call, the upper-layer application judges whether the call ID in the new call is the same as the existing call ID, and if they are the same, enter the created leg into the existing call, and notify the upper layer The steps of applying a new leg to join the existing call, the specific process is shown in FIG. 7 .

In step 701, the SCS creates a leg for the party that initiates the call request. This step is exactly the same as step 410 and will not be repeated here.

Next, in step 702 and step 703, the SCS creates a new call and associates the leg created in step 701 with the new call. For example, as shown in Figure 8, the leg created in step 701 is leg A, and in steps 702 and 703, the SCS creates a new call, the new call is call 2, and leg A is associated with call 2 .

Next, enter step 704, the SCS notifies the upper layer application that there is a new call.

Next, in step 705 and step 706, the upper layer application searches for the call identifier of the new call, and judges whether the call identifier in the new call is the same as the existing call identifier.

Specifically, the upper-layer application needs to save the call ID of the existing call, such as saving the call ID of the existing call in the form of a table, and after receiving the notification of a new call, look up the call ID in the table. The call ID for the new call. If find the call identification of this new call in this table, then explain that the call identification of this new call is identical with existing call identification, enter step 707, if do not find the call identification of this new call in this table, then It indicates that the call identifier of the new call is different from the existing call identifier, and enters step 710, where the upper layer application processes the new call.

In step 707, the new call is transferred to the existing call. For the above case, it is assumed that the call ID of the new call 2 is the same as that of the existing call 1, and leg B and leg C have joined the existing call 1. Then, in this step, the new call call 2 needs to be transferred to the existing call call 1. In this embodiment, the leg A created in step 701 is located in the same SCS as the existing call leg B and leg C.

Specifically, the new call can be transferred to the existing call through the function call of the Parlay interface between the bottom layer network and the upper layer application. The caller is the service, and the called party is the call object of the source call. The function of the Parlay interface called in this step is further introduced below.

The Parlay interface function called in this step is used to transfer the specified call leg from one call to another call. Its method can be defined as: moveCallLeg(callSessionID: inTpSessionID, targetCall: in IpMultiPartyCallRef, callLeg: in TpSessionID): void. Among them, the definition of each parameter is shown in Table 3.

parameter name Parameter Type Notes callSessionID TpSessionID The definition of session ID in the Parlay specification, indicating the session ID of the source call targetCall IpMultiPartyCallRef Leg needs to be transferred to the application reference of the target call object callLeg TpSessionID Call the ID of the Leg interface exception TpCommonExceptions Definition of interface exceptions in Parlay interface exception P_INVALID_SESSION_ID Invalid sessionID exception

table 3

It should be noted that after the transfer is completed, the new call established in step 702 needs to be released.

Next, enter step 708, add the created leg to the existing call. For the above case, in this step, leg A needs to be added to the existing call call 1 through the function call of the Parlay interface between the underlying network and the upper-layer application. The specific method is the same as the function call method of the Parlay interface described in step 440. Same, no more details here.

Next, enter step 709, and notify the upper layer application that a new leg joins the existing call. For the above case, in this step, it is necessary to call the Parlay interface function between the underlying network and the upper-layer application to notify the upper-layer application that a new leg A joins the existing call call 1. The specific method is the same as the Parlay interface described in step 450. The method of calling the function is the same and will not be repeated here.

It can be seen that in this embodiment, the upper layer application can judge whether the call ID in the call request is the same as the existing call ID, which provides a flexible implementation mode for the present invention.

The fourth embodiment of the present invention relates to a multi-party call method. This embodiment is substantially the same as the third embodiment, the difference is that in the third embodiment, the leg created by the SCS is located in the same In the SCS, in this embodiment, the leg created by the SCS is located in a different SCS than the existing call leg, and the call identifier is the reference identifier of the object.

As shown in Figure 9, in this embodiment, the newly created leg for the party that initiates the call request is legA. In SCS1, a new call call 2 is created, the leg A is associated with call 2, and the upper layer application is notified There is a new call. The upper-layer application searches for the call ID of call2. If it is determined that the call ID of the new call 2 is the same as that of the existing call 1, leg B and leg C have joined the existing call 1, and the leg B and leg C are respectively located in SCS2, add call2 to call1, add legA to call2, and release call2. Wherein, the call identifier to be searched is the reference identifier of the object, and by using the reference identifier of the object to locate calls in different SCSs, this embodiment can support the solution that different legs are distributed in different SCS nodes.

The fifth embodiment of the present invention relates to a multi-party call system, as shown in FIG. 10 , comprising: a creating unit, configured to create an instance leg for the party that initiated the call request on the underlying network when receiving a call request from the network side; Judging unit, used for judging whether the call ID in the call request is the same as the existing call ID; adding unit, used for judging that the call ID in the call request is the same as the existing call ID, adding the call ID created by the creating unit The leg is added to the existing call; the notification unit is used to notify the upper layer application that a new instance joins the existing call after the adding unit adds the instance to the existing call. The interface between the bottom layer network and the upper layer application supports adding a call initiated from the network side to an existing multi-party call.

Wherein, the judging unit may be located in the SCS in the underlying network, and the judging unit judges whether the calling ID in the call request is the same as the existing calling ID through the calling ID list of the existing call stored in the SCS. When the judging unit judges that the call identifier in the call request is the same as the existing call identifier, it adds the created leg to the existing call through the function call of the Parlay interface between the bottom layer network and the upper layer application. The notification unit calls the function of the Parlay interface between the bottom layer network and the upper layer application, and notifies the upper layer application of the result of adding the created leg to the existing call by the joining unit.

Alternatively, the creation unit is also used to create a new call, and associate the leg created by the creation unit for the party that initiates the call request with the new call. The notification unit is also used to notify the upper layer application of the new call created by the creation unit. The judging unit is located in the upper-layer application, and after the upper-layer application receives a notification of a new call, the judging unit judges whether the call ID in the new call is based on the call ID list of the existing call saved in the upper-layer application. Same as the existing call ID.

The system in this embodiment may also include a transfer unit, which is used to transfer the transfer between the underlying network and the upper-layer application when the judging unit is located in the upper-layer application and the judging unit judges that the call identifier in the new call is the same as the existing call identifier. Call the function of the Parlay interface between them, transfer the new call to the existing call, and output the transfer result to the joining unit. After the transferring unit transfers successfully, the joining unit adds the created leg to the existing call through the function call of the Parlay interface between the bottom layer network and the upper layer application. The notification unit notifies the upper layer application of the result of adding the created leg to the existing call by the joining unit through the function call of the Parlay interface between the bottom layer network and the upper layer application.

It should be noted that, in this embodiment, the leg created by the creating unit and the existing call leg may be located in the same SCS, or may be located in different SCSs. In the case that the leg created by the creation unit is located in a different SCS from the leg of the existing call, the call ID is the reference ID of the object, so that the call in a different SCS can be successfully located.

To sum up, in the embodiment of the present invention, when a call request from the network side is received, an instance leg is created on the underlying network for the party that initiates the call request. If the call ID in the call request is the same as the existing call ID, Add the created leg to the existing call, and notify the upper layer application that a new leg is added to the existing call. The interface between the bottom layer network and the upper layer application supports adding a call initiated from the network side to an existing multi-party call.

The SCS may judge whether the call ID in the call request is the same as the existing call ID; or the upper layer application may judge whether the call ID in the call request is the same as the existing call ID. This enables the implementation of the present invention to be flexibly implemented.

The created leg and the existing called leg can be located in the same SCS; or, the created leg and the existing called leg are located in different SCSs, and the calling identifier is an object reference, so that the embodiment of the present invention can be applied to more A wide range of scenarios, and, for the case where the created leg and the existing call leg are located in different SCSs, the call can be identified through the reference of the object, so as to smoothly locate the call in a different SCS, for this case Implementation provides feasibility.

Although the present invention has been illustrated and described with reference to certain preferred embodiments thereof, it will be understood by those skilled in the art that various changes in form and details may be made therein without departing from the present invention. The spirit and scope of the invention.

Claims (14)

1. A multi-party calling method, comprising the steps of:

when a call request of a network side is received, an example is created for a party initiating the call request in an underlying network;

if the calling identifier in the calling request is the same as the existing calling identifier, adding the instance into the existing calling;

and notifies the upper layer application that a new instance has been added to the existing call.

2. The multi-party calling method according to claim 1, further comprising the following steps after the step of creating an instance for the party originating the call request:

and judging whether the call identifier in the call request is the same as the existing call identifier by a Service Capability Server (SCS) in the underlying network.

3. The multi-party calling method according to claim 1, further comprising the following steps after the step of creating an instance for the party originating the call request:

the underlying network creating a new call, associating the instance with the new call, and notifying the upper layer application of the new call;

and after receiving the notice of the new call, the upper layer application judges whether the call identifier in the new call is the same as the existing call identifier.

4. The multi-party calling method according to claim 3, further comprising the following sub-steps before said step of adding the instance to the existing call after said upper layer application determines that the call identifier in the new call is the same as the existing call identifier:

transferring the new call to the existing call through an interface function call between the underlying network and the upper application.

5. The multiparty calling method according to claim 2 or 4, wherein the instance is added to the existing call in the following way: adding the instance to the existing call through an interface function call between the underlay network and the upper layer application;

the way to inform the upper layer application that there is a new instance to join the existing call is as follows: and informing the upper layer application that a new instance is added into the existing call through interface function call between the underlying network and the upper layer application.

6. The multiparty calling method according to claim 4, further comprising the step, after the step of transferring said new call into said existing call, of:

releasing the new call.

7. The multi-party calling method according to claim 5, wherein the interface between the underlying network and the upper application is a Parlay interface.

8. The multiparty calling method according to any of the claims 1 to 4, 6, wherein said created instance is located in the same service capability server as the instance of said existing call; or,

the created instance and the existing call instance are located in different service capability servers, and the call identifier is a reference identifier of an object.

9. A multi-party call system, comprising:

the device comprises a creating unit, a calling unit and a calling unit, wherein the creating unit is used for creating an example for a party initiating a calling request on an underlying network when the calling request of a network side is received;

a judging unit, configured to judge whether a call identifier in the call request is the same as an existing call identifier;

a joining unit, configured to join the instance created by the creating unit to an existing call when the determining unit determines that the call identifier in the call request is the same as the existing call identifier;

and the notification unit is used for notifying the upper layer application that a new instance is added into the existing call after the addition unit adds the instance into the existing call.

10. The multi-party calling system according to claim 9, wherein the determining unit is located in a service capability server in the underlay network;

the joining unit joins the instance to the existing call through interface function call between the underlying network and the upper application when the judging unit judges that the call identifier in the call request is the same as the existing call identifier;

and the notification unit notifies the upper layer application of the result of adding the instance into the existing call by the adding unit through the interface function call between the underlying network and the upper layer application.

11. The multi-party calling system according to claim 9, wherein the creating unit is further configured to create a new call and associate an instance created by the creating unit for the party initiating the call request with the new call;

the notifying unit is further configured to notify the upper layer application of the new call created by the creating unit;

the judging unit is located in the upper layer application, and after the upper layer application receives the notification of the new call, the judging unit judges whether the call identifier in the new call is the same as the existing call identifier.

12. The multi-party calling system of claim 11, further comprising:

a transfer unit, configured to transfer the new call to an existing call through interface function call between the underlying network and the upper application when the determination unit determines that the call identifier in the new call is the same as the existing call identifier, and output the transfer result to the joining unit;

the joining unit joins the instance to the existing call through interface function call between the underlying network and the upper application after the transfer unit successfully transfers the instance;

and the notification unit notifies the upper layer application of the result of adding the instance into the existing call by the adding unit through the interface function call between the underlying network and the upper layer application.

13. The multi-party calling system according to any of the claims 9 to 12, wherein the instance created by the creating unit is located in the same service capability server as the instance of the existing call; or,

the instance created by the creating unit and the instance of the existing call are located in different service capability servers, and the call identifier is a reference identifier of an object.

14. The multi-party call system according to claim 10 or 12, wherein the interface between the underlying network and the upper application is a Parlay interface.

Images