MXPA06011739A - Method for a session initiation protocol push-to-talk terminal to indicate answer operating mode to an internet protocol push-to-talk network server - Google Patents

Abstract

A push-to-talk communication device (20, 4, 5, 6) including an operating answer mode (22) indicates that operating answer mode to a Session Initiation Protocol / Internet Protocol based push-to-talk network server (24, 2) .The method includes employing as the operating answer mode of the push-to-talk communication device one of an automatic-answer mode (28), an always-automatic-answer mode (29) and a manual-answer mode (30). A Session Initiation Protocol / Internet Protocol core network (34) is employed including the Session Initiation Protocol /Internet Protocol based push-to-talk network server. The operating answer mode is indicated in a Session Initiation Protocol message (40) from the push-to-talk communication device to the Session Initiation Protocol / Internet Protocol push-to-talk network server over the Session Initiation Protocol / Internet Protocol core network

Description

METHOD FOR A PULSAR TERMINAL TO SPEAK OF PROTOCOL LOGIN TO INDICATE THE RESPONSE OPERATION MODE FOR A PULSAR NETWORK SERVER TO TALK ABOUT INTERNET PROTOCOL DESCRIPTION OF THE INVENTION This invention generally pertains to communication methods between communication devices and more particularly, to a method and apparatus for providing push to talk (PTT) communication services in a communication system, such as, for example, example, a cellular telephone system. A push to talk communication system (PTT) wireless, such as, for example, a push to talk on cell (PoC) system, allows a group of individuals, each having a wireless communication device, such as a cell phone, to communicate with other members of the group . Previous PTT systems typically relied on a single frequency, or a dedicated broadcast channel, over which communications were received by wireless communication devices. In most previous systems, only one member could transmit information to the other members at a time. However, all members could listen to the dedicated channel, in order to be able to receive communications from the member who was transmitting. A member who wishes to transmit to other members of the system would typically send a request for access by pressing a PTT button on the member's wireless communication device, which allows only access to the dedicated channel. Internet telephony encompasses a number of technologies for transporting voice traffic networks over Internet Protocol (IP). Examples of IP signaling protocol include the International Telecommunication Union - Telecommunications Standardization Sector (ITU-T) H.323 and the Session Initiation Protocol (SIP) specified by the Internet Engineering Task Force (IETF) ), RFC 3261, which is used as the signaling protocol for the 3GPP IP multimedia subsystem (IMS). Wireless communication devices find, join, leave and learn about various groups of people that require communications with each other (eg, networks) using, for example, SIP, which is a well-known signaling protocol used in the telecommunication industry . SIP is an application layer control protocol (signaling) to create, modify and terminate sessions with one or more users. These sessions include, for example, telephone calls over the Internet, multimedia distribution and multimedia conferences. A SIP function is the registration between a uniform SIP resource identifier (i.e., a character frequency used for address resources and users for transmission in a network protocol and for the representation of human language communication, for example, a SIP: URI) and one or more contact addresses (e.g., a device address, such as an IP address). The registration allows a wireless communication device to communicate with and be recognized by other wireless communication devices. SIP, through its registration function allows a user agent to create, multiply and delete records. The basic record includes the registration address to which the registration refers, the identification of the record and the registration status. The registration states can be initialized, activated and terminated. As long as there is at least one contact link for the registration address, a SIP state machine remains in its active state. When the last contact expires or is removed, the record makes transition to the finished state. The registration status is usually stored in an intermediary / record in a separate database. When the SIP wireless communication device is continuously active, it must be continuously registered in the SIP / IP network if it is to use the services in the 3GPP IMS-based SIP network. Records can be used by policy administrators to complete or shorten a record, and to request that the wireless communication device be re-registered, so that it can be re-authenticated. A SIP PTT wireless communication device or PTT terminal can support different modes of operation response including an Automatic Response mode and a Manual Response mode. For example, when the PTT terminal is in the Automatic Response mode, then, when another user of the network / group presses a PTT button on its PTT terminal and speaks on that PTT terminal, the other user with the terminals PTT set in the Automatic Answer mode listens to that spoken voice from its PTT terminals. Alternatively, when a PTT terminal is in the Manual Answer mode, users of that PTT terminal must answer manually (for example, there is first a "ringing sound" at the PTT terminals) before listening to that spoken voice. A further improvement for this basic concept is the use of Authorization Acceptance Lists stored in the network with user authorization of the operation response mode for each user's PTT sessions (some users may have only the Manual Response privilege). , while other users may have the Automatic Reply privilege). When used with per-user authorization, the handling for the PTT session is determined by a combination of the calling user's Authorization privilege on the Acceptance List and the operation response mode set by the terminal. Therefore, there are two possible cases for Automatic Response: (1) Automatic Response mode where only those users who have the Automatic Response privilege in the Acceptance List cause the terminal to answer automatically; and (2) the Always Automatic Response mode where all the users in the Acceptance List, regardless of the privilege, cause the terminal to answer automatically. The terminal can support one or two or three of these modes of operation. The operation response mode can be selected by the user in the PTT terminal when using eg a physical switch or button, one or more settings of a profile enabled, or by some other suitable mechanism. Since the operation response mode changes the network signaling scenario of the SIP / IP PTT network server controlling the establishment of the SIP PTT sessions, this mode of the SIP PTT terminal needs to communicate with the SIP PTT terminal. network server. Figure 1 shows a SIP / IP core network 1 including a PTT server 2, a presence server 3 and a plurality of SIP PTT terminals 4,5,6. Although the wireless SIP PTT terminals 4,5,6 are shown, the metallic line PTT terminals (e.g., terrestrial based or local area network (LAN) based) (not shown) can be employed. A PTT terminal, such as 4, can typically include an optional antenna 8, an optional display 9, and a plurality of keys 10, a mouthpiece or microphone 11, a hearing aid, headset, handset or loudspeaker 12, and a communicator 13 of PTT. Alternatively, one of the existing keys 10 or the selection of a deployed menu option can function as a PTT switch when in a communication PTT mode instead of using the dedicated PTT switch 13. SIP / IP core network 1, the creation of the group is possibly based on HTTP and XCAP, and the signaling control is based on SIP. Voice traffic is carried out through an appropriate Internet protocol, such as a Real-Time Transport Protocol (RTP), which is designed to provide end-to-end network transport functions for applications that transmit data in real time, such as voice and video. Both SIP and RTP are seated at the top of a related IP stack that includes UDP and IP layers. A plurality of suitable PoC applications form the upper layer of a PoC protocol stack, which includes that related IP stack. A suitable mobile channel, such as upgraded GPRS from 3GPP R99 or E-GPRS or W-CDMA / UMTS or CDMA 2000 IX or its variants, WLAN access or other 3G radio access technologies, provide the access network, which supports header compression and Quality of Service (QoS) of the continuous traffic class. A Header is a component of a SIP message such as 14, which carries information about the message. It is structured as a sequence of header fields. A header field is a SIP message header component. A header field can appear as one or more rows in the header field. The header field rows consist of a header field name and zero or more header field values. Multiple header field values in a given row of header field are separated by commas. Some header fields can only have a single header field value and as a result, they always appear as a single row of header field. A Header Field Value is a simple value. A header field consists of zero or more header field values. A Message is data sent between SIP elements, such as 2-7, as part of the SIP protocol. SIP messages 14,15,16 are any of requests or responses.

A Request, such as 14,15 is a SIP message sent from a client to a server, for the purpose of invoking a particular operation. A Response, such as 16, is a SIP message sent from a server to a client, to indicate the status of a request sent from the client to the server. A Server, such as 2,3,7 is a network element that receives requests in an order to service it and to send replies to those requests again. Examples of servers are intermediaries, user agent servers, redirection servers and registrars. The network-based PTT server 2 receives invitations for group communication from a user. In response, server 2 invites all other group members to communication, controls the "word" (for example, the right to speak), bridges communication between all members of the network / group, and needs to know the current response mode of SIP PTT terminals 4,5,6 for suitable signaling conditions, and media management. The network-based presence server 3 stores presence information published by the individual SIP PTT terminals 4,5,6, and possibly also other network-based resources (servers, such as 2,7) and distributes information notifications of Presence to authorized watchers who subscribe to the presence information using their terminals. SIP Registrar 7 is a server that accepts SIP Registration requests and places the information it receives in those requests in the location services database for the domain it manages. There is a known prior proposal to deal with an establishment of response mode in a PoC SIP / IP core network. In addition to accepting checklists, the PoC system has an Automatic Response mode tag, which can be set on a user and / or group basis. The Automatic Response mode tag is stored in a Group Management Server (GMLS) (not shown) in a group management database that is accessed by the PoC PTT server 2. The user has the ability to configure the corresponding PTT terminal, such as 4, to automatically accept the incoming session request or to be suggested before accepting the request. In the simplest case, if the user sets the Automatic Response mode, then the Automatic Response mode is applied to the incoming PoC sessions. Otherwise, if the Automatic Response mode is off, then the Manual Answer mode is applied. It is believed that this previous proposal is inappropriate because: (1) it modifies data in the GMLS that require the use of an HTTP database modification protocol; (2) the change of response mode can be done for example, by means of a switch or by the selection of a profile, which is not mapped well in a database manipulation (For example, this requires a high degree of complexity in the terminal to synchronize with and manipulate a database in response to a simple stimulus such as a switch, also, the database manipulation protocol may not be supported by all Since individual users may not have the authorization to manipulate their own group and authorization lists, since your company controls this, a simple telephone keypad is not ideal for entering and creating a large list of text-based information. ); and (3) depending on the user, the response mode can change many times a day (for example, it is relatively very dynamic) while the data (for example, address book entries, preferences for those users) stored in the GLMS are almost never changed (for example, it is relatively quasi-static). The IETF has defined this division of relatively static and relatively dynamic data as "Permanent State" and "Temporary State", respectively. Different protocol mechanisms are appropriate for manipulating Temporary Status and Permanent Status data.

The response mode is considered as a Temporary State, the group manipulation and the lists in a database are considered as a Permanent State. Therefore, it is believed to be more efficient than using an HTTP mechanism to simply report the change / status event of the network response mode. Therefore, there is a space for improvement in systems of Wireless PTT and methods. These needs and others are met by the invention, which provides a method for a push-to-talk (PTT) communication device that includes an operation mode for indicating that mode of operation for a push-to-talk network server. As an aspect of the invention, a method for a push-to-talk communication device that includes an operation mode for indicating the mode of operation for a push-to-talk network server comprises: employing as the operating mode of the push-to-talk device; push communication to speak one of a first response mode and a second response mode; employ a communication network that includes a push-to-talk network server; and indicate the mode of operation in a Session Initiation Protocol message from the push to talk communication device to the network server to press to talk about the communication network.

The method may further comprise using as the first response mode an Automatic Response mode; use a Manual Response mode as the second response mode; employing as the communication network a core network of Internet Protocol; and use as the network server to press to talk a network server to press to talk about Internet Protocol. As another aspect of the invention, a method for a push-to-talk communication device that includes an operation mode for indicating the mode of operation to a push-to-talk network server comprises: employing as the operating mode of the push-to-talk device; push communication to speak one of a first response mode, a second response mode and a third response mode; employ a communication network that includes a push-to-talk network server, and indicate the mode of operation in a Session Initiation Protocol message from the push-to-talk communication device to the push network server to talk about the communication network. The method can use as the first response mode an automatic response mode; use as the second response mode a response mode always automatic; use a manual response mode as the third response mode; employing as the communication network a core network of Internet Protocol; and use as the network server to press to talk a network server to press to talk about Internet Protocol. As another aspect of the invention, a method for a push-to-talk communication device that includes an operating mode for sending the mode of operation to a push-to-talk network server comprises: employing as the mode of operation between the device of communication to press to speak one of at least a first response mode and a second response mode; employ a communication network that includes a push-to-talk network server; and sending the operating mode in an event report message from the push-to-talk communication device or from another device on behalf of the push-to-talk communication device to the network server to press to talk about the communication network. BRIEF DESCRIPTION OF THE DRAWINGS A complete understanding of the invention can be gained from the following description of the preferred embodiments when read together with the accompanying drawings in which: Figure 1 is a block diagram of a core network of the Protocol Internet (IP), such as a Push to Talk (PTT) network over IP (PoC) IP / Session Initiation Protocol (SIP), which includes a PTT server, a presence server and a plurality of SIP PTT terminals, such as cellular phones with SIP PTT capability. Figure 2 is a flowchart of a method for a PTT terminal that includes an operation response mode for indicating that mode to a push-to-talk network server of Internet Protocol. Figure 3 is a message diagram according to one embodiment of the invention. Figure 4 is a message diagram according to another embodiment of the invention. Figures 5A-5B form a message diagram according to another embodiment of the invention. Figures 6-8 and 9A-9B are diagrams of goods according to other embodiments of the invention. As used herein, the terms "indicates" and "indicating" must expressly include, but not be limited to, notified and notified, published and published, and recorded and recorded. As used herein, the term "wireless communication device" must expressly include, but not be limited to, a cell phone, a mobile phone, a push-to-talk wireless terminal (PTT), a mobile electronic communication device, and a wireless portable electronic device that includes, for example, a wireless local area network (WLAN) terminal. As used herein, the term "PTT terminal" may expressly include, but not be limited to, a wireless PTT terminal, and a wired PTT terminal. As used herein, the term "event report message" means a message that reports an event or state change in an entity. The event report message may be sent to another entity as a notification in response to a subscription by another entity to receive notifications having to do with what is subscribed to the event (eg, without limitation, a SIP Notification method) or may pass or publish asynchronously to another entity (for example, without limitation, a SIP Publication method). As used herein, the term "event package" means a specification that defines a set of status information to be reported by a reporting entity to another entity. Event packages define the syntax and semantics to carry such status information. As used herein, the term "XML" means Extensible Marking Language.

The invention is described in association with Push to Talk (PPT) networks on cellular (PoC) Session Initiation Protocol (SIP), although the invention can be applied to core Internet Protocol (IP) networks. Figure 2 shows a method for a SIP PTT terminal 20 that includes an operation response mode 22 for indicating that operation response mode to an Internet Protocol PTT network server 24. The method includes employing, at 26, the operation response mode 22 as one of an automatic response mode 28, an always automatic response mode 29 and a manual response mode 30. Then, at 32, an Internet Protocol core network / Session Initiation Protocol 34 is employed which includes the Internet Protocol PTT network server 24. Finally, at 38, the operation mode 28 is indicated in a Session Initiation Protocol message, at 40, from the SIP PTT terminal 20 to the PTT network server 24 based on the Internet Protocol over the network Core 34 Internet Protocol / Session Initiation Protocol. Figure 3 shows a message diagram for changing the mode of operation of a PTT terminal 42, which includes the PTT switch 13 and an Automatic / Manual tilt switch 43, in a PTT server 44. SIP supports the capability of a PTT terminal, such as 42, to indicate the characteristics it supports in a SIP Registration request, such as 50, using a Contact Header of SIP, such as 51, by extending the feature-param of the contact header field. Feature labels can start with a plus sign for labels that are extensions defined by the user. A suitable mechanism is shown in Table 1: TABLE 1 feature-param = ene-feature-tag [EQUAL LDQUOT (tag-valué-list / string-value) RDQUOT] ene-feature-tag = base-tang / other-tags base-tags = "audio" / "automaton" / "class" / "duplex" / "data" / "control" / "mobility" / "description" / "events" / "priority" / "methods" / "schemes "/" application "/" video "/" language "/" type "/" isfocus "/" actor "/" text "other-tags =" + "ftag-name ftag-name = ALPHA * (ALPHA / DIGIT / "!" / "" / tag-value-list = tag-value * ("," tag-value) tag-value = ["!"] (token-nobang / boolean / numeric) token-nobang = 1 * ( alphanu / "_" / "." / "%" / »*" boolean = "TRUE" / "FALSE" numeric = "#" numeric-relation number numeric-relation = "&" = "/" < = "/" = "/ (number::") number = ["+" / "-"] 1 * DIGIT ["." 0 * DIGIT] string-value = "<" qdtext ">" where: EQUAL is "="; LDQUOT is "" "; RDQUOT is" ""; ALPHA is a, b, c, d, ... z; DIGIT is 0,1,2,3 ... 9; "*" means any number of them; "/" means alternative (for example, X / Y means X or Y); and feature-param is a feature parameter that describes a characteristic of the user agent associated with the uniform resource indicator in the contact header field. Feature parameters can be identified as they belong to the well-known set of base feature labels, or start with a plus sign. This mechanism provides the feature-param enc-featur-tag to extend. An ene. feature tag is included as part of the SIP Contact header 51 which indicates the current mode of operation of the PTT terminal 42. For example, + poc. operating.mode = "Auto", can be used to indicate that the switch 43 of the PTT terminal 42 is in an Automatic Response Mode (A). The PTT terminal 42 may include this feature-param in the contact header during each SIP record. If the mode of the PTT terminal 42 is changed by the user, then the PTT terminal 42 renews its registration which includes the feature-param with the new value in the contact header of the SIP registration request. The SIP PTT server 44 which controls the establishment of the PTT sessions needs to obtain the registration information of the SIP registrar 46 in the SIP / IP core 48, in order to obtain the mode of operation of the PTT terminal 42. Figure 3 shows two groups of messages 50,52,60,62 and 64,66,70,72 of SIP associated with Automatic Response Mode 58 and Manual Response Mode 68 of terminal 42 of PTT. First, the PTT terminal 42 is Registered with the SIP / IP core 48 in the Automatic Response Mode by sending the SIP Registration request 50 to the SIP / IP core 48 containing the Contact header 51 with a feature- param of + poc. operating.mode = "Auto". The SIP registrar 46 in the SIP / IP core 48 is configured to perform third party registrations with the PTT server 44 when the PTT terminal 42 is registered. The SIP registrar 46 in the SIP / IP core 48 sends a SIP Registration request 52 to the PTT server 44 which contains a Contact header 53 with the + poc feature-param. operating.mode = "Auto". In response, the PTT server 44 sets the state 54 (e.g., PTT state A) of the corresponding PTT terminal 42 in its state table 56 (e.g., it also includes the PTT B and C PTT states). for other PTT terminals (not shown)) for Automatic Response Mode 58. Then, the SIP registrar 46 in the SIP / IP core 48 responds to the SIP Registration request 50 with a SIP OK 200 response 60 for the PTT terminal 42. Finally, the PTT server 44 responds to the SIP Register request 52 with a SIP OK 200 response 62 for the SIP registrar 46 in the SIP / IP core 48. Example 1 An example of the SIP Registration request sent by the PTT terminal 42 to indicate the Automatic Response Mode is as follows: REGISTER sip: example. com SIP / 2.0 From: sip: POCuserOexample. com; tag = asd98 To: sip: POCuser @ example. com Call-ID: hh89as0d-asd88jkk @ host. example.com CSeq: 9987 REGISTER Max-Forwards: 70 Via: SIP / 2.0 / UDP POChost. example com; branch = z9hG4bKnashds8 Contact: < Yep; POCuserOhost. example com >; Audio; + poc. operating .mode = "Auto"; mobility = "mobile"; meth? ds = "INVITE, BYE, OPTIONS, ACK, CANCEL" Content-Length: 0 At 63, the user changes the PTT terminal 42 Automatic Response Mode to the Manual Response Mode when using the Automatic / Manual tilt switch 43 to select the Manual Answer Mode (M). This activates a Renewal Register by terminal 42 of PTT.

Alternatively, any suitable physical switch or button (not shown), one or more settings of a profile enabled (not shown), a menu selection (not shown), or any other suitable selection mechanism (not shown) may be employed. The PTT terminal 42 again registers with the SIP / IP core 48 upon sending a SIP registration request 64 to the SIP / IP core 48 which contains a contact header 65 with a + poc feature-param. operating.mode = "Manual". Then, the SIP Registrar 46 in the SIP / IP core 48 performs another Third Party Register with the PTT server 44 when the PTT terminal 42 is re-registered. The SIP registrar 46 in the SIP / IP core 48 sends a SIP registration request 66 to the PTT server 44 which contains a Contact header 67 with a + poc feature-param. operating.mode = "Manual". The PTT server 44 changes the state 54 of the corresponding PTT terminal 42 in its state table 56 to the Manual Response Mode 68. Then, the SIP registrar 46 in the SIP / IP core 48 responds to the SIP Register request 64 with a SIP OK 200 response 70 to the PTT terminal 42. Finally, the PTT server 44 responds to the SIP registration request 66 with a SIP OK 200 response 72 to the SIP registrar 46 in the SIP / IP core 48.

Example 2 An exemplary SIP Registration request sent by the PTT terminal 42 to indicate the Manual Response Mode is as follows: REGISTER si: example. com SIP / 2.0 From: sip: POCuser @ exampl. com; tag = asd98 To: sip: POCuser @ example. com Cali-ID: hh89as0d-asd88jkk @ host. example.com CSeq: 9987 REGISTER Max-Forwards: 70 Via: SIP / 2.0 / UDP POChost. example com; branch = z9hG4bKnashds8 Contact: < Yep; POCuser @ host. example com >; Audio; + poc. operating. mode = "" Manual "; mobility =" mobile "; methods =" INVITE, BYE, 0PTI0NS, ACK, CANCEL "Content-Length: 0 With reference to Figure 4, another message diagram shows the message sequences to change the operational mode of the PTT terminal 42 on the PTT server 44. SIP supports the ability of the SIP devices, such as the PTT server 44, to subscribe and notify of events occurring in other SIP devices, such as Terminal 42 of PTT, using an appropriate subscription mechanism This mechanism involves subscription using a SIP Subscription method for a SIP Events package An authorized subscription receives notifications about events related to the Events package using the Notification method SIP An Event Package is a specific application specification that defines a set of status information to be reported by a notifier to a subscriber. Vento is a special type of event package that defines a set of states that can be applied to all possible event packages, including the same. A Notification is the act of a notifier who sends a Notification message to a subscriber to inform the subscriber of the status of a resource. A Notifier is a user agent that generates Notification requests for the purpose of notifying subscribers of the status of a resource. Notifiers typically also accept subscription requests to create subscriptions. A State Agent is a notifier that publishes state information on behalf of a resource; In order to do it this way, you may need to gather state information from multiple sources. State Agents always have complete status information for the resource for which notifications are created. A Subscriber is a user agent, who receives notification requests from notifiers. These Notification requests contain information about the status of a resource in which the subscriber is interested. Subscribers typically also generate subscription requests and send them to notifiers to create subscriptions. A Dialogue is an equitable SIP relationship between two agents that persists for some time. A Dialog is set for SIP messages, such as a 2xx response for an invitation request. A Subscription is a set of application states associated with a Dialog. This application state includes a pointer to the associated dialog, the name of the event packet, and possibly an identification card. New Event packages can be defined for status information and additional subscription. By definition, subscriptions exist in both a subscriber and a notifier. The SIP Event Package can be advantageously employed for the PTT terminal operation mode. The SIP / IP PTT network server (e.g., PTT server 44) controlling the establishment of PTT sessions is subscribed to the Operation mode (response) Event package of the corresponding SIP PTT terminal. The corresponding PTT terminal, such as 42, is then sent to the SIP notification requests, such as 88 or 96, to the PTT server 44 whenever the mode of operation (response) changes in that PTT terminal. Entities in the SIP / IP network can subscribe to resource or call status for various resources or calls on the network, and those entities (or entities acting on their behalf) can send notifications when those states change. A typical flow of messages may include: (1) a Subscription from the Subscriber to the Notifier, in order to request a subscription status; (2) an OK 200 response from the Notifier to the Subscriber to know the subscription; (3) a Notification from the Notifier to the Subscriber to return the current status information; (4) an OK 200 response from the Subscriber to the Notifier, to be able to know the Notification; and (5) any additional repetitions of messages (3) and (4) for additional status information. In this way, Notification messages are sent to inform the Subscribers of the state changes to which the subscriber has a subscription. Subscriptions are typically placed in their place using the SIP Subscription method, although other suitable mechanisms may be employed. As shown in Figure 4, after the terminal PTT 42 has been initially registered, the PTT server 44 is subscribed to the XML Event package of operation mode (response) of the corresponding PTT terminal, which is defined for this application by sending a SIP Subscription request 80 for the XML event packet 81 of operation mode (response) to the SIP / IP core 48. Then, SIP / IP core 48 routes SIP Subscription 80, as shown at 82, to terminal 42 of PTT. Then, the PTT terminal 42, which will perform the role of a Notifier, responds to the SIP Subscription 80, as routed at 82, with an 84 response of the SIP OK 200 to the SIP / IP core 48. In turn, the SIP / IP core 48 routes the SIP OK 200 response 84, as shown at 86, to the PTT server 44. For the Automatic Response Mode, the PTT terminal 42 notifies its current mode of operation (e.g., Automatic Response Mode) by sending a SIP Notification 88 containing the Operation Mode = Auto 89 in the body of the Notification 88 for the SIP / IP core 48. Then, the SIP / IP core 48 routes the SIP Notification 88, as shown at 90, to the PTT server 44. In response, the PTT server 44 establishes the state 54 (Figure 3) of the corresponding PTT terminal 42 in its state table 56 (Figure 3) in the Automatic Response Mode 58 '. Then, the PTT server 44 responds to the Notification 88, as routed at 90, with a 92 response from the SIP OK 200 to the SIP / IP core 48. Finally, the SIP / IP core 48 routes the SIP OK 200 response 92, as shown at 94, to the PTT terminal 42. At 95, the user switches the PTT terminal 42 from the Automatic Response Mode to the Manual Response Mode. This activates the PTT terminal 42 to notify its new mode of operation (Manual Response Mode) by sending a SIP Notification 96 containing the Operation Mode = Manual 97 from the body of the Notification 96 to the SIP / IP core 48. The SIP / IP core 48 routes the SIP notification 96, as shown at 98, to the PTT server 44. In response, the PTT server 44 changes the state 54 (Figure 3) of the corresponding PTT terminal 42 in its state table 56 (Figure 3) to the Manual Response Mode 68 '. Then, the PTT server 44 responds to the notification 96, as routed at 98, with a 100 response of the SIP OK 200 to the known SIP / IP core 48. Finally, the SIP / IP core 48 routes the OK 100 response 100, as shown at 102, to the PTT terminal 42. With reference to Figure 5A, another message diagram shows the message sequences for changing the mode of operation of the PTT terminal 42 on the PTT server 44. User presence represents the availability and ability of a user to communicate with other users in the SIP / IP network. SIP supports presence functionality and the ability of PTT terminals, such as 42, to establish the presence status information on themselves using a suitable SIP Publication method for a suitable Presence User Agent, such as the server 108 of presence. The presence server 108 includes a set of contact addresses representing the various mechanisms for contacting the user. Typically, the contact address listed for voice will be a registration address. The state of that contact may depend on any number of factors, which include, for example, the status of any records against the registration address. The registration status can be put in equation for user presence. In fact, this allows the Presence server 108 to be separated from the SIP registrar 46 (Figure 3), still using the registration information to construct a presence document, which describes the presence of the presented one (for example, a presence entity).; a presence information provider for a presence service) to which the SIP registrar 46 has subscribed (Figure 3). This is discussed in greater detail in the following, together with Figure 6 and Example 3. When the presence server 108 receives a presence subscription for a particular user, the presence server 108 can generate a subscription for the registrar 46. SIP (Figure 3) for the registration event package. As a result, the presence server 108 can learn about the registration status for that user, and can use that information to generate presence documents. Alternatively, the SIP registrar 46 may Publish the Registration Status on the presence server 108 using the SIP Publication method (eg, as discussed in the following with Figures 5A-5B), or the server 108 of Presence can receive a third party record from the SIP Registrar 46 when a new user registers (eg, as discussed in the following along with Figure 6). With reference to Figures 5A-5B, the PTT terminal 42 publishes its mode of operation (response) either as a separate presence tuple or as an attribute of another presence tuple transported using the SIP Publication method. The Publication method is routed to either: (1) a network-based Presence server entity, such as the presence server 108, which allows the SIP PTT network server 44 which controls the establishment of the sessions Subscribe to the Presence status of the corresponding SIP PTT terminal for the operation mode (response), or (2) the SIP PTT network server 44, which implements the functions of Presence User Agent. In the last example, the Presence server 108 is merged with the PTT server 44. Therefore, the PTT server 44 implements the functionality of the presence server 108 with message exchanges that are employed between the combined entities. After the PTT terminal 42 has initially registered with the SIP registrar 46 (Figure 3), the PTT server 44 is subscribed to the corresponding PTT Presence status when sending a SIP Subscription request for the Event package. of Presence for the PTT user through the SIP / IP core 48. If the PTT server 44 is only interested in the Mode of Operation state, then the body of the Subscription 110 may contain filters 111 indicating that only changes for the operating mode state must be reported. In turn, the SIP / IP core 48 routes the SIP Subscription as shown at 112, to the Presence server 108. Then, the Presence server 108 responds to Subscription 110, as routed at 112, with a SIP OK 200 response 114 via the SIP / IP core 48. Then, the SIP / IP core 48 routes the SIP OK 200 response 114, as shown at 116, to the PTT server 44. In the Automatic Response Mode, the PTT terminal 42 notifies its current mode of operation (e.g., Automatic Response Mode) and, optionally, an additional presence state when sending a SIP Publication 118 containing the Operation Mode = Auto 119 in the body of Publication 118 to the 48 SIP / IP core. Then, the SIP / IP core 48 routes the SIP Publication 118, as shown at 120, to the Presence server 108. Then, the Presence server 108 responds to Publication 118, as routed at 120, with a SIP OK 200 response 122 to the SIP / IP core 48. In turn, the SIP / IP core 48 routes the SIP OK 200 response 122, as shown at 124, to the PTT terminal 42. Then, the Presence server 108 notifies the operation mode (response) of the corresponding PTT terminal when sending a SIP Notification 126 containing the Presence Information that includes the Operation Mode = Auto 127 in the Notification body 126 to the SIP / IP core 48 So, the SIP / IP core 48 routes the SIP Notification 126, as shown at 128, to the PTT server 44. In turn, the PTT server 44 establishes the state 54 (Figure 3) of the corresponding PTT terminal 42 in its state table 56 (Figure 3) in the Automatic Response Mode 58 ''. Then, the PTT server 44 responds to the Notification 126, as routed to 128, as a SIP OK 200 response 130 to the '48 SIP / IP core. Finally, the SIP / IP core 48 routes the SIP OK 200 response 130, as shown at 132, to the Presence server 108. Also with reference to Figure 5B, at 133, the user switches the PTT terminal 42 from the Automatic Response Mode to the Manual Response Mode. This activates the PTT terminal 42 to notify its current mode of operation (response) and, optionally, an additional presence state when sending a SIP Publication 134 containing the Mode of Operation = Manual 135 in the body of Publication 134 to SIP / IP core 48 In turn, the SIP / IP core 48 routes the SIP Publication 134, as shown at 136, to the Presencia server 108. Then, the Presence server 108 responds to the Publication 134, as routed 136, with a 138 response of the SIP OK 200 to the SIP / IP core 48. Then, the SIP / IP core 48 routes the SIP OK 200 response 138, as shown at 140, to the PTT terminal 42. In turn, the Presence server 108 notifies the new operation mode (response) of the corresponding PTT terminal when sending a SIP Notification 142 containing the Presence Information and including the Operation Mode = Manual 143 in the body from Notification 142 to SIP / IP core 48. Then, the SIP / IP core 48 routes the SIP Notification 142, as shown at 144, to the PTT server 44. Then, the PTT server 44 changes the state 54 (Figure 3) of the corresponding PTT terminal 42 in its state table 56 (Figure 3) to the Manual Response Mode 68 ''. Then, the PTT server 44 responds to the Notification 142, as routed at 144, with a SIP OK 200 response 146 to the SIP / IP core 48. Finally, the SIP / IP core 48 routes the SIP OK 200 response 146, as shown at 148, to the Presence server 108. With reference to Figure 6, as an alternative to the SIP registrar 46 in the SIP / lP core 48 of Figure 3 which sends the SIP Register requests 52 or 66 to the PTT server 44, the SIP registrar 46 may Publish the Presence server 108 in the PTT SIP terminal register and cause the PTT server 44 to subscribe to the Presence server 108, in order to discover the SIP registry and have the Presence server 108 distribute the mode of operation response that was published by SIP Registrar 46. Although the following description is with respect to the Automatic Response Mode, it will be appreciated that a suitable corresponding indication mechanism can be employed for the Manual Response Mode or the Always Automatic Response Mode. Before the PTT terminal 42 registers with the SIP registrar 46, the PTT server 44 Subscribes to the corresponding PTT terminal's Presence status by sending a SIP subscription request 210 to subscribe to the Presence Events of the SIP. that PTT terminal through the SIP / IP core 48. If the PTT server 44 is only interested in the Mode of Operation state, then the Subscription 210 may contain filters 211 indicating that only changes for the Mode of Operation state can be reported. In turn, the SIP / IP core 48 routes the SIP Subscription 210, as shown at 212, to the Presence server 108. Then, the Presence server 108 responds to Subscription 210, corao routed to 212, with a SIP OK 200 response 214 via the SIP / IP core 48. Then, the SIP / IP core 48 routes the SIP OK 200 response 214, as shown in 216, to the server 44 of PTT. Next, the Presence server 108 notifies that the PTT terminal 42 currently not registered by sending a SIP Notification 226 containing the Presence Information that includes the Unregistered State 227 in the body of the Notification 226 to the SIP core 48 / IP. The SIP / IP core 48 routes the SIP Notification 226, as shown at 228, to the PTT server 44. In response, the PTT server 44 establishes the state 54 (Figure 3) of the corresponding PTT terminal 42 in its state table 56 (Figure 3) for Non-Registered 217. Then, the PTT server 44 responds to the Notification 226 , as routed 228, with a SIP OK 200 response 230 to the SIP / IP core 48. Finally, the SIP / IP core 48 routes the SIP 230 OK 200 response, as shown in 232, to the Presence server 108.

Then, after the PTT terminal 42 is energized, it is registered with the SIP / IP core 48 in the Automatic Response Mode by sending the SIP Registration request 250 to the SIP / lP core 48 containing the header 251. of Contact with a feature-param of + poc. operating.mode = "Auto". The SIP registrar 46 in the SIP / IP core 48 is configured to perform third party registrations with the Presence server 108 when the PTT terminal 42 is registered. Then, the SIP registrar 46 in the SIP / IP core 48 sends a SIP Registration request 252 to the Presence server 108 that contains a Contact header 253 for a + poc feature-param. operating.mode = "Auto". In response, the Presence server 108 establishes the state 254 of the PTT terminal 42 in the Presence Document 256 (PD) for the Registered and Automatic Response Mode. Then, a SIP registrar 46 in the SIP / IP core 48 responds to the SIP Register request 250 with a SIP OK 200 response 260 to the PTT terminal 42. Then, the Presence server 108 responds to the SIP Registration request 252 with a SIP OK 200 response 262 to the SIP registrar 46 in the SIP / IP core 48. The Presence server 108 also notifies the operation mode (response) of the corresponding PTT terminal when sending a SIP Notification 266 containing the Presence Information that includes the Registration Status = Registered Mode 267 and Operation in the body of the Notification 266 to nucleus 48 of SIP / lP. Then, the SIP / IP core 48 routes the SIP Notification 266, as shown at 268, to the PTT server 44. In turn, the PTT server 44 establishes the state 54 (Figure 3) of the corresponding PTT terminal 42 in its state table 56 (Figure 3) for Registered Mode 58 '' 'and Automatic Response. Then, the PTT server 44 responds to the Notification 266, as routed at 268, with an SIP OK 200 response 270 to the SIP / IP core 48. Finally, the SIP / lP core 48 routes the SIP OK 200 response 270, as shown at 272, to the Presence server 108. It will be appreciated that if the PTT terminal 42 changes from the Automatic Response Mode to one of the Manual Answer Mode or the Always Automatic Response Mode, that the PTT terminal 42 can be registered with the SIP / IP core 48 in the appropriate mode. for employing the SIP Registration 250 request that contains the 251 Contact header with the appropriate feature-param (eg, + poc .operating.mode = "Manual" or "Always Automatic", respectively), and that the request SIP Record 252 that contains the Contact header 253 may also have the appropriate feature parameter. Otherwise, the messages 250,252,260,262,266,268,270,272 are used in a similar way. Figure 7 shows another alternative for the SIP registrar 46 in the SIP / IP core 48 of Figure 3 which sends the SIP Register requests 52 or 66 to the PTT server 44. Although the following description is with respect to the Automatic Response Mode, it will be appreciated that a suitable corresponding indication mechanism can be employed for the Manual Response Mode or the Always Automatic Response Mode. For example, if the user switches the PTT terminal 42 to the Manual Answer Mode, then this activates a Renewal Register for that PTT terminal. The PTT terminal 42 is again Registered with the SIP / lP core 48 by sending another SIP Registration request (not shown) to the SIP / lP core 48 which contains a Contact header (not shown) with a feature-param. from + poc. operating.mode = "Manual". Initially, in Figure 7, the PTT server 44 sends a SIP Subscriber Request 280 to the SIP Registrar 46 in the SIP / IP core 48 to subscribe to the Recording Events 281 of the PTT terminal 42. Then, the SIP registrar 46 responds to Subscription 280 with a 282 response from SIP OK 200 for the PTT server 44. After, the SIP registrar 46 notifies that the PTT terminal 42 currently not registered by sending a SIP Notification 284 containing the Unregistered state 285 in the body of the Notification 284 to the PTT server 44. In response, the PTT server 44 establishes the state 54 (Figure 3) of the corresponding PTT terminal 42 in its state table 56 (Figure 3) for the Unregistered state 286. Then, the PTT server 44 responds to the Notification 284 with a 287 response from SIP OK 200 to SIP Registrar 46. After the PTT terminal 42 is energized, it is registered with the SIP / IP core 48 in the Automatic Response Mode by sending a SIP registration request 288 to the SIP / IP core 48 that contains a Contact header 289. with a feature-param of + poc .operating.mode = "Auto". Then, the SIP registrar 46 in the SIP / IP core 48 responds to the register 288 with a SIP OK 200 response 290 to the PTT terminal 42. Then, the SIP registrar 46 in the SIP / IP core 48 notifies the Registration and Operation Mode of the corresponding PTT terminal when sending a SIP Notification 292 containing the Registration Status = Registered and Operation Mode = Auto 293 in the body of Notification 292 for server 44 of PTT. In response, the PTT server 44 establishes the status 54 (Figure 3) of terminal 42 of PTT in its table 56 of states (Figure 3) for Mode 58 '' '' Registered and Response Automatic Finally, the PTT server 44 responds to the Notification 292 with a SIP OK 200 response 294 to the SIP registrar 46. It will be appreciated that if the PTT terminal 42 changes from the Automatic Response Mode to one of the Manual Answer Mode or the Always Automatic Response Mode, that the PTT terminal 42 can be registered with the SIP / lP core 48 in the appropriate mode when employing a SIP Register request 288 containing the Contact header 289 with the appropriate feature-param (eg, + poc. operating .mode = "Manual" "Always-Auto", respectively), and that Notification 292 SIP that contains the Registration Status = Registered and Operational Mode 293 may include the registered, appropriate mode of operation. Otherwise, the messages 288,290,293,294 are used in a similar way. Figure 8 shows another alternative for the SIP registrar 46 in the SIP / IP core 48 of Figure 3 which sends the 52 or 66 requests from the SIP Registry to the PTT server 44. Although the following description is with respect to an initial mode (e.g., the Automatic Response Mode) and a subsequent mode (e.g., the Manual Response Mode), it will be appreciated that a suitable corresponding identification mechanism can be employed for mode changes. subsequent (for example, to the Always Automatic Response Mode). For example, if the user changes the PTT terminal 42 to the Always Automatic Response Mode, then these are recorded in a Renewal Register for that PTT terminal. The PTT terminal 42 is again registered with the SIP / IP core 48 by sending another SIP Registration request (not shown) to the SIP / lP core 48 that contains a Contact header (not shown) with a feature-param from + poc. operating.mode = "Al ays-Auto". In Figure 8, the SIP registrar 46 only performs a third party registration in an initial register (eg, after the PTT terminal 42 is energized). The PTT server 44 in response to the initial third party registration, subscribes to the Registration Event Package of the PTT terminal, in order to obtain the operation mode of that PTT terminal and other changes for the registration status. First, the PTT terminal 42 is energized and registered with the SIP / lP core 48 by sending a SIP registration request 300 to the SIP / IP core 48 that contains a Contact header 301 with a feature-param of + poc. operating.mode = "Auto". The SIP Registrar 46 in the SIP / IP core 48 has been configured to perform third party registrations with the PTT server 44 when the terminal 42 of the PTT is initially registered. Then, the SIP Registrar 46 in the SIP / IP core 48 sends a SIP Registration request 302 to the PTT server 44. This SIP Registry request 302 does not contain a mode parameter of operation in the contact header 303. Then, the SIP Registrar 46 in the SIP / lP core 48 responds to the Register 300 with a SIP OK 200 response 304 to the terminal 42 of the PTT. The PTT server 44 responds to the Register 302 with a SIP OK 200 response 306 to the SIP Registrar 46 in the SIP / IP core 48. Then, the PTT server 44 sends a SIP Subscription request 308 to the SIP registrar 46 in the SIP / IP core 48, in order to be able to subscribe to the Recording Events 309 of the terminal 42 of the PTT. Then, the SIP Registrar 46 responds to Subscription 308 with a 310 OK response from SIP 310 to the PTT server 44. The SIP Registrar 46 in the SIP / IP 48 kernel also notifies the Registration and Operation mode of the PTT terminal by sending a SIP Notification 312 containing the Registration Status = Registered Mode and Operation = Auto 313 in the body from Notification 312 to server 44 of PTT. In response, the PTT server 44 sets the state 54 (Figure 3) of the corresponding PTT terminal 42 in its state table 56 (Figure 3) for Registered Mode 58 '' '' 'and Automatic Response. Finally, for this initial mode, the PTT server 44 responds to the Notification 312 with a SIP OK 200 response 314 for the SIP Registrar 46.

If the user changes the PTT terminal 42, for example, to the Manual Answer Mode, then it activates a Renewal Register for the terminal 42 of PTT. The PTT terminal 42 is also registered with the SIP / lP core 48 by sending a SIP Registration request 316 to the SIP / IP core 48 that contains a Contact header 317 with a + poc feature-param. operating.mode = "Manual". SIP Registrar 46 in SIP / IP core 48 responds to Register 316 with a SIP OK 200 response 320 for terminal 42 of PTT. The SIP Registrar 46 in the SIP / IP core 48 also notifies the new Operation Mode of the PTT terminal by sending a SIP Notification 318 containing the Presence Information that includes the Operation Mode = Manual 319 in the body of Notification 318 for server 44 of PTT. In response, the PTT server 44 changes the state 54 (Figure 3) of the corresponding PTT terminal 42 in its state table 56 (Figure 3) to the Manual Response Mode 68 '' '. Finally, the PTT server 44 responds to the Notification 318 with a 322 response from the SIP OK 200 to the SIP Registrar 46. With reference to Figure 9A, the PTT terminal 42 communicates with its mode of operation (response) using the SIP Publication method and an event packet containing elements for the current value of its mode of operation (response). The Publication method is routed to the SIP PTT network server 44. Terminal 42 of PTT was initially registered with SIP Registrar 46 (Figure 3). In the Automatic Response Mode, the PTT terminal 42 notifies its current mode of operation (e.g., Automatic Response Mode) when sending a SIP Publication 338 containing the Operation Mode = Auto 339 in the body of the Publication 338 for the SIP / IP core 48. Then, the SIP / IP core 48 routes SIP Publication 338, as shown at 340, to the SIP PTT network server 44.

In response, the PTT server 44 establishes the status 54 (Figure 3) of the corresponding PTT terminal 42 in its state table 56 (Figure 3) for Mode 58 '' '' '' of Automatic response. Then, the SIP PTT network server 44 responds to Publication 338, as routed at 340, with a SIP OK 200 response 342 to the 48 SIP / lP core. In turn, the SIP / IP core 48 routes the SIP OK 200 response 342, as shown at 344, to the PTT terminal 42. With reference to Figure 9B, at 353, the user switches the PTT terminal 42 from the Automatic Response Mode to the Manual Response Mode. This activates the PTT terminal 42 to notify its current mode of operation (response) by sending a SIP Publication 354 containing the Mode of Operation = Manual 355 in the body of the Publication 354 for the SIP / IP core 48. In turn, the SIP / IP core 48 routes the SIP Publication 354, as shown at 356, to the SIP PTT network server 44. In response, the PTT server 44 changes the state 54 (Figure 3) of the corresponding PTT terminal 42 in its state table 56 (Figure 3) to the Manual Response Mode 68 '' ''. Then, the SIP PTT network server 44 responds to Publication 354, as routed at 356, with a SIP OK 200 response 358 to SIP / lP core 48. Then, the SIP / IP core 48 routes the SIP OK 200 response 358, as shown in 360, to the terminal 42 of the PTT. Example 3 As alternatives to the message diagrams of Figures 6 and 7, a wide range of variations and / or combinations of those message flows is possible. For example, the Presence server 108 of Figure 6 may employ messages 280,282,284,287,292,294 of Figure 7, with the Presence server 108, instead of the PTT server 44, which performs the Subscription for the 281 Registration Events of terminal 42. of PTT instead of messages 252,262 of Figure 6. Although an Automatic Response Mode, an Always Automatic Response Mode and a Manual Response Mode are described in conjunction with Figure 2, either, two or three such modes can be used .

Although the Automatic Response Mode and the Manual Response Mode are described together with Figures 3-5, 8 and 9A-9B, the Always Automatic Response Mode or any, two or three such modes can be employed. Although the Automatic Response Mode is described in conjunction with Figures 6 and 7, the Manual Response Mode, the Always Automatic Response Mode or any, two or three such modes can be employed. As used herein, the term "Automatic Response Mode" means the same as "Auto Response Mode". As used herein, the term "Auto Response Mode" means the same as "Automatic Response Mode". As used herein, the term "Mode of Always Automatic Response "means the same as" Always Auto Response Mode. "As used herein, the term" Always Auto Response Mode "means the same as" Always Automatic Response Mode. "The Management Server Group (GLMS) as referred to herein may be a Management Server for Group Lists (not shown) or a Management Server of XML documents (XDMS) (not shown). A document management server and / or a database (not shown), which includes an XDMS or GLMS Server or Group List Management, stores group identities, contact lists, and / or authorization policies. There may also be one or more XDMS that operate at the same time. While specific embodiments of the invention have been described in detail, it will be appreciated by those skilled in the art that various modifications and alternatives to those details may be developed in view of the general teachings of the disclosure. Accordingly, the particular provisions described are to be understood to be illustrative only and not restrictive since the scope of the invention will be given the broad scope of the appended claims and any and all equivalents thereof.

Claims (53)

1. CLAIMS 1. A method for a push-to-talk communication device that includes an operation mode to indicate the mode of operation for a push-to-talk network server, the method characterized in that it comprises: employing as the device operation mode communication to press to speak one of a first response mode and a second response mode; employ a communication network that includes a push-to-talk network server; and indicate the mode of operation in a Session Initiation Protocol message from the push to talk communication device to the network server to press to talk about the communication network.
2. 2. The method of compliance with the claim 1, further characterized in that it comprises: using as the first response mode an automatic response mode; use a manual response mode as the second response mode; employing as the communication network a core network of Internet Protocol; and use as the network server to press to talk a network server to press to talk about Internet Protocol.
3. 3. The method in accordance with the claim 2, further characterized in that it comprises: registering the mode of operation of the communication device of pressing to talk to the network server of pressing to talk about Internet Protocol.
4. 4. The method of compliance with the claim 3, further characterized by comprising: employing a Log of Session Initiation Protocol in the core network of Internet Protocol; and sending a first log-in message from the push-to-talk communication device to the log-in protocol log.
5. 5. The method according to claim 4, further characterized in that it comprises: sending a second Log-In Protocol message from the log-in protocol log to the push-to-talk network server Internet protocol.
6. 6. The method of compliance with the claim 4, further characterized in that it comprises: employing as the mode of operation of the push-to-talk communication device the automatic response mode; and including in the first registration message of the Session Initiation Protocol a header having a parameter representing the automatic response mode.
7. The method according to claim 6, further characterized in that it comprises: sending a second Log Start Protocol Log message from the Logon Protocol logon to the push network server to talk about Internet Protocol; include in the second Session Initiation Protocol Registration message a header having a parameter representing the automatic response mode; and establish a push-to-talk communication device state for the automatic response mode on the network server by pressing to talk about Internet Protocol.
8. The method according to claim 4, further characterized in that it comprises: employing as the mode of operation of the push-to-talk communication device an always-automatic response mode; and include in the first Registration message of Logon Protocol a header that has a parameter that represents the always automatic response mode.
9. 9. The method according to claim 8, further characterized in that it comprises: sending a second Log Start Protocol Log message from the Logon Protocol log to the push-to-talk network server of Internet Protocol; include a header in the second Session Initiation Protocol Registration message that has a parameter representing the always automatic response mode; and establish a push-to-talk communication device state for the always-automatic response mode on the network server by pressing to talk about Internet Protocol.
10. 10. The method according to claim 4, further characterized in that it comprises: employing as the mode of operation of the push-to-talk communication device the manual response mode, and including in the first Log-In Protocol message a header having a parameter representing the manual response mode.
11. The method according to claim 10, further characterized in that it comprises: sending a second Log Start Protocol Log message from the logon protocol log to the push to talk network server of Internet Protocol; include in the second Log of Start-up Protocol Register message a header that has a header representing the manual response mode; and establish a state of the push to talk communication device for the manual response mode on the network server to press to talk about Internet Protocol.
12. 12. The method in accordance with the claim 2, further characterized by comprising: notifying the network server of pressing to talk about Internet Protocol of the operation mode of the push-to-talk communication device.
13. 13. The method according to the claim 12, further characterized in that it comprises: sending a Protocol Subscription message of Login associated with the mode of operation of the push to talk communication device from the network server to press to talk about Protocol Internet to the Internet Protocol core network; and routing the Session Initiation Protocol Subscription message over the Internet Protocol core network to the push to talk communication device.
14. 14. The method in accordance with the claim 13, further characterized in that it comprises: defining and employing an event packet, which includes the automatic response mode, which is possessed by the push-to-talk communication device.
15. 15. The method of compliance with the claim 14, further characterized by comprising: subscribing using the Session Initiation Protocol Subscription message to the event pack in the push to talk communication device; send a Notification of Logon Protocol message for the automatic response mode from the push-to-talk communication device to the core Internet Protocol network; route the Notification Protocol message of Session by the Internet Protocol core network to the network server to press to talk about Internet Protocol; and establish a state of communication device to press to talk in the automatic response mode on the network server to press to talk about Internet Protocol.
16. The method according to claim 12, further characterized in that it comprises: defining and employing an event packet, which includes the automatic response mode, which is possessed by the push-to-talk communication device.
17. 17. The method according to claim 16, further characterized in that it comprises: sending a message of Protocol Publication of Log-in containing the event pack associated with the mode of operation of the push-to-talk communication device from the push-to-talk communication device to the core Internet Protocol network; route the message of publication of Protocol of Initiation by the network of core of Internet Protocol to the network server of pressing to speak of Internet Protocol; and establish a state of the push-to-talk communication device in an automatic response mode on the network server by pressing to talk about Internet Protocol.
18. 18. The method according to claim 13, further characterized in that it comprises: defining and employing an event packet, which includes an always-automatic response mode, which is possessed by the push-to-talk communication device.
19. The method according to claim 18, further characterized in that it comprises: subscribing using a Session Initiation Protocol Subscription message to the event packet in the push to talk communication device; send a Session Initiation Protocol Notification message for the always-automatic response mode from the push-to-talk communication device to the core Internet Protocol network; route the message of Notification of Protocol of Initiation by the network of core of Internet Protocol to the network server of pressing to speak of Internet Protocol; and establish a state of communication device from push to talk in the always automatic response mode on the network server to press to talk about Internet Protocol.
20. The method according to claim 12, further characterized in that it comprises: defining and employing an event packet, including an always automatic response mode, which is possessed by the push-to-talk communication device.
21. 21. The method according to claim 20, further characterized in that it comprises: sending a message of Protocol Publication of Log-in containing the event pack associated with the mode of operation of the push-to-talk communication device from the push-to-talk communication device to the core Internet Protocol network; route the message of Publication of Protocol of Initiation by the core network of Internet Protocol to the network server of pressing to speak of Internet Protocol; and establish a state of the communication device from push to talk in the always automatic response mode on the network server to press to talk about Internet Protocol.
22. 22. The method according to claim 13, further characterized in that it comprises: defining and employing an event packet, which includes the manual response mode, which is possessed by the push-to-talk communication device.
23. The method according to claim 22, further characterized by comprising: subscribing using the Session Initiation Protocol Subscription message in the event packet in the push to talk communication device; send a Session Initiation Protocol Notification message for the manual response mode from the push to talk communication device to the core Internet Protocol network; route the message of Notification of Protocol of Initiation by the network of core of Internet Protocol to the network server of pressing to speak of Internet Protocol; and establish a state of the communication device from push to talk in the manual response mode on the network server to press to talk about Internet Protocol.
24. 24. The method according to claim 12, further characterized in that it comprises: defining and employing an event packet, which includes the manual response mode, which is possessed by the push-to-talk communication device.
25. The method according to claim 24, further characterized in that it comprises: sending a Session Initiation Protocol Publication message containing the event pack associated with the push-to-talk communication device operation mode from the device from push to talk communication to the Internet Protocol core network; route the message of Publication of Protocol of Initiation by the core network of Internet Protocol to the network server of pressing to speak of Internet Protocol; and establish a state of the communication device from push to talk in the manual response mode on the network server to press to talk about Internet Protocol.
26. 26. The method of compliance with the claim 2, further characterized by comprising: publishing the mode of operation of the push-to-talk communication device on a Presence server of the Internet Protocol core network.
27. 27. The method of compliance with the claim 2, further characterized in that it comprises: publishing the mode of operation of the push-to-talk communication device on a network server to press to talk about Internet Protocol.
28. 28. The method of compliance with the claim 26, further characterized in that it comprises: defining and employing an event packet, for the push to talk communication device, which includes the operation mode.
29. 29. The method of compliance with the claim 28, further characterized in that it comprises: sending a Session Initiation Protocol Subscription message for the event packet from the dial-up network server to the Internet Protocol core network; and routing the Session Initiation Protocol Subscription message over the Internet Protocol core network to the Presence server of the Internet protocol core network.
30. 30. The method of compliance with the claim 28, further characterized in that it comprises: sending a message of Protocol Publication of Login containing a representation of the automatic response mode from the push-to-talk communication device to the core network of the Protocol of Internet .
31. The method according to claim 30, further characterized in that it comprises: routing the Session Initiation Protocol Publication message over the Internet Protocol core network to the Presence server; send a Session Initiation Protocol Notification message containing a representation of the automatic response mode from the Presence server to the core Internet Protocol network; route the Session Initiation Protocol Notification message through the Protocol core network Internet to the network server to press to talk about Internet Protocol; and establish a state of communication device from push to talk in the automatic response mode on the network server to press to talk about Internet Protocol.
32. The method according to claim 30, further characterized in that it comprises: routing the Session Initiation Protocol Publication message through the Internet Protocol core network to the push-to-talk network server of Internet Protocol; and establish a state of communication device from push to talk in the automatic response mode on the network server to press to talk about Internet Protocol.
33. 33. The method according to claim 28, further characterized in that it comprises: sending a message of Protocol Publication of Login that contains a representation of an always-automatic response mode from the push-to-talk communication device to the core Internet Protocol network.
34. The method according to claim 33, further characterized in that it comprises: routing the Session Initiation Protocol Publication message over the Internet Protocol core network to the Presence server; send a Session Initiation Protocol Notification message containing a representation of the always-automatic response mode from the Presence server to the core Internet Protocol network; route the message of Notification of Protocol of Initiation by the network of core of Internet Protocol to the network server of pressing to speak of Internet Protocol; and establish a state of the communication device from push to talk in the always automatic response mode on the network server to press to talk about Internet Protocol.
35. 35. The method according to claim 33, further characterized in that it comprises: routing the message of Protocol Publication of Logon by the Internet Protocol core network to the network server to press to talk about Internet Protocol; and establish a state of the communication device from push to talk in the always automatic response mode on the network server to press to talk about Internet Protocol.
36. 36. The method according to claim 28, further characterized by comprising: sending a Session Initiation Protocol Publication message containing a representation of the manual response mode from the push to talk communication device to the core network of Internet Protocol.
37. 37. The method according to the claim 36, further characterized in that it comprises: routing the Session Initiation Protocol Publication message over the Internet Protocol core network to the Presence server; send a Protocol Notification message Login that contains a representation of the manual response mode from the Presence server to the core network of Internet Protocol; route the message of Notification of Protocol of Initiation by the network of core of Internet Protocol to the network server of pressing to speak of Internet Protocol; and establish a state of communication device from push to talk in the manual response mode on the network server to press to talk about Internet Protocol.
38. 38. The method according to claim 36, further characterized in that it comprises: routing the Session Initiation Protocol Publication message through the Internet Protocol core network to the dial-up network server of the Internet Protocol; and establish a state of communication device from push to talk in the manual response mode on the network server to press to talk about Internet Protocol.
39. 39. The method according to claim 2, further characterized in that it comprises: using the push-to-talk communication device as a push-to-talk wireless terminal.
40. 40. The method according to claim 2, further characterized in that it comprises: employing as the core network of Internet Protocol a core network of Internet Protocol / Session Initiation Protocol.
41. 41. The method according to claim 2, further characterized in that it comprises: employing as the core network of Internet Protocol a push-to-talk network on cellular Logon Protocol to indicate the mode of operation for the network server to press to talk about Internet protocol.
42. 42. The method according to claim 2, further characterized by comprising: selecting one of the automatic response mode, an always automatic response mode, and the manual response mode in the push-to-talk communication device, and providing in responsible manner the indication of the mode of operation in a message of Protocol of Initiation of Session from the device of communication of pressing to speak until the network server of pressing to speak of Internet Protocol on the core network of Internet Protocol.
43. 43. The method according to the claim 42, further characterized by comprising: using a rocker switch to select one of the automatic response mode, the always-automatic response mode and the manual response mode in the push-to-talk communication device.
44. 44. The method according to claim 2, further characterized in that it comprises: employing a Session Initiation Protocol Presence server in the Internet Protocol core network; Send a Protocol Registration message Log-in that includes the mode of operation from the push-to-talk communication device to the core network of Internet Protocol; and routing the Session Initiation Protocol Registration message including the mode of operation by the Internet Protocol core network to the Presence server.
45. 45. The method according to claim 44, further characterized in that it comprises: sending a Session Initiation Protocol Notification message including the mode of operation from the Presence server to the core Internet Protocol network; and routing the Session Initiation Protocol Notification message which includes the mode of operation by the Internet Protocol core network to the network server to press to talk about Internet Protocol.
46. 46. The method according to claim 2, further characterized in that it comprises: employing a Session Initiation Protocol Registration server in the core Internet Protocol network; accept a Subscription from the Internet Protocol network server in the Logon Protocol logon server for a log event packet for the push-to-talk communication device; and register the mode of operation of the communication device of pressing to speak with the registration server.
47. 47. The method according to claim 46, further characterized in that it comprises: sending a Notification of Logon Protocol message for the mode of operation from the registration server to the network server of push to talk about Internet Protocol.
48. 48. The method according to claim 2, further characterized by comprising: employing a Session Initiation Protocol Registration server in the core Internet Protocol network; accept a Subscription from the network server to press to talk about Internet Protocol on the logon server from Logon to a Registration Event packet for the push-to-talk communication device; register the mode of operation of the communication device of pressing to speak with the Registry server, and notify the network server of pressing to talk about Internet Protocol of the operation mode.
49. 49. The method according to claim 48, further characterized in that it comprises: employing as the mode of operation of the push-to-talk communication device a first mode of operation; changing the first mode of operation in a second mode of operation different from the communication device of push to talk; register a second mode of operation different from the communication device of pressing to talk to the registry server; and notify the network server to press to talk about Internet Protocol of the second different operating mode.
50. 50. The method according to claim 2, further characterized in that it comprises: employing a Session Initiation Protocol Registration server in the core Internet Protocol network; employ a Session Initiation Protocol Presence server in the core Internet Protocol network; accept a Subscription from the Internet Protocol Presence server on the Registry server of Session Initiation Protocol for a registration event pack for the push to talk communication device; and register the mode of operation of the communication device of pressing to speak with the Registry server.
51. 51. The method of compliance with the claim 50, further characterized by comprising: sending a Session Initiation Protocol Notification message for the mode of operation from the Registration server to the Presence server.
52. 52. The method of compliance with the claim 51, further characterized by comprising: sending another Session Initiation Protocol Notification message for the mode of operation from the Presence server to the network server of pressing to talk about Internet Protocol.
53. 53. A method for a push-to-talk communication device that includes an operation mode for indicating the mode of operation for a push-to-talk network server, the method characterized in that it comprises: employing as the operating mode of the push-to-talk device; push communication to speak one of a first response mode, a second response mode, and a third response mode; employ a communication network that includes a push-to-talk network server; and indicate the mode of operation in a message of Session Initiation Protocol from the push to talk communication device to the network server to press to talk about the communication network. 5 . The method in accordance with the claim 53, further characterized in that it comprises: using as the first response mode an automatic response mode; use as the second response mode a response mode always automatic; use a manual response mode as the third response mode; employing as the communication network a core network of Internet Protocol; and use as the network server to press to talk a network server to press to talk about Internet Protocol. 55. The method of compliance with the claim 54, further characterized in that it comprises: using a rocker switch to select one of the automatic response mode, the always automatic response mode and the manual response mode in the push to talk communication device. 56. A method for a push-to-talk communication device that includes an operation mode for sending the operation mode to a push-to-talk network server, the method characterized in that it comprises: employing as the operating mode of the push-to-talk device; push communication to speak one of at least a first response mode and a second response mode; employ a communication network that includes a push-to-talk network server; and send the operation mode in an event report message from the push to talk communication device or from another device to the communication device name from press to talk to the network server to press to talk about the communication network . 57. The method of compliance with the claim 56, further characterized in that it comprises: using as the first response mode an automatic response mode; use a manual response mode as the second response mode; employing as the communication network a core network of Internet Protocol; and use as the network server to press to talk a network server to press to talk about Internet Protocol. 58. The method of compliance with the claim 57, further characterized by comprising: employing as the mode of operation of the push-to-talk communication device an always-automatic response mode such as a third response mode. 59. The method according to claim 56, further characterized by comprising: employing a Session Initiation Protocol message as the event report message. 60. The method according to claim 56, further characterized in that it comprises: employing a Session Initiation Protocol Notification message as the event report message. 61. The method of compliance with the claim 56, further characterized in that it comprises: employing a Session Initiation Protocol Publication message as the event report message. 62. The method according to claim 60, further characterized by comprising: employing an event packet to encode an event in the event report message for the operation mode. 63. The method according to claim 61, further characterized by comprising: employing an event packet to encode an event in the event report message for the operation mode. 6 The method according to claim 62, further characterized in that it comprises: employing the XML encoding for the event package for the event report message. 65. The method according to claim 63, further characterized in that it comprises: employing the XML encoding for the event package for the event report message. 66. A portable electronic push-to-talk device that includes a mode of operation, the portable electronic push-to-talk device characterized in that it comprises: means for communicating with a communication network including a push-to-talk network server; and means for indicating the mode of operation in a Session Initiation Protocol message from the portable electronic device of pressing to speak for the network of pressing to talk about the communication network; where the operation mode is one of a first response mode and a second response mode. 67. A push-to-talk network server for a push to talk communication device includes one mode of operation, the operation mode is one of a first response mode and a second response mode, the push communication device. to speak indicates the mode of operation in a Session Initiation Protocol message from the push to talk communication device to the network server to press to talk about a communication network, the push-to-talk network server characterized because comprises: means for communicating with the communication network to receive the Session Initiation Protocol message; and means for establishing a state of the push-to-talk communication device that corresponds to the operation mode on the push-to-talk network server in response to the Session Initiation Protocol message.