DE102004040024B4 - A communication system, method for operating a communication system, server, method for operating a server, push-to-talk client unit, and method for operating a push-to-talk client unit - Google Patents

Abstract

Communication system comprising a server (106) and more than two push-to-talk-over-cellular client units (101, 102, 103), wherein - the push-to-talk-over-cellular client units participate in push-to-talk-over-cellular communication by means of a push-to-talk-over-cellular subscriber server (105); A first push-to-talk-over-cellular client unit has a human-machine interface for selecting a second push-to-talk-over-cellular client unit and selecting a mute deactivation request Function of the first push-to-talk over-cellular client unit by a user of the first push-to-talk-over-cellular client unit, thus giving the user the first push to talk over-cellular Client unit is allowed to listen to another push-to-talk-over-cellular subscriber for a current transmission of voice data in a current push-to-talk-over-cellular communication, if the further push-to -talk-over-cellular-participant has activated mute; The first push-to-talk-over-cellular client unit (101) has a message generation unit that is configured to generate first messages, which first messages contain request information, that specify, on the one hand, that information that specifies whether the second push-to-talk-over-cellular client unit (102) is sending the voice data to the second push-to-talk-over-cellular client unit (102) as part of the push to talk Over-cellular communication is allowed to be transmitted to the first push-to-talk-over-cellular client unit (101), in which case the first message is set up as a mute info request message ...

Description

The invention relates to a communication system, a method for operating a communication system, a server, a method for operating a server, a push-to-talk client unit and a method for operating a push-to-talk client unit.

The push-to-talk-over-cellular (PoC) communication service allows a user of a mobile subscriber device to simultaneously transmit voice data to one or more recipients.

For this purpose, a special PoC key is typically provided on the mobile radio user equipment, after the operation of which the user can start to speak voice data.

The voice data are usually already distributed during the speech by means of a mobile communication network, that is transmitted to the desired recipient or receivers. This process is called streaming.

The transmission takes place in the half-duplex method, that is to say that during the speech and during the transmission only the transmitter, that is to say the user who interprets and transmits the voice data, can transmit voice data to the receivers, but the receivers do not simultaneously transmit voice data can send to the sender. In particular, the transmitter can not be interrupted by the receivers.

Clearly, communication by means of PoC from the user's point of view corresponds to the conventional CB radio, but with the extension that the transmitter can transmit voice data to receivers which can be reached by means of the suitable switching technology of at least one mobile radio communication network.

If a user of PoC wishes to send more voice messages to the same recipients, PoC will allow him to define personal, fixed user groups. For example, a user of PoC may define a group named "Friends" that has corresponding members and their respective addresses, for example, a Session Initiation Protocol Uniform Resource Locator (SIP) URL in the form of a telephone number or in the form of a SIP address ,

This group can then be assigned its own group address in the form of a SIP URL and when establishing a PoC communication, ie a communication session using PoC, specifying the group address that is initiated by a user, all members of the group of addressed to a PoC server and invited to the PoC communication.

The prerequisite for being able to invite a member of the group is that the member is registered in the mobile communication network by which the used PoC is provided, that is, "online".

Users of PoC active in a PoC communication, that is, as a sender, or passive, that is, as a receiver, are referred to hereinafter as a PoC subscriber of PoC communication.

Currently, standardization work to standardize the PoC communication service in the context of the PS (packets-switched, ie packet-switched) domain of UMTS (Universal Mobile Telecommunications System) communication systems and / or in the PS domain GPRS (General Packet Radio Service) of GSM (Global System for Mobile Communication) communication systems. This standardization work takes place within the standardization committees OMA (Open Mobile Alliance) and 3GPP (3rd Generation Partnership Project). The protocols used in these standardization work are partly defined in the standardization bodies of the IETF (Internet Engineering Task Force).

It is envisaged that PoC will be realized inter alia on the basis of IMS (Internet Protocol based Multimedia Subsystem) communication systems in which the signaling protocol SIP (Session Initiation Protocol) and its extensions is used.

A PoC subscriber can set by means of a PoC server that the PoC subscriber in the context of a PoC communication no voice data to be sent by a sender, for example, because the PoC participant is currently talking to a colleague and not wanting to be disturbed. The PoC Participants, however, continue to be a participant in the (or more than one) PoC communications) and will be managed as such.

This feature of PoC is called in OMA "Deactivate incoming talk bursts" or "media on hold", but here briefly referred to as "Mute".

It is envisaged that a PoC subscriber will have a single PoC communication. switches to mute (activated mute), that is, that no more voice data is sent to the PoC subscriber in the context of this PoC communication, or that the PoC subscriber can turn on a global mute, that is, the PoC subscriber in the frame All PoC communications in which the PoC participant is involved no longer send voice data.

In the publications [1], [2], [3] and [4] the SIP (Session Initiation Protocol) is described.

Reference [5] describes the RTP (Real-Time Transport Protocol).

WO 02/089501 A1 describes a PoC communication system in which a user can put a group communication session on hold and answer another incoming call.

The invention is based on the problem of enabling a more effective use of push-to-talk, in particular push-to-talk-over-cellular (PoC).

The problem is solved by a communication system, a method for operating a communication system, a server and a push-to-talk client unit having the features according to claims 1, 8 to 10.

Further provided is a method of operating a communication system, a server, and a push-to-talk client unit according to the communication system described above.

Illustratively, in the provided communication system, the first push-to-talk unit may request the information as to whether the second push-to-talk unit is receiving voice data sent to it as part of the push-to-talk communication, or whether the second push-to-talk unit is muted as part of push-to-talk communication. Furthermore, the first push-to-talk unit can clearly ask that the second push-to-talk unit is not muted during push-to-talk communication.

Clearly, the invention extends push-to-talk and enables features that significantly increase the convenience of using push-to-talk.

An extension is vividly in enabling a Mute-Info request, that is vividly spoken and in the case of PoC, that a PoC participant can be informed about whether another PoC participant has activated Mute in the context of a PoC communication that is, whether the other PoC subscriber allows voice data to be sent as part of the PoC communication.

Thus, a speaking PoC participant thus not only knows which other PoC participants are currently participating in the PoC communication, but also what other PoC participants have not activated mute at the moment and thus are actually listening to it. This has the considerable advantage that a speaking PoC participant also experiences when no one listens to him and it is therefore useless to continue speaking.

A further extension is vividly in enabling a mute-off request, that is, descriptive spoken and in the case of PoC that each PoC participant of a PoC communication another PoC participant who has activated in a PoC communication mute that is, it is not allowed that in the context of PoC communication voice data is sent to him, may ask to disable mute, that is, to allow voice data to be sent to him in the context of PoC communication.

This makes it vividly possible for a PoC subscriber, another PoC subscriber, for whom a momentary transmission of voice data, for example a discussion or a particular to him directed information, in an ongoing PoC communication is important to ask to listen, if the other PoC participant Mute has activated.

By using a Mute Info request, a user can make meaningful use of mute-off requests.

Preferred developments of the invention will become apparent from the dependent claims. The other embodiments of the invention, which are described in connection with the communication system, apply mutatis mutandis to the method for operating a communication system, the server, the method for operating a server, the push-to-talk client unit and the method of operation a push-to-talk client unit.

It is preferred that the request information specify whether information specifying whether the second push-to-talk client unit transmits voice data to the second push-to-talk client unit as part of the push-to-talk talk-communication allows, at each change from allowing to deny and / or denial, the transmission of voice data to the second push-to-talk client unit as part of the push-to-talk communication, or only once to the first push-to-talk client unit to be transferred.

Clearly (and in the case of PoC), a PoC participant can thus choose to be informed only once if the other PoC participant has switched Mute on or off, ie activated or not activated Mute, or if he always wants to be notified when the other PoC subscriber Mute turns on or off.

It is further preferred that the processing means is arranged, according to the request information, at each change from allowing to disallow and / or from disallowing to allow the transmission of voice data to the second push-to-talk client unit in the push-to -talk communication or one-time information that specifies whether the second push-to-talk client unit is transmitting voice data to the second push-to-talk client unit as part of push-to-talk communication allowed to transfer to the first push-to-talk client unit.

Preferably, the second push-to-talk client unit comprises a display device, which in accordance with the third message indicates to the user of the second push-to-talk client unit that the second push-to-talk client unit is requested is to allow the transmission of voice data to the second push-to-talk client unit in the context of push-to-talk communication.

Illustratively, the user of the second push-to-talk client unit is thus informed that another user, namely the user of the first PoC client unit, wishes the user to use the second push-to-talk client device. Unit in the context of push-to-talk communication mute disabled. In one embodiment, the user of the second push-to-talk client unit may then decide whether to disable mute.

It is preferred that the second push-to-talk client unit has a signaling device that is set up to transmit an acknowledgment message to the first push-to-talk client unit.

The confirmation message could, for example, be configured according to a SIP INFO message, a SIP MESSAGE message or according to an RTCP packet.

Clearly, by means of the confirmation, the first PoC client unit can be informed that the second PoC client unit has received the request to the second PoC client unit, Mute, and / or has followed the request Mute has been disabled and / or the request has been rejected, that is, Mute has not disabled. In particular, the user of the first PoC client unit can be informed, for example, that the second PoC client unit has deactivated mute or has not deactivated mute (despite the request).

It is further preferred that the first message and / or the second message and / or the third message according to SIP or RTP / RTCP are designed.

Preferably, according to a SIP SUBSCRIBE message, a SIP INFO message, a SIP MESSAGE message or an RTCP packet, the first message is the second message according to a SIP NOTIFY message, a SIP INFO message, a SIP MESSAGE message or an RTCP packet and / or configured the third message according to a SIP INFO message, a SIP MESSAGE message or an RTCP packet.

It is preferred that in the case of the embodiment of the first message and / or the second message and / or the third message according to SIP, the respective message has data in XML (extended markup language) format.

Thus, the respective message clearly contains a part of the data contained in it in XML format.

Embodiments of the invention are illustrated in the figures and are explained in more detail below.

1 shows a communication system according to an embodiment of the invention.

2 shows a message flow diagram according to an embodiment of the invention.

3 shows a message flow diagram according to another embodiment of the invention.

4 shows a message flow diagram according to another embodiment of the invention.

5 shows a message flow diagram according to another embodiment of the invention.

6 shows a message flow diagram according to another embodiment of the invention.

7 shows a message flow diagram according to another embodiment of the invention.

1 shows a communication system 100 according to an embodiment of the invention.

A first PoC client unit 101 , a second PoC client unit 102 and a third PoC client unit 103 are each using an interface 104 each with a PoC subscriber server (PoC server Participant Function) 105 coupled. The PoC subscriber servers 105 are with a PoC control server (PoC server controlling function) 106 coupled.

The PoC control server 106 is in this example with a group management server 107 coupled. The functionality of the group management server 107 can be the PoC control server 106 but also have yourself.

The interfaces 104 are used, for example, by the RAN (Radio Access Network), the Core Network (CN) and the Internet Protocol Based Multimedia Subsystem (IMS) of a UMTS (Universal Mobile Telecommunication System) communication system or a GSM (Global System for Mobile Communication), Communication system provided.

The interfaces 104 however, they may also be provided, for example, by means of a PSTN (Public Switched Telephone Network) communication network.

The PoC client units 101 . 102 . 103 are each in a mobile communication terminal, according to the respective interface 104 for example, is set up for communication according to the UMTS standard, the GSM standard, the GPRS (General Packet Radio Service) standard or another mobile communication standard.

2 shows a message flow diagram 200 according to an embodiment of the invention.

The illustrated message flow takes place between a first PoC client unit 201 (PoC Client A), a first PoC subscriber server 202 (PoC Server A), a PoC control server 203 (PoC Server X), a second PoC subscriber server (PoC Server B) 204 and a second PoC client unit 205 (PoC Client B) instead, analogous to 1 are arranged and configured.

The first PoC client unit 201 and the first PoC subscriber server 202 are part of a first home network 230 , which is the home network of the first PoC client unit 201 is. The second PoC client unit 205 and the second PoC subscriber server 204 are part of a second home network 206 , which is the home network of the second PoC client unit 205 is.

The home network 230 . 206 a PoC client unit 201 . 205 is the communication network by means of which the user information about the user of the PoC client unit 201 . 205 are stored.

The PoC control server 203 is part of a control network 207 ,

It is assumed that the first PoC client unit 201 and the second PoC client unit 205 (or the respective users) by means of the first PoC subscriber server 202 , the second PoC subscriber server 204 and the PoC control server 203 participate in a PoC communication.

The following is the flow of a mute-info query by the first PoC client unit 201 explained.

Under Mute Info Query is the request for information by the first PoC client unit 201 about the mute status of other PoC client devices 201 in this example the second PoC client unit 205 , to understand.

The mute status of a PoC client unit in a PoC communication may be that the PoC client unit has mute turned on, that is, in the context of PoC communication, no voice data is sent to the PoC client unit or that the PoC client unit has not turned on mute, that is, voice data is sent to the PoC client unit as part of the PoC communication.

In step 208 the user selects the first PoC client unit 201 the Mute-Info function, ie the function for a Mute-Info request, by MMI (Man Machine Interface, man-machine interface), for example, by corresponding actuation of a keyboard of the first PoC client unit 201 ,

In step 209 sends the first PoC client unit 201 a first Mute_Info_REQ message 216 to the first PoC subscriber server 202 ,

In step 210 derives the first PoC subscriber server 202 the first Mute_Info_REQ message 216 to the PoC control server 203 further.

Using the first Mute_Info_REQ message 216 the user requests the first PoC client unit 201 a list of the mute states of all other participants, ie each participating PoC client unit except the first PoC client unit 201 or the corresponding user, the PoC communication, to which the first PoC client unit 201 involved. That is, it requests a list containing for each other user of the PoC communication the information as to whether the user has switched the PoC communication to Mute, that is to say that no voice data is transmitted to the subscriber in the course of the PoC communication or whether the subscriber has not switched the PoC communication to mute, that is, that the subscriber voice data in the context of PoC communication are transmitted.

In step 211 the PoC control server starts 203 creating a list of the mute states of all other PoC communication participants.

In this example, it is assumed that only another subscriber of the PoC communication, namely the user of the second PoC client unit 205 , is available. The sequence with several other participants is analog.

To create the list sends the PoC control server 203 a second Mute_Info_REQ message 218 in step 212 to the second PoC subscriber server 204 ,

He answers in step 213 by submitting a Mute_Info_RES message 219 to the PoC control server 203 which Mute_Info_RES message 219 the mute status of the second PoC client unit 205 contains.

Once the PoC control server 203 All the required information about the mute statuses of the other subscribers is sent by the PoC control server 203 a Mute_Info_RES message 220 in step 214 to the first PoC subscriber server 202 containing the list of mute statuses of all other participants.

In step 215 becomes the Mute_Info_RES message 220 to the first PoC client unit 201 forwarded.

This will be the first PoC client unit 201 informed about the mute statuses of all participants.

In another embodiment, the user asks the first PoC client unit 201 using the first Mute_Info_REQ message 216 not only the current mute statuses of the other participants, but signals that he wants to be informed about any change in the mute statuses of the other participants. In this embodiment, the PoC control server sends 203 analogous to step 214 and step 215 upon a change in the mute status of any other party, that is, any party other than the first PoC client entity 201 , a Mute_Info_RES message 220 containing the corresponding information.

The following are two examples of reference to 2 explained general message flow for a Mute Info request.

3 shows a message flow diagram 300 according to a further embodiment of the invention.

The units involved in the presented message flow 301 to 305 and the communication networks involved in the message flow 306 . 307 and 330 are analogous to 2 furnished and designed.

The following example of a Mute Info Request will include the Mute_Info_REQ messages 216 . 218 realized in the form of SIP SUBSCRIBE messages according to the SIP (Session Initiation Protocol).

The SIP and the SIP messages used are described in [1], [2], [3] and [4].

In step 309 sends the first PoC client unit 301 according to step 209 a Subscribe message 322 to the first PoC subscriber server 302 which the subscribe message 323 in step 310 to the PoC control server 303 forwards.

Tabelle 1 The Subscribe message 322 is designed, for example, according to Table 1.

Table 1

In this example, it is assumed that by means of the Subscribe message 322 it is requested that the user of the first PoC client unit 301 is informed of any change in the mute statuses of other PoC communication participants.

This information is given in this example by means of the message header field named Event (see line 5 of Table 1).

Illustratively, the user subscribes to an event package called poc_mute_info.

According to the SIP, the PoC control server sends 303 in step 311 a first confirmation message (OK message) 323 to the PoC subscriber server 302 which is the first confirmation message 323 to the first PoC client unit 301 in step 312 forwards.

According to step 211 starts the PoC control server 303 in step 313 with creating a list of the mute states of all other participants. According to step 212 sends the PoC control server 303 a second Subscribe message 324 in step 314 to the second subscriber server 304 , In step 315 confirms the second PoC subscriber server 304 the receipt of the Subscribe message 324 by means of a second confirmation message 325 ,

In step 316 shares the second PoC subscriber server 304 by means of a first notification message 326 the PoC control server 303 the mute status of the second PoC client unit. In step 317 confirms the PoC control server 303 the receipt of the first notification message 326 by means of a third confirmation message 327 ,

According to step 316 sends the PoC control server 303 in step 318 a second notification message 328 to the first PoC subscriber server 302 which is the second notification message 328 in step 319 to the first PoC client unit 301 forwards.

The second notification message 328 contains the from the PoC control server 303 in step 313 created list with the mute states of all other participants.

In step 320 confirms the first PoC client unit 301 the receipt of the second notification message 328 by means of a fourth confirmation message 329 which in step 321 from the first PoC subscriber server 302 to the PoC control server 303 is forwarded.

Tabelle 2 The second notification message 328 is designed, for example, according to Table 2, in which the list of the mute states of all other participants is inserted as an XML document.

Table 2

The second notification message 328 In this example, it is configured as a SIP NOTIFY message and, in this example, is changed whenever the mute status of any other subscriber is changed by means of the first PoC subscriber server 302 to the first PoC client unit 301 transmitted.

The first notification message 326 is also configured as a SIP NOTIFY message, in which, however, only the Mute status of the client B is inserted as an XML document (according to Table 2 without the lines 16 to 21).

The following is another example of a Mute Info request.

4 shows a message flow diagram 400 according to a further embodiment of the invention.

The units involved in the presented message flow 401 to 405 and the communication networks involved in the message flow 406 . 407 and 430 are analogous to 2 furnished and designed.

The processing step 408 to 415 are also analogous to 2 designed.

Tabelle 3 However, in this example, the first Mute_Info_REQ message is 216 and the second Mute_Info_REQ message 218 according to an application-defined RTCP packet (application-defined real-time control protocol packet, APP), as described in [5], for example according to Table 3.

Table 3

In this case, the value of the subtype parameter is selected as a value that is specific to this message type and has not yet been assigned otherwise.

The first Mute_Info_REQ message designed in this way 216 and second Mute_Info_REQ message 218 be the first RTP: APP: Mute_info_req message 416 or second RTP: APP: Mute_info_req message 418 designated.

Tabelle 4 The second Mute_Info_RES message 220 is designed in this example according to Table 4.

Table 4

The first Mute_Info_RES message 219 is designed, for example, according to Table 5.

Tabelle 5

Table 5

The configured according to Table 4 Mute_Info_RES message 220 contains an indication of all other participants that Mute is activated, ie turned on (see Table 4, line 6).

The specification of the PoC subscribers who have activated mute is made by means of the parameters CNAME and NAME (see line 6 table 4) whose meaning is defined in [5].

In another embodiment, the Mute_Info_RES message contains 220 a specification of all other participants with their respective mute status.

The value of the subtype parameter, as above, should be a message type specific value not yet otherwise assigned.

The configured according to Table 4 second Mute_Info_RES message 220 and also according to RTP / RTCP (Real-time Transport Protocol / Realtime Control Protocol) configured first Mute-Info-RES message 219 be considered second RTP: APP: Mute_info_res message 420 or as the first RTP: APP: Mute_info_res message 419 designated.

In this embodiment, the second RTP: APP: Mute_info_res message 420 directly in response to a Mute Info request using the first RTP: APP: Mute_info_req message 416 and any change in the mute status of any other participant.

In the following, the message flow during a mute-off request is explained, that is to say when a first PoC client unit requests to a second PoC client unit, with the request that the second PoC client unit mute in the context the PoC communication switches off.

5 shows a message flow diagram 500 according to a further embodiment of the invention.

The communication network elements involved in the message flow 501 to 505 and the involved communication networks 506 . 507 and 530 are analogous to 2 arranged and designed.

As above, it is assumed that the first PoC client unit 501 and the second PoC client unit 505 (or the respective users) by means of the first PoC subscriber server 502 , the second PoC subscriber server 504 and the PoC control server 503 participate in a PoC communication.

In step 508 the user selects the first PoC client unit 501 via MMI the user of the second PoC client unit 505 and the mute-off request function of the first PoC client unit 501 out.

In step 509 sends the first PoC client unit 501 a Mute_Off_REQ message 517 to the first PoC subscriber server 502 that is the Mute_Off_REQ message 517 in step 510 to the PoC control server 503 forwards.

The PoC control server 503 directs the Mute_Off_REQ message 517 in the steps 511 and 512 by means of the second PoC subscriber server 504 to the second PoC client unit 505 further.

The user of the second PoC client unit 505 will be displayed indicating that a mute-off request has been sent to him and he is asked to turn mute off.

The user of the second PoC client unit 505 can now react accordingly, that is Mute off or Mute continue to be turned on.

In this example, it is assumed that the user is the second PoC client unit 505 terminates its mute state, that is mute off, for example by means of a corresponding message to the second PoC subscriber server 504 ,

The second PoC client unit 505 Now sends a confirmation that it is the Mute_Off_REQ message 517 received an Mute_Off_ACK message 518 in step 513 that in the steps 514 . 515 and 516 by means of the second PoC subscriber server 504 , the PoC control server 503 and the first PoC subscriber server 502 to the first PoC client unit 501 is forwarded.

Sending the Mute_Off_ACK message 518 is optional or not performed in another embodiment.

In one embodiment, the second PoC client unit sends 505 analogous to the Mute_Off_ACK message 518 a message to the first PoC client unit 501 , which signals whether the second PoC client unit 505 (according to the user's decision) Mute has turned off.

In the following, two examples of the procedure for a mute-off request are explained.

6 shows a message flow diagram 600 according to a further embodiment of the invention.

The communication network elements involved in the message flow 601 to 605 and the involved communication networks 606 . 607 and 630 are analogous to 5 arranged and designed.

The processing steps 609 to 616 become analogous to 5 carried out.

Tabelle 6 In this example, the Mute_Off_REQ message is 517 designed according to a SIP INFO message, for example according to Table 6.

Table 6

By means of the character string "application / poc-mute_off_req" (see line 7 of Table 6) contained in the message header field (header) with the name Content-Type, it is indicated that by means of the message thus configured, the message message 617 a mute-off request is made.

In another embodiment, the Mute_Off_REQ message becomes 517 realized by means of a SIP MESSAGE message.

In another embodiment, depending on the implementation, the Mute_Off_REQ message is configured as a SIP INFO message or as a SIP MESSAGE message 517 another message body in the form of an XML document, the information of the Mute_Off_REQ message 517 contains.

The Mute_Off_ACK message 518 is configured in accordance with a SIP 200OK message and is displayed as an OK message 618 designated.

As mentioned, in one embodiment, the second PoC client unit sends 505 analogous to the Mute_Off_ACK message 518 a message to the first PoC client unit 501 , which signals whether the second PoC client unit 505 (according to the user's decision) Mute has turned off.

This (for example, optional) confirmation message based on a user interaction in the MMI by the user of the second PoC client unit 505 is designed, for example, according to Table 7.

Tabelle 7 A user interaction of the user is, for example, a "mute off" command of the user to switch off mute or a "mute_off_req reject" command of the user to reject the request to deactivate mute.

Table 7

In this example, the string value = "accepted" indicates that the second PoC client unit 505 the mute-off request, ie the request to deactivate mute.

For example, the string value = "rejected" could indicate that the user of the second PoC client unit 505 the mute-off call was not followed up. In that case, for example, an area called <reason> could be used, by which the user of the second PoC client unit 505 the first PoC client unit 501 give a justification why he does not follow the mute-off request, for example by using the string "Not possible at the moment because I'm in an important meeting".

7 shows a message flow diagram 700 according to a further embodiment of the invention.

The communication network elements involved in the illustrated message flow 701 to 705 and the communication networks involved in the message flow 706 . 707 and 730 are analogous to 5 furnished and arranged.

The processing steps 708 to 716 become appropriate 5 carried out.

In this example, the execution and processing of a mute-off request is performed using RTP / RTCP (Real-time Transport Protocol / Real-time Control Protocol).

Tabelle 8 The Mute_Off_REQ message 517 is realized by means of an application-defined RTCP packet (application-defined RTCP packet, APP), and is designed, for example, according to Table 8.

Table 8

The value of the subtype parameter should be a message type-specific value that has not yet been assigned otherwise, analogous to the above.

The Mute_Off_REQ message configured in this way 517 is called RTP: APP: Mute_Off_req message 717 designated.

Tabelle 9 The Mute_Off_ACK message 518 is configured in a similar manner according to Table 9.

Table 9

The value subtype should, as above, be a value that has not yet been assigned otherwise and is specific to this message type.

The so configured Mute_Off_ACK message 518 is called RTP: APP: Mute_Off_res message.

Tabelle 10 A (possibly optional) message signaling by whether the second PoC client unit 705 (after the user's decision) Mute has been turned off, is configured according to Table 10 in this embodiment.

Table 10

The value subtype should, as above, be a value that has not yet been assigned otherwise and is specific to this message type.

• [1] RFC 3261 – SIP: Session Initiation Protocol
• [2] RFC 3428 – Session Initiation Protocol (SIP) Extension for Instant Messaging
• [3] RFC 3265 – Session Initiation Protocol(SIP)-Specific Event Notification
• [4] RFC 2976 – The SIP INFO Method
• [5] RFC 3550 – RTP: A Transport Protocol for Real-Time Applications

This document cites the following publications:

• [1] RFC 3261 - SIP: Session Initiation Protocol
• [2] RFC 3428 - Session Initiation Protocol (SIP) Extension for Instant Messaging
• [3] RFC 3265 - Session Initiation Protocol (SIP) -Specific Event Notification
• [4] RFC 2976 - The SIP INFO Method
• [5] RFC 3550 - RTP: A Transport Protocol for Real-Time Applications

LIST OF REFERENCE NUMBERS

100

communication system

101-103

PoC client unit

104

interface

105

PoC subscriber server

106

PoC control server

107

Group management server

200

Message flow diagram

201

PoC client unit

202

PoC subscriber server

203

PoC control server

204

PoC subscriber server

205

PoC client unit

206

Home Network

207

Control network

208-215

processing steps

216

message

218-220

news

230

Home Network

300

Message flow diagram

301

PoC client unit

302

PoC subscriber server

303

PoC control server

304

PoC subscriber server

305

PoC client unit

306

Home Network

307

Control network

308-321

processing steps

322-329

news

330

Home Network

400

Message flow diagram

401

PoC client unit

402

PoC subscriber server

403

PoC control server

404

PoC subscriber server

405

PoC client unit

406

Home Network

407

Control network

408-415

processing steps

416

message

418-420

news

430

Home Network

500

Message flow diagram

501

PoC client unit

502

PoC subscriber server

503

PoC control server

504

PoC subscriber server

505

PoC client unit

506

Home Network

507

Control network

508-516

processing steps

517, 518

news

530

Home Network

600

Message flow diagram

601

PoC client unit

602

PoC subscriber server

603

PoC control server

604

PoC subscriber server

605

PoC client unit

606

Home Network

607

Control network

608-616

processing steps

617, 618

news

630

Home Network

700

Message flow diagram

701

PoC client unit

702

PoC subscriber server

703

PoC control server

704

PoC subscriber server

705

PoC client unit

706

Home Network

707

Control network

708-716

processing steps

717, 718

news

730

Home Network

Claims (10)

Communication system that has a server ( 106 ) and more than two push-to-talk-over-cellular client units ( 101 . 102 . 103 ), wherein - the push-to-talk-over-cellular client units each using a push-to-talk-over-cellular subscriber server ( 105 ) participate in a push-to-talk-over-cellular communication; A first push-to-talk-over-cellular client unit has a human-machine interface for selecting a second push-to-talk-over-cellular client unit and selecting a mute deactivation request Function of the first push-to-talk over-cellular client unit by a user of the first push-to-talk-over-cellular client unit, thus giving the user the first push to talk over-cellular Client unit is allowed to listen to another push-to-talk-over-cellular subscriber for a current transmission of voice data in a current push-to-talk-over-cellular communication, if the further push-to -talk-over-cellular-participant has activated mute; - the first push-to-talk-over-cellular client unit ( 101 ) comprises a message generation unit configured to generate first messages containing first messages request information, - specifying that information specifying whether the second push-to-talk-over-cellular client unit ( 102 ) transmitting voice data to the second push-to-talk-over-cellular client unit ( 102 ) as part of the push-to-talk-over-cellular communication, to the first push-to-talk-over-cellular client unit ( 101 ), in which case the first message is set up as a Mute Info Request message; and - which, on the other hand, specify that the second push-to-talk-over-cellular client unit ( 102 ) transmitting voice data to the second push-to-talk-over-cellular client unit ( 102 in the context of push-to-talk-over-cellular communication, in which case the first message is set up as a mute deactivation request message; and which is set up the first messages by means of the push-to-talk-over-cellular subscriber server ( 105 ) of the first push-to-talk-over-cellular client unit ( 101 ) to the server ( 106 ), - the server ( 106 ) comprises processing means arranged according to the request information - information specifying whether the second push-to-talk-over-cellular client unit ( 102 ) transmitting voice data to the second push-to-talk-over-cellular client unit ( 102 ) as part of the push-to-talk-over-cellular communication, to determine and by means of a first transmitting device and by means of a second message to the first push-to-talk client-over-cellular unit ( 101 ) by means of their push-to-talk-over-cellular subscriber server ( 105 ) transferred to; and to generate a third message and, by means of a second transmitting device, to the second push-to-talk-over-cellular client unit ( 102 ) by means of their push-to-talk-over-cellular subscriber server ( 105 ), by means of which third message the second push-to-talk-over-cellular client unit ( 102 ), the sending of voice data to the second push-to-talk-over-cellular client unit ( 102 ) in the context of push-to-talk-over-cellular communication; - wherein the second push-to-talk-over-cellular client unit has a human-machine interface for indicating, upon receipt of the third message, that a mute-disable request is being sent to the second push-to-talk Client unit has been submitted and the user is the second push-to-talk-over-cellular client Unit is asked to design the sending of voice data to the second push-to-talk-over-cellular client unit. The communication system of claim 1, wherein the request information specifies whether information specifying whether the second push-to-talk-over-cellular client unit transmits voice data to the second push-to-talk-over-cellular client Unit as part of the push-to-talk-over-cellular communication, when switching from allowing to denial and / or denial to allowing the transmission of voice data to the second push-to-talk-over-cellular client Unit as part of the push-to-talk-over-cellular communication or only once to be transmitted to the first push-to-talk-over-cellular client unit. The communication system according to claim 2, wherein the processing means is arranged according to the request information at each change from allowing to disallowing and / or disallowing to transmitting the voice data to the second push-to-talk-over-cellular client unit in the frame the push-to-talk-over-cellular communication, or just one-time information that specifies whether the second push-to-talk-over-cellular client unit is transmitting the voice data to the second push-to-talk over Cellular client unit under the push-to-talk-over-cellular communication allowed to transfer to the first push-to-talk-over-cellular client unit. A communication system according to any one of claims 1 to 3, wherein the second push-to-talk-over-cellular client unit comprises signaling means arranged to send, in response to the third message, a confirmation message to the first push-to-talk to transmit over-cellular client unit. Communication system according to one of claims 1 to 4, wherein the first message and / or the second message and / or the third message according to SIP or according to RTP / RTCP are designed. Communication system according to claim 5, wherein the first message according to a SIP SUBSCRIBE message, a SIP INFO message, a SIP MESSAGE message or an RTCP packet, the second message according to a SIP NOTIFY message, a SIP INFO message, a SIP MESSAGE message or an RTCP packet and / or the third message according to a SIP INFO message, a SIP MESSAGE message or an RTCP packet is configured. Communication system according to one of claim 5 or 6, wherein, in the case of the embodiment of the first message and / or the second message and / or the third message according to SIP, the respective message data in XML format. Method for operating a communication system, which communication system uses a server ( 106 ) and more than two push-to-talk-over-cellular client units ( 101 . 102 . 103 ), wherein - the push-to-talk-over-cellular client units each using a push-to-talk-over-cellular subscriber server ( 105 ) participate in a push-to-talk-over-cellular communication; and wherein according to the method - the user of a first push-to-talk-over-cellular client unit uses a human-machine interface of the first push-to-talk-over-cellular client unit to initiate a second push-to Dial-to-talk-over-cellular client unit selects a Mute Disable Request feature of the first push-to-talk-over-cellular client unit, giving the user the first push to talk over -Cellular client unit allows to listen to another push-to-talk-over-cellular subscriber for an instantaneous transmission of voice data in a current push-to-talk-over-cellular communication, if the further push -to-talk-over-cellular-participant has activated mute; - the first push-to-talk-over-cellular client unit ( 101 ) generates first messages containing first message request information, - specifying on the one hand that information specifying whether the second push-to-talk-over-cellular client unit ( 102 ) transmitting voice data to the second push-to-talk-over-cellular client unit ( 102 ) as part of the push-to-talk-over-cellular communication, to the first push-to-talk-over-cellular client unit ( 101 ), in which case the first message is set up as a Mute Info Request message; and - which, on the other hand, specify that the second push-to-talk-over-cellular client unit ( 102 ) transmitting voice data to the second push-to-talk-over-cellular client unit ( 102 in the context of push-to-talk-over-cellular communication, in which case the first message is set up as a mute deactivation request message; and the first messages using the push-to-talk-over-cellular subscriber server ( 105 ) of the first push-to-talk-over-cellular client unit ( 101 ) to the server ( 106 ), - the server ( 106 ) according to the request information from the received first messages - information specifying whether the second push-to-talk-over-cellular client unit ( 102 ) transmitting voice data to the second push-to-talk-over-cellular client unit ( 102 ) in the context of push-to-talk-over-cellular communication, determined and transmitted by means of a first transmission device and by means of a second message to the first push-to-talk client-over-cellular unit ( 101 ) by means of their push-to-talk-over-cellular subscriber server ( 105 ) transmits; and - generates a third message and, by means of a second transmitting device, to the second push-to-talk-over-cellular client unit ( 102 ) by means of their push-to-talk-over-cellular subscriber server ( 105 ) transmits, by means of which third message, the second push-to-talk-over-cellular client unit ( 102 ), the sending of voice data to the second push-to-talk-over-cellular client unit ( 102 ) in the context of push-to-talk-over-cellular communication; - Is displayed by means of a man-machine interface of the second push-to-talk-over-cellular client unit upon receipt of the third message that a mute deactivation request to the second push-to-talk-over The Cellular Client unit has been submitting and the user of the second push-to-talk-over-cellular client unit is being prompted to send voice data to the second push-to-talk-over-cellular client unit allow. Server ( 106 ) of the communication system according to one of claims 1 to 7. Push-to-talk-over-cellular client unit ( 101 . 102 . 103 ) of the communication system according to one of claims 1 to 7.

Images