Method, system and apparatus for participating in group communication services in an existing communication system

ES 2 379 863 T3

DESCRIPTION

Procedure, system and apparatus to participate in group communication services in an existing communication system

Background of the invention

I. Field of the invention

The present invention relates to point-to-multipoint communication systems. More specifically, the present invention relates to an apparatus and method for enabling group communication services using the standard Internet protocol in an existing communication system.

II. Description of Related Art

Point-to-multipoint communication systems have been used to provide communications generally between a central location and multiple users of the system. For example, dispatch systems that use land mobile radios (LMRs) in trucks, taxis, buses and other vehicles to communicate time information between a dispatch center and one or more corresponding vehicles in the fleet. Communications can be directed to a specific vehicle in the fleet or to all vehicles simultaneously.

Another example of a point-to-multipoint communication system is a wireless push-button talk system. Such a system allows a group of individuals, each of whom has a wireless communications device, to communicate with other members of the group. Typically, a push-button talk system uses a single frequency or a single dedicated channel over which wireless communication devices receive communications. In most systems, only one member can transmit information to the other members at any one time. However, all members can listen on the dedicated broadcast channel to receive communications from a single broadcasting member. Typically, members wishing to broadcast to other members of the system send an access request by pressing a push-talk button on their respective communications device, allowing the user exclusive access to the dedicated channel.

Push-button talk systems are typically used in outdoor settings where a group of people or members require mutual “point-to-point” style communication. Examples of uses for push-button talk systems include workgroup communications, security communications, construction building communications, and localized military communications. The group of people who require mutual communication is commonly referred to as a "network", with each member of the network sometimes being referred to as a "network member".

In a typical push-button talk system, a dedicated channel, sometimes referred to as a broadcast channel, is used to simultaneously transmit communications from one member to multiple additional members of the network. The dedicated channel may comprise a single channel or single frequency, or a group of individual channels managed by a controller to mimic the single channel. In any case, at any given time only one member can transmit voice and / or data communications to the other user members. If another member tries to transmit on the broadcast channel while another member is transmitting, interference will occur between the two competing communications, resulting in the other network members receiving unintelligible communications.

GB 2,290,196A describes a radio relay system, with a central unit and mobile radio units, having a group call mode.

Document WO 98 / 21676A 1 describes a telecommunications system with a billing server separate from a billing system and a transfer of charge records between the billing server and the billing system.

Summary of the invention

To implement a push-talk communication system in a conventional wireless communication system, expensive infrastructure modifications are generally necessary.

In addition to the high costs associated with current point-to-multipoint wireless communication systems, communications are generally restricted to members operating in close relative proximity to each other using the same or similar technology. In other words, point-to-multipoint communications do not extend to other communications networks or technologies, such as the public switched telephone network (PSTN), to data networks, such as the Internet, or to satellite communications systems, such as the Internet. GlobalStar satellite communications system.

ES 2 379 863 T3

Thus, the present invention is a push button talk communication device in a group communication network. The group communication network comprises a controller for managing the group communication network and communicating with the push-button talk communication device. A processor converts information signals into data packets suitable for transmission over a distributed network. The processor may also have identifying information and updates your identifying information when your current identifying information needs to change or is about to change. The processor then transmits its new identification information to the controller. The push-button conversation device also comprises a transmitter for transmitting data packets to the controller on a first channel. A receiver receives data packets from the controller on a second channel. The push-button conversation device also comprises a user-activated mechanism to activate the transmitter when a user of the communication device wishes to transmit data packets to said controller.

In an exemplary embodiment, the communication device is a wireless communication device. The communications device may further comprise memory for storing data packets until the controller is ready to receive the data packets. Memory is used to minimize the perceived latency of a user. The processor may further comprise a dynamically configurable priority level in which the priority level determines whether the communications device has the authority to obtain a transmission privilege over another communications device so that the communications device can interrupt. the transmission of a communications device that has a lower priority level. In addition, the processor can receive information from the controller regarding the group communications network, such as who is participating in the network, how many are participating in the network, and where the users are physically located.

The communications device can also operate safely. The processor may further comprise identifying information. The processor updates your identifying information when your identifying information needs to change or is about to change, and then transmits your new identifying information to the controller.

The group communications network is also capable of being in dormant mode. Activation of the user-activated mechanism asks the controller to bring the communications network out of dormant mode.

The communications device communicates with the communications manager. The communications manager comprises a first node for establishing a first channel with a first communications device. At least one second node establishes at least one second channel with at least one second communication device. The channel that connects the communication devices with the controller, or the communication manager, comprises a signal initiation protocol (SIP) channel, a multimedia signaling channel, and a multimedia traffic channel. A controller, also called a communications manager, electrically connects the first node with the at least said second node. The controller further comprises a database module. The database module includes identification information for each of the communication devices in the group. The controller is dynamically configurable so that any individual communications device in the group is capable of sending data packets on its respective channel to the other communications devices in the group. In one embodiment, the data packets contain information as a function of time. In another embodiment, at least one of the communication devices is a wireless communication device.

The controller further comprises a central module and a network, or UCM module. The central module and said network module are connected to the distributed network. The central module establishes the identification of each of the communication devices and redirects information from the communication devices to the network module. The network module operates and manages information transmitted between the group of communication devices. In an exemplary embodiment, the database module is part of the core module. The central module further comprises a billing registration module. The billing log module maintains a history of activity between communication devices.

The network module further comprises a local registration module. The local logging module maintains a history of activity between communication devices and transfers the collected history to the billing logging module.

According to the present invention, there is provided a local mode for collecting and managing billable information in a group communication system according to claim 1, a corresponding system according to claim 6 and a corresponding method according to claim 9. In the dependent claims are defined preferred embodiments of the invention.

Brief description of the drawings

The features and advantages of the present invention will become more apparent from the detailed description presented below when taken in conjunction with the drawings in which like reference numerals identify like parts from start to finish, and in which :

ES 2 379 863 T3

FIG. 1 illustrates a network broadcasting system.

FIG. 2 illustrates an SRR network and how communication devices interact with a communication manager (GC) 104.

FIG. 3 illustrates a functional block diagram of the GC.

FIG. 4 illustrates an example of an SRR SIP signaling protocol stack.

FIG. 5 illustrates an SRR multimedia signaling protocol stack.

FIG. 6 illustrates a real-time protocol voice multimedia protocol stack.

FIG. 7 illustrates a UDP voice multimedia protocol stack.

FIG. 8 illustrates a multimedia traffic protocol stack.

FIG. 9 illustrates a DNS client protocol stack.

FIG. 10 illustrates the high-level functionality of the DC group services module 500.

FIG. 11 illustrates signaling 350 of a SIP call.

FIG. 12 illustrates a sequence of multimedia signaling messages.

FIG. 13 illustrates the sequence of multimedia signaling messages with respect to latency.

FIG. 14 illustrates a sequence of SRR multimedia signaling messages.

FIG. 15 illustrates a state diagram of the GC 104.

FIG. 16 illustrates a state diagram of the DC 352.

Detailed description of the preferred embodiments

The Network Broadcasting Service (SRR) system enables Internet Protocol (IP) communication devices to participate in a group voice and data conference. The SRR is primarily a Voice over IP (VoIP) application. Voice communication is transmitted from a talker communications end device to one or more listeners by encapsulating voice frames in IP datagrams. Data can also be transmitted by voice in this way. The SRR system is described in US Patent 6,477,150 B1, entitled "Method and Apparatus for Providing Group Communication Services in an Existing Communication System", filed March 3, 2000, Agent Docket No. 000212, and publication WO 01/67674 A2, entitled “Method and Apparatus for Participating in Group Communication Services in an Existing Communication System”, filed on March 3, 2000, agent file n ° 000211.

FIG. 1 illustrates a functional block diagram of a group communication system 10. The group communication system 10 is also referred to as a push-button talk system, network broadcast service (SRR), dispatch system, or point-to-multipoint communication system. A defining characteristic of the SRR system is that generally only one user can transmit information to other users at any given time. In SRR 10, a group of communication device users, individually known as network members, communicate with each other using a communication device assigned to each member of the network.

The term "network" denotes a group of communication device users authorized to communicate with each other. Generally, a central database contains information that identifies the members of each particular network. More than one network can operate on the same communication system. For example, a first network can be defined to have ten members and a second network can be defined to have twenty members. The ten members of the first network can communicate with each other, but generally not with members of the second network. In other situations, members of different networks are capable of monitoring communications between members of more than one network, but are only capable of transmitting information to members within their own network.

The network operates on an existing communications system without requiring substantial changes to the existing infrastructure. Thus, a controller and users in a network can operate in any system capable of transmitting and receiving information in packets using the internet protocol (IP), such as a code division multiple access system (CDMA), an access system time division multiplex (TDMA), a global system for a mobile communication system (GSM), satellite communication systems, such as Globalstar ™ or Iradium ™, or various other systems.

Members of the network communicate with each other using an assigned communications device, shown as Communications Devices (DC) 12, 14, 16, and 17. The DC 12, 14, 16 and 17 can be wired or wireless communication devices, such as landline cordless telephones, corded telephones equipped with push-button conversation capabilities, satellite phones equipped with push-button conversation functionality, wireless camcorders, photographic cameras , audio devices such as music recorders or players, laptops or desktops, paging devices or any combination thereof. For example, the DC 12 may comprise a cordless land telephone equipped with a video camera and display. Additionally, each DC may be able to send and receive information in either secure or non-secure mode (no encryption). Throughout the following discussion, reference to an individual DC may be expressed as a push-button conversation cordless telephone. However, it should be understood that reference to a DC is not intended to be limited in that sense, and that it may encompass other communication devices that have the ability to transmit and receive information in packets under Internet Protocol (IP).

ES 2 379 863 T3

In the SRR system 10 of FIG. 2, a transmission privilege is defined that generally allows a single user to transmit information to other members of the network at any given time. A broadcast privilege is granted or denied to requesting members of the network, depending on whether or not the broadcast privilege is currently assigned to another network member when the request is received. The procedure for granting or denying a transmission request is called arbitration. Other arbitration schemes evaluate factors such as the priority levels assigned to each DC when determining whether to grant the transmission privilege to a requesting member of the network.

To participate in the SRR system 10, DCs 12, 14, 16, and 17 each have the ability to request transmission privilege from a controller or communications manager 18 (GC). The GC 18 generally manages the real-time and administrative operation of the networks. The GC is any type of computer-type device that has at least one processor and memory. In one embodiment, the GC is a Sun Netra T1 ™ workstation.

The GC 18 maintains a list of defined networks, defined as either unencrypted or secure. Transitions between unencrypted and secure are not normally allowed. A secure network uses encryption provided by individual DCs to provide authentication and guard against eavesdropping. Encryption on secure networks is implemented end-to-end, which means that encryption and decryption takes place within each DC. The GC 18 generally operates without knowledge of algorithms, keys, or security guidelines.

The GC 18 performs remote management either through a communication system service provider, network members, or both, assuming the service provider provides authorization. The GC 18 can receive network definitions via an external management interface 226. Members of the network can request administrative actions through their service provider or manage network functions through defined systems, such as a member-operated security manager (GS) that follows a management interface. from GC 18. The GC 18 can authenticate to high-quality commercial standards to any party attempting to establish or modify a network.

The GS 20 is an optional component of the SRR 10 system that performs key management, user authentication, and related tasks to support secure networks. A single group communication system can interact with one or more GS 20. Generally, the GS 20 is not involved in real-time control of a network, including network activation or PTT arbitration. The GS 20 may have management capabilities compatible with a GC 18 interface to automate management functions. The GS 20 may also be capable of acting as a data endpoint in order to participate in a network, issue network keys, or simply monitor network traffic.

In one embodiment, the means for requesting the transmission privilege from a DC comprises a key or a push button talk (PTT) switch. When a user of the SRR 10 wishes to transmit information to other members of the network, he presses the push-button talk switch located on his DC, sending a request to obtain the transmission privilege from the GC 18. If no other member of the network is currently assigned the broadcast privilege, the requesting user is granted broadcast privilege and notified by the DC via an audible, visual, or tactile alert. After the requesting user has been granted the transmission privilege, information can be transmitted from that user to the other members of the network.

In one embodiment of the present invention, each member of the wireless network establishes an uplink and a downlink with one or more base stations 22 or a satellite gateway 24, as the case may be. Base station 22 is used to describe a communication channel from base station 22 or satellite gateway 24 to a DC. Satellite gateway 24 is used to describe a communication channel from a DC to a base station 22 or a gateway 24. Voice and / or data are converted into data packets using a DC, the data packets being suitable for a particular distributed network 26 by means of which communications with other users take place. In one embodiment, the distributed network 26 is the Internet. In another embodiment, a dedicated upstream channel is established in each communication system (ie, a terrestrial communication system and a satellite communication system) to broadcast information from each member of the network to the other members of the network. Each member of the network receives communications from the other members of the network through the dedicated channel. In yet another embodiment, a dedicated downlink is established in each communication system to transmit information to the GC 18. Finally, a combination of the above schemes can be used. For example, one scheme may be to establish a dedicated upstream broadcast channel but require wireless DCs to transmit information to GC 18 on an individual downlink assigned to each DC.

When a first member of the network wishes to transmit information to other members of the network, the first member of the network requests the transmission privilege by pressing a push-talk key on his DC, which generates a formatted request for transmission over the network. distributed 26. In the case of DC 12, 14 and 16, the request is transmitted over the air to one or more base stations 22. A mobile switching center (CCM) 28 comprises a well-known interworking function (FIF) for processing data packets, including the request, between the CCM 18 and the distributed network 26. For the DC 16, the request is transmitted via from the satellite to the satellite gateway 24. For DC 17, the request is transmitted to the public switched telephone network (PSTN) 30, then to a

ES 2 379 863 T3 battery 32 of modems. The modem battery 32 receives the request and provides it to the distributed network 26. A terminal 34 of the SRR monitors the traffic of the SRR system through its connection to the Internet 26. Since the terminal 34 of the SRR is connected to the Internet 26 , geographic proximity to network participants is not necessary.

If no other member currently has the transmitting privilege when GC 18 receives the request for transmitting privilege, GC 18 transmits a message to the requesting member of the network, notifying him that the transmitting privilege has been granted. Sound, visual, or other information can then be transmitted from the first network member to the other members of the network by sending the information to GC 18, using one of the transmission paths just described. In one embodiment, the GC 18 then provides the information to the members of the network by duplicating the information and sending each duplicate to the members of the network. If a single broadcast channel is used, the information only needs to be duplicated once for each broadcast channel in use.

In an alternative embodiment, GC 18 joins CCM 28 so that data packets from supporting base stations are routed directly to GC 18 without being routed to distributed network 26. In this embodiment, GC 18 remains connected to the distributed network 26 so that other communication systems and devices can participate in group communication.

The GC 18 maintains one or more databases to manage information regarding individual members of the network, as well as each defined network. For example, for each member of the network, a database may comprise information such as the user's name, account number, telephone number or dial number associated with the member's DC, a mobile identification number assigned to the DC, the current status of the member on the network, such as whether the member is currently participating in the network, a priority code to determine how the broadcast privilege is assigned, a data phone number associated with the DC, an IP address associated with the DC and an indication of which networks the member is authorized to communicate with. The database can also store other related types of information regarding each member of the network.

As part of the SRR structure, the communications manager (GC) forms individual communications terminal connections forming a conversation group or network. The GC comprises various hardware and software functionalities that are configurable in different ways to accommodate different applications. Typically, the GC provides the ability to manage network authenticity, administrative and real-time (SRR) operations, push-button talk request (PTT) arbitration, membership and registration list maintenance and distribution, establishment and disconnection of Necessary CDMA system calls and network resources, as well as full control of network health.

The SRR network can be within a dedicated deployable cellular system, or be a large multi-site configuration. In the case of a large configuration, multiple GCs can be geographically deployed to form a single integrated system.

Each operates as a pluggable module in the existing cellular infrastructure. As such, new features introduced by SRR networks are available to mobile users without requiring modification of the existing cellular structure.

One function of the GC is to maintain a list of defined SRR networks. Each network definition includes a network identifier, a member list that includes telephone numbers or other identifying information, user priority information, and other generic management information. Networks are statistically defined as either unencrypted or secure, and transitions between unencrypted and secure are not allowed. Typically, a secure SRR network uses media encryption to provide authentication and guard against eavesdropping. Media encryption for secure networks is implemented end-to-end, which means that encryption and decryption takes place within the communications device. The GC generally operates without knowledge of algorithms, keys, or security guidelines.

The GC receives network definitions through an external management interface. Customers can request administrative actions through their service provider or network administrative functions through defined systems, such as a customer-operated security manager that conforms to the GC administration interface. The GC authenticates to high-quality commercial standards to any party attempting to establish or modify a network.

Before an embodiment of the invention is explained in detail, it should be understood that the invention is not limited in its application to the details of the construction and arrangement of the components presented in the following description or illustrated in the drawings. The invention is susceptible to other embodiments and is carried out in various ways. Furthermore, it is understood that the phraseology and terminology used herein is for the purpose of description and should not be construed as limiting.

FIG. 2 illustrates an SRR 100 network and how communication devices interact with a GC 104. Multiple GC 104's can be deployed as desired for large scale SRR 100 networks. In Fig. 2, the communications device 108, or a DC 108, is allowed to transmit media to the network. In this case, the DC 108 is

ES 2 379 863 T3 calls a speaker and transmits media over a channel. When the DC 108 is called a talker, the remaining network participants, communication devices 112 and 116 (or DC 112 and DC 116) are not allowed to transmit media to the network. Consequently, DC 112 and DC 116 are called listeners. If the DC 116 is called a talker, the DC 108 and DC 112 are called listeners, and so on.

As described above, each DC 108, 112, and 116 is connected to GC 104 using at least one channel. In one embodiment, the channel is divided into separate channels comprising a Session Initiation Protocol (SIP) channel 120, an SRR multimedia signaling channel 124, and a multimedia traffic channel 128. The session initiation protocol (SIP) channel 120 and the multimedia signaling channel 124 of the SRR can be used at any time as bandwidth allows, regardless of the name of speaker or listener, by anyone of DC 108, 112 and 116. SIP is an application layer protocol, defined by an Internet Engineering Task Force (IETF), that describes control mechanisms for establishing, modifying, and terminating multimedia sessions that operate on Internet Protocol (IP). SIP provides a general solution to call signaling problems for Internet telephony applications, supporting means to register and locate users, mechanisms that define user capabilities and describe multimedia parameters, mechanisms to determine user availability, call establishment. and call management.

SIP channel 120 is used to initiate and terminate a DC's participation within network 100. Optionally, a session description protocol (SDP) signal may also be used within SIP channel 120. When DC participation within an SRR network is configured using SIP channel 120, real-time call control and signaling takes place between the DC and GC 104 using SRR multimedia signaling channel 124. Specifically, among other tasks, the SRR multimedia signaling channel 124 is used to manage push-button conversation requests and releases, for arbitration between competing requests, or channel control, to announce the start and end of information transmission. , manage network latency, monitor end-to-end connectivity, request and exchange network status, notification and error messages. The SRR multimedia signaling channel 124 protocol minimizes the length of the most common messages, and to simplify the task of interpreting responses and responding to requests while maintaining flexibility for future enhancements. The SRR multimedia signaling channel 124 protocol also allows requests to be resent without adversely affecting the state of the protocol.

Signaling traffic on multimedia channel 124 can be further differentiated into two categories: call setup and control signaling, which mainly consists of SIP invitation requests and acknowledgments, and media signaling, which mainly comprises real-time channel control requests. and related asynchronous messages. Multimedia traffic on multimedia traffic channel 128 comprises point-to-multipoint real-time voice and / or data broadcasts. Both categories of messaging have unique functional attributes. In addition, each DC can issue Domain Name Service (DNS) client requests to facilitate mapping between fully qualified DNS server names and Internet network addresses.

SRR call setup and call control signaling is carried out according to SIP semantics. Although SIP can be transported using either the well-known User Datagram Protocol (UDP) or Transmission Control Protocol (TCP), in a preferred embodiment each DC performs SIP-based signaling functions using UDP, such as is illustrated in Fig. 4. Furthermore, each GC expects to receive all SIP signaling requests over UDP. Real-time signaling occurs via dynamic UDP / IP interfaces on the GC and each DC. Other signaling can take place over a fixed TCP / IP interface between the GC and the DC using SIP.

Fig. 3 illustrates the modules and physical makeup of the GC 104. The GC 104 comprises a central GC module or complex 204, at least one network module or media control unit 208 and 212 (UCM), a DNS server 216, a redirect server 220, and an administration workstation 224. GC Central Complex 204 provides manageability to a web browser with Java ™ capabilities. One or more DNS servers 216 may also be included in the central GC complex 204. The central GC complex 204 further comprises a GC node 228 and a database server 232. The GC 104 is separable into at least two parts, the central GC complex 204 and each node 208 of the MCU. After initial connection to central GC complex 204, a network is operated by MCU node 208. The MCU node 208 sends and receives information, as needed, from the central GC complex 204. The separability of the central GC complex 204 allows versatility because, once a particular network is established, the network is operated by a dedicated node 208 of the MCU. This allows the central GC complex 204 to provide initial connections to other potential networks, regardless of the type of communication structure in which you want the network to operate. Additionally, central GC complex 204 may be geographically offset from MCU node 208. For example, a single central GC complex 204 may be located in the central part of the United States and a plurality of UCM nodes 208 may be regionally located to operate networks from their given region. As such, the central GC complex 204 can route a user to a particular MCU node 208 based on the

ES 2 379 863 T3 location of the user. In addition, information may be provided to a user or a group of users based on location, such as a broadcast based on location, addresses or identification of landmarks.

GC node 228 provides centralized functionality associated with SRR networks. The GC node 228 comprises a session initiation protocol user agent (SAU SIP) server 236 and GC manager 240, a central billing register 244, and an administration server 248. The SAU SIP server 236 supports network list user requests and handles network SIP invitation messages. When a SIP invite message 229 is received from a communications device, the network assigns the communications device to an appropriate UCM node 208 and directs the communications device to UCM node 208.

GC manager 240 monitors the status of all MCU nodes within a network, and assigns network execution to given MCU nodes, such as MCU node 208. The manager GC 240 assigns administrative functions pertinent to network administration, including creating and removing networks, defining new users and deleting existing ones, adding and removing users as members of the network, and regulating various operational parameters per user, network. or GC.

Central billing register 244 maintains timing and identification information for billing purposes. The central billing registry receives billing registration information from a local registration server 260 at the MCU node 208. Detailed log information is maintained for each user, such as which communication devices are active on the network, for how long, from where, and when, and for how long each DC is a talker or listener. The administration server 248 supports an interface to allow the administration workstation 224 to retrieve status information, initiate database administration and system management functions through the network status interface 280.

The GC implements both the SIP user agent server 236 and a SIP UCM server 252. To support SRR, each DC implements a SIP user agent client. The GC receives incoming SIP connections on a published node or port. When a connection occurs, the SIP server 236 receives and processes requests according to the SIP call signaling conventions. The SIP server 236 is capable of processing multiple call signaling connections in parallel.

To conserve network resources, the DC can release its UDP connection to the SIP server 236 after it has successfully (or unsuccessfully) connected to the SRR network 100. The UDP connection can then be re-established to send additional SIP call signaling requests (eg, leave the network or switch to another network).

FIG. 4 illustrates an example SRR SIP signaling protocol stack 300. The stack is a collection of protocol layers that implements network communication. The protocol associated with each layer communicates with the layers immediately above and below it, and takes over the support of the underlying layers. Since UDP is a less reliable connectionless transport, application-level reliability is preferred to ensure robust communication, which is achieved through implementation by SIP-compliant endpoints. Generally, the signaling 302 of SIP calls in UDP flows 304 is encapsulated in the IP protocol 306. No special formatting is required. SIP call signaling IP packets 306 are exchanged between, for example, a CDMA-based cellular DC or a dial-up PSTN-based DC, which are encapsulated in 308 point-to-point (PPP) frames. Consequently, no special formatting is required. Furthermore, SIP call signaling PPP 308 frames exchanged between a CDMA-based cellular DC and a base station are encapsulated in a radio link protocol 310 (RLP). For dial-up PSTN-based users, a standard such as V.32bis or V.90 can replace RLP 310. In either case, special handling is generally not required and a free physical link is not assumed. mistakes.

Fig. 5 illustrates an SRR multimedia signaling protocol stack 312 that carries voice and data traffic using UDP 304 datagrams over IP 306. SRR multimedia signaling 314 is layered into UDP / IP traffic 306 and is managed by similarly with respect to the description of Fig. 4.

FIG. 6 illustrates a real-time protocol voice multimedia protocol stack 320. In this embodiment, vocoder payload data 322 is layered into the real-time protocol (RTP) 324. RTP 324 is then layered into UDP 304 and IP 306. In an optional embodiment, compression 330 of the Compressed Real Time Protocol (CRTP) header is used to further encapsulate multimedia traffic using TRP 322 at the streaming layer. app. Header compression techniques can be applied, as appropriate, to all incoming UDP / IP traffic and outgoing UDP / IP traffic illustrated in Figures 4-9. Multimedia signaling requests and responses are encapsulated in UDP datagrams. When available, compression of the CRTP header can be applied to reduce the impact of sending uncompressed UDP / IP headers. In Fig. 6, the CRTP compresses the RTP layer 34, the UDP layer 304, the IP layer 306, and the PPP layer 308. In Figures 4, 5, and 7-9, the CRTP 320 compresses the layers between UdP 304 to PPP 308, inclusive. .

In operation, each DC dynamically selects a UDP port through which it intends to listen for multimedia signaling requests from the SRR and communicates the port number to the SIP server 236 as part of the SIP invitation it delivers when it tries to connect to a network. The network GC media signaling destination address (including the UDP port number) is described in the network session description delivered as 8

ES 2 379 863 T3 for a positive response to the INVITE SIP request to the DC. Unlike SIP signaling addresses, multimedia signaling destination addresses are network specific and can change between instances of a DC connecting to a network. Generally, multiple networks served by the same GC operate independently and do not share multimedia signaling or multimedia traffic ports. However, it is contemplated that multiple networks can share multimedia signaling and multimedia traffic ports.

Referring to Fig. 6, voice traffic is encapsulated by bundling one or more frames from the voice coder into a TRP / UDP 324 or UDP 304 payload. The use of RTP 324 with CRTP 330 enabled is used to minimize multimedia latency between endpoints and provide interoperability with IP telephony applications and services. In any case, the DC dynamically selects the UDP port through which it expects to receive multimedia traffic and communicates the port number to the SIP server 236 as part of the SIP invitation it delivers when it tries to connect to a network.

The voice encoder and the network transport encapsulation protocol, as well as its destination address of the multimedia traffic (including the UDP port number), are described in the session description response to a positive SIP invitation response from the SIP server 236. Like the multimedia signaling addresses of a network, the destination addresses of multimedia traffic are specific to the network and can change between instances of a DC connecting to a network.

Typically, as shown in Fig. 6, voice traffic is encapsulated at the application layer using TRP 324, which segments each UDP 304 datagram into a TRP 324 header and a speech scrambler 322 payload. FIG. 7 illustrates a UDP voice multimedia protocol stack 332. Optionally, voice traffic can be encapsulated using only UDP 304 datagrams, without any RTP encapsulation, typically when a network member does not have available or does not support compression 330 of the CRTP header. FIG. 8 illustrates a stack 334 of multimedia traffic protocols. The multimedia traffic protocol stack 334 is used for network participants without any application layer RTP encapsulation. Data 336 is encapsulated in UDP 304 datagrams.

The structure of the UDP payload 304 follows the definition given for a corresponding RTP payload 324, without the RTP header fields. The decision to encapsulate media directly on the UPD 304 is configured by the network administrator 248 and published by the network session advertisement. In addition to voice media, SRR networks can also support arbitrary data broadcasts. If a network supports a data broadcast channel, the SIP server 236 advertises the media type in the network's SIP session description when a DC formally connects to the network.

FIG. 9 illustrates a DNS client protocol stack 338. Each DC includes the ability to convert Internet domain names to Internet addresses using Domain Name Service (DNS) protocol 340. The DC operates as a DNS client. The DC encapsulates requests to DNS 340 using UDP 326, as shown in Fig. 9. In order for the DC to resolve DNS server names, the DC is provided with the network IP address of the DNS server 216, as shown in Fig. 3. The DNS address is also configurable by the DC's service provider, and, optionally, by the user.

In addition to voice media, networks can also support arbitrary data broadcasts, such as secure network key regeneration, email, data files, etc. If a network supports a data broadcast channel, the GC announces the media type and description of the network's SIP session when the DC formally connects to the network. Like traditional multimedia broadcasts, generic data broadcasts operate on the RLP in one embodiment (or a corresponding physical layer), but are generally considered to be less reliable transports.

The DC includes the ability to convert Internet domain names to Internet addresses using the Domain Name Service Protocol (DNS), as defined in RFC 1034. Alternatively, the DC operates as a DNS client or resolver, such as It is described in RFC 1035.

In order for the DC to resolve DNS server names, the DC is programmed in advance with the IP network address of a DNS server. The DNS address is also configurable by the DC service provider and, optionally, by the user.

The GC 104 may optionally be configured to act as a DNS server 216. Although it can respond to DNS requests from external entities using TCP as the transport protocol, in order to serve DC-originated service requests, the SIP server 236 also encapsulates DNS messages using UDP 304 according to Fig. 8.

The SRR also takes advantage of the development of a multicast cellular channel. Such a channel generically allows a transmitting station to directly address N listening stations on an upstream channel without the need for N separate rebroadcasts of the transmitted data. The presence of a cellular rebroadcast channel implies changes to the SRR multimedia stack below the IP network layer. To take advantage of the efficiencies provided by a cellular multicast channel, the multimedia signaling of a network, and

ES 2 379 863 T3 traffic destination are conventional IP multicast channels, and the signaling and multimedia traffic broadcasts originating from the GC are multicast broadcasts. Every GC-originated multimedia traffic and signaling broadcast and SIP signaling remain point-to-point communications .

The radio link protocol (RLP) 310 shown in Figures 4-9 can be modified within each DC to minimize the latency experienced when a link layer loss (RLP frame) occurs. Such modifications are optional and do not necessarily affect the transport operation of the application layer protocols, since neither TCP nor UDP 304 assumes reliable network (IP) or link layer service.

Various strategies for modifying the RLP 310 are possible. For example, the RLP 310 can be modified to send multiple messages, such as NAK responses, after the RLP timeout is exceeded, thus requesting that the remote end transmit multiple copies of the frame. RLP 310 lost and improving the probability of a successful RLP 310 recovery. RLP 310 can also be modified to never send NAK responses (after the RLP timeout is exceeded) and allow RLP 310 interrupted frames to force higher levels of the protocol stack to generate errors. Any TCP-based application layer protocols are routinely recovered using TCP error recovery mechanisms. Traffic that uses UDP 304 for its transport already contends with the potential for loss.

Referring again to Fig. 2, once the DC establishes participation within the SRR's network 100 using the SIP channel 120, the DC is ready to send and receive media from the network 100 on a specific multimedia port of the DC through channel 128 of multimedia traffic. If the DC obtains channel control through multimedia signaling, as in the case of DC 108 in Fig. 2, the DC transmits media to the destination network and transport addresses, as indicated in the description of the session of the network 100. The DC decodes media received by its multimedia ports according to the voice decoder and the defined multimedia format in the session description of the network 100 received in an invite response when the DC connects to the network 100.

Each DC participating in a network determines the destination network and the transport address for each multimedia channel from the description of the signal received from the SIP server 236 of the GC 104 and acknowledged during the SIP call establishment and uses them to address the corresponding media within the network 100. Each DC provides a packet data connection to the GC. Changes can be made to the DC implementation of this interface to optimize SRR performance. Changes to the infrastructure side of this interface are generally not necessary. The DC can optionally support most SRR activities using a fast network connection (QNC), as described further herein.

Upon delivery to a service provider, the GC manager 240 undergoes a basic administrative setup before supporting SRR activities. The initial configuration involves a basic configuration of the system, such as assigning passwords to accounts at the operating system level for system administration at the root level and configuring the network interfaces of the GC 240 manager for proper operation on the network. local wireless infrastructure.

Once the GC 104 is configured, general network administration can take place. Network administration functions take place through an HTML or other network interface built on top of TCP / IP. Administration workstation 224 interacts with GC central complex 204 using a world wide web (WWW) browser. Administration can take place locally or remotely (anywhere on the Internet or via dial-up). However, the underlying transport path for administrative access is typically TCP / IP. Multiple simultaneous management connections (at least three) are also allowed.

After connecting to the central GC complex 204 for the purpose of network administration, the manager workstation 224 is successfully authenticated to ensure that only authorized administrative actions are accepted. Different levels of access are accommodated; for example, authorized members of the network can connect directly to the GC administrative interface (248) to modify lists of specific network members. More generic administrative privileges are generally reserved for specific administrative accounts. For the sake of clarity, administrative actions are generally separated into those that specifically address user definitions and those that define networks. A user definition comprises information such as the user's name, the DC's unique cellular system identifier, the DC's telephone number, and an email address of the user. A unique user identifier is defined that can be passed to the DC and is used to uniquely identify the user in signaling messages. A network definition comprises information such as the network address, the network hang time, the private dispatch time disconnect, and the member list. A network member list comprises information such as a list of member records, which individually contain a user identifier and a priority level. Typically, a member with the lowest priority level only has listening privileges.

The GC administrator 248 can monitor the current status of networks for which he has administrative privileges. In particular, the GC administrator 248 can determine the current list of network participants, as well as monitor the status of the network (active, idle, dormant, waking, etc.). As long as the network is active, the GC administrator 248 can also monitor the identity of the current speaker. They can also 10

ES 2 379 863 T3 additional statistics and statuses, such as current session duration, total talk time, average number of registrants, etc., are available to administrators through the administrative interface.

The management server interface 248 comprises at least two network nodes or ports. One is a TCP / IP-based Hypertext Transfer Protocol (HTTP) interface that supports administrative access via a conventional web browser with Java ™ capabilities. The second is a TCP / IP-based SRR-specific command line interpreter (CLI).

Administration server 248 makes all administrative functions available to a generic web browser through an HTTP web server interface with one or more pages formatted using an Internet-readable medium, such as markup language syntax. hypertext (HTML). At least one of the administrative pages can include a reference to an embedded Java ™ applet. Some administrative functions can be optionally performed by means of HTTP GET and POST instructions issued by the web browser using conventional HTACCESS authorization mechanisms. Generally, the administrative functions supported are a subset of those supported by the CLI interface.

The HTTP interface can be used to distribute a Java ™ applet to the web browser. The applet can then use the CLI interface of the administrative server 248 to provide additional administrative functionality to the user through a web browser interface. Before it is granted access to the CLI interface, a potential administration workstation 224 is authenticated and connects to the CLI interface of the administrative server 248. In a preferred embodiment, the CLI interface is reachable on a well-known fixed TCP port address and is capable of simultaneously managing multiple CLI sessions.

Database server 232 is responsible for the storage of network information and parameters, network user information, status information associated with MCUs 208 and 212, and GC node 228. The database server 232 also serves this information to the rest of the GC 104, such as the SIP server 236 and other modules that need such information. The database server 232 maintains databases that capture information that supports the network activities of the SRR, including a network database portion SRR and a user database portion of the SRR. The information that supports activities and administration privileges can be stored in either of the two databases, or in a third database with differentiated functionality. The database server may be further subdivided into a user portion and a network portion.

The CLI interface supports administrative functions such as user / network CLI creation, user / network deletion, user / network modification, user enumeration / presentation, network enumeration / presentation, status, and help. The Create User function allows the administration server 248 to create new users in the user portion of the database, including the specification of all user record fields. The Delete User function allows the administration server 248 to delete existing user records in the user pool of the database 232. The Modify User function allows the administration server 248 to modify existing user records in the user portion of the database 232, including the modification of all the fields of the record of a specific user.

The Create Network function allows the management server 248 to create new networks in the user portion of the database 232, including the specification of all network definition parameters. The Delete Network function allows the management server 248 to delete existing networks in the user portion of the database 232. The Modify Network function allows the management server 248 to modify existing networks in the user portion of the database 232, including modifying all network definition parameters for a specific network. The Enumerate Users feature allows the management server 248 to list all users, by username, dial-in number, and user ID, in the user portion of the database 232.

The List Networks function allows the management server 248 to list all networks, by network address and network identifier, in the network portion of the database 232. The Show User feature allows the management server 248 to display all fields for a specific user identified by the user's userid. The Show Network function allows the management server 248 to display all the fields for a specific network identified by the network identifier or the network address of the network. The Status feature allows the management server 248 to query for a static status report for a specific network. The Status function can also allow the management server 248 to query for real-time (up-to-date) reports. In particular, the Status function identifies the current list of network participants, the current speaker, the presence or absence of multimedia traffic and identifies any signaling messages, and all of them, sent or received by the GC. The Help function allows the management server 248 to query for a brief human-readable summary of each supported CLI statement, including a description of usage and syntax.

The SRR user portion of the database 232 keeps track of individual SRR users. The user records contained in database 232 may or may not necessarily be members of networks defined in the network portion of the GC of database 232.

ES 2 379 863 T3

Each record in the user portion of the database 232 comprises fields such as username, user identifier, voice scrambler list, dial number, user type, CRTP support, DC user address, and public key. really good privacy policy (PGP). The vocoder list is a list of the vocoders supported by the subscriber's DC. This field is empty, or null, for generic Internet users. User Type is a type field that describes whether the user is a CDMA cellular or a generic Internet user. Users who connect using PSTN dial-up are considered generic Internet users. CRTP support is a flag that indicates whether the DC supports and tries to negotiate CRTP header compression over PPP when connecting. This flag is valid for cellular users as well as those based on the PSTN. The DC user address is the globally unique user address of the DC. A DC known by multiple user addresses will have multiple corresponding entries in the user portion of the database 232. The PGP public key is the key associated with the DC user address.

The SRR network database defines the set of networks known to the GC. The network portion of the database 232 also lists the defined members of each network, that is, those users who can request to connect and become participants in a network. Each record in the network portion of the database 232 comprises several fields. The fields include a network identifier, which is a unique integer that identifies the network within the context of the GC. The fields also include a network address, which is the network's SIP-compliant network address. The owner (s) of the network, a nonempty list of users, are identified by user identifiers who have administrative privileges (defined separately) for the network. Also, the network security status is a field for a flag that indicates whether the network is unencrypted or secure.

The fields also include an arbitration scheme, which is a unique value that identifies the arbitration scheme used to resolve PTT arbitration conflicts between network participants. The speech decoder describes a field having a unique value that identifies the standard speech decoder displayed in the session description advertised on the network. Defined members of the network have this speech scrambler listed in their list of supported speech decoders. The PTT safe timeout is the maximum number of seconds that a network participant can transmit to the network before the GC revokes control of the channel with a PTX deny message. The hang time timeout value is the maximum number of seconds the network can remain idle before the GC puts it into dormancy. The PTX latency response timeout value is the maximum number of seconds the GC waits after determining that a latent network channel can be granted before transmitting a PTX grant response to the requesting DC. The wake-up time-out value is the maximum number of seconds the GC waits for participants to respond to the AYT “wake-up” message before granting a pending PTT request. The late wake-up time-out value is the maximum number of seconds the GC waits for a DC to respond to the GC's AYT “wake-up” message before the GC removes the unresponsive DC from the list of the GC. network of active participants. The AYT timeout value is the maximum number of seconds the GC waits for the DC to respond to the GC's AYT message before the GC removes the DC from the network list of active participants. The multimedia channel list is a list of multimedia channels that includes payload specifications for the network (networks list at least one multimedia channel that carries voice).

The network member list defines the set of users who can request to connect to the network as participants and the specific privileges associated with the network. Each entry in the list contains fields such as the user identifier, which is a unique identifier of a user listed in the GC user database 232. The fields also include the user priority level on the network, which is the user priority level to be used by the network's PTT arbitration algorithm to resolve PTT conflicts. A priority level of zero indicates that the user only has listening privileges and can never be granted control of the network. The fields can also include a user authorization list, which details the authorization privileges, if any, that the user has for the network. Privileges may include the ability to add, edit, or modify network member list entries and the ability to modify other network parameters.

Each DC maintains a database, also called a group list, that identifies known networks that the DC can request to connect to. Each entry in the DC database includes fields such as the network address, the network security informational flag, the network traffic encryption key, and the latency watchdog timer. The network address is the formal SIP network address that the DC uses to request connection to the network as an active participant. The network security informational flag is the security or lack of encryption informational flag distributed by the GC SIP server 236 in its list of available networks or set by the user to indicate a network defined to carry secure multimedia traffic of type IV. The network traffic encryption key is the traffic encryption key used to encrypt and decrypt all media traffic for secure Type IV networks. The latency watchdog timer is the length of interval, in seconds, that the DC will wait when, in the latency / idle state, it enters the Connected state, confirming that the packet data call is still valid and that the base station has not unilaterally interrupted the connection.

ES 2 379 863 T3

The MCU node 208 comprises a MCU 252, a MCU node manager 256, and the local registration server 260. UCM node 208 and 212 may also optionally comprise an additional uCm 264. UCM node 212 is substantially the same as UCM node 208. In this document, for descriptive purposes, only node 208 of the UCM is exposed. The UCM 252 is responsible for the control of a single active network. The UCM supports SIP, multimedia signaling, and multimedia interfaces for the network, and provides the functionality associated with normal network operation. Each MCU node 208 may have a group of MCUs 252 that may be instructed to manage networks as appropriate. Each UCM 252 provides a UCM management interface 268 to support functions such as start, stop, and status information.

The node manager 256 of the UCM monitors the operation of node 208 of the UCM and manages the operation of each UCM 252 in its node 256 of the UCM. The MCU node manager 256 also provides an external interface 272 to the central GC complex 204 to allow startup and / or shutdown, assigning a network to the node, and sharing status information.

The local logging server 260 locally logs all log events for the MCU node 208. The local registration server 260 also responds to requests from the local registration server 244 through its registration event interface 276. Requests include loading certain classes of events or priorities. To avoid event loss, messages are stored in local registration server 260 until central billing registration server 244 receives acknowledgment.

The DNS server 216 provides name services to the communication devices of the SRR. The DNS server 216 can service SRV registration requests. The DNS server 216 can be located anywhere on the network. In one embodiment, the DNS server 216 is part of the central complex 204 of the GC.

Each DC maintains a list of networks, or a list of groups, that internally represents the set of known networks in which the DC can participate. The list is non-volatile, but can be updated as needed, either through interactions with a GC 104 or interactively by the user. The user is also able to determine who and how many users are active or inactive on the network. The SRR group list maintained internally by a DC is analogous to the list of names and dial numbers maintained in the phone book and used to provide voice services. The SRR group list can be integrated into the conventional phone book of the phone. In either case, selecting a network from the group list instructs the phone to try to connect to the selected network.

To participate in a specific SRR network, each DC initially requests that the GC be added to the list of active network participants for a specific network. Thus, each DC is initially aware or able to learn the network address of whatever network it wishes to participate in. Furthermore, each DC initially knows or is capable of being configured with the address of a top-level SIP server 236 to which SIP requests can be sent.

Network addresses can be provided to, or learned by, a DC in a number of different ways. For example, in one embodiment, the DC may be initially provided with the address of a known or default top-level SIP server that provides a current list of networks in which the DC can participate. The DC can also be provided with a group list that defines at least one network address of which the DC is a member. The DC can then send a request to the top-level SIP server 236 to update its group list. In the event that no explicit allocation of the SRR has taken place for the DC, a top-level SIP server 236 and a network address may be provided to the user to interactively enter into the DC prior to using the SRR. The user can also interactively enter additional network addresses to a group list that has been provided with entries. Such a configuration step is analogous to entering personal names and dial numbers in the conventional telephone book.

Note that although users can interactively enter a network address into the DC group list, it is preferable that the corresponding network and top-level SIP server 236 are in existence and the user is required to be listed as a member of the network. so that DC can successfully participate in the network.

The DC can also be provided with an IP network address of the primary domain name service (DNS) server 216 to which the DC can send DNS queries. Typically, the address of the DNS server 216 operated by a CDMA cellular operator is provisioned. The DC can also be provided with the IP network address of an alternate DNS server.

To support SIP authentication, the DC can be provided with a unique PGP user identity and a secret key that it can use to sign SIP transactions when requested by the GC 104. The unique PGP user identity can also be used as the address of DC user for generic SIP transactions.

FIG. 10 illustrates the high-level functionality of the DC group services module 500. Typically, the group services module initializes to a default idle state 504 when the DC is turned on. From idle state 504, the DC can transition to other states that allow it to actively participate in SRR networks.

ES 2 379 863 T3

The user may wish to temporarily disable SRR services through a menu option within the user interface of the DC. If the user has disabled SRR services, the group services module defaults to a 508 disabled state when the DC is powered on. When disabled, the DC does not automatically attempt to connect to any SRR networks. Also, the DC does not carry out any SRR-specific SIP transactions (the DC may hold registrations or carry out other SIP transactions for other IP-based telephony applications that reside within the DC).

Optionally, the group services can be completely hidden from the user by provisioning the group services within the DC in an unequipped state 512. The unequipped state disables the group services, while an equipped state enables the group services. Once unequipped, the DC requires an administrative envelope to equip group services. When group services are unequipped, the SRR group services functionality and related user interface features are not available to the user.

DC can support air crew to equip SRR group services. In the case that the DC group list contains more than one network address, no more than one network address can be identified as 514 network by default. If a network address is selected, the DC automatically attempts to go from sleep state 504 by attempting to connect to this selected network shortly after the DC is turned on.

When the DC is connected, the DC iterates from a silent state 516, a listening state 520, a speaking state 524, and a latent state 528 based on the user's place in the push-talk system, such as described with respect to Fig. 16.

The SRR uses call signaling syntax and semantics, as defined by SIP, to advertise available network addresses and provide mechanisms by which an individual DC can formally connect to or leave networks. The GC 104, along with other functional entities, includes a top-level SIP server 236, one or more multipoint control units (UCM) 252 and associated SIP user agent servers, and user and network portions of the database. Administration 232. The top-level SIP server 236 acts as a known meeting point to participate in the system. Each UCM 252 performs multimedia signaling and multimedia traffic switching for one or more networks. The database 232 stores and provides definitions of known user, management, and network addresses and can serve multiple GC installations or can be remotely accessed.

Each DC is provided with a list of network addresses and one or more addresses of a top-level SIP server 236. If the group list is empty, the user can interactively specify the address of an existing network. If no top-level SIP 236 server is defined, the user can interactively specify the address of a top-level SIP 236 server. Once the address of the top-level SIP server 236 is known, the DC can request an updated list of networks available to it by making a call using the SIP INVITE procedure to a predefined SIP destination.

The top-level SIP server 236 can redirect the request to an internal destination or respond directly to it. The INVITE response to this call includes the current list of networks available to the DC. The DC uses this list to update its internal group list.

After a network has been selected, the DC attempts to connect to the network using the SIP INVITE procedure specifying the network address as the invitation destination and sending the request to the top-level SIP server 236. The top-level server 236 attempts to map the network address to a known destination and, if successful, redirects the DC to the corresponding SIP user agent server on the UCM 252. If no correspondence is available, the invitation generally fails.

Normally, the destination SIP user agent server of the UCM 252 confirms that the DC is a member of the selected network and responds to the invitation, embedding in the content of its response a description of the traffic and multimedia signaling parameters to use. to participate in the network. The UCM 252 SIP user agent server may also respond with an error if it is unable to confirm that the DC is a legitimate member of the network or if some other error condition arises, such as an error that prevents normal operation of the network. network. If the invitation is accepted, the DC acknowledges the response by means of a message, such as a SIP ACK procedure. Note that the DC may also receive other transient response codes that indicate the progress of the call while the invitation is being processed.

The DC is responsible for updating its group list with the set of networks in which it can participate. The user can instruct the DC to query the GC 104 database 232, even when no network address is selected, in order to receive updates to its group list. If the DC determines that it has been added to, or removed from, a network, it briefly presents the user with an appropriate message (eg: "Added to group X") and / or possibly requests user interaction. If the DC determines that it is not a member of any network, it will inform the user in a similar manner. The DC can automatically add new addresses to its group list, but it can warn the user before deleting network addresses from the group list of which it is no longer a member.

ES 2 379 863 T3

Generally, no more than one network in a DC's group list can be identified as selected at any one time. Initially a default network can be selected or the user can select a network from the group list.

The GC SIP user server agent of the UCM 252's response to an INVITE request to connect to a network includes, as embedded content, the network media signaling and real-time media destination addresses, as well as other parameters network (such as multimedia payload format descriptors). Once confirmed, the DC briefly presents the user with feedback, indicates whether the user has listen-only privileges, and enables group services features. If the GC 104 determines that the DC is not a member of the selected network, or if an error or other exception condition occurs, the SIP server 252 responds with a corresponding error response. When such registration is rejected, the DC briefly displays a corresponding error message and the group services functions remain inactive. If no network is selected, group services within the DC remain inactive.

As for the activation of group services, the DC initializes and opens its RTP multimedia traffic channel 128 and the separate SRR multimedia signaling channel 124 to the destination address of the GC provided in a positive response to the invitation. Once these channels have been initialized, the group services are activated in the DC 108 and it enters the silent state 516 of the group services with the ability to receive voice traffic from the network and request permission to send traffic. voice to the network.

With group services active, the DC 108 monitors its multimedia traffic 128 and signaling 124 channels to the GC. Voice data received on multimedia traffic channel 128 is decoded and presented using a DC 108 far-field loudspeaker or headphone-type accessory according to the current user configuration. The DC 108 displays the identity of the current speaker, as identified through the real-time multimedia signaling 124. If the identity of the current talker is not available, the DC 108 displays the name of the current selected network as listed in the group list. The DC 108 can also tabulate multimedia traffic statistics (eg, total time spent talking, listening and monitoring, estimated packet loss from multimedia traffic receipt) and make them available to the user for diagnostics using a menu option. While receiving network traffic, DC 108 transitions to group services listening state 520, returning to silent state 516 when voice traffic stops.

At any time, the user can request permission to speak to the network by pressing the PTT button and causing the DC 108 to send the GC (specifically, the UCM 252) a channel control request signal. The PTT button can be any type of activation instruction, including, without limitation, a key press or sequence of keys, a voice activation, a switch, a rocker, or dialing discs. UCM 252 responds by either granting or denying the request. if the DC only has listening privileges, such as DC 112 (that is, the DC has a priority level of zero within the selected network), the request is denied. If denied, the DC 112 alerts the user with an error tone, displays an appropriate error or explanatory message, and returns to the silent state 516. The DC insists that the PTT be released and pressed again before attempting another request for channel control. If granted, the DC 112 enters the group services speech state 524, signals it to the user with, for example, a short audible chirp, and begins transmitting voice traffic to the GC 104 as long as the PTT is depressed. The GC 104 can signal asynchronously to the DC 112 (while the PTT is depressed) that it has lost control of the channel. Upon receipt of such a signal, the DC 112 aborts the transmission of voice traffic and alerts the user with an error tone until the PTT is released, at which point it returns to the silent state 516. If not, once the PTT is released, the DC 112 signals the GC 104 that it has released the channel and returns to the silent state 516.

A user can switch to a different network by selecting another network from the group list as long as the group services within the DC are in the silent state 516, the listening state 520 or the dormant state 528. When a new network is selected , DC 108 signals GC 104 to remove it from the current network via SIP call setup mechanisms and then follows similar procedures to connect to the new network. If the new network connection procedure fails, the DC 108 is no longer a member of any network and the group services within the DC 108 revert to the idle state 504.

If the GC 104 determines that the DC 108 requesting the channel of a particular network is the only registered member of the network in question, the GC 104 denies control of the channel and sends a signal with an error message, such as an error. Username, which the DC 108 displays to the user. Although a network may exist with only one registered member, a network cannot carry voice traffic unless there are at least two registered members.

The SRR application is based on two different application-level protocols: Session Initiation Protocol (SIP) call signaling, as described with respect to Fig. 11, and SRR multimedia signaling, such as is described with respect to Figures 12-14. SIP is used exclusively for call signaling and call setup. Multimedia signaling carries PTT requests (Fig. 12), manages network latency (Fig. 13) and resolves PTT arbitration disputes (Fig. 14).

SIP call signaling 350 is illustrated in FIG. 11. The session initiation protocol provides SRR application layer control (signaling) to discover, connect, and disconnect from SRR networks using the 15

ES 2 379 863 T3 interface 236 of the SIP server of the GC 104. To connect to a network, a DC 352 invites the network 100, by name, to participate in a call, through the top-level SIP server 236. To disconnect from network 100, the DC 352 sends a corresponding "goodbye" to the network.

The DC 352 determines the IP address of the top-level SIP server 236 using DNS 216 to resolve the endowed addresses of the primary or secondary SIP servers into Internet network addresses, if necessary. As an optional alternative approach, the SIP conventions allow the DC 352 to query DNS 216 for service records associated with the host SRR domain portion of the network address and to contact the SIP server 236 at the SIP server (s). returned addresses.

By default, the DC 352 tries to contact the SIP server 236 using a default SIP port, unless alternative port information is determined through DNS 216. Before it tries to connect to a network, the DC 352 can make a call using the SIP INVITE procedure to request an updated list of available networks.

For example, an IP address is assigned to the DC 352, which has established an air connection and wants to determine its current list of available networks. This opens a UDP / IP connection to the SIP server port and issues a request. the request for an up-to-date list of networks is directed to a special destination. Where appropriate, the DC 352 also includes additional application-specific headers that identify the CDMA network and the system from which the CDMA cell-based DC 352 obtains service.

The DC 352 may also include a header indicating that the DC 352 expects the SIP server 326 to understand and support SRR services. The option value distributed with the header can also be used by the DC 352 to inform the server 236 of a specific version or type of SRR services that the DC 352 expects the server 236 to support.

The top-level SIP server 236 of the GC can redirect an invitation request 356, using SIP redirection mechanisms, to a specifically defined destination to receive and respond to requests for network information. Upon receiving such redirection, the DC 352 acknowledges (ACK) the response 357 and forwards the request to the redirected destination.

The DC 352 may need to determine the appropriate SIP point of contact for the redirect address through DNS mechanisms. To simplify this procedure for the DC 352, the server 236 can specify the redirect destination explicitly using its Internet network address. Once the server 236 successfully receives and accepts an INVITE message 354 requesting a list of networks, the server 236 gives a response 356 to the INVITE request.

The response 356 to the INVITE request includes in its content a list of registers that define the set of networks to which the DC 352 can then connect. The server 236 consults its network database 232 for the networks that list the DC 352. Requestor as a defined member to form response 356 to INVITE request 354. Networks are identified within the content using an application-defined record format that includes the network form address of the network. Networks can be listed in any order.

Server 236 may be unable to successfully respond to DC 352 for various reasons. In such circumstances, the server 236 delivers an appropriate SIP status code instead of the INVITE 356 response. The DC 352 should be prepared to accept and interpret such status codes, taking appropriate action (such as displaying an error message in the DC 352 UI screen) in the event of any fatal error. Server 236 may also precede a positive INVITE 356 response with status informational responses indicating the progress of registrations. The DC 352 can accept and interpret informational status codes that precede successful registrations.

The DC 352 requests to connect to a network using a SIP INVITE 358 request to the GC 240 manager through the server 252. If the DC 352 does not have an open UDP / IP connection to the SIP server 252, it will open a new UDP / IP connection with the port of the SIP server.

The DC 352 is ready to be redirected by the top-level SIP server 236 and, if necessary, reissue the request to the redirected destination. The GC top-level SIP server 236 redirects any incoming INVITE requests, as appropriate, to the UCM server 252 currently associated with the network in question. The DC 352 can be redirected more than once.

The INVITE 358 request may include a description (as message content) of the multimedia sources originating from the DC 352, assuming the invitation is successful. If included, the description is included as message content and is described using field constructs.

The session description is distributed in a format that is compatible with the Session Description Protocol (SDP). After defining SDP version (v), the session description includes a required source description (o). The DC 352 may use any convenient mechanism to choose the values ​​for the session identifier and the session version. Providing an estimate of the current time is one possible way to define the

ES 2 379 863 T3 session identifier. The connection data (c) is specified by defining the network type, the address type, and the connection address. The DC 352 uses the IP address with which it labels (or provides) multimedia traffic as the address of the connection. The DC 352 uses the name portion of the network address of the network as the name of the session (s). The DC 352 specifies the lifetime (t) of the session by providing its best estimate of the current or start time, preferably in Network Time Protocol (NTP) format, and indicates that the session is unlimited (0) . The multimedia format description (m) defines the multimedia type, source port, transport protocol, and payload format that the DC 352 intends to use to transmit to the network. Finally, the session description uses an attribute type definition (a) to indicate that the DC 352 expects the session to be operated as an SRR conference. The server 236 should confirm that the invitee to speak is indeed a valid SRR network address before granting the invitation.

To indicate a successful invitation and specifically inform DC 352 that it has been added to the participant list for the invited network, server 236 delivers an INVITE 360 response.

A positive INVITE 360 response includes the primary session description for the guest network, which describes ports and supported multimedia traffic formats using SPD syntax. The session description includes a connection description (o) that defines the network address to which all signaling and multimedia traffic should be sent. The network address of the network multimedia destination is not necessarily the same as the network address of the SIP user agent server resolved using DNS from the network address of the network.

The session description describes all media and destination media ports. The session description should also include an identifier assigned to DC 352 by UCM 252 in order to identify multimedia signaling messages transmitted by DC 352 as part of its subsequent participation in the network. The value of this identify is unique among all active participants in a given network and, thus, it should be dynamically generated. The DC 352 does not necessarily buffer this identifier between successful SIP invites.

The session description may also include an SRR protocol version announcement indicating the revision level to which the network's multimedia signaling adheres. Such an advertisement can be implemented by extending the value of the type attribute field or by defining a new attribute whose value is the protocol version number.

After receiving a successful INVITE response, the DC 352 confirms the invitation by sending a SIP ACK request 362 back to the UCM SIP user agent server 252. After transmitting the ACK request 362, the DC 352 can close its TCP connection to the SIP server. Before the 362 ACK request is transmitted, the DC initializes its signaling ports and multimedia traffic according to the session description delivered in the INVITE 360 response.

At any time after the DC 352 has successfully transmitted the ACK SIP 362 message in response to an INVITE 360 response, the DC 352 can formally terminate its participation in the network by sending a BYE SIP message 364 to the user agent server 252 of network. Before sending the BYE 364 message, the DC 352 may need to open a TCP connection with the user agent server 252. The BYE message 364 is acknowledged by the GC with a BYE response message 366. Once the BYE response message 366 is acknowledged, the DC 352 can close its UDP connection with the user agent server 252. Prior to the acknowledgment of the BYE response message 366, the user agent server 252 removes the DC 352 from the indicated network list of active participants.

In general, a DC 352 SIP user agent client can use the OPTIONS procedure to query the capabilities of a SIP server. In particular, the DC 352 may wish to query an arbitrary SIP destination to determine if the destination provides SRR call signaling support.

The DC 352 may wish to abort a pending INVITE request 358 before receiving the INVITE response 360 ​​and sending the acknowledgment 362. In such circumstances, the DC 352 may use a CANCEL SIP procedure (not shown) to orderly abort the call. Both the top-level SIP redirect server 236 and the GC SIP user agent server 252 support the CANCEL procedure.

For example, the DC 352 may use the CANCEL procedure to abort an INVITE 358 message in progress if the user decides to make a voice services call and presses send before the INVITE 358 message is completed. In such a circumstance, instead of wait for the INVITE 360 response to complete and immediately send the BYE 364 message, the DC 352 can simply immediately CANCEL the INVITE 358 message and proceed to make the requested voice services call.

After the DC 108 has successfully negotiated its entry into the current members of an SRR network using SIP, all real-time control takes place through application-level point-to-point multimedia signaling messages exchanged between each DC 352. and the SIP server 252 of the network MCU.

ES 2 379 863 T3

Multimedia signaling messages are transported using the protocol stack depicted in Fig. 4 and in accordance with the sequence depicted in Fig. 12. Fig. 12 illustrates a sequence 368 of multimedia signaling messages. A PTT request message 370 is sent by the DC 352 to the SIP user agent server 252 of the MCU node 208 and signals a user's desire to broadcast media, typically voice, to the network. Typically, the PTT request message 370 is sent for each press of the DC 352 push talk button to denote a channel control request. In addition, the DC 352 sends a PTT release message to the SIP user agent server 252 to denote normal release of the "channel" when the user releases the DC 352's push talk button.

The PTT message comprises fields such as opcode, identity, source, and reserved. The opcode field defines whether the PTT message is a channel control request or a release message. The identity field provides a unique message identifier to allow subsequent PTT release and for PTX messages to reference a specific PTT request. The identity should be unique within the registration session of a particular DC 352. The source field uniquely identifies the DC 352 that sends the PTT request 370 to the SIP user agent server 252. The reserved field reserves space in the PTT 370 message for future performance.

The DC 352 expects to receive at least one PTX response message 372 for each PTT request 370 transmitted. If a PTX 372 response is not received within a predetermined time-out period, the DC 352 assumes that the PTT request 370 was lost in transit and retransmits the PTT 370 message using the same PTT identity.

If a PTX response message 372 is never received from the SIP user agent server 252 in less than a predetermined number of retransmissions, the DC 352 assumes that the SIP user agent server 252 is no longer reachable, it goes into sleep mode SRR and indicates an error condition to the user. In a preferred embodiment, the DC 352 uses a different PTT identity for request and release messages.

The PTX message 372 is sent by the SIP user agent server 252 to a DC 352 to acknowledge and respond to a previous PTT request 370, as well as to signal asynchronous channel control events. The SIP user agent server 252 uses the PTX message 372 to respond to a request or release of control of the PTT channel. The PTX 372 message includes information such as whether the referenced channel control request was granted or denied. When responding to a PTT channel control release 370, the PTX message 372 is used to indicate acknowledgment only. The SIP user agent server 252 may also use the PTX 372 message to asynchronously deny a previously granted channel control request (when a higher priority DC 352 issues a channel control request, the PTX lease expires (i.e. , disconnects for time), or some other event occurs that requires that control of the network channel be revoked).

The PTX 372 message comprises fields such as opcode, identity, action, status, and expiration. The opcode field defines whether the PTX 372 message is a synchronous response to a pending PTT request or whether it is an asynchronous message indicating an error or priority arbitration conflict. The identity field refers to a previously received PTT request. The action field indicates whether the PTX 372 message is granting, denying, revoking, or confirming control of the network channel. The status field provides additional information that explains the PTX action, particularly in cases where the PTX 372 message denies, revokes, or cannot service the previous PTT request. The status field may indicate that a higher priority talker has been granted control of the network, or that the DC 352 is not listed as a network participant and is therefore not allowed to send signaling requests multimedia for the network. The expiration field represents the maximum duration, in whole seconds, for which control of the network channel is granted to the receiving DC 352. The SIP user agent server 252 starts its timer the instant it sends the response of the PTX message 372, not when the DC 352 starts sending the multimedia traffic. The value of the expiration field is a configurable parameter of the network.

The DC 352 does not explicitly acknowledge the response 372 of the PTX message. Instead, if the response 372 of the transmitted PTX message is lost, the PTT retransmission timer of the DC 352 expires and the DC 352 retransmits its PTT request 370. Since the retransmitted PTT 370 has the same identity as the lost PTX 372 response, the SIP user agent server 252 responds by sending the missed PTX response 370 again instead of treating the retransmitted PTT message request 372 as a request event. separate conversation button.

The SIP user agent server 252 sends a PTA message 374 to each DC 352 currently participating in a network to announce the identity of the source of the pending multimedia traffic. A PTA 374 message is also used to formally announce the end of a voice sequence.

The PTA 374 message comprises fields such as opcode, talker, and reserved. The opcode field indicates whether the PTA message 374 is announcing the grant (or release) of the channel to the DC 352 (or by part thereof) identified by the talker. The speaker field identifies the DC 352 originating the multimedia traffic to the network until the next PTA 374 message is sent. The reserved field reserves space in the PTA 374 message for future performance.

ES 2 379 863 T3

The DC 352 whose PTT channel control request 370 was successful may or may not receive a PTA message 374 announcing that it has control of the channel. The message can arrive before or after it receives the corresponding PTX response, since UDP does not necessarily preserve the order of the datagrams. However, the SIP user agent server 252 sends the PTA advertisement 374 before it waits to start forwarding media (in the case of a PTA grant advertisement). It is recommended that the requesting DC 352 ignore received PTA 374 messages announcing that it has gained control of the channel and rely solely on the receipt of a PTX grant message response 374 to determine if it can begin streaming media to the network.

The SIP user agent server 252 sends an AYT 404 "you are there" message (FIG. 13) to an individual DC 352 to confirm that the DC 352 in question is reachable using IP. A collection of AYT 404 messages can also be sent to a group of network participants to signal that a network is no longer in dormant mode.

The AYT 404 message comprises fields such as operation code, identity, and reserved. The opcode field indicates whether the MCU node 208 is sending the AYT 404 message to determine if the DC 352 is still reachable or if the SIP user agent server 252 is using the traffic from the AYT 404 message to get channels CDMA cellular traffic partners of the latent mode network. The identity field provides a unique message identifier to allow a subsequent IAH response message 408 "Here I am" to reference a specific AYT request message 404. The identity can include a timestamp reference to generate latency estimates. The reserved field reserves space in the AYT 404 message for future performance.

The DC 352 may or may not be in dormant mode when the AYT 404 message is sent. In all cases, the DC 352 responds to a received AYT 404 message with an IAH 408 reply message.

The SIP user agent server 252 assumes that the DC 352 generally responds to an AYT 404 message with an IAH 408 response. If an IAH 408 response is not received within a reasonable disconnect time, the SIP user agent server 252 transmits a new AYT 408 message with a new identity. If, after a configurable number of retransmissions, no response to the AYT 408 message is received from the DC 352, the DC 352 is assumed to be unreachable and the SIP user agent server 252 removes it from the current list of participants in the net. Future multimedia signaling messages from the removed DC 352 will be ignored (or will generate an error response) until the DC 352 successfully reconnects to the network.

The DC 352 sends the IAH message 408 to the SIP user agent server 252 to acknowledge receipt of a previously sent AYT 404 message. The IAH 408 message comprises fields such as identity, source, and reserved. The identity field refers to a previously received AYT message 408 acknowledged by the DC 352. The source field uniquely identifies the DC 352 that sends the IAH message 408 to the SIP user agent server 252. The reserved field reserves space in the IAH 408 message for optional features.

The SIP user agent server 252 assumes that the DC 352 acknowledges all received AYT 408 messages with an IAH 408 reply message. If the referenced AYT 408 message was sent to confirm that a DC 352 is still connected in the silent state of the SRR, passively monitoring the traffic and multimedia signaling of the SRR, the SIP user agent server 252 records the time of reception IAH 408 for your future reference.

Since the SIP user agent server 252 is responsible for defining the value of the identity field, the SIP user agent server 252 can use the identity to determine and track whether a specific DC 352 is still reachable.

The SIP user agent server 252 sends the ZZZ or Idle message (illustrated in FIG. 13 with reference number 412) to the DC 352 to incentivize the DC 352 to release its air resources and enter latency mode. The DC 352 may choose to ignore this message (especially if it is currently supporting other packet applications at the same time).

The ZZZ message comprises fields such as identity and reserved. The identity field provides a unique message identifier to allow the DC 352 to differentiate between multiple receptions of the ZZZ message. The reserved field reserves space in the ZZZ message for optional or future features.

The DC 352 does not acknowledge the ZZZ message. Generally, error recovery is not attempted if the ZZZ message is lost. To prevent a ZZZ message from being lost, the SIP user agent server 252 can send multiple copies of the same ZZZ message to an individual DC 352. The SIP user agent server 252 ensures that copies of the same idle message are sent at a defined interval, and the DC 352 waits a period longer than this interval from the moment the first idle message is received (with a new identity) before releasing its air link and going into dormancy.

As illustrated in FIG. 15, the DC 352 sends an ASK message 382 as an inquiry 384 to the SIP user agent server 252 to confirm connectivity to the SIP user agent server 252. ASK 382 message also

ES 2 379 863 T3 allows the DC 352 to determine if the DC 352 is still listed as a network participant. The DC 352 may confirm its participation after a service interruption or other period in which it may have temporarily lost connectivity with the SIP user agent server 252.

ASK message 382 comprises fields such as identity, source, and reserved. The identity field provides a unique non-null message identifier to allow a subsequent FYI response message to reference a specific ASK request message. The source field uniquely identifies the DC 352 that sends the ASK message 382 to the SIP user agent server 252. The reserved field reserves space in the ASK 382 message for optional or future features.

The DC 352 assumes that the SIP user agent server 252 responds to a received ASK message 382 with an FYI response message 386. If an FYI 386 response is not received within a predetermined timeout period, the DC 352 transmits a new ASK 382 message with a new identity. If, after a configurable number of retransmissions, no response to the ASK 382 is received from the SIP user agent server 252, the SIP user agent server 252 is assumed to be unreachable and the DC 352 enters the sleep state of group services.

The FYI message 386 is sent by the SIP user agent server 252 to the DC 352 to acknowledge receipt of a previously sent ASK message 382 or is sent asynchronously by the SIP user agent server 252 to inform the DC 352 of a exceptional condition.

The FYI 386 message comprises fields such as opcode, action, status, identity, and reserved. The opcode field defines whether the FYI 386 message is a synchronous response to a pending ASK 382 request or an asynchronous message indicating an exceptional condition. The action field indicates whether the FYI message 386 is confirming participation in the network, informing dc 352 that it has been administratively deleted from the list of network members, or carrying out some other function pending definition. The status field provides additional information that explains the FYI 386 response, in particular in the case where the FYI 386 message indicates that the DC 352 is not a participant or member of the network. The identity field refers to a previously received ASK 382 message acknowledged by the DC 352. The value of the identity field is not defined for asynchronous FYI responses. The reserved field reserves space in the IAH 408 message for optional or future features.

Generally, the DC 352 does not acknowledge FYI 386 message responses. If a response from a synchronous FYI 386 message is lost, the DC 352 sends a new ASK 382 message request. Since the DC 352 does not request responses of asynchronous FYI 386 messages, in a preferred embodiment the SIP user agent server 252 performs at least three staggered transmissions of any asynchronous FYI 386 message response.

A participating DC 352 signals a user's desire to broadcast media to the network by issuing a request 376 for a PTT message to the SIP user agent server 252. The SIP user agent server 252 responds to the PTT request 376 with a PTX message response 378 that can either grant or deny the request. if the request is granted, a PTA announcement message 380 is issued to all network participants. The user interface of the requesting DC 352 may indicate to the user that permission to speak has been granted to the network as soon as the response 378 of the grant PTX message is received. Typically, the DC 352 broadcasts multimedia traffic until the user releases the PTT button, at which point it signals the end of the voice sequence by broadcasting a PTT release message 376 to the SIP user agent server 252. The SIP user agent server 252 responds with a PTX confirmation message 378 and broadcasts an announcement signifying the end of the voice stream to all network participants.

When any DC 352 has the channel (the right to speak) of a network, the network is said to be active; if not, it is inactive. If a network is idle for a time that exceeds the network hang time, the SIP user agent server 252 can put the network into dormant mode by signaling all registered mobile stations to release their air traffic channels. A connection is maintained to allow a request for channel control or other traffic to bring the network out of dormancy relatively quickly. Members of the network can ignore "go dormant" messages. The sIp user agent server 252 does not explicitly or implicitly keep track of the latency of individual members of the network.

As illustrated in FIG. 15, SIP user agent server 252 will "wake up" a network from dormant mode 616 when a channel control request 704 is successfully received during latency. As soon as the channel control request 704 is granted, the SIP user agent server 252 will send a signal to each registered DC 352 requesting the response 716 of you are there (AYT) over the multimedia signaling channel and launching an internal wake-up timer 724. Each DC 352 acknowledges receipt of the AYT 716 response to the SIP user agent server 252 if it wishes to remain registered in the network. Optionally, a dormant DC 352 can temporarily store multimedia traffic 740 from the time the user presses PTT until the DC 352 traffic channel is (re) connected. The SIP user agent server 252 may temporarily store multimedia traffic 740 received from the talking DC 352 until the wake-up timer 724 exceeds the wake-up timeout 724, at which point it begins to forward media traffic to each given DCD 352. discharged - including any member who has not responded to the request 20

ES 2 379 863 T3

AYT 716—. Thus, both the DC 352 and the MCU node 208 have the ability to temporarily store data until the recipient is ready to receive the temporarily stored information. In one embodiment, portions of data are stored in both the DC 352 and the node 208 of the UCM.

The SIP user agent server 252 periodically relays AYT 716 requests to any given fault DC 352 that has not acknowledged the AYT 716 request. late activation, the SIP user agent server 252 will unregister any member DC 352 whose AYTE acknowledgment is pending and stop the wake-up timer 724. The SIP user agent server 252 ignores duplicate AYT responses.

If the DC 352 tries to connect to a network that is dormant at the time, the SIP user agent server 252 processes the request normally and then sends a signal to the DC 352 to go into latency. The signaled DC 352 may ignore the go-to-latency instruction.

During extended periods of network inactivity, the SRR allows a packet data services call to be made in the dormant / idle state 528 (see FIG. 11). The SIP user agent server 252 facilitates transitions to and out of and into the dormant / idle state 528, independently managing a similar latency concept for each network 100 in the SRR.

FIG. 13 illustrates the multimedia signaling message sequence with respect to latency 400 between the DC 352 and the SIP user agent server 252. In general, a message is sent to all DCs in the network to go into latency based on a control signal sent from the GC, based on a timer on each DC. As such, the resources allocated to the network are released and can be used by other users. On a configurable schedule, the SIP user agent server 252 sends a message request 404 (AYT) to each DC 352 in order to confirm that the idle DC 352 is still reachable. Thus, the GC 104 maintains a centralized query of current network users and their status. This also allows individual DCs to dynamically connect to or leave the network. The DC 352 responds to the AYT request 404 with a message response 408 (IAH). AYT 404 messages are not necessarily broadcast to each DC 352 at the same time. The SIP user agent server 252 may alternate sending AYT messages 404 to each network participant to avoid receiving a flood of simultaneous responses 408 to IAH messages.

After the network has been idle long enough for the configurable network hang time to expire, the SIP user agent server 252 broadcasts a ZZZ request message 412 to all network participants. In response, each DC 352 can release its air resources and enter dormant mode. It is not strictly necessary for the network participants to respond to the ZZZ request message 412.

A successful PTT request 416 by DC 352 brings the network out of dormant mode. In one embodiment, a predetermined threshold number of users is required to respond to pull the network out of latency. Before granting the request with a PTX message 420, the SIP user agent server 252 sends each DCD 352 an AYT message request 424 to force each previously participating DC 352 out of latency. This is done if the DC 352 chose to release its air resources in response to the ZZZ 412 message and to confirm that the participating DC 352 is still reachable. In another embodiment, after a configurable, but fixed delay, defined as the PTX latency response timer, the SIP user agent server 252 transmits the response 420 of the PTX grant message to the requesting DC 352. After the second wake-up timer expires (the value of which is generally not less than the PTX latency response timer), the SIP user agent server 252 announces the talker via a PTA 428 message to all network participants and can start submitting media.

The UCM node 208 is responsible for receiving the incoming data packets from the transmitting DC 352 and sending duplicate copies of the received data packets to other members of the network to which the transmitting DC 352 belongs. As each data packet is received by the MCU node 208, it is stored in memory (not shown). The transmitting DC 352 can be identified by interrogating the data packet. In one embodiment, an IP address representing the transmitting DC is included in each data packet as a means of carrying out identification.

After the transmitting DC 352 is identified, the UCM node manager 256 retrieves from local memory a list of network members belonging to the network associated with the particular UCM node 208 (typically, a UCM is assigned to a network only). A destination address is associated with each active member of the network, that is, network members that are currently registered in the node 208 of the MCU, in local memory. In one embodiment, the destination address is an IP address. The UCM node manager 256 then creates a duplicate of the original data packet, except that the destination address identified within the data packet is modified to reflect the destination address of the first network member. The UCM 208 then creates a second duplicate data packet, directed to the second network member. This process continues until the original data packet has been duplicated and sent to all identified active members of the network in local memory. During the broadcast of any buffered media, the GC 104 treats the network as active, even though the speaking DC 352 has released the channel. Therefore, the GC 104 does not allow the DC 352 to interrupt

ES 2 379 863 T3 broadcast of buffered media, unless the interrupting DC 352 has a higher priority than the source of the buffered media.

Note that the SIP user agent server 252 may receive IAH message responses 432 for a long interval after the network has been brought out of dormancy mode and that the SIP user agent server 252 does not wait for all participants to respond first. to grant the pending PTT 416 request. Late responders whose IAH 432 response arrives after the PTX grant message response 420 is transmitted are still listed as network participants, but may not receive all initial multimedia signaling and traffic. It is generally assumed that any DC 352 that does not respond to the AYT 424 request after a third higher (and configurable) delay is no longer reachable and is removed from the list of active network participants.

FIG. 14 illustrates a sequence of SRR multimedia signaling messages 440 demonstrating a higher priority DC 442 interrupting a lower priority DC 444 with network channel control.

Initially, a lower priority DC 442 sends a request 446 for a PTT message to the SIP user agent server 252 that is granted by the SIP user agent server 252. The SIP user agent server 252 advertises that the DC 442 has control of the network channel.

While the lower priority DC 442 is transmitting media 443, a second DC 444 attempts to interrupt sending a PTT message request 448 to the SIP user agent server 252 for the same network. The SIP user agent server 252 determines that the second DC 444 has higher priority than the talking DC 442 and immediately revokes control of the network channel from the talking DC 442 by sending it an asynchronous PTX denial message 450. The SIP user agent server 252 then grants the PTT request 448 to the higher priority DC 444 with a normal PTX grant message response 452 and announces that the higher priority DC 444 has control of the network channel.

If the SIP user agent server 252 determines that the interrupting DC 444 does not have a higher priority, the SIP user agent server 252 immediately rejects the PTT request 448 with a PTX message response 454 and continues to distribute 456 media from the DC speaking to network participants without interruption.

Although the priority assigned to a particular DC is a fixed value defined in the database maintained by the SIP user agent server 252, the SIP user agent server 252 may use other arbitration algorithms that do not necessarily always grant the channel to the participant. highest priority applicant, as depicted here. The PTT arbitration algorithm used to arbitrate conflicts can be individually configured on a network-to-network basis.

At a minimum, the SIP user agent server 252 supports an arbitration policy that allows a DC to interrupt the current talker only if the DC has a higher priority level that exceeds that of the current talker. A DC with a low priority can listen to multimedia traffic, but never gains control of the network channel.

Figures 15 and 16 illustrate the operation of the GC 104 and DC 352, respectively, during various states. The GC 104 maintains an idle timer for each network, or hang time timer 620. When the idle timer 620 reaches a dictated configurable value, the timer causes the GC 104 to put the network into a dormant state 616 by broadcasting a multimedia signaling message 696 to all network participants. Upon receipt of the message, a participating DC 352 can clear its traffic channel and enter a dormant / idle state 844, or the DC 352 can ignore the message and remain in a connected state 820. In particular, the participants of the networks that are not operating on a channel, such as dial-up PSTN users, should ignore multimedia signaling messages.

The network hang time timer 620 does not advance during the interval that a response 632 of a PTX grant message is in effect. Timer 720 is reset when the PTX lease message 632 is transmitted and remains at zero until the PTX lease 632 expires or the DC 352 releases channel 872 from the network. After the channel is released, the hang time timer advances until the next response 632 of the PTX grant message is transmitted.

If a participating DC 352 enters the dormant / idle state 844, it remains dormant until data packets, addressed to the DC 352, arrive at the DC 352's multi-access cellular infrastructure or until the DC 352 generates data for forwarding using the packet data service. The first case can be triggered by traffic sent to DC 352 by GC 104 (908). The latter case can be triggered by the user pressing the PTT button to request permission to broadcast 824 to the network. Other triggers unrelated to SRR are also possible.

The network itself remains dormant until one or more participants trigger the transmission of a PTT request 704. If the GC 104 determines that it can grant the PTT request message 704 (including performing any arbitration necessary to address multiple requests), it sends a request 716 to each enumerated participant on the network to trigger a transition to bring it out of the dormant / idle 844 state. To

ES 2 379 863 T3 any specific DC 352, the trigger may or may not be necessary, but each DC 352 nevertheless responds to the request. In this circumstance, when a network is coming out of latency 616, the GC 104 refrains from sending the initial PTX grant response message 756 until a fixed but configurable delay expires: the PTX latency response timer 728. After timer 728 expires, the default value of which is typically zero, the GC 104 sends, as usual, the PTX grant 756. However, the GC 104 continues to refrain from forwarding media to the network until a second timer expires. Related, the network wake-up timer 724. Both timers are reset when the GC 104 determines that the latent network channel can be granted. The value of the wake-up timer 724 should not be less than the value of the PTX latency response timer 728. After the wake-up timer 724 has expired, the GC 104 begins to forward media and signaling and multimedia traffic flow normally. Both timers are configurable network to network.

If the GC 104 determines that it cannot grant the PTT request 704, it sends, accordingly, an immediate signal to the requesting DC 352 with a PTX denial message 708 and the network remains dormant.

A DC 352 that has entered the dormant / idle 844 state may require a system change, change service options, or experience some other service interruption that causes it to never receive or respond to the AYT “wake up” message 908. The GC 104 maintains a third longest timer that is also reset with the wake-up and latency response timers PTX. This late-wake longer duration timer (not shown) is also configurable network-to-network. After the late wake-up time expires, any DC 352 whose IAH 916 response to AYT wake-up message 908 has not been received is removed from the list of active network participants by the GC 104. Any such removed DC 352 has to re-enlist in the SIP server 236 of the GC 104 to become a participant on the network again.

Due to the potential delays associated with exiting a DC 352 from the dormant / idle state 844 to the connected state, both the DC 352 and GC 104 can perform voice buffering to mitigate the perceived transition delay. by the user.

Typically, the user interface of the DC 352 signals to the user, by visual or auditory mechanisms, at least two milestones in the processing of a push of the PTT key. First, the DC 352 signals that it has detected a press of the PTT key. The DC 352 then signals that it has received the 868 response of the PTX message from the GC 104. If the 868 response of the PTX message grants permission to broadcast media, the user interface of the DC 352 provides an indication that the user can begin speaking to the network; if not, the user interface of the DC 352 indicates that the user has been denied permission (856) to speak to the network.

When the network is not dormant, the latency between the transmission of the PTT request message and the receipt of the corresponding PTX response message is relatively small, and the user becomes accustomed to being granted permission to speak shortly after the button is pressed. PTT button. However, when the network is dormant, a relatively significant delay can separate the transmission of the PTT 852 request and the receipt of the corresponding PTX 856 or 868 message. The delay may occur because the DC 352 may have cleared its traffic channel and experiences a delay in restoring packet data service. The delay can also occur because the GC 104 waits until the network wake-up timer has expired before sending the 856 or 868 response of the PTX message. In this circumstance, the DC 352 may optimistically assume that the GC 104 ends up responding with a PTX grant response 868 and sending a signal to the user that the PTT request 876 has been granted. To allow the user to start speaking "early", the DC temporarily stores the voice internally, until the PTX request arrives or until it consumes all available internal temporary storage space.

If the response of the PTX message arrives and the request is granted, the DC 352 can begin to transmit the voice (temporarily stored) and the operation proceeds normally. If the response of the PTX message arrives and the request is denied, the DC 352 sends a signal to the user that permission to speak to the network has been denied. Since the user has already started speaking, this late denial may appear to be a priority conflict. In this circumstance, special care is taken to avoid unnecessarily confusing the user. The GC 104 signals the PTX denial message 856 as soon as possible to limit the length of time the user can speak with the assumption that the pending PTT request ends up being granted.

If the PTX message does not arrive before all available internal buffer space is consumed, the DC 352 can simulate a PTX deny message 856 and signal the user to stop talking (856). If the DC 352 has not been able to restore service, it may also need to take another error action at this point and inform the user accordingly. Alternatively, if packet data service is restored by then, the DC 352 may, in this situation, begin transmitting voice media to the GC 104 without prior receipt of a response 868 to a PTX grant message.

While waiting for the wake-up timer to expire, the GC 104 temporarily stores any voice media received on the network multimedia channels from the DC 352 that has sent the pending PTT request 852 and ends up sending a corresponding PTX grant response 868. After the wake-up timer expires, the GC 104 transmits the PTX grant response 868 to the requesting DC 352, 23

ES 2 379 863 T3 broadcasts a PTA announcement to the network and starts broadcasting the temporarily stored voice media. If the internal voice buffer of the GC 104 is consumed before the wake-up timer expires, the GC 104 immediately transmits a PTX deny message 856 to the requesting DC 352. The processing of the buffered speech is undefined, but the GC 104 can transmit the contents of its speech buffer to the network after the wake-up timer has expired. After the wake-up timer has expired, network operation continues normally.

The size of the voice buffer in the DC 352 is chosen based on the maximum time expected to go into the IS-707.5 connected state 812 from the IS-707.5 dormant / idle state 844. Similarly, the media buffer size of the GC 104 should be chosen based on the (maximum) value of the network wake-up timer specified in the GC 104 network database 232.

A more complete description of the states of GC 104 follows. GC 104 implements the SRR multimedia signaling state diagram 600 shown in FIG. 15 for each case of a network. The GC 104 initializes to a state 604 when a network is created. The network remains in the idle state 604 as long as there is no PTT request 608 from a network participant or until channel control is granted (612) and the network is not dormant (616). The GC 104 resets the hang time timer 620 to zero upon entering the idle state 604. The GC 104 transitions from the idle state 604 to the grant state 612 when a PTT request 608 is received from a network participant. The GC 104 transitions from the idle state 604 to the latency pass state 624 when the hang time timer expires.

GC 104 transitions from grant state 612 to idle state 604 and sends a PTX denial response 626 to requesting DC 352 if the arbitration algorithm denies channel control to requesting DC 352. GC 104 transitions from grant state 612 to advertisement state 628 and sends a PTX grant response 632 to requesting DC 352 if arbitration grants channel control to requesting (or interrupting) DC 352. After the PTX grant response 632, the GC 104 considers the requesting (or breaking) DC 352 the current speaker on the network. The GC 104 transitions from the announcement state 628 to the speaking state 636 and sends a PTA message 640 announcing the new speaker to all network participants immediately after entering the announcement state 628. The current talker remains in the speaking state 636 as long as no PTT request 644 or release message 648 is received from a network participant and the network security timer 652 has not expired. The GC 104 resets the network security timer 652 upon entering the speech state 636. While in the speaking state 636, the GC 104 broadcasts media to the network from the current speaker on the network.

The GC 104 transitions from the talk state 636 to the arbitrate state 656 when the PTT request message 644 is received from a network participant. The GC 104 transitions from the talk state 636 to the release confirmation state 660 when the PTT release message 648 is received from the DC 352 with network channel control. GC 104 transitions from speech state 636 to security recovery state 664 when security timer 652 expires. Typically, the user is given the amount of time remaining before the safety timer expires. While remaining in the speaking state 636, the GC 104 broadcasts to the network multimedia traffic received from the current speaker on the network. If the network media buffer is not empty, the GC 104 continues to buffer the media received from the current speaker on the network while broadcasting media traffic to the network.

The GC 104 enters the arbitrate state 656 as a result of the receipt of the PTT request message 644 while in the speech state 636. The DC 352 that originated the 644 request message 644 is called the switch party. If the switch party and the current talker are identical, the GC 104's PTX grant message 668 is lost and the current talker is sending the PTT request 644 again. The GC 104 stops from the arbitration state 656 to the speaking state 636 and sends the PTX grant message 668 to the switch party if the switch party and the current network speaker are identical. The GC 104 applies the arbitration algorithm to the current speaker on the network and the switch party immediately after entering the arbitration state 656 if the switch party and the current speaker on the network are different.

The GC 104 transitions from the arbitration state 656 to the speaking state 636 and sends the switch party a PTX deny message 672 if the arbitration algorithm fails in favor of the current talker. The GC 104 transitions from the arbitration state 656 to the grant state 612 sends the current network talker a PTX interrupt messages 676 if the arbitration algorithm fails in favor of the switching party. The GC 104 transitions from the release confirmation state 660 to the release announcement state 680 and sends a PTX confirmation message 684 to the current talker immediately after entering the release announcement state 680.

The GC 104 transitions from the security recovery state 664 to the release announcement state 680 and sends a PTX denial message 688 to the current talker immediately after entering the security recovery state 664. The GC 104 transitions from the release announcement state 680 to the idle state 604 and sends a PTA release announcement 692 to all network participants immediately after entering the release announcement state 680. The GC 104 goes from the dormant state 624 to the dormant state 616 and sends a ZZZ message 696 announcing to all network participants that the network has gone dormant immediately after in the dormant state 616. The network state machine remains in the dormant state 616

ES 2 379 863 T3 as long as no network participant requests channel control. The GC 104 transitions from the dormant state 616 to the wake-up state 700 when a PTT request 704 is received from a network participant.

The GC 104 transitions from the wake-up state 700 to the dormant state 616 and sends a PTX deny response 708 to the requesting DC 352 if the arbitration algorithm denies channel control to the requesting DC 352. Since the network is dormant, this can occur only if the requesting DC 352 has only listening privileges. The GC 104 transitions from the reactive state 700 to a wake-up pending state 712 and sends an AYT wake-up request 716 to all network participants if arbitration grants channel control to the requesting DC 352. After the AYT reactivation request 716 has been sent, the GC 104 considers the requesting DC 352 the pending network talker.

The GC 104 remains in the wake-up pending state 712 as long as no PTT request message 720 is received from a network participant, a wake-up timer 724 has not expired, and the PTX latency response timer 728 has not expired. The GC 104 resets the wake-up timer 724 and the PTX latency response timer 728 after entering the wake-up pending state 712. The GC 104 transitions from the wake-up pending state 712 to the latency arbitration state 732 when the PTT request message 720 is received from a DC 352 other than the pending network talker. The GC 104 transitions from the wake-up pending state 712 to the latency grant state 736 when the network wake-up timer 724 expires. The GC 104 transitions from the wake-up pending state 712 to a buffer-grant state 740 when the PTX latency response timer 728 expires.

The GC 104 applies the arbitration algorithm to the pending network talker and switch party immediately after entering the latent arbitration state 732. The GC 104 transitions from the latent arbitration state 732 to the wake-up pending state 712 and sends the switch party a PTX deny message 744 if the arbitration algorithm fails in favor of the pending talker. The GC 104 goes from the latent arbitration state 732 to the wake-up pending state 712, sends the PTX deny message 744 to the pending talker, and considers the switch party to be the network's new pending talker if the arbitration algorithm fails in favor of the switch participant.

The GC 104 transitions from the latency grant state 736 to the announcement state 628 and sends a PTX grant response 748 to the network pending talker immediately after entering the latency grant state 736. The GC 104 transitions from the temporary storage grant state 740 to a temporary storage state 752 and sends a pending PTX grant response 756 to the talker immediately after entering the temporary storage grant state 740. The network state machine remains in the buffer state 752 as long as the wake-up timer 724 has not expired. While in buffer state 752, GC 104 buffers any received multimedia traffic from the talker pending from the network.

GC 104 transitions from buffer state 752 to advertisement state 628 when wake-up timer 724 expires. The GC 104 temporarily stores any received multimedia traffic from the network pending talker in the network multimedia buffer as long as it remains in buffer state 752. The GC 104 responds to any multimedia signaling request that contains invalid or reserved field values ​​by sending an ERR response 760 in an error state 764 to the DC 352 that sent the message, and if not, ignores the request.

The DC 352 implements the SRR multimedia signaling state diagram 800 shown in FIG. 16 whenever a user is participating in a network. The DC 352 initializes to a boot state 804 after the DC 352 accepts the session description from the network by sending an ACK SIP message 808 to the GC 104. The DC 352 transitions from the start-up state 804 to a start-up wait state 812 and sends an ASK request message 816 to the GC 104 immediately after entering the start-up state 812.

The DC 352 remains in a listening state 820 as long as the user does not press the push talk button 824, no PTA 828 messages are received from the 104 GC, and no ZZZ 832 idle messages are received from the 104 GC. DC 352 transitions from the listening state 820 to a channel request state 836 when the user presses the push talk button 824. The DC 352 transitions from the listening state 820 to a talker announcement state 840 when the PTA message 828 is received from the GC 104. The DC 352 transitions from the listening state 820 to a latency-idle state 844 when the message is received. Idle ZZZ message 832 from GC 104. DC 352 transitions from channel request state 836 to channel wait state 848 and sends a PTT grant request 852 to GC 104 immediately upon entering request state 836 of the Chanel.

The DC 352 remains in the channel 848 wait state as long as no response 856 messages are received

PTX from GC 104 and a PTT cancel timer 860 has not expired. The DC 352 resets its PTT cancel timer 860 and a PTT retransmission timer (not shown) after entering the channel hold state 848. The DC 352 transitions from the channel hold state 848 to a talk state 864 and alerts the user that the user has gained control of the network channel when a PTX grant response message 868 is received from the GC 104. The DC 352 transitions from the channel standby 848 state to a

ES 2 379 863 T3 channel loss status 872 when PTX deny message 856 is received from GC 104. The DC 352 remains in channel wait status 848 and retransmits an identical 876 PTT request to GC 104 after your PTT retransmission timer expires. The DC 352 transitions from the channel's wait state 848 to the listening state 820 after its PTT cancel timer 860 expires. The DC 352 transitions from the talk state 864 to a channel release state 880 if the user releases the push talk button 884 while still waiting for a PTX response.

The DC 352 remains in the talk state 864 as long as no PTX interrupt message 888 is received from the GC 104 and the user has not released the talk button 884. The DC 352 transitions from the talk state 864 to the channel loss state 872 when the PTX interrupt response message 888 is received from the GC 104. The DC 352 transitions from the talk state 864 to the channel release state 880 when the user releases the push talk button. The DC 352 remains in the talk state 864 when the PTX grant response message 868 is received from the GC 104. The DC 352 transitions from the channel loss state 872 to the listening state 820 and alerts the user 892 with a message indicating that control of the network channel has been lost immediately upon entering the channel loss state 872.

The DC 352 transitions from the channel release state 880 to a release wait state 896 and sends a PTT release request 900 to the GC 104 immediately upon entering the channel request state 836. The DC 352 remains in the release wait state 896 as long as no PTX acknowledge response message 904 is received from the GC 104 and the PTT cancel timer 860 has not expired. The DC 352 resets its PTT cancel timer 860 and a PTT retransmission timer after entering the release wait state 896. The PTT retransmission timer is activated each time there is a PTT request or release.

The DC 352 transitions from the awaiting release state 896 to the listening state 820 when the PTX acknowledge response message 904 is received from the GC 104. The DC 352 remains in the awaiting release state 896 and retransmits an identical request 900 release PTT to the GC 104 after its PTT retransmission timer expires. The DC 352 transitions from the release wait state 896 to the listen state 820 after its PTT cancel timer 860 expires.

The DC 352 transitions from the speaker announcement state 840 to the listening state 820 and announces the speaker immediately upon entering the speaker announcement state 840. The announcement may indicate that a new speaker has control of the channel, that the current speaker has released the channel, or that no speaker currently has control of the channel.

The DC 352 remains in the dormant idle state 844 as long as no AYT request message 908 is received from the GC 104 and the user does not press the push talk key 824. The DC 352 transitions from the idle dormant state 844 to the dormant wake-up state 912 when the AYT request message 908 is received from the GC 104. The DC 352 transitions from the idle dormant state 844 to the channel request state 836 when the user presses the push talk key 824.

The DC 352 discards any ZZZ 916 Idle messages received while in the latent Idle 844 state. The DC 352 transitions from the wake-up latency state 912 to the wake-up state 820 and sends an IAH response message 916 to the GC immediately after entering the wake-up latency state.

Upon receipt of an AYT trace request 920 received from the GC 104 while in any state other than the idle dormant state 844, the DC 352 saves its current state, temporarily transitions to an IAH response state 924, builds and sends an IAH response message 928 to GC 104 and returns to its previous state. The GC 104 sends an eRr response 932 to the DC 352 when it receives a multimedia signaling error and enters an error state 936, such as a malformed request that makes use of invalid or reserved field values.

Upon receipt of the ERR 932 response received from the GC 104 while in any state, the DC 352 alerts the user that an error has occurred, disables the DC 352 (940), and performs any appropriate ZIP signaling to finish their participation in the network in an orderly manner (944).

When the DC 352 has entered a dormant state (844), the DC 352 can receive point-to-point voice service calls via another IS-707 service option and still remain a participant in a dormant network. After the voice services call ends, the DC 352 returns to the 844 dormant / idle state IS707.5.

However, if the network exits dormancy 844 while the DC 352 has chosen to receive a point-to-point voice service option call, the CD 352 may miss the AYT "wake up" message request 908 and be removed from the network. list of active participants. In such cases, DC 352 can determine its participation status by sending an ASK 382 request to GC 104. Once the DC 352 has been removed from the list of active participants in the network, the DC 352 re-registers with the SIP server of the GC 104 to participate in the network again.

ES 2 379 863 T3

The DC 352 allows the user to originate and receive conventional point-to-point TRPC calls, as well as participate in group service discussions. Although the DC 352 can operate internally in one of several modes, the DC 352 avoids restricting certain functionality within the context of distinct operating modes in which the user is explicitly required to navigate. Thus, receiving and making point-to-point voice service calls are seamless as long as group services are enabled and activated.

The DC 352 can be used to make point-to-point voice services or secure point-to-point packet voice calls at any time, regardless of whether group services are active or not, provided that the DC 352 you are not simultaneously acting as a speaker. If the DC 352 has been registered as a member of a network, the DC 352 is removed from the network. If the selected point-to-point call is made using a voice service option, the DC 352 terminates data services. Once the point-to-point call is complete, the DC 352 can transparently enable the data service and re-enlist as a member of the current selected network.

The DC 352 can be used to receive PSTN or secure point-to-point packet voice calls while group services are enabled, within the limitations imposed by the cellular infrastructure. If the DC has connected to a network and the selected network is active, the DC 352 appears busy for an incoming PSTN call and the cellular infrastructure gives the call the appropriate busy treatment. If the selected network is idle, but the network hang-up time 620 has not expired, the cellular infrastructure also gives the call the normal busy treatment. However, if the hang-up time 620 of the selected network has expired, the network has been put into dormant mode 616, and the DC 352 has released its air resources, the cellular infrastructure may not treat the call as busy and busy. the DC 352 can be paged to initiate reception of the incoming call.

While a voice services call is active, the DC 352 is unable to receive any SRR network traffic. After the voice services call has completed, the DC 352 may be required to reconnect to the network, as one or more AYT 716 requests may have been missed. Whenever the DC 352 appears busy for an incoming voice services call, the caller is redirected based on whether, as expected, a busy situation handling has been defined for the called DC 352 (such as a call forwarding). calls, voicemail, etc.) over the cellular infrastructure. Optionally, a user can configure the DC 352 to disable the reception of incoming point-to-point calls while a network is selected and the DC 352 is registered as a member.

The DC 352 also detects if your IP network address has changed or is about to change. If the DC 352 is participating in a network when the address change occurs, the DC 352 is INVITED back to the network, as discussed with respect to Fig. 11.

For example, a roaming DC 352 can switch cellular systems or cellular networks and thus negotiate a new IP network address. Or the DC 352 may experience a service outage or packet data service option call interruption for whatever reason and, after service is restored, be assigned a new IP network address. If the DC 352 is participating in a network during an address change and does not reconnect to the selected network in a timely manner, the GC 104 ends up causing its membership to expire and removes the DC 352 from the list for the selected network. The DC 352 is removed from the list of active network participants if it does not end up responding to a series of multimedia signaling AYT request messages 716.

In the absence of the IS-707.5 packet data service option, the SRR can operate over the existing and commonly available packet fast network connection (QNC) service. However, currently the QNC does not support latency. Consequently, application level messages such as "go dormant" can be ignored by the DC 352 operating the SRR over QNC.

The QNC does provide a protocol stack similar to that provided by IS-707.5. The DC 352 can be configured to negotiate a packet connection using QNC instead of IS-707.5, and, if QNC service is available, treat the connection as a latency-free packet data service option connection or optionally CRTP header compression support.

In mobile IP, the DC 352 connects to the network using a foreign agent, which assigns the mobile a custodial address. The custodial address is a temporary, but legal, address to which IP datagrams can be directed from anywhere on the Internet. The mobile uses the custodial address to contact your local agent and to inform them of the custody address of the mobile. After confirming the identity of the mobile, the home agent sends packets addressed to the mobile's permanent home address (which normal Internet routing mechanisms deliver directly to the home agent or the home agent's network) to the mobile using the mobile's custodial address. mobile.

Although the SRR can operate over mobile IP, mobile IP can have a potential adverse impact on end-to-end latency and the perceived voice quality of SRR multimedia signaling and traffic. This may be of particular importance if the DC 352 connects to a network using its permanent address and the home agent is located far away, in a network topology sense, from the GC 104 and the DC 352. In such a case, optionally may

ES 2 379 863 T3 routing multimedia traffic over the public Internet or other variable quality of service networks, which might not have been required if mobile IP was not used. To avoid this, it is preferable for the DC 352 to access SRR services using your custodial address and connect to networks when your custodial address changes.

Both SIP call signaling and PGP public key encryption use a CD 352 unique user identity or similar unique identifier. The user database 232 defines an internal user identifier that can be forwarded to and used by the DC 352 in multimedia signaling requests. Preferably, the user identity address of the DC 352 does not contain any private data whose public disclosure could compromise the existing authentication mechanisms of the cellular infrastructure.

The DC 352 user address is used in the SIP sign-up and invite headers, and can be used to form other parts of the required SIP syntax. The user address is also an input for the generation of the private PGP key used to authenticate SIP requests. The user interface of the DC 352 allows the user to view the user's address. The user interface of the DC 352 can allow the user to change the user address, at the risk of potentially disrupting SRR access ability or satisfying SIP authentication requests.

To prevent certain denial of service attacks and avoid spoofing the DC 352, the GC 104 can optionally request that the DC 352 authenticate itself before logging on or connecting to a network. Authorization is carried out at the application level, regardless of other authorization schemes that may exist at the network or cellular infrastructure level. The DC 352 authorization is also implemented and operates independently of concepts and data structures that support encrypted (secure) SRR networks.

In particular, the GC 104 may request that the DC 352 include an "Authorization" header with its SIP requests. The authorization header allows the SIP message to be signed by the DC 352 using PGP public key cryptography signatures.

Public key cryptography generates a public and a private key from a private secret, typically known only to the cipher (in this case, the DC 352). To sign a message, the private key is required, in combination with the secret, but only the public key can be used to verify the signature of a signed message. Thus, to support SIP authorization, each DC 352 is preferably provided with a private and a private secret key, which are never shared. Each GC 104 to which the DC 352 may need to be authorized should know the DC 352's public key. Since the public key is not secret, it can be stored as part of the user portion of the database 232 maintained by the GC. 104, or it can be accessed through generic public key servers on the Internet.

The GC 104 may require authorization from the DC 352 at the server, network, or user level. At the server level, the GC 104 requires that all clients connecting to the SIP server 236 of the GC 104 (see FIG. 3) provide authorization credentials that reject all requests that are not authorized. When server-level authorization is enabled, only clients whose identities (ie, a client's public key) are previously known to the GC 104 can effectively use the server. Server-level authorization can protect GC 104 SIP server 236 from many relatively straightforward denial-of-service attacks.

A GC 104 can protect one or more networks that it manages by authorization, but leaves other networks "unprotected". If the DC 352 tries to INVITE to a secured network, the SIP server 236 of the GC 104 rejects the request, unless the DC 352 can be authorized by the GC 104.

In addition, the GC 104 can use authorization to ensure that the DC 352 (or any SIP user agent client in general) does not attempt to impersonate another DC 352 and thereby deny service to legitimate network participants. or passively monitor multimedia channels on a network. If the GC 104 requires a specific DC 352 to be authorized, the GC 104 does not accept any SIP requests from a client connecting as a DC 352 unless the requests from the SIP client include a PGP signature that can be verified by the client. GC 104. At the user level, authentication can be configured user-to-user (ie, GC 104 can require certain users to authenticate first, while allowing other users to remain unauthenticated).

The PGP private key can be administratively provisioned within the DC 352, or created by the DC 352, once the DC 352 user address is defined. The private key does not need to be stored externally ,,, but the The associated public key is generally loadable in the user portion of the database 232 of any SIP server that requires DC 352 authentication.

In one embodiment, the primary DC 352 SRR or network participant platform is a DC 352 multiple access cellular handset. Since the SRR is built on top of the IP and IP transport protocols, any platform with IP capabilities with connectivity to the GC 104 can potentially serve as SRR's DC 352. Consequently, dial-up users can connect to the GC 104 via the PSTN through existing IP terminal servers operated by Internet Service Providers (ISPs), as illustrated in Fig. 1. The terminal server operates as a bridge between the PSTN and a LAN that supports IP. The server of

ES 2 379 863 T3 terminals comprise a battery of modems, which provide a connection point for high speed PSTN modems, a server and one or more network interfaces. The server is capable of hosting multiple independent PPP sessions, one for each connected modem user. The server also functions as a routing device, routing IP packets between each of the individual PPP interfaces and any active LAN interfaces. The GC 104 includes an integrated commercial terminal server as standard (or can be deployed in conjunction with an external one).

The dial-in terminal server supports and includes the ability to negotiate the compression of the CRTP header in its PPP sessions. Similarly, the PPP stack used by a dial-up client also includes and attempts to use CRTP. However, given the additional bandwidth available on high-speed modems, the inability of a dial-based user to negotiate CRTP header compression may not necessarily force a network to avoid using payload-based specifications. RTP.

If the terminal server is located on an internal LAN of the DC 352 multiple access service provider and thus close, in a network topology sense, to the service provider GC 104, dial-up users can avoid quality of service issues that can contribute to high end-to-end latency if the path between the ISP's terminal server and the GC 104 traverses a portion of the public Internet. Since PSTN-based modems typically do not support a latency concept similar to that implemented by IS-707.5, dial-based network participants ignore any idle messages received from GC 104. Although the user database 232 keeps track of whether a connecting user is cellular or terrestrial, this feature continues to be provided. Consequently, the GC 104 may or may not send idle or other multimedia signaling messages to dial-in users.

SRR service areas are designed to be integrated, both to allow users to roam between service areas and to connect in equivalent networks defined within separate service areas. Peer-to-peer communications between multiple GCs 104 takes the form of SIP server redirects, exchange of network and user database records, and additional messages specific to an integrated SRR service.

In an integrated SRR service embodiment, it may be preferable to allow any GC 104 to take ownership of a network. Thus, the operation of a network is not specific to a particular GC 104 or a node 208 of the MCU. The choice of GC 104 can be dynamically determined based on factors such as proximity to the majority of network participants and available quality of service in an intersystemic network of service providers. Similarly, any SIP redirect server 236 is capable of redirecting any DC 352 to the UCM SIP user agent server and / or, if necessary, forwarding DC 352 to another SIP redirection server.

In an integrated SRR service embodiment, the network address of a network has meaning throughout the SRR system. Consequently, one or more top-level SIP servers 236 are responsible for redirecting INVITE requests and distributing to the network participants on the appropriate nodes 208 of the MCU. Top-level SIP servers 236 can share a common user and network database 232, providing similar functionality and redirection decisions at different network rendezvous points. Consequently, redirection of invitations originating from DC 352 provides an important and critical layer of abstraction that allows multiple installations of GC 104 to be integrated into a single homogeneous SRR service.

In an integrated SRR service, the system increases in size, doubling the functionality provided by the UCM node manager 256, its associated set of the UCM 252 (loosely called the “UCM group”), including its user agent server. YEP. All elements of the system share a single database 232 and a management interface 248.

The procedure by which a DC 352 is connected to a network in such an embedded system is substantially the same as that used in a system comprising a single installation of a GC 104. The DC 352 begins by sending all SIP requests to the server 236 of top-level SIP redirection (now global). The redirect server 236 redirects, via SIP mechanisms, the requesting DC 352 to the appropriate destination. In the case of an INVITE request to meet a network, the destination is the SIP user agent server 252 associated with the MCU node 208 with current responsibility for the network in question. In the case of an INVITE requesting a current list of available networks from DC 352, the destination is any user agent capable of responding to the request.

Separately, the redirect server 236 can exchange additional messages with the UCM 252 via inter-application messaging using implementation-specific protocols and / or messaging conventions. As in the non-integrated case, a special boot action may be required to ensure that the redirect server 236 can determine a destination for each legitimate INVITE request it receives. In one embodiment the SIP registries exist on the top-level redirect server 236. In addition, the top-level server can query the system database and attempt to correlate each invitation request with a network definition contained therein.

ES 2 379 863 T3

The DC 352 can offer encrypted network broadcast communications. At the choice of network users, voice and data transmitted over a particular network can be encrypted at the transmitting DC 352 and decrypted by all other DCs on the network. Encryption is end-to-end, that is, from one DC to another. Typically, network communications are encrypted using a commercial encryption algorithm embedded in a DC with SRR capabilities. The choice of whether a DC 352 treats a network as encrypted and unencrypted is discretionary for the users of the network; that is, the involvement of GC 104 is not required.

Users can select network to network if they would prefer the traffic transmitted / received over that network to be encrypted / unencrypted. The user is given the ability to enter an encryption key for the network using, for example, the telephone keypad. The user is thus able to establish encrypted communications with other users on the network who have also selected the encryption option for the network and who are also using the same encryption key.

The user can enable or disable encryption of network traffic for any network key that the user has entered into the DC 352 at any time. Multimedia traffic can be symmetrically encrypted by using a symmetric key (a traffic encryption key, or TEK) that is shared by network users. Traffic encryption keys can be generated offline by a network user or network administrator and then securely distributed to network participants, who manually enter the keys into their respective communication devices. The key is used for multimedia traffic on a particular network, until new keys are generated and distributed to network users to replace the network's previous TEK.

The DC 352 is notified that it is a member of a particular network by messages received from the GC 104. The network administrator for a specific network may set an informational flag indicating that the network is intended to be encrypted. This indication is generally informative, and does not necessarily necessarily indicate that network communications are actually encrypted. The user interface of the DC 352 allows a user to designate any network as an encrypted network and allows the user to enter the TEK of the network from the DC 352, regardless of whether the GC 104 has received an informational flag for the network.

The DC 352 can enforce minimum and maximum key lengths. The DC 352 may provide a means for a checksum to be entered in conjunction with the key and, if provided, to verify the checksum in the entered key. If the checksum is not entered, the DC 352 calculates the checksum and makes it available for display to the user. The DC 352 does not necessarily display the key on the DC 352 display after the initial key entry.

Once a key has been successfully entered for a given network, multimedia transmissions over the network are encrypted using that particular key, and all traffic received by the network is decrypted using that particular key. Encrypted traffic includes additional headers that allow the DC 352 to synchronize the encryption / decryption process to allow late synchronization (synchronization with a transmission already in progress) and to confirm that the sender and recipient are using identical encryption keys. of traffic. If a DC 352 receives encrypted traffic (detected by the presence of encryption headers) on a network that it has not designated as encrypted, the DC 352 indicates to the user that it is receiving encrypted traffic, and does not output the traffic (muting the sound or suppressing the data output). Similarly, if the DC 352 receives media traffic that is not encrypted on a network that is configured to encrypt, or if the traffic is not properly encrypted (for example, if the keys are incompatible), the DC 352 alerts the user and silence the traffic.

The key to an encrypted network can simply be a random (binary) number. In general, the key can be generated by a party on a network, or an administrator of that network, and be distributed securely to network participants. Since the key distribution guideline is currently in the hands of network users, it is a potential source of compromising network security. Thus, it is recommended that the network encryption key be distributed to network participants using secure means, such as PGP encrypted email. Security manager 20 (FIG. 1) also provides a central repository for common network keys. Other procedures, such as a standard phone call or a face-to-face meeting, are also possible. Keys can also be automatically distributed to DCs using a PGP secret key embedded in a communications device for SIP authentication.

The previous description of the preferred embodiments is provided to enable any person skilled in the art to make or use the present invention. The various modifications to these embodiments will be immediately apparent to those skilled in the art, and the generic principles defined herein may be applied to other embodiments without the use of inventiveness. Thus, the present invention is not intended to be limited to the embodiments shown herein, but may vary within the scope of the appended claims.