Abstract:
An architecture, client specification and application programming interface (API) for supporting advanced voice services (AVS) 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, 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.

Description:
CROSS REFERENCE TO RELATED APPLICATIONS  
       [0001]     This application claims the benefit under 35 U.S.C. Section 119(e) of the following co-pending and commonly-assigned U.S. provisional patent applications: 
        Ser. No. 60/569,953, filed on May 11, 2004, by Ravi Ayyasamy and Krishnakant Patel, entitled PRESS TO TALK CLIENT APPLICATION PROGRAMMING INTERFACE (PCAPI), attorneys&#39; docket number 154.9-US-P1; and     Ser. No. 60/579,309, filed Jun. 14, 2004, by Ravi Ayyasamy, Krishnakant Patel, and Gorachand Kundu, entitled CLIENT SPECIFICATION AND ARCHITECTURE FOR SUPPORTING PRESS TO TALK AND OTHER PREMIUM VOICE SERVICES IN WIRELESS NETWORKS, attorneys&#39; docket number 154.15-US-P1;     both of which applications are incorporated by reference herein.        
 
         [0005]     This application is a continuation-in-part and claims the benefit under 35 U.S.C. Sections 119, 120 and/or  371  of the following co-pending and commonly-assigned patent applications: 
        Ser. No. 10/515,556, filed on Nov. 23, 2004, by Gorachand Kundu, Ravi Ayyasamy, and Krishnakant Patel, entitled DISPATCH SERVICE ARCHITECTURE FRAMEWORK, attorneys&#39; docket number 154.4-US-WO, which application claims the benefit under 35 U.S.C. Section 371 of the following co-pending and commonly-assigned PCT international patent application: 
            Serial No. PCT/US03/16386, filed on May 23, 2003, by Gorachand Kundu, Ravi Ayyasamy, and Krishnakant Patel, entitled DISPATCH SERVICE ARCHITECTURE FRAMEWORK, attorneys&#39; docket number 154.4-WO-U1, which application claims the benefit under 35 U.S.C. Section 119(e) of the following co-pending and commonly-assigned U.S. provisional patent applications: 
                Ser. No. 60/382,981, filed on May 24, 2002, by Gorachand Kundu, Ravi Ayyasamy, and Krishnakant Patel, entitled RADIO GATEWAY ARCHITECTURE FRAMEWORK, attorneys&#39; docket number 154.3-US-P1;     Ser. No. 60/383,179, filed May 24, 2002, by Gorachand Kundu, Ravi Ayyasamy, and Krishnakant Patel, entitled DISPATCH SERVICE ARCHITECTURE FRAMEWORK, attorneys&#39; docket number 154.4-US-P1; and     Ser. No. 60/407,168, filed Aug. 30, 2002, by Gorachand Kundu, Ravi Ayyasamy, and Krishnakant Patel, entitled DISPATCH SERVICE ARCHITECTURE FRAMEWORK, attorneys&#39; docket number 154.5-US-P1; and    
               
            Seral No. PCT/US04/23038, filed on Jul. 16, 2004, by F. Craig Farrill, Bruce D. Lawler, and Krishnakant M. Patel, entitled PREMIUM VOICE SERVICES FOR WIRELESS COMMUNICATIONS SYSTEMS, attorneys&#39; docket number 154.7-WO-U1, which application claims the benefit under 35 U.S.C. Section 119(e) of the following co-pending and commonly-assigned U.S. provisional patent applications: 
            Ser. No. 60/488,638, filed on Jul. 18, 2003, by F. Craig Farrill, Bruce D. Lawler and Krishnakant Patel, entitled REAL-TIME EXCHANGE, attorneys&#39; docket number 154.7-US-P1;     Ser. No. 60/492,650, filed Aug. 5, 2003, by Bruce D. Lawler, Krishnakant Patel, and F. Craig Farrill, entitled CDMA PRESS-TO-TALK (P2T) PROOF-OF-CONCEPT DEMONSTRATION, attorneys&#39; docket number 154.8-US-P1; and     Ser. No. 60/576,094, filed Jun. 2, 2004, by Craig Farrill, Bruce Lawler, and Krishnakant Patel, entitled TECHNIQUE FOR ZERO DELAY CALL SET-UP IN P2T SYSTEMS, attorneys&#39; docket number 154.14-US-P1;    
            all of which applications are incorporated by reference herein.       
 
     
    
     BACKGROUND OF THE INVENTION  
       [0016]     1. Field of the Invention  
         [0017]     This invention relates in general to wireless communications systems, and more specifically, to an architecture, client specification and application programming interface (API) for supporting advanced voice services (AVS) including push-to-talk or press-to-talk on wireless handsets and networks.  
         [0018]     2. Description of Related Art  
         [0019]     Group-based voice services, such as two-way half-duplex voice calls within a group or between individuals, also known as “Push-to-Talk,” “Press-to-Talk,” PTT or P2T, have enormous 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.  
         [0020]     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 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.  
         [0021]     Another approach is based on Voice over IP (VoIP) technologies. While this approach promises compliance with newer and emerging standards, such as GPRS (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 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.  
         [0022]     Still another approach is that defined in the co-pending and commonly-assigned patent applications cross-referenced above and incorporated by reference herein. In 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 handsets that use the group-based voice services communicate with each other using call setup and in-band signaling within the wireless network.  
         [0023]     Notwithstanding these innovations, there is a need in the 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 communications systems. The present invention aims to satisfy this need.  
       SUMMARY OF THE INVENTION  
       [0024]     To overcome the limitations in the prior art described above, and to overcome other limitations that will become apparent upon reading and understanding the 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, 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. 
     
    
     BRIEF DESCRIPTION OF THE DRAWINGS  
       [0025]     Referring now to the drawings in which like reference numbers represent corresponding parts throughout:  
         [0026]      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;  
         [0027]      FIG. 2  illustrates a proposed architecture for a real-time exchange according to the preferred embodiment of the present invention;  
         [0028]      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;  
         [0029]      FIG. 4  illustrates the high-level functional components and their interfaces inside a mobile handset according to a preferred embodiment of the present invention;  
         [0030]      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. 
     
    
     DETAILED DESCRIPTION OF THE INVENTION  
       [0031]     In the following description of the preferred embodiment, reference is made to the accompanying drawings which form a part hereof, and in which is shown by way of illustration the specific embodiment in which the invention may be practiced. It is to be understood that other embodiments may be utilized as structural changes may be made without departing from the scope of the present invention.  
         [0032]     Overview  
         [0033]     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.  
         [0034]     Network Architecture  
         [0035]      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.  
         [0036]     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 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 quality (as voice vocoder conversion is avoided) between mobile-to-mobile calls.  
         [0037]     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 TFO (if it is supported) on a TDM link with the far end (in this case, the RTX  102 ).  
         [0038]     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 the MSC  104 , PSTN  106  or IP network  124  via a PDSN (Public Data Switched Network)  126 , Router  128 , and/or Internet/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 terminating BSC  112 ) for each terminating leg to a handset  120 .  
         [0039]     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 .  
         [0040]     The RTX  102  may use an IP network  124  or the Internet/Intranet  130  for two different purposes. The IP network  124  or the Internet/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 Internet/Intranet  130  is used as a backbone transport of voice traffic between two RTXs  102 .  
         [0041]     The IP network  124  or the Internet/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 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 .  
         [0042]     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.  
         [0043]     Real Time Exchange  
         [0044]      FIG. 2  illustrates a proposed architecture for the RTX  102  according to the preferred embodiment of the present invention.  
         [0045]     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 (Integrated Services Digital Network User Part)  216 , SCCP (Signaling Connection Control Part)  218 , and TCAP (Transactions Capabilities Application Part)  220  protocols.  
         [0046]     The Call Processing system  200 , Presence Server  202 , Media Managers  204 , SMPP Transport  206 , and other modules communicate across an IP network  222 . The 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 Managers  204  communicate among themselves using the H.110 protocol  228  (or some other protocol, such TCP/IP).  
         [0047]     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.  
         [0048]     P2T State Diagram  
         [0049]      FIG. 3  is a state diagram that illustrates the operation of a P2T call according to a preferred embodiment of the present invention.  
         [0050]     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 making a request to terminate a group call triggers a transition out of this state.  
         [0051]     State  302  represents a mobile handset  120  in an active group call state. In this 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 the half-duplex operation required for a P2T call.  
         [0052]     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 “free-floor” state) is assigned the floor, wherein the network  100  sends a chirp tone to the successful user.  
         [0053]     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 network  100  and remains in the same functional state.  
         [0054]     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.  
         [0055]     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.  
         [0056]     State  310  represents a terminating leg being released from the group call after the user ends the call.  
         [0057]     State  312  also represents a terminating leg being released from the group call after the user ends the call.  
         [0058]     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.  
         [0059]     Mobile Handset Components  
         [0060]      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 physical layer  400 , layer  2   402 , signaling layer  3   406 , cellular voice application  408 , 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 .  
         [0061]     Note that P2T client application  410  and presence/group management 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.  
         [0062]     The P2T client application  410  performs all the call signaling states described 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.  
         [0063]     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. 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.)  
         [0064]     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 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.  
         [0065]     P2T Client Application and Presence/Group Management Application  
         [0066]      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.  
         [0067]     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 client application  410  provides an application programming interface (API) for use by other components of the handset  120 .  
         [0068]     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 .  
         [0069]     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 for any of these media based on the configuration parameters.  
         [0070]     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 the message transport. In case of any failures in sending the messages, the transport layer  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.  
         [0071]     As noted above, the presence server  202  and handset  120  communicate using Wireless Village messages. The encoder  502  encodes the Wireless Village messages, and handles message fragmentation, if necessary.  
         [0072]     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 each of the incoming messages. A message will not be processed further if the decoder  504  fails to decode the message.  
         [0073]     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 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 .  
         [0074]     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 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.  
         [0075]     Since most of the presence information is stored in the database  506 , the 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 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 the handset  120 , which is stored in the NV memory  512 , to provide seamless “alias” naming for contacts between cellular calls and P2T calls.  
         [0076]     The user interface  508  provides a mechanism for the user to view and manage groups, group members, contacts, presence and availability. The user interface  598  also makes it possible to make P2T calls from the group/contact list screens.  
         [0077]     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 .  
         [0078]     The NV memory  512  is also used to store the configuration parameters, which can be updated by the RTX as required.  
         [0079]     User Interactions with the Mobile Handset  
         [0080]     This section describes various scenarios that a group user may explicitly invoke through the mobile handset  120 .  
                                                   TABLE 1                           User Interactions with the Mobile Handset                    Action by the P2T client                   application 410 and               presence/group               management application       No.   User action   414 in the handset 120   Remarks                    1.   The user powers on the   The presence/group   Each handset 120 is           handset 120.   management application   configured with the               414 is notified when the   address of the home RTX               handset 120 is turned on.   102 when it is               The presence/group   provisioned for group               management application   service.               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).       2.   The user powers off the   The presence/group           handset 120.   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   The P2T client   The MSC 104, based on           button on the handset 120   application 410 is   the DP trigger, sends a           to contact the default   invoked. It sends a call   query to the RTX 102           group.   origination message with   with the called party&#39;s               the called party&#39;s address   address. The RTX 102               parameter filled with a   responds with its routing               DP trigger code, a code to   number and sets up the               identify a private/group   terminating legs for the               call and the default group   group. The call setup is               id. A bearer path is set up   performed in parallel in               and the vocoder   order to improve call               input/output is connected   setup time.               to the microphone and               speaker of the handset               120, respectively.       4.   The user selects a   The P2T client           particular group from a   application 410 is           list of groups displayed   invoked. It sends a call           on the handset 120 and   origination message with           presses the P2T button.   the called party&#39;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   The P2T client   The RTX 102 should be           private call and presses   application 410 is   able to isolate the MS-           the P2T button. (A private   invoked. (A private call is   ISDN number and group           call involves only two   considered a group call   id based on the code.           parties. The called party   where only two parties           in a private call may be a   are involved). It sends a           member of his/her   call origination message           subscribed group or   with the called party&#39;s           he/she can enter called   address parameter filled           party&#39;s MS-ISDN number   with a DP Trigger code, a           explicitly).   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.       6.   The user selects a   The P2T client           particular group from the   application 410 is           list of groups displayed   invoked. It sends a call           on the handset, marks a   origination message with           set of members and then   the called party&#39;s address           presses the P2T button.   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.       7.   While in a group call   The P2T client           active state, the user   application 410 sends a           releases the P2T button to   “#” as an in-band DTMF           free the floor.   signal to the BSC 112.               The BSC 112 injects this               DTMF signal into the               PCM stream.       8.   While in a group call   The P2T client           active state, the user   application 410 sends a           presses the P2T button to   “*” as an out of band           get the floor.   DTMF signal to the BSC               112. The BSC 112 injects               this DTMF signal into the               PCM stream.       9.   While in a group call   The P2T client           active state, the user   application 410 sends a           presses the “End” button   call release message to           explicitly to release the   the MSC 104. The MSC           group call.   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&#39;s leg from the               group call.                  
 
         [0081]     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-pending and common-assigned patent application Serial Number PCT/US04/23038, filed on Jul. 16, 2004, by F. Craig Farrill, Bruce D. Lawler, and Krishnakant M. Patel, entitled PREMIUM VOICE SERVICES FOR WIRELESS COMMUNICATIONS SYSTEMS, attorneys&#39; docket number 154.7-WO-U1, which application is incorporated by reference herein.  
         [0082]     Network Interactions with the Mobile Handset  
         [0083]     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 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                    Action by P2T client                   application 410 and               presence/group               management application           Causing Event/Scenario   414 in the Mobile       No.   in Mobile   Handset 120   Remarks                    1.   A cellular call terminates   The P2T client   The indicator for group           to the handset 120 which   application 410 is   call in the calling party&#39;s           the calling party starts   invoked. It does not play   address should be unique           with a “*” (in an alerting   an alerting tone to the   enough so that it is never           state). The call   user as specified in the   used in a cellular call.           termination identifier can   “Alert With Info”           be either a prefix or a   message. Instead, it plays           suffix.   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.       2.   While in a group call   The P2T client           active state, a release   application 410 releases           event is received from the   allocated resources in the           network 100.   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   The presence/group           Notification message is   management application           delivered through the   414 is invoked to decode           SMS interface.   the message. It               adds/deletes/modifies the               member&#39;s information               with the presence               information in the specific               group indicated in the               message. There is a               special WV delimiter that               differentiates this from               regular SMS/data.       4.   An Auto Configuration   The presence/group           Update message is   management application           delivered through the   414 is invoked to decode           SMS application 412.   the message.           This message is received   Configuration parameters           only once when a user is   for the P2T client           provisioned for group   application 410 and           voice service.   presence/group               management application               414 are set.                  
 
         [0084]     Service Interactions with the P2T Client Application  
         [0085]     A handset  120  can support either cellular or group voice service at any instant of time. This section highlights various scenarios when the two services may conflict with each other. In some of these cases, the user&#39;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 services, such as call hold, call forwarding, call forwarding busy, call waiting, call forwarding no answer, etc., on group voice services.  
         [0086]     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 be released from the RTX  102  or disjoined at the MSC  104  (at the time of service switching) during a session. The network  100  releases a group call only when the 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.  
         [0087]     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 identity presentation features enabled on the handset  120 .  
                                                           TABLE 3                           Service Interactions for the P2T client application                        Action by the                       P2T client                   application 410                   and                   presence/group                   management                   application 414 in           Present State (in       the Mobile       No.   Mobile)   Triggering Event   Handset 120   Remarks                    1.   A group voice call   Another group or   (1) In this case, the   For (1), the user           is in an active state   cellular call is   P2T client   remains as a non-           and the user is   being terminated   application 410   talking leg to the           talking with the   by the MSC 104   sends a DTMF   RTX 102, even           P2T button   and a call-waiting   signal to free the   though the circuit           pressed.   tone is played. The   floor. Next, the   is broken at the               user is prompted to   P2T client   MSC 104. The               accept the second   application 410   RTX 102 may               call. The following   sends a “Flash   release all legs of               scenarios can   with Info”   the call at any               occur: (1) the user   message to accept   time.               releases the P2T   the second call,               button and accepts   while the first call               the second call; (2)   is broken at the               the user releases   MSC 104. After               the P2T button,   attending to the               ends the active call   second call, the               and accepts the   user may toggle to               second call; (3) the   the first call. (2) In               user does not   this case, the P2T               accept the waiting   client application               second call and   410 sends a DTMF               continues with the   signal to free the               first call.   floor. Next, it                   releases the active                   call and the second                   call is established.                   (3) The MSC 104                   handles the second                   call using a “call                   forwarding no                   answer” feature                   provisioned for the                   user.       2.   A group voice call   Another group or   (1) In this case, the           is in an active state   cellular call is   P2T client           and the user is not   being terminated   application 410           talking (i.e., does   by the MSC 104   sends a “Flash           not press the P2T   and the call-   with Info”           button).   waiting tone is   message to accept               played. The user is   the second call,               prompted to accept   while the first call               the second call.   is broken at the               The following   MSC 104. After               scenarios can   attending to the               occur: (1) the user   second call, the               accepts the second   user may toggle to               call, (2) the user   the first call. (2) In               ends the active call   this case, the P2T               and accepts the   client application               second call, or (3)   410 releases the               the user does not   active call and the               accept the waiting   second call is               call and continues   established. (3) In               with the first call.   this case, the MSC                   104 handles the                   second call using                   the “call                   forwarding no                   answer” feature                   provisioned for the                   user.       3.   A cellular voice   Another group call   Similar to the           call is in an active   is terminated by   previous case.           state   the MSC 104 and               the “call-waiting”               tone is played. The               user&#39;s action is               similar to the               previous case.       4.   A group call is in   The user wants to   (1) In this case, the   The first case may           an active state and   originate another   P2T client   lead to a 3-party           the user is talking   cellular call. The   application 410   call, which should           with the P2T   following   sends a DTMF   be avoided from a           button pressed.   scenarios may   signal to free the   group call               occur: (1) The user   floor. Next, the   perspective.               releases the P2T   P2T client               button and   application 410               originates the   sends a “Flash               second call, or (2)   with Info”               the user releases   message to               the P2T button,   originate the               ends the first   second cellular               active call, and   call, while the first               originates the   call is broken at               second call (the   the MSC 104.               user can originate   After attending to               a group call as   the second call, the               well).   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.       5.   A group call is in   The user wants to   (1) In this case, the           an active state with   originate another   P2T client           a non-talking user   cellular call. The   application 410           (the P2T button is   following   sends a “Flash           free).   scenarios may   with Info”               occur: (1) the user   message to               originates a second   originate the               cellular call, or (2)   second cellular               the user ends the   call, while the first               first active call and   call is broken at               originates a second   the MSC 104.               call (the user can   After attending to               also originate a   the second call, the               group call).   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   The user wants to   (1) In this case, the           call is in an active   originate a P2T   P2T client           state.   call. The   application 410               following   sends a “Flash               scenarios may   with Info”               occur: (1) the user   message to               originates a second   originate the               P2T call by   second P2T call,               pressing the P2T   while the first call               button, or (2) the   is broken at the               user ends the first   MSC 104. After               active call and   attending to the               originates a second   second call, the               P2T call.   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  
       [0088]     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 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.