CN101340490B - Multi-part calling method and system thereof - Google Patents
Multi-part calling method and system thereof Download PDFInfo
- Publication number
- CN101340490B CN101340490B CN2007101296008A CN200710129600A CN101340490B CN 101340490 B CN101340490 B CN 101340490B CN 2007101296008 A CN2007101296008 A CN 2007101296008A CN 200710129600 A CN200710129600 A CN 200710129600A CN 101340490 B CN101340490 B CN 101340490B
- Authority
- CN
- China
- Prior art keywords
- call
- existing
- identifier
- instance
- unit
- Prior art date
- Legal status (The legal status 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 status listed.)
- Expired - Fee Related
Links
- 238000000034 method Methods 0.000 title claims abstract description 31
- 230000000977 initiatory effect Effects 0.000 claims description 13
- 238000012546 transfer Methods 0.000 claims description 12
- 238000004891 communication Methods 0.000 abstract description 3
- 238000010586 diagram Methods 0.000 description 8
- 238000011161 development Methods 0.000 description 7
- 101100072644 Saccharomyces cerevisiae (strain ATCC 204508 / S288c) INO2 gene Proteins 0.000 description 4
- 101100454372 Saccharomyces cerevisiae (strain ATCC 204508 / S288c) LCB2 gene Proteins 0.000 description 4
- 101100489624 Saccharomyces cerevisiae (strain ATCC 204508 / S288c) RTS1 gene Proteins 0.000 description 4
- 238000005516 engineering process Methods 0.000 description 4
- 101150080315 SCS2 gene Proteins 0.000 description 2
- 230000000694 effects Effects 0.000 description 1
- 230000003993 interaction Effects 0.000 description 1
- 238000012544 monitoring process Methods 0.000 description 1
- 238000012545 processing Methods 0.000 description 1
- 230000001737 promoting effect Effects 0.000 description 1
- 230000011664 signaling Effects 0.000 description 1
- 239000011800 void material Substances 0.000 description 1
Images
Landscapes
- Exchange Systems With Centralized Control (AREA)
- Telephonic Communication Services (AREA)
Abstract
The invention relates to the communication field and discloses a multi-party calling method and a system thereof, thereby leading an interface which is arranged between an underlying network and an upper layer application to support that a call which is initiated from a network side joins in the existing multi-party call. When a call request of the network side is received, the underlying network creates a leg for a party which initiates the call request, if a call identifier in the call request is the same with the existing call identifier, the created leg joins in the existing call, and the information of joining the new leg in the existing call is notified to the upper layer application. Whether the call identifier in the call request is the same with the existing call identifier or not can be judged by SCS; or whether the call identifier in the call request is the same with the existing call identifier or not can be judged by the upper layer application. The created leg and the leg of the existing call can be positioned in the same or different SCS.
Description
Technical Field
The invention relates to the field of communication, in particular to a multi-party calling technology.
Background
With the increasing demand of new services and the increasing proportion of calls related to intelligent services in telecommunication services, the bottleneck of the processing capacity of the traditional centralized intelligent network becomes more and more prominent, and the increasing service demand cannot be met in the aspects of expandability and quick response.
On the other hand, the operator has a stronger and stronger demand for rapid service development, while the traditional service development technology is established on the signaling protocol, and different manufacturers define different service development modes, and because of the uniqueness and the specialty of the development technology, the service development technology is too closed, and the services of different manufacturers cannot be transplanted and opened for the use of a third party, so that the demand of the operator for rapid service development cannot be met.
In order to solve the above problems, operators introduce interfaces between the underlying network and the upper layer applications, such as Parlay and other open interfaces, so that various capabilities in the underlying network, such as call control capability, number playing and receiving capability, conference control capability and the like, can be opened in an abstract interface mode, and meanwhile, various accesses can be effectively controlled, thereby further promoting the development of services on the premise of ensuring network security. Therefore, no matter the operator or a third-party service provider, the value-added service is developed by following a set of unified standard interfaces, so that the developed service can be operated on all platforms following the open interface standard. The Parlay interface is further described below as an example.
In the Parlay interface, the Call Control function is the most important function, and Multi-Party Call Control (MPCC), multimedia Call Control (MMCC), and Conference Call Control (CCC) are all related to the Multi-Party participation scenario, and have a considerable application in the industry. The relationship of Call Control in Parlay interface is shown in fig. 1, and General Call Control (GCC) provides a basic Call Control interface to support the Call between two parties; the MPCC provides a control interface of multi-party call and supports the call of multi-party; the MMCC is arranged on an interface of the MPCC, and the media control capability is increased; CCC adds the ability to support conferences based on the MMCC.
In the currently existing Parlay specification, MPCC defines a set of interfaces supporting multi-party calls, providing services with the ability to create and control multi-party calls. These key capabilities include:
(1) and informing the upper application of the new call of the network side, wherein the new call corresponds to the report notification interface function call in the Parlay specification.
(2) A multi-party call is created corresponding to the createCall interface function call in the Parlay specification.
(3) Creating a call leg (i.e., an instance of a party to the call in the underlay network) that connects to a party corresponds to a RouteReq interface function call in the Parlay specification.
(4) And releasing the call or releasing the call leg of one party, wherein the call corresponds to a release interface function call in Parlay specifications.
(5) And monitoring a network side report event of a calling leg of one party, wherein the event corresponds to an eventReportReq interface function call in Parlay specifications.
(6) The media connection of a party's call leg is started and stopped, corresponding to the attachMediaReq, dettachmedia req interface function calls in the Parlay specification.
Based on the existing interface standard of Parlay MPCC, the service can realize the scene of two-party and multi-party call. A multi-party call scenario is shown in fig. 2, where a user a initiates a network-side call, an MPCC Service Capability Server (SCS) creates a call leg a and a call object call, an application side executes Service logic, creates a connection call leg B to a user B, and then creates a connection to a leg c to establish a multi-party call.
However, the inventor of the present invention finds that the MPCC capability of Parlay does not support adding a call originated from the network side to an existing call. For example, in the scenario shown in fig. 3, a user a initiates a network-side call, an MPCC SCS creates a call leg a and a call object call, an application side executes service logic, and creates a connection call leg B to a user B. At this time, the user C dials the access number and wants to join the multiparty call between a and B, but the current MPCC capability cannot support the scenario.
In addition, the current MPCC capability also does not consider how to support the case where new call leg is allowed to be distributed in different SCS in the distributed scenario.
Disclosure of Invention
The main technical problem to be solved by the embodiments of the present invention is to provide a multi-party calling method and system thereof, so that an interface between an underlying network and an upper application can support adding a call initiated from a network side into an existing multi-party call.
In order to solve the above technical problem, an embodiment of the present invention provides a multiparty calling method, including the following steps:
when a call request of a network side is received, an instance is created for a party initiating the call request in the bottom layer network, if the call identifier in the call request is the same as the existing call identifier, the instance is added to the existing call, and the upper layer application is informed that a new instance is added to the existing call.
The embodiment of the present invention also provides a multi-party calling 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;
the judging unit is used for judging whether the calling identifier in the calling request is the same as the existing calling identifier or not;
the joining unit is used for joining the instance created by the creating unit into the existing call 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 is used for notifying the upper layer application that a new instance is added into the existing call after the adding unit adds the instance into the existing call.
Compared with the prior art, the implementation mode of the invention has the main differences and the effects that:
when a call request of a network side is received, an example leg is created for a party initiating the call request in an underlying network, if a call identifier in the call request is the same as an existing call identifier, the created leg is added to the existing call, and an upper layer application is informed that a new leg is added to the existing call. So that the interface between the underlying network and the upper layer application supports the joining of calls originating from the network side into existing multiparty calls.
Drawings
Fig. 1 is a schematic diagram of a call control relationship of a Parlay interface in the prior art;
FIG. 2 is a scene diagram illustrating a multi-party call based on the existing Parlay MPCC interface standard in the prior art;
fig. 3 is a schematic diagram illustrating a prior art scenario of adding a call initiated by a network side to an existing call;
fig. 4 is a flowchart of a multiparty calling method according to a first embodiment of the present invention;
fig. 5 is a diagram illustrating a multiparty calling method according to a first embodiment of the present invention;
fig. 6 is a diagram illustrating a multiparty calling method according to a second embodiment of the present invention;
fig. 7 is a flowchart of a multiparty calling method according to a third embodiment of the present invention;
fig. 8 is a diagram illustrating a multiparty calling method according to a third embodiment of the present invention;
fig. 9 is a diagram illustrating a multiparty calling method according to a fourth embodiment of the present invention;
fig. 10 is a schematic configuration diagram of a multiparty call system according to a fifth embodiment of the present invention.
Detailed Description
In order to make the objects, technical solutions and advantages of the present invention more apparent, embodiments of the present invention will be described in detail with reference to the accompanying drawings.
A first embodiment of the present invention relates to a multiparty calling method. For a multi-party call, the underlying network creates an instance for each party of the call, which is called leg, in this embodiment, after creating an instance leg for the party initiating the call request, the SCS in the underlying network determines whether the call identifier in the call request is the same as the existing call identifier, and if so, adds the created leg to the existing call and notifies the upper layer application that a new leg is added to the existing call, and the specific flow is shown in fig. 4.
When a call request is received from the network side, step 410 is entered to create a call leg. Specifically, when a call request is received from the network side, a leg is created by the SCS of the underlying network for the party that initiated the call request.
Next, step 420 is entered, and the SCS searches for the call identifier. Specifically, the SCS looks up the call identification in the call request in the existing call.
Then, entering step 430, the SCS determines whether the calling identifier already exists, i.e. whether the calling identifier in the calling request is the same as the existing calling identifier, if the calling identifier in the calling request is determined to be the same as the existing calling identifier, then step 440 is entered, and if the calling identifier in the calling request is determined to be different from the existing calling identifier, then step 460 is entered.
That is, in this embodiment, the SCS needs to store the existing call identifier, for example, in the form of a table. After the SCS creates a leg for the party initiating the call request, the SCS 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 indicates that the call identifier in the current call request is the same as the existing call identifier, step 440 is entered, and if the call identifier in the current call request is not found in the table, it indicates that the call identifier in the current call request is different from the existing call identifier, step 460 is entered.
In step 440, the SCS associates the created leg with the existing call. Specifically, after determining that the call identifier in the call request is the same as the existing call identifier, the SCS associates the leg created in step 410 with the existing call found to be the same as the call identifier in the call request, i.e., adds the created leg to the existing call. In this embodiment, the leg created in step 410 is located in the same SCS as the leg of the existing call. For example, as shown in fig. 5, the leg created in step 410 is leg a, the call identifier in the call request is the same as the call identifier of the existing call1, and both leg B and leg C have joined the existing call 1. Then, in this step, the SCS needs to associate leg a with the existing call1, i.e. to add the created leg a to the existing call 1.
The SCS may add the created leg to the existing call via Parlay interface function calls between the underlying network and the upper layer application. The Parlay interface function called in this step is further described below.
The Parlay interface function called in this step is used for internal communication between calls in SCS, such as the interface where the source call calls the target call, and the reference of the related leg is passed to the target call object, and the life cycle of this leg is managed by the subsequent target call object. The method can be defined as: addParty (srcCallLeg: in IpCallLegRef): TpSessionID. Wherein, the definition of each parameter is shown in table 1.
Parameter name | Type of parameter | Note |
srcCallLeg | IpCallLegRef | Reference to transferred leg |
Return value | TpSessionID | Identification of destination call object reassigned to leg |
TABLE 1
Then, in step 450, the SCS notifies the upper layer application that a new leg has joined the existing call, and the SCS may notify the upper layer application that a new leg has joined the existing call through a Parlay interface function call between the underlying network and the upper layer application. For the above case, the SCS notifies the upper layer application that leg a is added to the existing Call1 through Parlay interface function Call between the underlying network and the upper layer application, where the calling party may be called SCS Call, and the called party may be called: an App Call. The Parlay interface function called in this step is further described below.
The Parlay interface function called in this step is used to notify the upper layer application through this interface when a new leg is added in a call, and the new leg joins the call. The method can be defined as: PartyJoined (callSessionID: in TpSessionID, callLeg: in TpCallLegIdentifier, eventInfo: in TpJoinEventInfo): IpAppCallLegRef. The definitions of the parameters are shown in table 2.
Parameter name | Type of parameter | Note |
callSessionID | TpSessionID | Definition of session identification in Parlay specification, representing source call |
Called session identification | ||
callLeg | TpCallLegIdentifier | Reference of a New party leg |
eventInfo | TpJoinEventInfo | Supplementary information |
Return value | I pAppCallLegRef | Object created by service corresponding to 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 step 460 is entered. In step 460, the SCS creates a new call, associating the leg created in step 410 with the new call.
Then, step 470 is entered, and the SCS notifies the upper layer application that there is a new call.
It is easy to find that, in this embodiment, if the call identifier in the call request is the same as the existing call identifier, the leg created for the requesting party can be directly added to the existing call, and the upper layer application is notified that a new leg is added to the existing call. Therefore, the Parlay interface between the underlying network and the upper layer application can be enabled to support the call initiated from the network side to be added into the existing multi-party call.
A second embodiment of the present invention relates to a multi-party calling method, which is substantially the same as the first embodiment except that in the first embodiment, the leg created by the SCS is located in the same SCS as the leg of the existing call, whereas in the present embodiment, the leg created by the SCS is located in a different SCS from the leg of the existing call, and the call identifier is a reference identifier of the object.
Specifically, in the original Parlay specification, Session ID (Session identification) is usually used to identify Call or Leg in the interface, but in a distributed scenario (i.e. different legs are distributed in different SCS nodes), often a Call cannot be directly located to the Session through the Session identification. Therefore, in this embodiment, the session identifier is replaced by the reference identifier of the object, and the object may be a distributed object, and the session is directly located by the reference identifier.
As shown in fig. 6, when a call request from the network side is received, a new leg, called leg a, is created for the requesting party in SCS1, and the call id in the call request is found to be the same as the call id of existing call1 (the SCS1 may need to perform information interaction with other SCS, and the call id in the call request is found to be the same as the existing call id), the existing call1 is created in SCS2, and currently existing legs B and C join the existing call1, and both legs B and C are located in SCS 2.
Since the Leg a created by SCS1 is located in a different SCS than the legs (i.e., Leg B and Leg C) of call1 already in existence, in a scenario where different legs are distributed in different SCS nodes, a call often cannot be directly located to the session through the session identifier. Therefore, in this embodiment, the reference identifier of the object is used instead of the session identifier, i.e. the call is identified by the reference of the object, so as to locate the call in a different SCS.
Therefore, the created leg and the leg of the existing call can be located in the same SCS or different SCSs, and the call identifier is the reference of the object, so that the embodiment of the invention can be applied to wider scenes.
A third embodiment of the present invention relates to a multiparty calling method, in which, after an instance leg is created for a party initiating a call request by an SCS in an underlying network, a new call is created, the created leg is associated with the new call, and an upper layer application is notified of the new call. After receiving the notification of the new call, the upper layer application determines whether the call identifier in the new call is the same as the existing call identifier, and if so, enters a step of adding the created leg to the existing call and notifying the upper layer application that the new leg is added to the existing call, and the specific flow is as shown in fig. 7.
In step 701, the SCS creates a leg for the party initiating the call request, which is the same as step 410 and will not be described herein again.
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 fig. 8, the leg created in step 701 is leg a, and in steps 702 and 703, the SCS creates a new call, which is call2, associating leg a with call 2.
Next, step 704 is entered, and 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 determines whether the call identifier in the new call is the same as the existing call identifier.
In particular, the upper layer application needs to store the call identifier of the existing call, for example, in the form of a table, and after receiving the notification of the new call, look up the call identifier of the new call in the table. If the call id of the new call is found in the table, it indicates that the call id of the new call is the same as the existing call id, step 707 is entered, if the call id of the new call is not found in the table, it indicates that the call id of the new call is different from the existing call id, step 710 is entered, and 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 identifier of the new call2 is the same as the call identifier of the existing call1, and the existing leg B and leg C join the existing call 1. Then, in this step, the new call2 is transferred to the existing call 1. In this embodiment, the leg a created in step 701 is located in the same SCS as leg B and leg C of the existing call.
Specifically, the new call may be transferred to an existing call through a Parlay interface function call between the underlay network and the upper layer application. The caller is a service and the callee is a call object of the source call. The Parlay interface function called in this step is further described below.
The Parlay interface function invoked in this step is used to transfer the specified call leg from one call to another. The method can be defined as: moveCallLeg (callSessionID: inTpSessionID, targetCall: in ipmultipartitacalref, callLeg: in TpSessionID): void. The definitions of the parameters are shown in table 3.
Parameter name | Type of parameter | Note |
callSessionID | TpSessionID | Definition of session identifier in Parlay specification, session identifier representing source call |
targetCall | IpMultiPartyCallRef | Application reference of target call object for which Leg needs to be transferred |
callLeg | TpSessionID | Identification of calling Leg |
Interface exception | TpCommonExceptions | Definition of interface anomalies in Parlay |
Interface exception | P_INVALID_SESSION_ID | Illegal sessionID exception |
TABLE 3
It should be noted that after the transfer is completed, the new call established in step 702 is released.
Step 708 is then entered where the created leg is added to the existing call. For the above case, in this step, leg a needs to be added to the existing call1 through Parlay interface function call between the underlying network and the upper application, and the specific method is the same as the Parlay interface function call method described in step 440, and is not described herein again.
Step 709 is then entered to notify the upper layer application that a new leg has joined the existing call. For the above case, in this step, it is required to notify the upper layer application that there is a new leg a to join the existing call1 through the Parlay interface function call between the underlying network and the upper layer application, and the specific method is the same as the Parlay interface function call method described in step 450, and is not described herein again.
Therefore, in the embodiment, whether the call identifier in the call request is the same as the existing call identifier can be judged by the upper layer application, and a flexible implementation mode is provided for the invention.
A fourth embodiment of the present invention relates to a multiparty calling method, which is substantially the same as the third embodiment except that in the third embodiment, the leg created by the SCS is located in the same SCS as the leg of the existing call, whereas in the present embodiment, the leg created by the SCS is located in a different SCS from the leg of the existing call, and the call identifier is a reference identifier of the object.
As shown in fig. 9, in the present embodiment, a leg newly created for the party that initiated the call request is leg a, and in SCS1, a new call2 is created, and this leg a is associated with call2, and the upper layer application is notified that there is a new call. The upper layer application searches the call identifier of call2, and if the call identifier in the new call2 is determined to be the same as the call identifier of the existing call1, the existing leg B and leg C are added to the existing call1, and the leg B and leg C are respectively located in the SCS2, then call2 is added to call1, leg a is added to call2, and call2 is released. The searched call identifier is the reference identifier of the object, and the call in different SCS is positioned by using the reference identifier of the object, so that the embodiment can support different schemes that leg is distributed in different SCS nodes.
A fifth embodiment of the present invention relates to a multiparty calling system, as shown in fig. 10, including: the device comprises a creating unit, a sending unit and a receiving unit, wherein the creating unit is used for creating an instance leg for a party initiating a call request on an underlying network when the call request of a network side is received; the judging unit is used for judging whether the calling identifier in the calling request is the same as the existing calling identifier or not; the joining unit is used for joining the leg created by the creating unit into the existing call 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 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. So that the interface between the underlying network and the upper layer application supports the joining of calls originating from the network side into existing multiparty calls.
The judging unit judges whether the calling identifier in the calling request is the same as the existing calling identifier or not through a calling identifier list of the existing call stored in the SCS, and the adding unit adds the created leg into the existing call through the Parlay interface function call between the underlying network and the upper layer application when the judging unit judges that the calling identifier in the calling request is the same as the existing calling identifier. The notification unit notifies the upper layer application of the result that the created leg is added to the existing call by the adding unit through the Parlay interface function call between the underlying network and the upper layer application.
Or, the creating unit is further configured to create a new call, and associate the leg 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 positioned in the upper layer application, and after the upper layer application receives the notice of the new call, the judging unit judges whether the call identifier in the new call is the same as the existing call identifier through the call identifier list of the existing call stored in the upper layer application.
The system in this embodiment may further include a transfer unit, configured to transfer the new call to the existing call through Parlay interface function call between the underlying network and the upper layer application when the determination unit is located in the upper layer application and 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. And the adding unit adds the created leg into the existing call through the Parlay interface function call between the underlying network and the upper application after the transfer unit successfully transfers the leg. The notification unit notifies the upper layer application of the result that the created leg is added to the existing call by the adding unit through the Parlay interface function call between the underlying network and the upper layer application.
It should be noted that, in this embodiment, the leg created by the creating unit and the leg of the existing call may be located in the same SCS or may be located in different SCS. In the case that the leg created by the creating unit is located in a different SCS from the leg of the existing call, the call identifier is a reference identifier of the object, so that the call in the different SCS can be successfully located.
To sum up, in the embodiment of the present invention, when a call request from a network side is received, an instance leg is created for a party initiating the call request in an underlying network, and if a call identifier in the call request is the same as an existing call identifier, the created leg is added to the existing call, and an upper layer application is notified that a new leg is added to the existing call. So that the interface between the underlying network and the upper layer application supports the joining of calls originating from the network side into existing multiparty calls.
The SCS can judge whether the calling identifier in the calling request is the same as the existing calling identifier; the upper layer application may also determine whether the call identifier in the call request is the same as the existing call identifier. So that the embodiments of the present invention can be flexibly implemented.
The created leg and the leg of the existing call can be located in the same SCS; or, the created leg and the leg of the existing call are located in different SCS, and the call identifier is a reference of the object, so that the embodiments of the present invention can be applied to a wider range of scenarios, and for the case that the created leg and the leg of the existing call are located in different SCS, the call can be identified by the reference of the object, so as to smoothly locate the call in different SCS, thereby providing feasibility for the embodiments of this case.
While the invention has been shown 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 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.
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN2007101296008A CN101340490B (en) | 2007-07-06 | 2007-07-06 | Multi-part calling method and system thereof |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN2007101296008A CN101340490B (en) | 2007-07-06 | 2007-07-06 | Multi-part calling method and system thereof |
Publications (2)
Publication Number | Publication Date |
---|---|
CN101340490A CN101340490A (en) | 2009-01-07 |
CN101340490B true CN101340490B (en) | 2012-07-04 |
Family
ID=40214438
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN2007101296008A Expired - Fee Related CN101340490B (en) | 2007-07-06 | 2007-07-06 | Multi-part calling method and system thereof |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN101340490B (en) |
Citations (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN1602081A (en) * | 2003-09-22 | 2005-03-30 | 华为技术有限公司 | Method of calling short dialing to client setup by cluster system |
CN1756389A (en) * | 2004-09-29 | 2006-04-05 | 华为技术有限公司 | Method for realizing group short message receiving and transmitting in communication system |
CN1941953A (en) * | 2005-09-26 | 2007-04-04 | 日本电气株式会社 | System and method for group session communication |
-
2007
- 2007-07-06 CN CN2007101296008A patent/CN101340490B/en not_active Expired - Fee Related
Patent Citations (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN1602081A (en) * | 2003-09-22 | 2005-03-30 | 华为技术有限公司 | Method of calling short dialing to client setup by cluster system |
CN1756389A (en) * | 2004-09-29 | 2006-04-05 | 华为技术有限公司 | Method for realizing group short message receiving and transmitting in communication system |
CN1941953A (en) * | 2005-09-26 | 2007-04-04 | 日本电气株式会社 | System and method for group session communication |
Also Published As
Publication number | Publication date |
---|---|
CN101340490A (en) | 2009-01-07 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US7532628B2 (en) | Composite controller for multimedia sessions | |
US8484704B2 (en) | Next generation integration between different domains, such as, enterprise and service provider using sequencing applications and IMS peering | |
CN102035798B (en) | Service processing method, system and device for realizing disaster tolerance | |
JP2008508753A (en) | Method and apparatus for providing correlation means in a hybrid communication network | |
BRPI0516736B1 (en) | method to enable ip multimedia content communication, and, communication terminal | |
WO2009084528A1 (en) | Server device and message transmission method | |
CN101854703B (en) | Method, server and system for acquiring status information | |
WO2015117442A1 (en) | Processing method and device for converged communications terminal discovery and capability detection | |
US20160205147A1 (en) | Session Information Recording Method and Recording Server | |
US11678149B2 (en) | Communications network | |
WO2021254442A1 (en) | Session initiation method, apparatus and system, electronic device, and computer readable storage medium | |
JP2006101528A (en) | Detection of looping communication channel | |
CN105681603B (en) | A kind of call center attends a banquet the method and apparatus of terminal call troubleshooting | |
US8213373B2 (en) | Supporting method for REFER message expansion parameter | |
US8983043B2 (en) | Data communication | |
CN101340490B (en) | Multi-part calling method and system thereof | |
JP4343189B2 (en) | Server device | |
US20200021626A1 (en) | Management of subscriber identity in service provision | |
US20110286589A1 (en) | Method and apparatus for tagging outgoing telephony calls | |
WO2017113071A1 (en) | Supplementary service implementation method, terminal device and ims server | |
WO2019161721A1 (en) | Correspondence processing method and device based on interworking rcs system | |
EP1817682A2 (en) | Providing a proxy server feature at an endpoint | |
US20060250976A1 (en) | Method and apparatus for media device correspondence | |
CN110418346B (en) | Call establishment method and call establishment system | |
WO2016197677A1 (en) | Co-group pick-up method and apparatus for multiple service control processors, service control processor and computer storage medium |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
C06 | Publication | ||
PB01 | Publication | ||
C10 | Entry into substantive examination | ||
SE01 | Entry into force of request for substantive examination | ||
C14 | Grant of patent or utility model | ||
GR01 | Patent grant | ||
CF01 | Termination of patent right due to non-payment of annual fee | ||
CF01 | Termination of patent right due to non-payment of annual fee |
Granted publication date: 20120704 |