Architecture, client specification and application programming interface (api) for supporting advanced voice services

179124,7m J 453514 rnx bia>*rb ηο’ηϊ bbia α'Ώίρηα bip wvn na>njib nmn pv»» ow»i rnpb u*ia« n*nvpv>aiN jivvnnbN jw Ί1 pabv juiatawa

Architecture, client specification and application programming interface (API) for supporting advanced voice services (AVS) including push to talk on wireless handsets and networks

Kodiak Networks, Inc. C.171121 179124/2

This page was intentionally left blank 1 179124/2

This page was intentionally left blank 2 179124/2

BACKGROUND OF THE INVENTION 1. Field of the Invention.

This invention relates in general to wireless communications systems, and more specifically, to an architecture, client specification and application programming 10 interface (API) for supporting advanced voice services (AVS) including push-to-talk or press-to-talk on wireless handsets and networks. 2. Description of Related Art.

Group-based voice services, such as two-way half-duplex voice calls within a 15 group or between individuals, also known as “Push-to-Talk,” “Press-to-Talk,” PTT or P2T, have enonnous revenue earnings potential for wireless networks, such as cellular networks and personal communications systems (PCS) networks. Corporate subscribers primarily use such services for coordinating field people or fleet users from a central location. 20 Currently, there are three major approaches employed in providing group- based voice services such as P2T in wireless networks. One approach requires the installation of a dedicated private network, parallel to the wireless network, to support the group-based voice services. NEXTEL uses such a system, based on a solution developed by MOTOROLA known as IDEN. However, a dedicated private network 25 is costly to install and maintain and is employed by a few public wireless carriers.

Also, the IDEN system is non-standard, and hence cannot be used in standard wireless communications networks, such as those based on CDMA and GSM.

Another approach is based on Voice over IP (VoIP) technologies. While this approach promises compliance with newer and emerging standards, such as GPRS 3 WO 2005/112494 PCT/US2005/016534 (General Packet Radio Service), UMTS (Universal Mobile Telecommunications

System), etc., it does not provide a solution for carriers employing wireless networks based on existing standards, such as GSM (Global System for Mobile

Communications), CDMA (Code Division Multiple Access), etc. However, even for 5 the newer standards, solutions based on VoIP have serious drawbacks, including slower call setup, significant overhead, increased susceptibility to packet losses, low bit rate voice coders (vocoders), and significant modifications to the mobile handset. There is a need, instead, for solutions that require only minimal upgrades to the handset. 10 Still another approach is that defined in the co-pending and commonly- assigned patent applications cross-referenced above and incorporated by reference herein, hi this approach, group-based voice services are provided by a real-time exchange or dispatch gateway that interfaces to the wireless network to provide the group-based voice services therein, wherein both the real-time exchange and mobile 15 handsets that use die group-based voice services communicate with each other using call setup and in-band signaling within the wireless network.

Notwithstanding these innovations, there is a need in die art for an architecture, client specification and application programming interface (API) for use in handsets in order to support advanced voice services (AVS) for wireless 20 communications systems. The present invention aims to satisfy this need.

SUMMARY OP THE INVENTION

To overcome the limitations in the prior art described above, and to overcome other limitations that will become apparent upon reading and understanding the 25 present specification, the present invention discloses an architecture, client specification and application programming interface (API) for use in handsets in order to support advanced voice services (AVS) for wireless communications systems. The handset or mobile unit executes a client application therein for performing the call setup and in-band signaling with the wireless network for the group voice services, 4 WO 2005/112494 PCT/US2005/016554 and executes a presence/group management application therein for performing presence and group management functions related to the group voice services in the mobile unit.

5 BRIEF DESCRIPTION OF THE DRAWINGS

Referring now to the drawings in which like reference numbers represent corresponding parts throughout: FIG. 1 is a block diagram that illustrates an exemplary embodiment of a wireless communications network according to a preferred embodiment of the present 10 invention; FIG. 2 illustrates a proposed architecture for a real-time exchange according to the preferred embodiment of the present invention; FIG. 3 is a state diagram that illustrates the operation of a push-to-talk call according to a preferred embodiment of the present invention; 15 FIG. 4 illustrates the high-level functional components and their interfaces inside a mobile handset according to a preferred embodiment of the present invention; FIG. 5 illustrates the high-level functional components of the push-to-talk client application and presence/group management application according to a preferred embodiment of the present invention. 20

DETAILED DESCRIPTION OF THE INVENTION

In the following description of the preferred embodiment, reference is made to the accompanying drawings which fonn a part hereof, and in which is shown by way of illustration the specific embodiment in which the invention may be practiced. It is 25 to be understood that other embodiments may be utilized as structural changes may be made without departing from the scope of the present invention. 5 WO 2005/112494 PCT/US2005/016534

Overview

The present invention provides an architecture, client specification and application programming interface (API) for supporting advanced voice services (AVS) on handsets used in wireless communications networks. 5

Network Architecture FIG. 1 is a block diagram that illustrates an exemplary embodiment of a wireless communications network according to a preferred embodiment of the present invention. 10 Within the network 100, an RTX (Real-Time Exchange) 102, previously known as a Dispatch Gateway (DG), communicates with a MSC (Mobile Switching Center) 104 and PSTN (Public Switched Telephone Network) 106 using SS7 -ISUP/WIN/CAMEL (Signaling System 7 - Integrated Services Digital Network User Part/Wireless Intelligent Network/Customized Applications for Mobile Enhanced

15 Logic) messages at a signaling plane 108. A bearer path 110 implements a TDM (Time Division Multiplexing) interface carrying PCM (Pulse Code Modulation) or TFO (Tandem Free Operation) voice frames. Support for TFO in this path 110 is negotiated between a BSC (Base Station Controller) 112 and the RTX 102 for each originating and terminating leg of a group call. The use of TFO ensures high voice 20 quality (as voice vocoder conversion is avoided) between mobile-to-mobile calls.

When a subscriber originates a group call, the MSC 104 routes the call to the RTX 102. The MSC 104 also requests the BSC 112 via 116 to establish a radio traffic path 118 with a mobile unit or handset 120 via the BTS (Base Transceiver Station) 122 (as it does for a normal cellular call). At this time, the BSC 112 tries to negotiate 25 TFO (if it is supported) on a TDM link with the far end (in this case, the RTX 102).

At the same time (after the MSC 104 terminates the group call request to the RTX 102), the RTX 102 identifies the terminating group users and their MS-ISDN (Mobile Station - Integrated Services Digital Network) numbers. It sends an ISUP call origination request for each terminating handset 120. It may send requests directly to 6 WO 2005/112494 PCT/US2005/016534 the MSC 104, PSTN 106 or IP network 124 via a PDSN (Public Data Switched Network) 126, Router 12S, and/or Intemet/Intranet 130, depending on the routing table configuration for terminating MS-ISDN numbers. Once the bearer path 110 is established, the RTX 102 begins a negotiation with the far end (in this case, the 5 terminating BSC 112) for each terminating leg to a handset 120.

Once bearer paths 110 are established for originating and terminating legs for a group call, the RTX 102 switches (or duplicates) voice frames from the originating handset 120 to all terminating mobile handsets 120.

The RTX 102 may use an IP network 124 or the Intemet/Intranet 130 for two 10 different purposes. The IP network 124 or the Intemet/Intranet 130 can be used in a toll bypass mode where two RTXs 102 can exchange voice traffic bypassing the PSTN 106. However, each RTX 102 is responsible for terminating traffic to its closest MSC 104. In this case, the IP network 124 or the Intemet/Intranet 130 is used as a backbone transport of voice traffic between two RTXs 102. 15 The IP network 124 or the Intemet/Intranet 130 can also be used for a

registration and presence application. Since the MSC 104 will not direct a registration request from a handset 120 to the RTX 102 (because it would require changes in the MSC 104), the latter does not have any information of the registered mobile handsets 120. To circumvent this issue, a registration and presence application runs over an IP 20 stack in the handset 120. After the handset 120 registers for a data interface (i.e., obtaining an IP address) with the PDSN 126 (or Serving GSM Service Nodes (SGSN) in the case of GSM networks), the registration and presence application in the handset 120 registers with the RTX 102 using its IP address. The RTX 102 also uses this IP interface to update the presence information of other group members to a handset 120. 25 An alternative embodiment would use the SMS (Short Message Service) transport to carry presence messages over a data channel. The RTX 102 interacts with the mobile handset 120 using predefined presence application related messages that are transported as SMS messages. The same messages can be transported via the PDSN 126 interface, if group users have data service. 7 WO 2005/112494 PCT/US2005/016534

Real Time Exchange FIG. 2 illustrates a proposed architecture for the RTX 102 according to the preferred embodiment of the present invention. 5 The architecture includes a Call Processing system 200, Presence Server 202,

Real-Time Event Processing system 204, one or more Media Managers 206, and an SMPP (Short Message Peer-to-Peer) Transport 208, as well as modules for Various SS7 protocols, such as MTP-1 (Message Transfer Part Level 1) 210, MTP-2 (Message Transfer Part Level 2) 212, MTP-3 (Message Transfer Part Level 3) 214, ISUP 10 (Integrated Services Digital Network User Part) 216, SCCP (Signaling Connection Control Part) 218, and TCAP (Transactions Capabilities Application Part) 220 protocols.

The Call Processing system 200, Presence Server 202, Media Managers 204, SMPP Transport 206, and other modules communicate across an IP network 222. The 15 Real-Time Event Processing system 204 communicates directly with the Call Processing system 200, Presence Server 202, and the modules for various SS7 protocols. The modules for various SS7 protocols communicate with other entities via a SS7 Signaling Link 224. The SMPP Transport 206 communicates with a SMSC (Short Message Service Center) gateway using the SMPP protocol 226. The Media 20 Managers 204 communicate among themselves using the Η. 110 protocol 228 (or some other protocol, such TCP/IP).

The operation of these various components are described in the co-pending and commonly-assigned patent applications cross-referenced above and incorporated by reference herein. 25 P2T State Diagram FIG. 3 is a state diagram that illustrates the operation of a P2T call according to a preferred embodiment of the present invention. 8 WO 2005/112494 PCT/US2005/016534 ··»

State 300 represents a mobile handset 120 in a NULL state, i.e., the start of the logic. A user pressing a P2T button or malting a request to terminate a group call triggers a transition out of this state.

State 302 represents a mobile handset 120 in an active group call state. In tins 5 state, the user receives a chirp tone to start talking. The user responds by pressing the P2T button on the mobile handset 120 and talking. A talking user must hold the P2T button. The mobile handset 120 ensures that only when the user presses the P2T button is the reverse traffic channel is used to send voice frames, and the RTX 102 switches voice frames only in one direction, i.e., from talker to listener, which ensures 10 the half-duplex operation required for a P2T call.

State 304 represents the group “floor” being available to all members of the group. When the talking user releases the P2T button, the floor is available to all group members. All members of the group receive a “free floor” tone on their mobile handset 120. A user who requests the floor by pressing the P2T button first (in the 15 “ffee-floor” state) is assigned the floor, wherein the network 100 sends a chirp tone to the successful user.

State 306 represents a mobile handset 120 being in an active group call state.

In this state, the user is listening to the group call. If a non-talking user presses the P2T button in a call active state, the user does not receive any response from the 20 network 100 and remains in the same functional state.

State 308 represents a user receiving an “unsuccessful bidding” tone on his mobile handset 120, after the user pressed the P2T button, but was not granted the floor of the group call. The user subsequently starts listening to the voice message of the talking user. 25 Non-talking users (including the talking user who must release the P2T button to end the call thus becoming non-talking and making the floor available for others) can request the network 100 to end their respective call legs explicitly.

State 310 represents a terminating leg being released from the group call after the user ends the call. 9 WO 2005/112494 PCT/US2005/016534

State 312 also represents a terminating leg being released from the group call after the user ends the call.

State 314 represents all terminating legs being released from the group call when no member of the group bids for the floor within a specified time period. 5

Mobile Handset Components FIG. 4 illustrates the high-level functional components and their interfaces inside the mobile handset 120 according to a preferred embodiment of the present invention. The high-level functional components and their interfaces include a 10 physical layer 400, layer 2 402, signaling layer 3 406, cellular voice application 40S, P2T client application 410, SMS (or USSD (Unstructured Supplementary Services Data) or GPRS (General Packet Radio Service)) application 412 and presence/group management application 414.

Note that P2T client application 410 and presence/group management 15 application 414 are incorporated without requiring any changes in signaling layer 3 406 and below. All the existing messages that the cellular voice application 408 and SMS application 412 use remain as is and no additional messages are required to be implemented. i

The P2T client application 410 performs all the call signaling states described 20 in FIG. 3, which are the same that are traversed through by the cellular voice application 408. However, in some cases, the actions or behaviors in a particular state may vary.

As an example, for terminating a P2T call, the P2T client application 410 in an “alerting” state does not play an alerting tone to the user and wait for user action. 25 Instead, it plays a small duration “alert” tone, sends a “connect” message immediately to the network 100 and joins the vocoder output to a speaker on the handset 120. (Alternatively, the handset 120 could answer the call, and the RTX 102 plays the tone.) 10 WO 2005/112494 PCT/US2005/0165S4

Similarly, the presence/group management application 414 messages are

tunneled via SMS (or USSD or GPRS) messages and delivered to the SMS application 412 by Layer 3 signaling 406, and vice versa. These messages are identified and handed over to the presence/group management application 414 for 5 decoding. In one embodiment, the Wireless Village protocol messages are used between the handset 120 and the RTX 102 for presence and group management operations, although other messages could be used as well. P2T Client Application and Presence/Group Management Application 10 FIG. 5 illustrates the high-level functional components of the P2T client application 410 and the presence/group management application 414 according to a preferred embodiment of the present invention.

In this embodiment, the P2T client application 410 includes a message transport layer 500, encoder 502, decoder 504 and database 506. In addition, the P2T 15 client application 410 provides an application programming interface (API) for use by other components of the handset 120.

Other components in the handset 120 that use the API of the P2T client application 410 include the presence/group management application 414, a user interface 508, call manager 510 and non-volatile (NV) memory 512. 20 The P2T client application 410 itself interfaces to the operating system 514 of the handset 120 in order to perform its functions.

The transport layer 500 delivers encoded messages from the handset 120 to a destination presence server 202 in the RTX 102. The media used to transport these messages could be SMS, USSD or GPRS. The transport layer 500 can be configured 25 for any of these media based on the configuration parameters.

The transport layer 500 implements a queue to transport the messages from the handset 120. The transport layer 500 also notifies the upper layer modules, such as the presence/group management application 414, about the failure or success of tire message transport. In case of any failures in sending the messages, the transport layer 11 WO 2005/112494 PCT/US2005/016534 500 handles the re-transmission of the messages. The retransmission parameters are configurable and can be modified at run time without affecting the other module functionalities.

As noted above, the presence server 202 and handset 120 communicate using 5 Wireless Village messages. The encoder 502 encodes the Wireless Village messages, and handles message fragmentation, if necessary.

The decoder 504 decodes incoming Wireless Village messages from the RTX 102 and populates specific data structures in the handset 120. The decoder 504 checks the validity of the incoming messages by verifying mandatory parameters for 10 each of the incoming messages. A message will not be processed further if the decoder 504 fails to decode the message.

The presence/group management application 414 does the most of the processing of the Wireless Village messages. The decoded message from decoder 504 is sent to the presence/group management application 414 to take the appropriate 15 action. In this regard, the presence/group management application 414 may interact with the encoder 502, database 506, transport layer 500 or user interface 508.

The presence/group management application 414 enables P2T subscribers to track the presence of fellow members of the group in the network 100 on their mobile handsets 120. It also provides a mechanism and API to carry-out group management 20 operations on the handset 120, such as add member, delete member, etc. The communication interface between presence/group management application 414 and the presence server 202 in the RTX 102 may rely on either SMS (or USSD or GPRS) messages for transport.

Since most of the presence information is stored in the database 506, the 25 database 506 is tightly integrated with the presence/group management application 414. The database 506 stores groups, contacts, presence and availability related information in the NV memory 512. The database 506 information essentially contains group and member information along with presence information associated with each group and member. Apart from group and member information, the 12 WO 2005/112494 PCT/US2005/016534 database 506 also stores subscriber information, such as privileges, presence information, etc. The other components of the handset 120 may interact with the database 506 to retrieve/update the group, members and presence information for various operations. The database 506 also has pointers to the native address book on 5 the handset 120, which is stored in the NV memory 512, to provide seamless “alias” naming for contacts between cellular calls and P2T calls.

The user interface 508 provides a mechanism for the user to view and manage groups, group members, contacts, presence and availability. The user interface 59S also makes it possible to make P2T calls from the group/contact list screens. 10 . The call manager 510 handles all the telephony related functionalities, such as P2T Group/Private/Dynamic Group calls. The call manager 510 implementation is device-specific and vendor-specific, and it interacts with the user interface 508 and database 506. The required information for call-related functionalities is obtained from the wrappers provided by the database 506. 15 The NV memory 512 is also used to store the configuration parameters, which can be updated by the RTX as required.

User Interactions with the Mobile Handset

This section describes various scenarios that a group user may explicitly 20 invoke through the mobile handset 120.

Table 1: User Interactions with the Mobile Handset

No. User action Action by the P2T client application 410 and presence/group management application 414 in the handset 120 Remarks 1. The user powers on the handset 120. The presence/group management application 414 is notified when the handset 120 is turned on. The presence/group management Each handset 120 is configured with the address of the home RTX 102 when it is provisioned for group 13 WO 2005/112494 PCT/US2005/016534 application 414 sends a “presence registration” message to the home RTX 102. The presence/group management application 414 interacts with the SMS application 412 to transport this message to the SMSC gateway and the SMSC gateway routes the message to the home RTX 102 via the IP network 124 (as e-mail). service. 2 The user powers off the handset 120. The presence/group management application 414 is notified when the handset 120 is turned off. The presence/group management application 414 sends a predefined “presence registration” message to the home RTX 102. The presence/group management application 414 interacts with the SMS application 412 to transport this message to the SMSC gateway and the SMSC gateway routes this message to the home RTX 102 via the IP network 124 (as e-mail). 3. The user presses the P2T button on the handset 120 to contact the default group. The P2T client application 410 is invoked. It sends a call origination message with the called party’s address parameter filled with a DP trigger code, a code to identify a private/group call and the default group id. A bearer path is set up and the vocoder input/output is connected to the microphone and speaker of the handset 120, respectively. The MSC 104, based on the DP trigger, sends a query to the RTX 102 with the called party’s address. The RTX 102 responds with its routing number and sets up the terminating legs for the group. The call setup is performed in parallel in order to improve call setup time. 14 WO 2005/112494 PCT/US 2005/016534 4. The user selects a particular group from a list of groups displayed on the handset 120 and presses the P2T button. The P2T client application 410 is invoked. It sends a call origination message with the called party’s address parameter filled with a DP trigger code, a code to identify the private/group call, and the selected MS-ISDN/group id. A bearer path is set up and the vocoder input/output is connected to the microphone and speaker of the handset 120, respectively. 5. The user wants to make a private call and presses the P2T button. (A private call involves only two parties. The called party in a private call may be a member of his/her subscribed group or he/she can enter called party’s MS-ISDN number explicitly). The P2T client application 410 is invoked. (A private call is considered a group call where only two parties are involved). It sends a call origination message with the called party’s address parameter filled with a DP Trigger code, a code to identify a private/group call and the selected MS-ISDN number. A bearer path is set up and the vocoder input/output is to the microphone and speaker of the handset 120, respectively. TheRTX102 should be able to isolate the MS-ISDN number and group id based on the code. 6. The user selects a particular group from the list of groups displayed on the handset, marks a set of members and then presses the P2T button. The P2T client application 410 is invoked. It sends a call origination message with the called party’s address parameter filled with a DP Trigger code, a selected group id and the positions of the marked members within the group. A bearer path is set up and the vocoder input/output is connected to the microphone and speaker of the handset 120, respectively. 15 WO 2005/112494 PCT/US2005/016534 7. While in a group call active state, the user releases the P2T button to free the floor. The P2T client application 410 sends a “#” as an in-band DTMF signal to the BSC 112. The BSC 112 injects this DTMF signal into the PCM stream. 8. While in a group call active state, the user presses the P2T button to get the floor. The P2T client application 410 sends a as an out of band DTMF signal to the BSC 112. The BSC 112 injects this DTMF signal into the PCM stream. 9. While in a group call active state, the user presses the “End” button explicitly to release the group call. The P2T client application 410 sends a call release message to the MSC 104. The MSC 104 requests the handset 120 to clear its call states and sends a release message to the RTX 102. The RTX 102 releases that user’s leg from the group call.

Note that the P2T client application 410 and presence/group management application 414 also may manage a P2C (Press-To-Conference) session in a manner similar to a P2T session. More information on P2C sessions can be found in the co-

5 pending and common-assigned patent application Serial Number PCT/US04/2303 8, filed on July 16,2004, by F. Craig Farrill, Bruce D. Lawler, and Krishnakant M. Patel, entitled PREMIUM VOICE SERVICES FOR WIRELESS COMMUNICATIONS SYSTEMS, attorneys’ docket number 154.7-WO-U1, which application is incorporated by reference herein. 10

Network Interactions with the Mobile Handset

This section outlines scenarios that occur when the P2T client application 410 and presence/group management application 414 in the mobile handset 120 interact with the network 100. Note that user is not aware of these scenarios as the P2T client 16 WO 2005/112494 PCT/US2005/016534 application 410 and presence/group management application 414 in the mobile handset 120 handle these network-generated events in the background.

Table 2: Network Interactions with the Mobile Handset 5

No. Causing Event/Scenario in Mobile Action by P2T client appUcation 410 and presence/group management application 414 in the Mobile Handset 120 Remarks 1. A cellular call terminates to the handset 120 which the calling party starts with a (in an alerting state). The call termination identifier can be either a prefix or a suffix. The P2T client application 410 is invoked. It does not play an alerting tone to the user as specified in the “Alert With Info” message. Instead, it plays a small duration (e.g., 200 ms) special group call terminating alerting tone, immediately sends a connect message to the network 100, and connects the vocoder output to the speaker of the handset 120. The indicator for group call in the calling party’s address should be unique enough so that it is never used in a cellular call. 2. While in a group call active state, a release event is received from the network 100. The P2T client application 410 releases allocated resources in the handset 120 and sends a “release complete” message to the network 100. There are two possible scenarios: (1) the originator disconnects and the call goes on, or (2) the originator disconnects and the entire call is ended. 3. A Presence Update Notification message is delivered through the SMS interface. The presence/group management application 414 is invoked to decode the message. It 17 WO 2005/112494 PCT/US2005/016534 adds/deletes/modifies the member’s information with the presence information in the specific group indicated in the message. There is a special WV delimiter that differentiates tins from regular SMS/data. 4. An Auto Configuration Update message is delivered through the SMS application 412. This message is received only once when a user is provisioned for group voice service. The presence/group management application 414 is invoked to decode the message. Configuration parameters for the P2T client application 410 and presence/group management application 414 are set.

Service Interactions with the P2T client application A handset 120 can support either cellular or group voice service at any instant of time. This section highliglits various scenarios when the two services may conflict 5 with each other. In some of these cases, the user’s intervention is needed to select one of the services, whereas other cases are decided by the P2T client application 412 itself as part of the call processing logic. This section also discusses the impact of other cellular sendees, such as call hold, call forwarding, call forwarding busy, call waiting, call forwarding no answer, etc., on group voice sendees. 10 The following table has been prepared with the assumption that, while using group voice services, a user cannot put other parties on hold, even though they can switch to another call without disconnecting the group call leg. However, a user can leave a group call session at any time by selecting an “end” soft key. The objective is to allow group members to continue with the call, while one or more legs can either 15 be released from the RTX 102 or disj oined at the MSC 104 (at the time of service switching) during a session. The network 100 releases a group call only when the 18 WO 2005/112494 PCT/US2005/016534 floor remains free for some predefined time. If a talking user leaves the session, the network 100 will make the floor available to all others.

It is also assumed that a member of a group has call waiting, calling number presentation at call waiting, call forwarding busy (to voicemail) and calling line 5 identity presentation features enabled on the handset 120.

Table 3: Service Interactions for the P2T client application

No. Present State (in Mobile) Triggering Event Action by the P2T client application 410 and presence/group management application 414 in the Mobile Handset 120 Remarks 1. A group voice call is in an active state and the user is talking with the P2T button pressed. I Another group or cellular call is being terminated bytheMSC104 and a call-waiting tone is played. -The user is prompted to accept the second call. The following scenarios can occur: (1) the user releases the P2T button and accepts the second call; (2) the user releases the P2T button, ends the active call and accepts the second call; (3) the user does not accept the waiting second (1) In this case, the P2T client application 410 sends aDTMF signal to free the floor. Next, the P2T client application 410 sends a “Flash with Info” message to accept the second call, while the first call is broken at the MSC 104. After attending to the second call, the user may toggle to the first call. (2) In this case, the P2T client application 410 sends a DTMF signal to free the floor. Next, it releases the active call and the second call is established. (3) The MSC 104 handles the second For (1), the user remains as a non-talking leg to the RTX 102, even though the circuit is broken at the MSC 104. The RTX 102 may release all legs of the call at any time. 19 WO 2005/112494 PCT/US2005/016534 call and continues with the first call. call using a “call forwarding no answer” feature provisioned for the user. 2. A group voice call is in an active state and the user is not talking (i.e., does not press the P2T button). Another group or cellular call is being terminated by the MSC 104 and the call-waiting tone is played. The user is prompted to accept the second call. The following scenarios can occur: (1) the user accepts the second call, (2) the user ends the active call and accepts the second call, or (3) the user does not accept the waiting call and continues with the first call. (1) In this case, the P2T client application 410 sends a “Flash with Info” message to accept the second call, while the first call is broken at the MSC 104. After attending to the second call, the user may toggle to the first call. (2) In this case, the P2T client application 410 releases the active call and the second call is established. (3) In tliis case, the MSC 104 handles the second call using the “call forwarding no answer” feature provisioned for the user. 3. A cellular voice call is in an active state Another group call is terminated by tire MSC 104 and the “callwaiting” tone is played. The user’s action is similar to the previous case. Similar to the previous case. 4. A group call is in an active state and the user is talking with the P2T button pressed. The user wants to originate another cellular call. The following scenarios may occur: (1) The (1) In this case, the P2T client application 410 sends aDTMF signal to free the floor. Next, the P2T client application 410 The first case may lead to a 3-party call, which should be avoided from a group 20 WO 2005/112494 PCT/US2005/016534 user releases the P2T button and originates the second call, or (2) the user releases the P2T button, ends the first active call, and originates the second call (the user can originate a group call as well). sends a “Flash with Info” message to originate the second cellular call, while the first call is broken attheMSC 104. After attending to the second call, the user may toggle to the first call. (2) In this case, the P2T client application 410 sends a DTMF signal to free the floor. Next, the P2T client application 410 releases the active call and then originates a cellular or group call (by pressing the P2T button). call perspective. 5. A group call is in an active state with a non-talking user (the P2T button is free). The user wants to originate another cellular call. The following scenarios may occur: (1) the user originates a second cellular call, or (2) the user ends the first active call and originates a second call (the user can also originate a group call). (1) In this case, the P2T client application 410 sends a “Flash with Info” message to originate the second cellular call, while the first call is broken attheMSC 104. After attending to the second call, the user may toggle to the first call. (2) In this case, the P2T client application 410 releases the active call and then originates a cellular or group call (by pressing the P2T button). 6. A cellular voice call is in an active state. The user wants to originate a P2T (1) In this case, the P2T client application 21 WO 2005/112494 PCT/DS2005/016534 call. The following scenarios may occur: (1) the user originates a second P2T call by pressing the P2T button, or (2) the user ends the first active call and originates a second P2T call. 410 sends a “Flash with Info” message to originate the second P2T call, while the first call is broken at theMSC 104. After attending to the second call, the user may toggle to the first call. (2) In this case, the P2T client application 410 releases the active call and then originates a group call (by pressing the P2T button).

Conclusion

The foregoing description of the preferred embodiment of the invention has been presented for the purposes of illustration and description. It is not intended to be 5 exhaustive or to limit the invention to the precise form disclosed. Many modifications and variations are possible in light of the above teaching. It is intended that the scope of the invention be limited not with this detailed description, but rather by the claims appended hereto. 22 □’Ewan pp^a , crnxan ;w:n ατα inia^a pnow pnszn irn nr -jaoa ,ρνιη pxan paoana ma™ na^maa np’ioa .zrtwan rwaa mp’pan ρ-ίΛ axnria ......r. Geodau«r □innn Pi? »*···»· · ·* sw J«w\ _ ♦ ,.~... H J112)1101:1035+0300 .(mcna nannn) cras&’an nwa

<img img-format="tif" img-content="drawing" file="IL179124AD00021.tif" id="idf0001" />