Method and apparatus for speaker arbitration in a multi-participant communication session

Method and equipment for speaker arbitration in multi-participant communication session

Technical field

Generally, the present invention relates to Internet Protocol (IP) networks, and, more specifically, to speaker arbitration in multi-participant IP network communication sessions.

Background technique

Wireless communication systems are well known in the art. In traditional wireless communication systems, real-time services are typically implemented using a circuit-switched architecture combined with at least a dedicated wireless resource. However, the current trend in the industry is to use a packet-switched architecture to support wireless communications. For example, the so-called 2.5-generation wireless technology provides unprecedented access to the Internet through wireless devices to transmit data and voice. In a communication system using a packet-switched architecture, the Internet Protocol (IP) is becoming the standard for voice and data communication.

In a voice over IP (VoIP) communication session, the messages involved in the establishment of the session generally use the Session Initiation Protocol (SIP) to establish the session, and use the Real Time Protocol (RTP) to provide voice data packets between session participants Real-time exchange. SIP is an application layer signaling protocol, which can run on a variety of different transport layer protocols and is used to initiate, modify, and terminate a session involving one or more participants. SIP uses proxy servers, registration servers, and application and conference servers to provide registration functions for session participants, locate and route requests to participants, provide authentication and authorization services for participants, and provide participants with features.

SIP messages used to initiate a session typically include session description information, which allows participants in the session to reach a consensus on a set of compatible media types (such as vocoders) and exchange information (such as IP addresses and ports). Typically, such information is formatted according to different protocols, such as Session Description Protocol (SDP). SDP is designed to transmit related call establishment information to call participants, and is used to describe multimedia sessions for the purposes of session publishing, session invitations, and other forms of multimedia session initiation.

Multi-participant communication sessions, such as dispatch communication sessions (which are typically half-duplex communication sessions), and conference calls, require strict mechanisms to arbitrate who is allowed to speak at any particular moment during the session. This speaker arbitration agreement is called "speaking right control". SIP does not provide such services, because SIP is only used to initiate a session, which will be controlled by some other conference control protocol. Once the session is established, SIP does not provide the exchange of voice and other data. Although RTP is generally used to exchange data packets between participants in a VoIP session, there is no prescribed mechanism for using RTP to provide floor control. However, speaker arbitration can occur multiple times during the process of dispatch or conference calls, so speaker arbitration must occur quickly and with minimal delay. Therefore, there is a need for methods and devices that provide high-speed floor control for multi-participant IP-based communication sessions.

Description of the drawings

Fig. 1 is a block diagram of a wireless communication system according to an embodiment of the present invention.

Fig. 2 is a bitmap of an exemplary real-time protocol data packet in the prior art.

Fig. 3 is a bitmap of a real-time protocol data packet according to an embodiment of the present invention.

Fig. 4 is a logic flow diagram of steps performed by the communication system of Fig. 1 when providing floor control in a multi-participant communication session according to an embodiment of the present invention.

Fig. 5 is a block diagram of a wireless communication system according to another embodiment of the present invention.

detailed description

In order to meet the needs of methods and devices for providing high-speed floor control for multi-participant IP-based communication sessions, the communication system provides in-band speaker arbitration in multi-participant communication sessions by using RTP floor control messages. The message contains the speaker arbitration command embedded in the header extension of the data packet.

Generally, embodiments of the present invention include methods for providing speaker arbitration in a communication session involving multiple participants. The method includes the following steps: assembling a real-time protocol (RTP) data packet, adding a header extension to the real-time protocol data packet, and embedding a speaker arbitration command in the header extension to generate an RTP floor control message.

Another embodiment of the invention includes a method for speaker arbitration in a communication session involving multiple participants. The method includes the following steps: receiving a request to reserve the floor of the communication system, assembling a real-time protocol (RTP) floor control message including the request to reserve the floor, and sending the RTP floor control message.

Yet another embodiment of the present invention includes a method for speaker arbitration in a communication session involving multiple participants and multiple nodes associated with the multiple participants. The method includes the steps of receiving a real-time protocol (RTP) floor control message including a request to reserve the floor of the communication session from one of a plurality of participants in the communication session, and determining whether the floor can be obtained. The method further includes the following steps: when the right to speak is obtained, sending a second RTP speaking right control message that agrees to the request to reserve the right to speak, and when the right to speak is not available, sending a third RTP speaking right control message that does not agree to the request to reserve the right to speak news.

Yet another embodiment of the present invention includes a device for providing floor control in a communication session involving multiple participants and multiple nodes associated with the multiple participants. The device includes a gateway with a signal processing unit that assembles real-time protocol (RTP) data packets, adds header extensions to the RTP data packets, and embeds speaker arbitration commands in the header extensions to generate RTP floor control messages .

The present invention can be described more fully with reference to Figures 1-5. FIG. 1 is a block diagram of a wireless communication system 100 according to an embodiment of the present invention. The communication system 100 includes a plurality of system nodes 101-104 (four are shown), and each node communicates with an Internet Protocol (IP) network 106. In an embodiment (wireless embodiment) of the present invention, each node is basically a logical representation of a basic device responsible for wireless transmission and reception in one or more coverage areas. In the wireless embodiment, each node includes a base station controller (BSC), which is connected to one or more base transceiver systems (BTS). Each node 101-104 is connected to the IP network 106 through a wireless network subsystem (not shown) that constitutes a wireless network controller. Each node 101-104 provides a communication service to a wireless user communication device 111-114 (for example, a mobile station (MS), such as a mobile phone, a wireless phone, or a wireless modem, which is located in the coverage area served by the node). Each communication device 111-114 communicates with the IP network 106 through the corresponding node 101-104 of the device.

In other embodiments of the present invention, one or more of the nodes 101-104 may be a proxy server, which reports to the corresponding user equipment 111-114 (for example, voice over IP (VoIP) phone or data communication device (DCD)). , Such as digital modems) to provide communication services. The DCD is preferably connected to a digital terminal equipment (DTE), such as a personal computer, workstation, notebook computer, or other data terminal, and transmits data between the DTE and the IP network 106.

Each communication device 111-114 includes a signal processing unit 116, such as one or more microprocessors, microcontrollers, digital signal processors (DSP), combinations thereof, or other devices known to those of ordinary skill in the art, and also includes one Or multiple storage devices (not shown), such as random access memory (RAM), dynamic random access memory (DRAM), and/or read-only memory (ROM) or their equivalents. The storage device stores programs executed by the signal processing unit 116 and data utilized by the signal processing unit to allow the operation of the corresponding communication device in the communication system 100.

The IP network 106 includes a media gateway 120 that is operatively connected to the media gateway controller 130. The media gateway 120 provides a common IP communication link to each of a plurality of nodes (eg, nodes 101-104) involved in a multi-participant communication session. In one embodiment of the present invention, the media gateway 120 is an Intelligent Packet Duplicator (IPD), which is available from Motorola, Schaumburg, Illinois, which has been modified to perform the functions of the present invention. In another embodiment of the present invention, the media gateway 120 may include a conference bridge that communicates with a packet data router to provide a common digital communication link to each of the multiple nodes involved in the multi-participant communication session road. The media gateway 120 then further includes a packet duplicator connected to the conference bridge, which provides a packet duplication function.

When the media gateway 120 receives a data packet from a node (such as node 101) involved in a multi-participant communication session, the media gateway creates one or more copies of the received data packet to send to other parties in the multi-participant communication session. Participants, such as communication devices 112-114. The media gateway 120 then routes the copied data packet to nodes corresponding to other participants, namely nodes 102-104. In another embodiment of the present invention ("IP multicast" embodiment), the media gateway 120 may use a well-known IP multicast method to copy RTP packets and send the packets to each of the communication devices 111-114. In the IP multicast embodiment, each of the nodes 101-104, or as another alternative, is assigned a common IP multicast address to each of the communication devices 111-114. The audio packet including the public IP multicast address may be sent by the SPU 116 of any one of the communication devices 111-114 to the media gateway 120 in the form of unicast. Thereafter, all required duplication can be economically performed by a gateway including an IP router (e.g., media gateway 120).

In another embodiment of the present invention, when the media gateway 120 routes the data packet received from a first node (for example, node 101) to another node (for example, node 103), thereafter, the media gateway may only route the received data packet. Data packet without duplicating the packet may change the header about the destination of the data packet, and provide any speaker arbitration service invisibly. In another embodiment of the present invention, the speaker arbitration service performed by the media gateway 120 described here can be performed by one of the participating communication devices 111-114 or nodes 101-104, and the media gateway is also allowed to route only the received data packets It does not provide any speaker arbitration services explicitly, except for the possibility of changing the header about the destination of the data packet.

The media gateway 120 includes a signal processing unit 124, such as one or more microprocessors, microcontrollers, digital signal processors (DSP), combinations thereof, or other devices known to those of ordinary skill in the art, and also includes one or more memories A device (not shown), such as random access memory (RAM), dynamic random access memory (DRAM), and/or read only memory (ROM), or equivalents thereof, which stores data and programs executable by the signal processing unit 124. Among the data stored by one or more memory devices, there are multiple gateway routing addresses associated with the media gateway, preferably IP addresses and port numbers. Multiple gateway routing addresses provide routing destinations, where the communication devices 111-114 can send data packets to the media gateway. When a communication session is established, the media gateway 120 communicates with each of the multiple nodes involved in the session through the media gateway IP address/port combination assigned to the node by the media gateway controller 130.

The media gateway controller 130 controls the allocation and bridging of multiple IP address/port combinations from the media gateway 120 to the communication session. In one embodiment of the present invention, the media gateway controller 130 may be a dispatch communication controller, such as a distribution application processor (DAP) available from Motorola, which has been modified to perform the functions of the present invention. In another embodiment of the present invention, where the media gateway 120 may include a conference bridge, the media gateway controller 130 may be a conference bridge controller, which has been modified to perform the functions of the present invention. The media gateway controller 130 includes a signal processing unit 132, such as one or more microprocessors, microcontrollers, digital signal processors (DSP), combinations thereof, or other devices known to those of ordinary skill in the art, and also includes one or more A memory device (not shown), such as random access memory (RAM), dynamic random access memory (DRAM), and/or read only memory (ROM) or their equivalents, which stores data and can be executed by the signal processing unit 132 program.

The communication system 100 includes a packet data communication system. In order to establish a communication session with one or more other communication devices (such as communication devices 112-114) of the system 100 for a communication device of the system 100 (for example, the communication device 111), the communication device exchanges a session initiation protocol through its corresponding nodes 101-104 (SIP) message. The establishment of a communication session by exchanging SIP messages is well known in the art, and is described in detail in RFC (Request for Comments) 2543 issued by the IETF (Internet Engineering Task Force), which is fully integrated here by reference. When a communication session is established, voice data is exchanged through data packets formatted in accordance with the real-time protocol (RTP). RTP is a well-known protocol and is described in RFC 1889 issued by the IETF, which is fully integrated here by reference.

Each SIP message includes a header and a message body, and includes a request to call a specific method or function on the node or communication device that receives the message. The header includes routing addresses associated with the source of the message (e.g., communication device 111), and routing addresses associated with one or more intended destinations of the message (e.g., communication devices 112-114). Each routing address is typically a SIP Uniform Resource Identifier (URI), which includes a host name and domain that identifies the communication device. The routing address can also identify the target multi-participant talk group. For example, the US patent application No. 09/990,929 entitled "Improved Use and Management of Groups Defined According to a Call Initiation Protocol" describes the use of a call initiation protocol (such as SIP) to route messages to members of a multiparty talk group. This patent application is assigned to the assignee of the present invention and is fully integrated here by reference.

The message body of the SIP message includes a description of the session, such as media type, vocoder, sampling rate, etc., which allows participants in the session to reach a consensus on a compatible set of session details. However, the session description information is not described using SIP. In fact, the message body of each SIP message is encoded in a different protocol format, which is preferably the Session Description Protocol (SDP), as described in RFC 2327 issued by the IETF, and is fully integrated here by reference. SDP is designed to transmit related communication session establishment information to session participants, and is used to describe multimedia sessions for the purposes of session publishing, session invitations, and other forms of multimedia session initiation.

In the communication system 100, when an initiating communication device (for example, the communication device 111) sends a SIP_INVITE message to the IP network 106, a multi-participant communication session is initiated. The SIP_INVITE message informs the IP network 106 that the communication device 111 wants to establish a multi-participant communication session involving at least two communication devices, such as a group call or a conference call. The IP network 106 routes the SIP_INVITE message to the media gateway controller 130, and the controller determines that the communication device 111 wants to establish a multi-participant communication session, and further determines the intended participants in the communication session.

In an embodiment of the present invention, the SDP of the SIP_INVITE message may include a group identifier, which is associated with the talk group including the communication device 111. The database 134 existing in or connected to the media gateway controller 130 stores the group identifier and further stores a group of communication devices, which are members of the talk group. For example, the database 134 may store a group of identifiers, each identifier being uniquely associated with a communication device, and further associated with the group identifier. The location registration server 140 connected to the media gateway controller 130 stores the location of each communication device 111-114 in the communication system 100, such as a node serving the communication device. In another embodiment of the present invention, the SDP of the SIP_INVITE message may include a code word associated with a pre-scheduled conference call. The codewords are further associated with a group of communication devices that intend to participate in the conference call, and the codewords and corresponding lists are stored in the media gateway controller 130. In yet another embodiment of the present invention, the SDP of the SIP_INVITE message may include a set of communication device identifiers associated with the communication device that the initiating communication device wants to invite to participate in the session.

Upon receiving the SIP_INVITE message, the media gateway controller 130 determines that the initiating communication device (ie, the communication device 111) is requesting the establishment of a multi-participant communication session. The media gateway controller 130 further determines the communication devices (ie, the communication devices 112-114) to be invited to participate in the session. The media gateway controller 130 then allocates a media gateway (ie, media gateway 120) to the communication session, and instructs the media gateway 120 to allocate and assign to each node corresponding to the participant in the communication session (ie, each node 101-104) The routing address associated with the media gateway is preferably an IP address and a port number. In response to receiving the instruction, the media gateway 120 allocates multiple media gateway IP addresses and multiple media gateway ports to the session, and reports the allocated IP addresses and ports to the media gateway controller 130. The media gateway controller 130 then assigns one of the multiple media gateway IP address/port combinations 120a-120d (four shown) to each node 101-104 participating in the session, and notifies the media of the assigned address/port combination Gateway 120. The media gateway controller 130 also informs the media gateway 120 of the binding of each assigned media gateway address/port combination 120a-120d with the IP address and port of the corresponding node 101-104, so as to route the subsequent received The information of SIP and RTP data packets is notified to the media gateway.

In another embodiment of the present invention, the media gateway controller 130 may instruct the media gateway 120 to allocate an IP address and port to the communication session. In response to receiving the instruction, the media gateway 120 allocates a media gateway IP address and a media gateway port to the session, and reports the allocated IP address and port to the media gateway controller 130. The media gateway controller 130 then assigns a media gateway IP address/port combination to each node 101-104 participating in the session, and associates the assigned address/port combination and the assigned media gateway address/port combination with those corresponding to the nodes 101-104 The binding of the IP address and port is notified to the media gateway 120, so as to notify the media gateway of where to route the SIP and RTP data packets received thereafter. The media gateway 120 then monitors the assigned port, and copies all voice packets arriving at the port in accordance with the speaker arbitration mechanism described below. Each voice packet arriving at the media gateway 120 is completely identified by the source IP address and SSRC/CSRC parameters included in the packet, and these parameters are described below.

The media gateway controller 130 then transmits the SIP_INVITE message to each of the one or more session invitees through the media gateway 120 and the nodes 102-104 respectively associated with the communication devices (ie, the communication devices 112-114 ). The SDP of each SIP_INVITE message includes information that notifies the receiving node and/or communication device of the media gateway 120 address/port combination assigned by the media gateway controller 130 to the receiving node, so as to route the subsequent SIP and The information of the RTP data packet is notified to the communication device and/or node.

As a response to receiving the SIP_INVITE message, each invitee (ie, each communication device 112-114) sends back a SIP_OK message to the initiating communication device (ie, communication device 111) through the IP network 106. The initiating communication device 111 then confirms each SIP_OK message by sending back a SIP_ACKNOWLEDGMENT message to the responding communication device, and the communication device 100 establishes RTP media following the well-known method for exchanging voice and data packets between multiple participants Conversation. As noted above, the SIP messages exchanged by participants when establishing a session provide communication about the type of RTP media session that the participant is willing to establish, including the services and features that will be provided to the participant.

The IP network 106, preferably the media gateway controller 130, or as an alternative, the media gateway 120, checks the SDP part of each SIP message exchanged during the establishment and communication of the communication session. When the conversation communication shows that the message format between the nodes is incompatible, for example, the first node of the participating nodes 101-104 has a first vocoder, which is compatible with the second voice used by the second node of the participating nodes 101-104. The encoder is different, or the first node of the participating nodes 101-104 operates in accordance with the first standard or message format (such as pulse code modulation (PCM)), which is the same as the second node used by the second node of the participating nodes 101-104. Standards or message formats (such as Universal Mobile Telecommunications System (UMTS)) are different. In this case, the media gateway controller 130 can discard incompatible nodes, such as using a vocoder that is different from the vocoder used by other nodes participating in the session. node.

In another embodiment of the invention, the IP network 106 may include one or more translators 122 (one is shown) that can translate messages from one format to another, such as from one protocol or Standard to another protocol or standard. Each of the one or more translators 122 may be included in the media gateway 120, or may be included in an application platform operably connected to the media gateway 120. When the media gateway controller 130 determines that there is a format incompatibility between the nodes that are invited to participate in the session, such as a vocoder or standard incompatibility, the media gateway controller 130 assigns an appropriate translator 122 to translate the incompatibility between the nodes and the incompatible node. Communication. The assigned translator 122 then translates the RTP data packets exchanged between the media gateway 120 and the incompatible node during the communication session.

After establishing the RTP media session, by using data packets formatted in compliance with RTP and assembled by the signal processing units 116 of the communication devices 111-114, multiple communication devices (ie, communication devices 111-114) involved in the communication session Exchange voice data between. Fig. 2 is a bitmap of an exemplary RTP data packet in the prior art. The RTP data packet 200 includes an RTP fixed header, which includes a plurality of data fields 201-210 and a payload data field 212. Optionally, the RTP data packet 200 may further include an undefined RTP header extended data field 211. The fixed header includes a "version" data field 201, which identifies the RTP version used, and also includes a "padding" data field 202. When set to a value of '1', it indicates that the data packet 200 includes one or more extras at the end of the packet. The padding octet (octet), these octets are not part of the payload. The fixed header further includes an "extension" data field 203, when set to a value of '1', it indicates that the fixed header is followed by a header extension, and also includes a "contributing source count" (CSRC, Contributing Source Count) data field 204, which includes the number of CSRC identifiers following the fixed header.

The "flag" data field 205 of the fixed header provides flags of important events in the data packet stream, such as the boundary of a data frame, and this field is determined by a profile. The "payload type" data field 206 of the fixed header includes a code that identifies the format of the RTP payload. The profile determines the default static mapping of the load type code to the load format, so that the load type code determines the interpretation of the load by the application in the receiving communication device. The "sequence" data field 207 of the fixed header provides a sequence number for each data packet in a series of related data packets. The receiving communication device can use the sequence number to detect the loss of data packets and restore the order of the data packets when the packets are received out of order. The "time stamp" data field 208 of the fixed header identifies the sampling time of the first octet in the RTP data packet. The receiving communication device can use the time stamp to synchronize and measure the data packet arrival jitter. The "Synchronization Source Count" (SSRC) data field 209 of the fixed header uniquely identifies the sender of the RTP packet. The "CSRC" data field 210 of the fixed header includes a set of identifiers associated with the branch source of the load included in the data packet.

In order to provide speaker arbitration (ie "speaking right control") for high-speed multi-participant communication sessions that can be implemented within the framework of RTP sessions, the communication system 100 provides'in-band' speaking rights by using RTP floor rights control messages control. Each RTP floor control message includes an RTP data packet, which includes the RTP floor control header extension. FIG. 3 is a bitmap of an RTP floor control message 300 according to an embodiment of the present invention. Preferably, each RTP floor control message 300 is assembled by a signal processing unit of a component of the system 100 that sends the message (for example, the signal processing unit 116 of each communication device 111-114 or the signal processing unit 124 of the media gateway 120). Similar to the RTP data packet 200, the RTP floor control message 300 includes a payload data field 312 and a fixed header 301-310, which includes a version data field 301, a padding data field 302, an extended data field 303, a CSRC count data field 304, and a flag The data field 305, the load type data field 306, the sequence data field 307, the timestamp data field 308, the SSRC data field 309, and the CSRC data field 310.

Different from the RTP data packet 200, the RTP floor control message 300 further includes the RTP floor control header extension data field 311, which includes a plurality of floor control subfields 321-323. The first subfield 321 of the RTP floor control header extension 311 includes a floor control message type data field, which identifies the type of the RTP floor control message. The second subfield 322 of the RTP floor control header extension 311 identifies the length of the RTP floor control header extension. The third subfield 323 of the RTP floor control header extension 311 is embedded with floor control data, preferably a speaker arbitration command, corresponding to the RTP floor control message identified by the subfield 321. In order to notify the receiving communication device of the existence of the RTP floor control header extension 311, the extension data field 303 of the RTP floor control message 300 is embedded with a value of '1'.

By implementing an in-band floor control protocol between communication devices, the communication system 100 provides a floor control protocol, which is transparent to the following network and devices. The actual deployment of floor control protocols for multi-party communication sessions will generally require firewalls placed at various locations within and between the infrastructure and remote entities. In order to allow SIP and RTP to traverse the firewall, it is known in the art to allow the firewall to monitor the SDP settings for the conference, so as to allow or disallow packets to pass through the firewall based on the rules established by the firewall manager. Since additional firewall services are required to allow the control protocol to pass transparently, the'out-of-band' voice control protocol will suffer losses. The floor control protocol is embedded in the carrier load structure of RTP data packets to ensure the timely delivery of control information and free access through any central security measures.

Preferably, the multiple RTP floor control messages implemented by the communication system 100 to provide a speaker arbitration process include the following six types of floor control messages. The first message among the multiple RTP floor control messages is a request to send a message, which requests to reserve the floor, that is, it requests to be a user information transmission device in a multi-participant communication session, such as a speaker. The RTP packet containing the request to send message may further include voice samples. If the source of the voice packet is not allowed to speak at a given time, the audio contained in the voice packet is ignored, because only one participant can reserve the right to speak at any given time. The second message among the multiple RTP floor control messages is an approval to send message, which grants the floor to the requester in response to the request to send the message. The third message among the multiple RTP floor control messages is a start sending message, which identifies the start of data transmission after the grantee (grantee) is granted the floor. The fourth message among the multiple RTP floor control messages is an end-sending message, which relinquishes the authorized person's control of the floor and indicates that the floor is reserved and open to other participants in the communication session. The fifth message among the multiple RTP floor control messages is a confirmation message. When there is no other response, the confirmation message can be used as a general response to the request to send the message. The sixth message among the multiple RTP floor control messages is a request rejection message, which rejects the requester's request to reserve the floor.

By providing RTP floor control messages that can be exchanged between the participants involved in a multi-participant IP communication session and the centered IP network, the communication system 100 provides in-band speaker arbitration. The arbitration is high-speed and is Operate with minimal changes to the existing IP network. Preferably, each of the approval message, the confirmation message, and the request rejection message includes information that uniquely identifies the requester, and the start message includes information that uniquely identifies the authorized person.

Referring now to FIG. 4, a message flow diagram 400 is provided that illustrates the speaker arbitration process of the communication system 100 for a multi-participant communication session in accordance with an embodiment of the present invention. When a participant in a multi-participant communication session who wants to reserve the right to speak to send user information (that is, to speak or send user data) (for example, the user of the communication device 112) enters the right to reserve request (402) into the participant's communication When the device (ie, the communication device 112), the message flow diagram 400 starts. For example, the participant can press a key on the keypad, such as the Push-To-Talk (PTT) key on the keypad of a wireless phone, to indicate that the user wants to reserve the right to speak. As a response to the receiving request, the communication device 112 assembles an RTP floor control request to send a message (404) and transmits the message to the IP network 106, particularly the media gateway 120, through the corresponding node 102.

In response to receiving the request to send the message, the IP network 106, particularly the media gateway 120, determines (406) whether the right to speak can be obtained. In other embodiments of the present invention, one or more functions performed by the media gateway 120 in the message flowchart 400 may be performed by the media gateway controller 130, depending on the level of intelligence implemented in the media gateway 120 by the designer of the system 100. When the media gateway 120 determines that the floor is not available, for example, the floor is reserved by another communication device (such as the communication device 111) participating in the communication session, the media gateway 120 transmits the RTP floor control message to the requester, that is, , Transmitted to the communication device 112, and the message rejects the request to agree to reserve the right to speak. In one embodiment of the present invention, the message that refuses to agree to the request to reserve the right to speak may be a refusal to send the message (408). For example, the communication device 111 may actively send data to the media gateway 120 for distribution to other participants in the communication session. In another example, the communication device 111 may have tried to release the right to speak by sending an end-sending message to the media gateway 120, but the media gateway has not released the right to speak from the reservation of the communication device 111. If the refusal to send message contains information identifying the requester, the media gateway 120 may use IP multicast to send one or more refusal to send messages. The message can be copied to the requestor (ie, the communication device 112) and to one or more of the other participants (ie, one or more of the communication devices 111, 113, and 114). Other participants can later use the information identifying the requester to determine that the message is not for them, and choose to ignore the message.

In another embodiment of the present invention, the message that is transmitted by the media gateway 120 to the requestor to reject the request to reserve the floor can be an RTP floor control confirmation message (410). In another embodiment of the present invention, a plurality of participants request the right to speak, and the media gateway 120 determines to grant the right to speak to different participants. As described below, the media gateway sends a rejection consent to the requester. The message of the request to reserve the floor may be the RTP floor control consent to send message (416), which grants the floor to the other party. By responding to the transmission of the RTP floor control request to send the message, the requester (ie, the requesters communication device) receives a message different from the RTP floor control approval to send the message that grants the floor to the requester, the requesters The communication device is notified that the requester's request to reserve the right to speak has been rejected.

When the media gateway 120 determines that the floor is open (that is, it can be reserved), the media gateway transmits the RTP floor control consent to send message (414) to the requester (that is, to the communication device 112), and communicates with the requesters communication device The associated node (ie, node 102). The opening of the right to speak may be because it is no longer reserved, or because the media gateway 120 determines to open the right to speak reserved by a communication device for the reservation of another communication device. For example, the communication system 100 can implement a speaker preemption process in which the speaker can be preempted, that is, after the speaker has reserved the right to speak for a continuous and predetermined length of time, the speaker can lose his or her right to speak. Reservation of the right to speak. In another example, the communication system 100 may implement an emergency reload process, in which when the second communication device requests the right to speak to send an emergency communication, the first communication device may lose the reservation of the right to speak in favor of the second communication device.

Agree to send a message to notify the requester that he or she is granted a reservation of the right to speak, and can start to speak or send user data. In another embodiment of the present invention, in addition to transmitting a message of consent to send to the authorized person, the media gateway 120 may additionally send to one or more of the other participants in the communication session through a node associated with the participant. (Ie, one or more of the communication devices 111, 113, and 114) transmit RTP floor control consent to send a message (416), which identifies the authorized person (ie, the communication device 112), and/or is associated with the authorized personofnode (ie, node 102). Since the consent to send message contains information that identifies the authorized person, the media gateway 120 can use IP multicast to copy a single consent to send message to the authorized person (ie, the communication device 112) and to one or more of the other participants ( That is, one or more of the communication devices 111, 113, and 114).

In yet another embodiment of the present invention, the media gateway 120 may receive a request to send a message from each of the communication devices of a plurality of participants (for example, the communication devices 112, 113, and 114). Multiple request-to-send messages can be received simultaneously by the media gateway 120, or can be received with each other within a predetermined or dynamically determined time period, thereby allowing geographically remote communication devices to be on an equal basis with closer communication devices. Competition for a say. When the media gateway 120 determines that the floor is not available, the media gateway transmits an RTP floor control rejection message (408) to each requester (ie, to each of the communication devices 112, 113, and 114). When the media gateway 120 determines that the right to speak is available, the media gateway, especially the arbitration logic unit 128 in the media gateway, executes the arbitration algorithm (412) stored in one or more memory devices of the media gateway to obtain the right to speak. Choose a reservation request for approval. In another embodiment of the present invention, the arbitration logic unit 128 may exist in the media gateway controller 130 and execute the arbitration algorithm stored in the memory device of the media gateway controller.

Those of ordinary skill in the art realize that any one of many well-known arbitration algorithms can be used here without departing from the spirit and scope of the present invention. For example, the communication system 100 may assign a priority, such as a rank order, to each communication device (111-114). Upon receiving a request to send message from each of the multiple communication devices 112-114, the media gateway 120 determines the multiple based on the identifier included in the SSRC data field 209 of the RTP floor control request to send message transmitted by the device. The priority of each of the two communication devices. Based on the determined priority, the arbitration logic unit 128 executes an arbitration algorithm to determine the communication device with the highest priority, and preferably, grants the right to speak to the communication device.

In another example, the determination of which reservation request is approved may be based on a roundrobin algorithm, where the media gateway 120 or the media gateway controller 130 maintains a record of the number of times each participant in the communication session has been granted the right to speak. Based on the number of times each participant is granted the right to speak, the arbitration logic unit 128 executes the arbitration algorithm stored in the memory device of the media gateway 120 to determine the participant with the least number of consents, and preferably, grants the right to speak to the communication equipment. Other examples of arbitration algorithms include prioritization based on the arrival time of each of the multiple requests, and prioritization based on the location of each of the multiple participants.

After determining that the floor can be obtained, and further determining the reserved requestor to be granted the floor when a plurality of request sending messages are received, the media gateway 120 sends an RTP floor control consent to send message to the authorized person (414). In an embodiment of the present invention, when multiple request to send messages are received, the media gateway controller 130 further sends (416) the RTP floor control consent to send message to each of the other participants requesting to reserve the floor. The consent to send the message identifies the authorized person who is granted the right to speak. In another embodiment of the present invention, after determining that the right to speak can be obtained, and further determining the reserved requestor to be granted the right to speak when a plurality of request to send messages are received, the media gateway controller 130 and the media gateway 120 IP multicast can be used to copy and send an RTP floor control message to each of multiple participants in a communication session, which agrees to a request to reserve the floor. Each of the multiple participants requesting to reserve the right to speak can then determine whether they have been granted or denied the right to speak based on the authorized person identified in the message. In another embodiment of the present invention, when multiple request to send messages are received, the media gateway controller 130 may send RTP floor control to each of the participants who have requested to reserve the floor but are denied the floor. Refuse to send the message (418). In yet another embodiment of the present invention, the media gateway controller 130 may send an RTP floor control confirmation message to each of the other participants who have requested to reserve the floor but are denied the floor right to be granted (420). Each of the multiple participants who request to reserve the right to speak can then determine that they have been denied permission to speak based on the fact that they have received a message (the fact) that they agree to send a message based on the RTP-speaking right control that lists them as authorized persons. right.

The authorized person communication device 112, in response to receiving the consent message, provides (422) an indication that the user has been granted the right to speak to the user of the authorized person communication device. For example, the authorized person communication device may provide an audio indication to the user, such as a buzzer, or the communication device may provide a visual indication to the user, such as activating an inactive light emitting diode (LED), or deactivating an active LED. When notified that he or she has been granted the reservation of the right to speak, the user can then send voice data or other user information to other participants in the communication session. The user inputs user information including voice or other user data to the user's communication device (ie, the communication device 112) (424). In response to receiving the user information, the communication device 112 assembles one or more RTP data packets including the user information, and passes the requesters node 102 and the media gateway address/port combination 120b associated with the requesters node to The one or more RTP data packets (426) are transmitted to the media gateway 120. Each of the one or more user data RTP data packets includes user information embedded in the payload data field 212 and the value "0" embedded in the extended data field 203.

When the media gateway 120 receives each RTP data packet including user information from the authorized person communication device 112, the media gateway generates a copy of the user information included in the received data packet. The media gateway 120 then assembles the RTP packet including user information for each node 101, 103, 104 bound to the media gateway address/port combination 120a, 120c, 120d allocated to the communication session, and assembles the RTP packet including user information. The copied RTP data packet (428) is transmitted to each of the other participants in the communication session through its corresponding node. For example, when the media gateway 120 receives an RTP data packet including user information from the communication device 112, the media gateway is associated with at least one of the other communication devices (ie, the communication devices 111, 113, and 114) participating in the session , And each node 101, 103, 104 associated with the media gateway address/port combination 120a, 120c, 120d assigned to the session copies the user information included in the received RTP packet. The media gateway 120 assembles RTP data packets including copies of user information for each such node. The media gateway 120 then routes the assembled RTP data packets to each communication device 111, 113, 114 through the nodes 101, 103, 104 and the media gateway address/port combinations 120a, 120c, and 120d associated with the nodes, respectively.

When the user of the authorized person communication device finishes sending user information, the authorized person initiates the release of the floor right by instructing his or her willingness to release the floor right (430) of the authorized person communication device (ie, the communication device 112). For example, the user can simply stop speaking to the device, or the user can release the PTT key, and the user keeps pressing the key while the user wishes to retain the right to speak and send user information. In response to receiving the user's indication of his or her willingness to release the floor, the authorized person communication device determines to release the floor and configures the RTP floor to control the end of sending the message. The RTP floor control ends to notify the receiver of the message that the sender intends to release the reservation of the floor. The authorized person communication device then sends the RTP floor control end sending message (432) to the IP network 106, especially the media gateway 120.

The media gateway 120 receives the RTP floor control end transmission message, and in response to receiving the message, generates the RTP floor control end transmission message for each of the other participants in the communication session. As another alternative, the media gateway 120 may create a copy of the received end-to-send message to send to each of the other participants. The media gateway controller 130 then routes (434) the RTP floor control end to send the message to each of the other participants in the communication session. In another embodiment of the present invention, as a response to receiving the end-of-send message, the media gateway 120 may also generate an RTP floor control confirmation message, which confirms the receipt of the end-of-send message, and sends the RTP floor control confirmation message. (436) Transmit to the authorized person's communication device (ie, the communication device 112). In response to receiving the RTP floor control end transmission message, the communication device of each participant (ie, the communication devices 111, 113, and 114) indicates to the user of the device that the channel is available for reservation (438). Those of ordinary skill in the art realize that many methods of indicating the availability of the right to speak can be used here, without departing from the essence and scope of the present invention, such as audio instructions, such as buzzers, or visual instructions, such as when the end of the transmission is received. The LED is activated or deactivated at the time of the message.

In another embodiment of the present invention, one or more of the nodes 101-104 may not be able to support the exchange of RTP floor control messages described above with reference to FIGS. 1-4. In such an embodiment, the media gateway 120 may further include at least one interactive function unit (IWF) 126 (one shown), which may be used to interconnect nodes that support different versions of RTP. In this embodiment, the SDP part of the SIP message exchanged by participants when establishing a communication session informs each node 101-104 of the RTP version supported. When the media controller 130 determines that one or more of the nodes 101-104 supports an RTP version different from the version supported by one or more other nodes of the nodes 101-104, the media controller 130 instructs the media gateway 120 to allocate the IWF 126 , To reformat the communication between the two kinds of nodes, or to generate a message that one RTP version supports but the other RTP version does not support, thereby allowing nodes that support various RTP versions to communicate with each other.

For example, each node 101-103 may support an RTP version that uses RTP header extensions to include speaker arbitration, as described above, while node 104 may be an obsolete node, which supports those that do not include header extensions. RTP version. The media gateway controller 130 may then allocate the IWF 126 to process the packets received from the nodes 101-103 and sent to the node 104, so that the packets are in a format supported by the node 104. When the IWF 126 receives the RTP data packet including the header extension from one of the nodes 101-103 and is to be sent to the node 104, the IWF 126 processes the remaining part of the RTP data packet for the node 104 to ignore the header extension.

The IWF 126 can also generate an RTP floor control message on behalf of the obsolete node 104, so that the node 104 can still participate in speaker arbitration with the nodes 101-103. For example, the IWF 126 can preferably distinguish between voice and silence. When the floor right is available and the IWF 126 receives a non-muted RTP data packet from the node, the IWF can generate an RTP floor right control request sending message on behalf of the node 104. When the node 104 is denied the right to speak in response to the sending request to send the message, the IWF 126 subsequently blocks the RTP message received from the node 104. When the node 104 is granted the right to speak in response to the sending request to send the message, the IWF 126 then forwards the RTP message received from the node 104. And when the node 104 is granted the right to speak and remains silent for a predetermined period of time thereafter, the IWF 126 may generate an RTP right to control end sending message on behalf of the node 104 to give up control of the right to speak.

In another embodiment of the present invention, IWF 126 can support multiple packet data protocols, such as iDEN (Integrated Digital Enhanced Network) and the RTP version that uses RTP header extensions to include speaker arbitration, and can support a protocol Translate data packets between a node and a node that supports another protocol.

Generally, the communication system 100 provides in-band speaker arbitration in a multi-participant communication session by using a variety of RTP floor control messages 300 including speaker commands embedded in the RTP data packet header extension. The RTP floor control message 300 includes a request to send a message, which requests to reserve the floor, and also includes a consent to send message, which grants the floor to the requester as a response to the request to send the message, and also includes the start of sending a message, which identifies the authorized person The beginning of the data transmission after being granted the right to speak also includes the end of sending the message, which relinquishes the authorized persons control of the right to speak, and instructs that the right to speak is reserved for other participants in the communication session. It also includes a confirmation message. When there is no other response, the confirmation message can be used as a general response to the request to send the message, and includes a request rejection message, which rejects the requester's request to reserve the right to speak. When the media gateway 120 receives the RTP floor control message, the gateway may return a responsive RTP floor control message to the sender of the message and/or other participants in the communication session, or it may copy the message for transmission to other participants. By. The communication system 100 can also use IP multicast to copy and transmit received floor control messages or responsive floor control messages. By implementing an in-band floor control protocol between communication devices, the communication system 100 provides a floor control protocol, which is transparent to the underlying network and devices, thereby ensuring timely delivery of control information and passing through any center The security measures are free to access.

FIG. 5 is a block diagram of a communication system 500 according to another embodiment of the present invention. Similar to the communication system 100, in the communication system 500, each of the communication devices 111 and 112 communicates with the first media gateway 120 and the first media gateway controller 130 of the IP network 106 through the nodes 101 and 102, respectively. However, unlike the communication system 100, in the communication system 500, each of the communication devices 113 and 114 involved in the communication session is included in the second media gateway 520 and the first media gateway 520 in the IP network 106 through the nodes 103 and 104, respectively. The media gateway communicates with the media gateway controller 130. In an embodiment of the communication system 500, the first media gateway 120 and the second media gateway 520 are both controlled by the same media gateway controller 130. In another embodiment of the present invention, the first media gateway 120 is controlled by the first media gateway controller 130, and the second media gateway 520 is controlled by the second media gateway controller 530.

In one embodiment of the communication system 500, each of the nodes 103 and 104 is operatively connected to the second media gateway 520 as part of the design of the system 500. In another embodiment of the communication system 500, the media gateway controller 130 may allocate the second media gateway 520 to serve the nodes 103 and 104 during the establishment of a communication session involving the communication devices 111-114. In yet another embodiment of the communication system 500, during the establishment of a communication session involving the communication devices 111-114, the media gateway controller 130 may determine that another media controller 530 should provide services to the nodes 103 and 104. The media gateway controller 130 then instructs the second media gateway controller 530 to serve the node during the session, and allocate the second media gateway 530 to the node. Preferably, when multiple gateways 120 and 520 are used in a communication session, one gateway of the multiple gateways (for example, the media gateway 120) is assigned as the master (gateway), and other gateways among the multiple gateways are assigned as the master (gateway). The gateway (for example, the media gateway 520) is the slave (gateway). Thereafter, the main gateway (ie, the gateway 120) and the associated gateway controller (ie, the gateway controller 130) execute the floor control determination and arbitration algorithm.

For example, during the exchange of SIP messages for establishing a communication session, the media gateway controller 130 may determine that multiple nodes (ie, nodes 103, 104) invited to participate in the communication session suffer from the same incompatibility, for example, using the same Incompatible message format or have the same incompatible vocoder. The media gateway controller 130 may then assign a second media gateway 530 to serve each of the similarly incompatible nodes 103 and 104. The allocated second media gateway 520 may include a translator that performs translation between the incompatible data formats of the vocoders of the nodes 101-102 and the vocoders of the nodes 103-104, or may be operatively connected to An appropriate translator in the application platform of the media gateway 520.

In another example, the media gateway controller 130 may determine that a subset of the participants in the communication session (for example, the communication devices 113 and 114 and their associated nodes 103, 104) are geographically close to the second media gateway 520 and geographically It is far away from the first media gateway 120. The proximity of the nodes can be determined by comparing the IP addresses of each of the nodes to determine that two or more of the nodes are in the same IP network or sub-network. Thereafter, the second media gateway 520 can be selected so that the gateway is in the same network or related network (as determined by the lookup table). The proximity of a node can also be determined based on the "contact" information that is located within the SIP message and exchanged by the communication device 111-114 and the node 101-104 during the establishment of the communication session. "Contact" information includes a URL (Uniform Resource Locator) or IP address that identifies the location of the participant at the time. Thereafter, the URL can be investigated to obtain a normal text string, and/or the IP address can be investigated to obtain a normal network or sub-network. Thereafter, a second media gateway 520 with a similar URL or IP address can be selected. The media gateway controller 130 can then assign a second media gateway 520 to serve a remote subset of participants, thereby reducing the number of packets that must traverse a portion of the IP network 106. For example, the number is 10/137,137 and the title is "Method and Apparatus for Placing a Dispatch The US patent application "Call" describes a method for distributing data packets to a remote subset of participants. This patent application is assigned to the assignee of the present invention and is fully integrated herein by reference.

In the communication system 500, when a communication session including the communication devices 111-114 is established, the media gateway controller 130 assigns the media gateway 120 IP address/port combination to each of the node 101, the node 102, and the media gateway 520, and The media gateway 120 is notified of the allocated address/port combination. The media gateway controller 130 also notifies the media gateway 120 of the binding of each assigned address/port combination of the media gateway 120 with the IP address and port of the corresponding node or media gateway. The media gateway controller associated with the media gateway 520 (ie, the first media gateway controller 130 or the second media gateway controller 530) also allocates the media gateway 520 to each of the node 103, the node 104, and the media gateway 120. The IP address/port combination, and the assigned address/port combination is notified to the media gateway 520. The media gateway controller associated with the media gateway 520 also notifies the media gateway 520 of the binding of each assigned media gateway 520 address/port combination with the IP address and port of the corresponding node or media gateway.

When the RTP data packet is routed by the first media gateway 120 to each of the communication devices 113 and 114 through the nodes 103 and 104, a single version of the packet can be routed by the first media gateway 120 to the second media gateway 520. The media gateway 520 makes a copy of the received RTP packet to send to each participating node (ie, nodes 103 and 104) bound to the address/port combination of the media gateway 520, and passes the duplicate RTP data packet through the corresponding node of the device 103, 104 are routed to each communication device 113, 114.

By allocating the second media gateway 520 to serve multiple nodes suffering the same incompatibility, the communication system 500 effectively facilitates incompatible nodes to participate in the exchange of RTP floor control messages as a multi-participant communication session. In addition, by allocating the second media gateway 520 to serve multiple nodes adjacent to the second media gateway, the communication system 500 reduces the number of packets that must traverse a part of the IP network 106, thereby providing RTP floor control messages traversing the network 106. Efficient distribution. The result is an efficient and high-speed voice control process. The voice control protocol is transparent to the underlying network and equipment, and the equipment imposes minimal additional overhead on the implementation of the communication system.

Although the present invention is shown and described with particular reference to its specific embodiments, those skilled in the art will understand that various changes can be made or equivalents can be substituted for its components without departing from the scope of the present invention as defined in the claims. Accordingly, the specification and drawings should be regarded as expressive rather than restrictive, and all such modifications and substitutions are intended to be included in the scope of the present invention.

The benefits, other advantages, and solutions to problems have been described above with reference to specific embodiments. However, benefits, advantages, solutions to problems, and any one or more components that can cause any benefits, advantages, or solutions to occur or become more significant shall not be construed as decisive and necessary for any claim , Or essential characteristics or components. As used herein, the term "comprising" or any variation thereof is intended to cover non-exclusive inclusion, so that a process, method, article, or device that includes a series of components includes not only the listed components, but also includes not specifically Listed or other components inherent to the process, method, article, or equipment.