DE102004040024B4

DE102004040024B4 - Kommunikationssystem, Verfahren zum Betreiben eines Kommunikationssystems, Server, Verfahren zum Betreiben eines Servers, Push-to-talk-Client-Einheit und Verfahren zum Betreiben einer Push-to-talk-Client-Einheit

Info

Publication number: DE102004040024B4
Application number: DE102004040024A
Authority: DE
Inventors: Norbert Schwagmann; Dr. Trauberg Markus; Andreas Schmidt
Original assignee: Intel Mobile Communications GmbH
Current assignee: Intel Deutschland GmbH
Priority date: 2004-08-18
Filing date: 2004-08-18
Publication date: 2013-12-19
Anticipated expiration: 2024-08-19
Also published as: DE102004040024A1

Abstract

Kommunikationssystem, das einen Server (106) und mehr als zwei Push-to-talk-over-Cellular-Client-Einheiten (101, 102, 103) aufweist, wobei – die Push-to-talk-over-Cellular-Client-Einheiten mittels je eines Push-to-talk-over-Cellular-Teilnehmerservers (105) an einer Push-to-talk-over-Cellular-Kommunikation teilnehmen; – eine erste Push-to-talk-over-Cellular-Client-Einheit eine Mensch-Maschine-Schnittstelle aufweist zum Auswählen einer zweiten Push-to-talk-over-Cellular-Client-Einheit und zum Auswählen einer Mute-Deaktivierungs-Anfrage-Funktion der ersten Push-to-talk-over-Cellular-Client-Einheit durch einen Benutzer der ersten Push-to-talk-over-Cellular-Client-Einheit, womit es dem Benutzer der ersten Push-to-talk-over-Cellular-Client-Einheit ermöglich wird, einen weiteren Push-to-talk-over-Cellular-Teilnehmer für eine momentane Übertragung von Sprachdaten in einer laufenden Push-to-talk-over-Cellular-Kommunikation zu bitten zuzuhören, falls der weitere Push-to-talk-over-Cellular-Teilnehmer Mute aktiviert hat; – die erste Push-to-talk-over-Cellular-Client-Einheit (101) eine Nachrichtenerzeugungseinheit aufweist, die eingerichtet ist, erste Nachrichten zu erzeugen, welche ersten Nachrichten Anfrageinformationen enthalten, – die zum einen spezifizieren, dass Informationen, die spezifizieren, ob die zweite Push-to-talk-over-Cellular-Client-Einheit (102) das Übersenden von Sprachdaten an die zweite Push-to-talk-over-Cellular-Client-Einheit (102) im Rahmen der Push-to-talk-over-Cellular-Kommunikation gestattet, an die erste Push-to-talk-over-Cellular-Client-Einheit (101) übertragen werden sollen, in welchem Fall die erste Nachricht als Mute-Info-Anfragenachricht eingerichtet ist ...

Description

Die Erfindung betrifft ein Kommunikationssystem, ein Verfahren zum Betreiben eines Kommunikationssystems, einen Server, ein Verfahren zum Betreiben eines Servers, eine Push-to-talk-Client-Einheit und ein Verfahren zum Betreiben einer Push-to-talk-Client-Einheit.
Der Kommunikationsdienst Push-to-talk-over-Cellular (PoC) ermöglicht es einem Benutzer eines Mobilfunk-Teilnehmergeräts, Sprachdaten an einen oder mehrere Empfänger gleichzeitig zu übermitteln.
Dazu ist typischerweise eine spezielle PoC-Taste an dem Mobilfunk-Teilnehmergerät vorgesehen, nach deren Betätigung der Benutzer mit dem Einsprechen von Sprachdaten beginnen kann.
Die Sprachdaten werden üblicherweise schon während des Einsprechens mittels eines Mobilfunk-Kommunikationsnetzwerks verteilt, das heißt an den oder die gewünschten Empfänger übermittelt. Dieser Vorgang wird als ”streaming” bezeichnet.
Die Übermittlung erfolgt im Halb-Duplex-Verfahren, das heißt, dass während des Einsprechens und während der Übertragung nur der Sender, das heißt der Benutzer, der die Sprachdaten einspricht und versendet, Sprachdaten an die Empfänger übermitteln kann, die Empfänger aber nicht gleichzeitig Sprachdaten an den Sender senden können. Insbesondere kann der Sender nicht von den Empfängern unterbrochen werden.
Anschaulich entspricht eine Kommunikation mittels PoC aus Sicht des Benutzers dem herkömmlichen CB-Funk, jedoch mit der Erweiterung, dass der Sender weltweit an Empfänger, die mittels der geeigneten Vermittlungstechnik mindestens eines Mobilfunk-Kommunikationsnetzwerks erreichbar sind, Sprachdaten übermitteln kann.
Möchte ein Benutzer von PoC öfter Sprachnachrichten an dieselben Empfänger senden, so wird es ihm bei PoC ermöglicht, persönliche, feste Benutzergruppen zu definieren. Beispielsweise kann ein Benutzer von PoC eine Gruppe mit der Bezeichnung ”Freunde” definieren, die entsprechende Mitglieder und deren jeweilige Adresse, beispielsweise eine SIP-URL (Session Initiation Protocol Uniform Resource Locator) in Form einer Telefonnummer oder in Form einer SIP-Adresse, aufweist.
Dieser Gruppe kann dann eine eigene Gruppenadresse in Form einer SIP-URL zugewiesen werden und beim Aufbau einer PoC-Kommunikation, das heißt einer Kommunikations-Session mittels PoC, unter Angabe der Gruppenadresse, die von einem Benutzer initiiert wird, werden alle Mitglieder der Gruppe von einem PoC-Server adressiert und zu der PoC-Kommunikation eingeladen.
Die Voraussetzung dafür, dass ein Mitglied der Gruppe eingeladen werden kann, ist, dass das Mitglied in dem Mobilfunk-Kommunikationsnetzwerk, mittels welchem der genutzte PoC bereitgestellt wird, angemeldet ist, das heißt ”online” ist.
Benutzer von PoC, die in einer PoC-Kommunikation aktiv, das heißt als Sender, oder passiv, das heißt als Empfänger, involviert sind, werden im Folgenden als PoC-Teilnehmer der PoC-Kommunikation bezeichnet.
Derzeit werden Standardisierungsarbeiten zur Standardisierung des PoC-Kommunikationsdienstes im Rahmen der PS(packetswitched, das heißt paketvermittelt)-Domain von UMTS(Universal Mobile Telecommunications System)-Kommunikationssystemen und/oder im Rahmen der PS-Domain GPRS (General Packet Radio Service) von GSM(Global System for Mobile Communication)-Kommunikationssystemen durchgeführt. Diese Standardisierungsarbeiten finden im Rahmen der Standardisierungsgremien OMA (Open Mobile Alliance) und 3GPP (3rd Generation Partnership Project) statt. Die in diesen Standardisierungsarbeiten verwendeten Protokolle werden teilweise in dem Standardisierungsgremien der IETF (Internet Engineering Task Force) definiert.
Es ist vorgesehen, dass PoC unter anderem auch auf Basis von IMS(Internet Protocol based Multimedia-Subsystem)-Kommunikationssystemen realisiert wird, in welchen das Signalisierungsprotokoll SIP (Session Initiation Protocoll) und dessen Erweiterungen verwendet wird.
Ein PoC-Teilnehmer kann mittels eines PoC-Servers einstellen, dass dem PoC-Teilnehmer im Rahmen einer PoC-Kommunikation keine Sprachdaten von einem Sender zugesendet werden, beispielsweise weil der PoC-Teilnehmer sich gerade mit einem Kollegen unterhält und kurzeitig nicht gestört werden will. Der PoC-Teilnehmer bleibt aber weiterhin ein Teilnehmer der (oder auch mehrerer) PoC-Kommunikationen) und wird als solcher geführt.
Dieses Feature von PoC wird bei OMA „Deactivate incoming talk bursts” oder „media an hold” genannt, hier jedoch kurz als ”Mute” bezeichnet.
Es ist vorgesehen, das ein PoC-Teilnehmer eine einzelne PoC-Kommunikation. auf Mute schaltet (Mute aktiviert), das heißt, dass dem PoC-Teilnehmer im Rahmen dieser PoC-Kommunikation keine Sprachdaten mehr gesendet werden, oder dass der PoC-Teilnehmer ein globales Mute einschalten kann, das heißt, dass dem PoC-Teilnehmer im Rahmen aller PoC-Kommunikationen, an denen der PoC-Teilnehmer beteiligt ist, keine Sprachdaten mehr gesendet werden.
In den Druckschriften [1], [2], [3] und [4] ist das SIP (Session Initiation Protocol) beschrieben.
In Druckschrift [5] ist das RTP (Real-Time Transport Protocol) beschrieben.
WO 02/089 501 A1 beschreibt ein PoC-Kommunikationssystem, bei dem ein Benutzer eine Gruppen-Kommunikationssitzung auf ”Halten” setzen kann und einen anderen eingehenden Anruf entgegennehmen kann.
Der Erfindung liegt das Problem zugrunde, eine effektivere Nutzung von Push-to-talk, insbesondere von Push-to-talk-over-Cellular (PoC), zu ermöglichen.
Das Problem wird durch ein Kommunikationssystem, ein Verfahren zum Betreiben eines Kommunikationssystems, einen Server und eine Push-to-talk-Client-Einheit mit den Merkmalen gemäß den Patentansprüchen 1, 8 bis 10 gelöst.
Ferner werden ein Verfahren zum Betreiben eines Kommunikationssystems, ein Server und eine Push-to-talk-Client-Einheit gemäß dem oben beschriebenen Kommunikationssystem bereitgestellt.
Anschaulich kann bei dem bereitgestellten Kommunikationssystem die erste Push-to-talk-Einheit die Information anfordern, ob die zweite Push-to-talk-Einheit Sprachdaten, die im Rahmen der Push-to-talk-Kommunikation an sie gesendet werden empfängt, oder ob die zweite Push-to-talk-Einheit im Rahmen der Push-to-talk-Kommunikation auf stumm geschaltet ist. Ferner kann anschaulich gesprochen die erste Push-to-talk-Einheit darum bitten, dass die zweite Push-to-talk-Einheit im Rahmen der Push-to-talk-Kommunikation nicht auf stumm geschaltet ist.
Anschaulich gesprochen erweitert die Erfindung Push-to-talk und ermöglicht Funktionen, die die Bequemlichkeit der Nutzung von Push-to-talk erheblich erhöhen.
Eine Erweiterung besteht anschaulich in der Ermöglichung einer Mute-Info-Anfrage, das heißt anschaulich gesprochen und im Falle von PoC, dass ein PoC-Teilnehmer sich darüber informieren lassen kann, ob ein anderer PoC-Teilnehmer im Rahmen einer PoC-Kommunikation Mute aktiviert hat, das heißt, ob der andere PoC-Teilnehmer es gestattet, dass im Rahmen der PoC-Kommunikation Sprachdaten ihn gesendet werden.
Anschaulich weiß somit ein sprechender PoC-Teilnehmer nicht nur, welche anderen PoC-Teilnehmer gerade an der PoC-Kommunikation teilnehmen, sondern darüber hinaus auch, welche anderen PoC-Teilnehmer momentan Mute nicht aktiviert haben und ihm somit gerade tatsächlich zuhören. Das hat den erheblichen Vorteil, dass ein sprechender PoC-Teilnehmer auch erfährt, wenn ihm keiner mehr zuhört und es somit sinnlos ist, weiterzusprechen.
Eine weitere Erweiterung besteht anschaulich in der Ermöglichung einer Mute-Off-Anfrage, das heißt anschaulich gesprochen und im Falle von PoC, dass jeder PoC-Teilnehmer einer PoC-Kommunikation einen anderen PoC-Teilnehmer, der im Rahmen einer PoC-Kommunikation Mute aktiviert hat, das heißt es nicht gestattet, dass im Rahmen der PoC-Kommunikation Sprachdaten an ihn gesendet werden, auffordern kann, Mute zu deaktivieren, das heißt es zu gestatten, dass im Rahmen der PoC-Kommunikation Sprachdaten an ihn gesendet werden.
Dies ermöglicht es anschaulich einem PoC-Teilnehmer, einen weiteren PoC-Teilnehmer, für den eine momentane Übertragung von Sprachdaten, beispielsweise eine Diskussion oder eine besonders an ihn gerichtete Information, in einer laufenden PoC-Kommunikation wichtig ist, zu bitten zuzuhören, falls der weitere PoC-Teilnehmer Mute aktiviert hat.
Durch Verwendung einer Mute-Info-Anfrage kann ein Benutzer Mute-Off-Anfragen sinnvoll nutzen.
Bevorzugte Weiterbildungen der Erfindung ergeben sich aus den abhängigen Ansprüchen. Die weiteren Ausgestaltungen der Erfindung, die im Zusammenhang mit dem Kommunikationssystem beschrieben sind, gelten sinngemäß auch das Verfahren zum Betreiben eines Kommunikationssystems, den Server, das Verfahren zum Betreiben eines Servers, die Push-to-talk-Client-Einheit und das Verfahren zum Betreiben einer Push-to-talk-Client-Einheit.
Es ist bevorzugt, dass die Anfrageinformationen spezifizieren, ob Informationen, die spezifizieren, ob die zweite Push-to-talk-Client-Einheit das Übersenden von Sprachdaten an die zweite Push-to-talk-Client-Einheit im Rahmen der Push-to-talk-Kommunikation gestattet, bei jedem Wechsel vom Gestatten zum Nichtgestatten und/oder vom Nichtgestatten zum Gestatten des Übersendens von Sprachdaten an die zweite Push-to-talk-Client-Einheit im Rahmen der Push-to-talk-Kommunikation oder nur einmalig an die erste Push-to-talk-Client-Einheit übertragen werden sollen.
Anschaulich (und im Falle von PoC) kann somit ein PoC-Teilnehmer wählen, ob er nur einmalig darüber informiert werden will, ob der andere PoC-Teilnehmer Mute ein- oder ausgeschaltet hat, das heißt Mute aktiviert oder nicht aktiviert hat, oder ob er immer benachrichtigt werden will, wenn der andere PoC-Teilnehmer Mute einschaltet oder ausschaltet.
Es ist ferner bevorzugt, dass die Verarbeitungseinrichtung eingerichtet ist, gemäß den Anfrageinformationen bei jedem Wechsel vom Gestatten zum Nichtgestatten und/oder vom Nichtgestatten zum Gestatten des Übersendens von Sprachdaten an die zweite Push-to-talk-Client-Einheit im Rahmen der Push-to-talk-Kommunikation oder nur einmalig Informationen, die spezifizieren, ob die zweite Push-to-talk-Client-Einheit das Übersenden von Sprachdaten an die zweite Push-to-talk-Client-Einheit im Rahmen der Push-to-talk-Kommunikation gestattet, an die erste Push-to-talk-Client-Einheit zu übertragen.
Vorzugsweise weist die zweite Push-to-talk-Client-Einheit eine Anzeigeeinrichtung auf, die gemäß der dritten Nachricht dem Benutzer der zweiten Push-to-talk-Client-Einheit anzeigt, dass die zweite Push-to-talk-Client-Einheit aufgefordert wird, das Übersenden von Sprachdaten an die zweite Push-to-talk-Client-Einheit im Rahmen der Push-to-talk-Kommunikation zu gestatten.
Anschaulich wird somit dem Benutzer der zweiten Push-to-talk-Client-Einheit angezeigt, dass ein anderer Benutzer, nämlich der Benutzer der ersten PoC-Client-Einheit, es wünscht, dass der Benutzer der zweiten Push-to-talk-Client-Einheit im Rahmen der Push-to-talk-Kommunikation Mute deaktiviert. In einer Ausführungsform kann der Benutzer der zweiten Push-to-talk-Client-Einheit daraufhin entscheiden, ob er Mute deaktivieren möchte.
Es ist bevorzugt, dass die zweite Push-to-talk-Client-Einheit eine Signalisierungseinrichtung aufweist, die eingerichtet ist, eine Bestätigungsnachricht an die erste Push-to-talk-Client-Einheit zu übermitteln.
Die Bestätigungsnachricht könnte beispielsweise gemäß einer SIP-INFO-Nachricht, einer SIP-MESSAGE-Nachricht oder gemäß einem RTCP-Packet ausgestaltet sein.
Anschaulich kann mittels der Bestätigung die erste PoC-Client-Einheit darüber informiert werden, dass die zweite PoC-Client-Einheit die Anfrage an die zweite PoC-Client-Einheit, Mute zu deaktivieren, empfangen hat und/oder die Anfrage befolgt hat, das heißt Mute deaktiviert hat und/oder die Anfrage abgelehnt hat, das heißt, Mute nicht deaktiviert hat. Insbesondere kann der Benutzer der ersten PoC-Client-Einheit beispielsweise darüber informiert werden, dass die zweite PoC-Client-Einheit Mute deaktiviert hat oder Mute (trotz der Anfrage) nicht deaktiviert hat.
Es ist ferner bevorzugt, dass die erste Nachricht und/oder die zweite Nachricht und/oder die dritte Nachricht gemäß SIP oder gemäß RTP/RTCP ausgestaltet sind.
Vorzugsweise ist die erste Nachricht gemäß einer SIP-SUBSCRIBE-Nachricht, einer SIP-INFO-Nachricht, einer SIP-MESSAGE-Nachricht oder einem RTCP-Packet, die zweite Nachricht gemäß einer SIP-NOTIFY-Nachricht, einer SIP-INFO-Nachricht, einer SIP-MESSAGE-Nachricht oder einem RTCP-Packet und/oder die dritte Nachricht gemäß einer SIP-INFO-Nachricht, einer SIP-MESSAGE-Nachricht oder einem RTCP-Packet ausgestaltet.
Es ist bevorzugt, dass im Falle der Ausgestaltung der ersten Nachricht und/oder der zweiten Nachricht und/oder der dritten Nachricht gemäß SIP, die jeweilige Nachricht Daten in XML(extended markup language)-Format aufweist.
Anschaulich enthält die jeweilige Nachricht also einen Teil der in ihr enthaltenen Daten im XML-Format.
Ausführungsbeispiele der Erfindung sind in den Figuren dargestellt und werden im Weiteren näher erläutert.
1 zeigt ein Kommunikationssystem gemäß einem Ausführungsbeispiel der Erfindung.
2 zeigt ein Nachrichtenflussdiagramm gemäß einem Ausführungsbeispiel der Erfindung.
3 zeigt ein Nachrichtenflussdiagramm gemäß einem weiteren Ausführungsbeispiel der Erfindung.
4 zeigt ein Nachrichtenflussdiagramm gemäß einem weiteren Ausführungsbeispiel der Erfindung.
5 zeigt ein Nachrichtenflussdiagramm gemäß einem weiteren Ausführungsbeispiel der Erfindung.
6 zeigt ein Nachrichtenflussdiagramm gemäß einem weiteren Ausführungsbeispiel der Erfindung.
7 zeigt ein Nachrichtenflussdiagramm gemäß einem weiteren Ausführungsbeispiel der Erfindung.
1 zeigt ein Kommunikationssystem 100 gemäß einem Ausführungsbeispiel der Erfindung.
Eine erste PoC-Client-Einheit 101, eine zweite PoC-Client-Einheit 102 und eine dritte PoC-Client-Einheit 103 sind mittels jeweils einer Schnittstelle 104 mit jeweils einem PoC-Teilnehmerserver (PoC-Server Participant Function) 105 gekoppelt. Die PoC-Teilnehmerserver 105 sind mit einem PoC-Steuerserver (PoC-Server controlling function) 106 gekoppelt.
Der PoC-Steuerserver 106 ist in diesem Beispiel mit einem Gruppen-Management-Server 107 gekoppelt. Die Funktionalität des Gruppen-Management-Servers 107 kann der PoC-Steuerserver 106 jedoch auch selbst aufweisen.
Die Schnittstellen 104 werden beispielsweise mittels des RAN (Radio Access Network), des Kernnetzwerks (Core Network, CN) und des IMS (Internet Protocol based Multimedia Subsystem) eines UMTS(Universal Mobil Telecommunication System)-Kommunikationssystems oder eines GSM(Global System for Mobile Communication)-Kommunikationssystems bereitgestellt.
Die Schnittstellen 104 können aber auch beispielsweise mittels eines PSTN(Public Switched Telephone Network)-Kommunikationsnetzwerks bereitgestellt werden.
Die PoC-Client-Einheiten 101, 102, 103 sind jeweils in einem Mobilfunk-Kommunikationsendgerät, das gemäß der jeweiligen Schnittstelle 104 beispielsweise eingerichtet ist zur Kommunikation gemäß dem UMTS-Standard, dem GSM-Standard, dem GPRS(General Packet Radio Service)-Standard oder einem anderen Mobilfunk-Kommunikationsstandard, integriert.
2 zeigt ein Nachrichtenflussdiagramm 200 gemäß einem Ausführungsbeispiel der Erfindung.
Der dargestellte Nachrichtenfluss findet zwischen einer ersten PoC-Client-Einheit 201 (PoC Client A), einem ersten PoC-Teilnehmerserver 202 (PoC Server A), einem PoC-Steuerserver 203 (PoC Server X), einem zweiten PoC-Teilnehmerserver (PoC Server B) 204 und einer zweiten PoC-Client-Einheit 205 (PoC Client B) statt, die analog zu 1 angeordnet und ausgestaltet sind.
Die erste PoC-Client-Einheit 201 und der erste PoC-Teilnehmerserver 202 sind Teil eines ersten Heimnetzwerks 230, das das Heimnetzwerk der ersten PoC-Client-Einheit 201 ist. Die zweite PoC-Client-Einheit 205 und der zweite PoC-Teilnehmerserver 204 sind Teil eines zweiten Heimnetzwerks 206, das das Heimnetzwerk der zweiten PoC-Client-Einheit 205 ist.
Das Heimnetzwerk 230, 206 einer PoC-Client-Einheit 201, 205 ist das Kommunikationsnetzwerk, mittels welchem die Benutzerinformationen über den Benutzer der PoC-Client-Einheit 201, 205 gespeichert sind.
Der PoC-Steuerserver 203 ist Teil eines Steuernetzwerks 207.
Es wird angenommen, dass die erste PoC-Client-Einheit 201 und die zweite PoC-Client-Einheit 205 (bzw. die jeweiligen Benutzer) mittels des ersten PoC-Teilnehmerservers 202, des zweiten PoC-Teilnehmerservers 204 und des PoC-Steuerservers 203 an einer PoC-Kommunikation teilnehmen.
Im Folgenden wird der Ablauf einer Mute-Info-Abfrage durch die erste PoC-Client-Einheit 201 erläutert.
Unter Mute-Info-Abfrage ist die Anfrage nach Information durch die erste PoC-Client-Einheit 201 über den Mute-Status anderer PoC-Client-Einheiten 201, in diesem Beispiel der zweiten PoC-Client-Einheit 205, zu verstehen.
Der Mute-Status einer PoC-Client-Einheit bei einer PoC-Kommunikation kann sein, dass die PoC-Client-Einheit Mute eingeschaltet hat, das heißt, dass im Rahmen der PoC-Kommunikation keine Sprachdaten an die PoC-Client-Einheit gesendet werden, oder dass die PoC-Client-Einheit Mute nicht eingeschaltet hat, das heißt, dass im Rahmen der PoC-Kommunikation Sprachdaten an die PoC-Client-Einheit gesendet werden.
In Schritt 208 wählt der Benutzer der ersten PoC-Client-Einheit 201 die Mute-Info-Funktion, das heißt die Funktion für eine Mute-Info-Anfrage, per MMI (Man Maschine Interface, Mensch-Maschine-Schnittstelle) aus, beispielsweise durch entsprechende Betätigung einer Tastatur der ersten PoC-Client-Einheit 201.
In Schritt 209 sendet die erste PoC-Client-Einheit 201 eine erste Mute_Info_REQ-Nachricht 216 an den ersten PoC-Teilnehmerserver 202.
In Schritt 210 leitet der erste PoC-Teilnehmerserver 202 die erste Mute_Info_REQ-Nachricht 216 an den PoC-Steuerserver 203 weiter.
Mittels der ersten Mute_Info_REQ-Nachricht 216 fordert der Benutzer der ersten PoC-Client-Einheit 201 eine Liste mit den Mute-Stati aller anderen Teilnehmer, das heißt jeder teilnehmenden PoC-Client-Einheit außer der ersten PoC-Client-Einheit 201 bzw. des entsprechenden Benutzers, der PoC-Kommunikation, an der die erste PoC-Client-Einheit 201 beteiligt ist, an. Das heißt, er fordert eine Liste an, die für jeden anderen Teilnehmer der PoC-Kommunikation die Information enthält, ob der Teilnehmer die PoC-Kommunikation auf Mute geschaltet hat, das heißt, dass dem Teilnehmer keine Sprachdaten im Rahmen der PoC-Kommunikation übermittelt werden, oder ob der Teilnehmer die PoC-Kommunikation nicht auf Mute geschaltet hat, das heißt, dass dem Teilnehmer Sprachdaten im Rahmen der PoC-Kommunikation übermittelt werden.
In Schritt 211 beginnt der PoC-Steuerserver 203 mit der Erstellung einer Liste mit den Mute-Stati aller anderen Teilnehmer der PoC-Kommunikation.
In diesem Beispiel wird angenommen, dass nur ein anderer Teilnehmer der PoC-Kommunikation, nämlich der Benutzer der zweiten PoC-Client-Einheit 205, vorhanden ist. Der Ablauf bei mehreren anderen Teilnehmern ist analog.
Zum Erstellen der Liste sendet der PoC-Steuerserver 203 eine zweite Mute_Info_REQ-Nachricht 218 in Schritt 212 an den zweiten PoC-Teilnehmerserver 204.
Dieser antwortet in Schritt 213 durch Übermitteln einer Mute_Info_RES-Nachricht 219 an den PoC-Steuerserver 203, welche Mute_Info_RES-Nachricht 219 den Mute-Status der zweiten PoC-Client-Einheit 205 enthält.
Sobald dem PoC-Steuerserver 203 alle erforderlichen Informationen über die Mute-Stati der anderen Teilnehmer vorliegen, sendet der PoC-Steuerserver 203 eine Mute_Info_RES-Nachricht 220 in Schritt 214 an den ersten PoC-Teilnehmerserver 202, die die Liste mit den Mute-Stati aller anderen Teilnehmer aufweist.
In Schritt 215 wird die Mute_Info_RES-Nachricht 220 an die erste PoC-Client-Einheit 201 weitergeleitet.
Auf diese Weise wird die erste PoC-Client-Einheit 201 über die Mute-Stati aller Teilnehmer informiert.
In einer anderen Ausführungsform fragt der Benutzer der ersten PoC-Client-Einheit 201 mittels der ersten Mute_Info_REQ-Nachricht 216 nicht nur die momentanten Mute-Stati der anderen Teilnehmer ab, sondern signalisiert, dass er über jede Änderung der Mute-Stati der anderen Teilnehmer informiert werden möchte. In dieser Ausführungsform sendet der PoC-Steuerserver 203 analog zu Schritt 214 und Schritt 215 bei einer Änderung des Mute-Status irgendeines anderen Teilnehmers, das heißt irgendeines Teilnehmers außer der ersten PoC-Client-Einheit 201, eine Mute_Info_RES-Nachricht 220, die die entsprechende Information enthält.
Im Folgenden werden zwei Beispiele für den mit Bezug auf 2 erläuterten allgemeinen Nachrichtenfluss für eine Mute-Info-Anfrage erläutert.
3 zeigt ein Nachrichtenflussdiagramm 300 gemäß einem weiteren Ausführungsbeispiel der Erfindung.
Die an dem dargestellten Nachrichtenfluss beteiligten Einheiten 301 bis 305 und die an dem Nachrichtenfluss beteiligten Kommunikationsnetzwerke 306, 307 und 330 sind analog zu 2 eingerichtet und ausgestaltet.
Bei dem im Folgenden erläuterten Beispiel zu einer Mute-Info-Anfrage werden die Mute_Info_REQ-Nachrichten 216, 218 in Form von SIP-SUBSCRIBE-Nachrichten gemäß dem SIP (Session Initiation Protocol) realisiert.
Das SIP und die verwendeten SIP-Nachrichten sind in [1], [2], [3] und [4] beschrieben.
In Schritt 309 sendet die erste PoC-Client-Einheit 301 entsprechend Schritt 209 eine Subscribe-Nachricht 322 an den ersten PoC-Teilnehmerserver 302, welcher die Subscribe-Nachricht 323 in Schritt 310 an den PoC-Steuerserver 303 weiterleitet.
Die Subscribe-Nachricht 322 ist beispielsweise gemäß Tabelle 1 ausgestaltet.
Tabelle 1
In diesem Beispiel wird angenommen, dass mittels der Subscribe-Nachricht 322 angefragt wird, dass der Benutzer der ersten PoC-Client-Einheit 301 über jede Änderung der Mute-Stati der anderen Teilnehmer der PoC-Kommunikation Informiert wird.
Diese Information wird in diesem Beispiel mittels des Nachrichtenkopffeldes mit der Bezeichnung Event (siehe Zeile 5 von Tabelle 1) angegeben.
Anschaulich subskribiert sich der Benutzer damit für ein Event-Package mit der Bezeichnung poc_mute_info.
Gemäß dem SIP sendet der PoC-Steuerserver 303 in Schritt 311 eine erste Bestätigungsnachricht (OK-Nachricht) 323 an den PoC-Teilnehmerserver 302, welcher die erste Bestätigungsnachricht 323 an die erste PoC-Client-Einheit 301 in Schritt 312 weiterleitet.
Entsprechend Schritt 211 beginnt die PoC-Steuerserver 303 in Schritt 313 mit dem Erstellen einer Liste mit den Mute-Stati aller anderen Teilnehmer. Entsprechend Schritt 212 sendet der PoC-Steuerserver 303 eine zweite Subscribe-Nachricht 324 in Schritt 314 an den zweiten Teilnehmerserver 304. In Schritt 315 bestätigt der zweite PoC-Teilnehmerserver 304 den Erhalt der Subscribe-Nachricht 324 mittels einer zweiten Bestätigungsnachricht 325.
In Schritt 316 teilt der zweite PoC-Teilnehmerserver 304 mittels einer ersten Notifizierungsnachricht 326 dem PoC-Steuerserver 303 den Mute-Status der zweiten PoC-Client-Einheit mit. In Schritt 317 bestätigt der PoC-Steuerserver 303 den Erhalt der ersten Notifizierungsnachricht 326 mittels einer dritten Bestätigungsnachricht 327.
Entsprechend Schritt 316 sendet der PoC-Steuerserver 303 in Schritt 318 eine zweite Notifizierungsnachricht 328 an den ersten PoC-Teilnehmerserver 302, welcher die zweite Notifizierungsnachricht 328 in Schritt 319 an die erste PoC-Client-Einheit 301 weiterleitet.
Die zweite Notifizierungsnachricht 328 enthält die von dem PoC-Steuerserver 303 in Schritt 313 erstellte Liste mit den Mute-Stati aller anderen Teilnehmer.
In Schritt 320 bestätigt die erste PoC-Client-Einheit 301 den Erhalt der zweiten Notifizierungsnachricht 328 mittels einer vierten Bestätigungsnachricht 329, welche in Schritt 321 von dem ersten PoC-Teilnehmerserver 302 an den PoC-Steuerserver 303 weitergeleitet wird.
Die zweite Notifizierungsnachricht 328 ist beispielsweise gemäß Tabelle 2 ausgestaltet, in der die Liste mit den Mute-Stati aller anderen Teilnehmer als XML-Dokument eingefügt ist.

Tabelle 2
Die zweite Notifizierungsnachricht 328 ist in diesem Beispiel als SIP-NOTIFY-Nachricht ausgestaltet und wird in diesem Beispiel bei jeder Änderung des Mute-Status irgendeines anderen Teilnehmers mittels des ersten PoC-Teilnehmerservers 302 an die erste PoC-Client-Einheit 301 übermittelt.
Die erste Notifizierungsnachricht 326 ist ebenfalls als SIP-NOTIFY-Nachricht ausgestaltet, in der allerdings nur der Mute-Status des Client B als XML-Dokument eingefügt ist (entsprechend der Tabelle 2 ohne die Zeilen 16 bis 21).
Im Folgenden wird ein weiteres Beispiel für eine Mute-Info-Anfrage erläutert.
4 zeigt ein Nachrichtenflussdiagramm 400 gemäß einem weiteren Ausführungsbeispiel der Erfindung.
Die an dem dargestellten Nachrichtenfluss beteiligten Einheiten 401 bis 405 und die an dem Nachrichtenfluss beteiligten Kommunikationsnetzwerke 406, 407 und 430 sind analog zu 2 eingerichtet und ausgestaltet.
Die Verarbeitungsschritt 408 bis 415 sind ebenfalls analog zu 2 ausgestaltet.
In diesem Beispiel sind jedoch die erste Mute_Info_REQ-Nachricht 216 und die zweite Mute_Info_REQ-Nachricht 218 gemäß einem applikations-definierten RTCP-Packet (Application-Defined Realtime Control Protocol Packet, APP), wie es in [5] beschrieben ist, ausgestaltet, beispielsweise gemäß Tabelle 3.
Tabelle 3
Der Wert des Parameters subtype wird in diesem Fall als ein für diesen Nachrichtentyp spezifischer, noch nicht anderweitig belegter Wert gewählt.
Die auf diese Weise ausgestaltete erste Mute_Info_REQ-Nachricht 216 und zweite Mute_Info_REQ-Nachricht 218 werden als erste RTP:APP:Mute_info_req-Nachricht 416 bzw. zweite RTP:APP:Mute_info_req-Nachricht 418 bezeichnet.
Die zweite Mute_Info_RES-Nachricht 220 ist in diesem Beispiel gemäß Tabelle 4 ausgestaltet.

Tabelle 4
Die erste Mute_Info_RES-Nachricht 219 ist beispielsweise gemäß Tabelle 5 ausgestaltet.
Tabelle 5
Die gemäß Tabelle 4 ausgestaltete Mute_Info_RES-Nachricht 220 enthält eine Angabe aller anderen Teilnehmer, die Mute aktiviert, das heißt eingeschaltet, haben (siehe Tabelle 4 Zeile 6).
Die Spezifikation der PoC-Teilnehmer, die Mute aktiviert haben, erfolgt mittels der Parameter CNAME und NAME (siehe Zeile 6 Tabelle 4) deren Bedeutung in [5] definiert ist.
In einer anderen Ausführungsform enthält die Mute_Info_RES-Nachricht 220 eine Spezifikation aller anderen Teilnehmer mit ihrem jeweiligen Mute-Status.
Der Wert des Parameters subtype sollte wie oben ein noch nicht anderweitig belegter, Nachrichtentyp-spezifischer Wert sein.
Die gemäß Tabelle 4 ausgestaltete zweite Mute_Info_RES-Nachricht 220 sowie die ebenfalls gemäß RTP/RTCP (Realtime Transport Protocol/Realtime Control Protocol) ausgestaltete erste Mute-Info-RES-Nachricht 219 werden als zweite RTP:APP:Mute_info_res-Nachricht 420 bzw. als erste RTP:APP:Mute_info_res-Nachricht 419 bezeichnet.
In diesem Ausführungsbeispiel wird die zweite RTP:APP:Mute_info_res-Nachricht 420 direkt als Antwort auf eine Mute-Info-Anfrage mittels der ersten RTP:APP:Mute_info_req-Nachricht 416 übermittelt sowie bei jeder Änderung des Mute-Stati irgendeines anderen Teilnehmers.
Im Folgenden wird der Nachrichtenfluss bei einer Mute-Off-Anfrage erläutert, das heißt bei der Anfrage einer ersten PoC-Client-Einheit an eine zweite PoC-Client-Einheit, mit der Aufforderung, dass die zweite PoC-Client-Einheit Mute im Rahmen der PoC-Kommunikation ausschaltet.
5 zeigt ein Nachrichtenflussdiagramm 500 gemäß einem weiteren Ausführungsbeispiel der Erfindung.
Die an dem Nachrichtenfluss beteiligten Kommunikationsnetzwerkelemente 501 bis 505 und die beteiligten Kommunikationsnetzwerke 506, 507 und 530 sind analog zu 2 angeordnet und ausgestaltet.
Wie oben wird angenommen, dass die erste PoC-Client-Einheit 501 und die zweite PoC-Client-Einheit 505 (bzw. die jeweiligen Benutzer) mittels des ersten PoC-Teilnehmerservers 502, des zweiten PoC-Teilnehmerservers 504 und des PoC-Steuerservers 503 an einer PoC-Kommunikation teilnehmen.
In Schritt 508 wählt der Benutzer der ersten PoC-Client-Einheit 501 per MMI den Benutzer der zweiten PoC-Client-Einheit 505 und die Mute-Off-Anfrage-Funktion der ersten PoC-Client-Einheit 501 aus.
In Schritt 509 sendet die erste PoC-Client-Einheit 501 eine Mute_Off_REQ-Nachricht 517 an den ersten PoC-Teilnehmerserver 502, der die Mute_Off_REQ-Nachricht 517 in Schritt 510 an den PoC-Steuerserver 503 weiterleitet.
Der PoC-Steuerserver 503 leitet die Mute_Off_REQ-Nachricht 517 in den Schritten 511 und 512 mittels des zweiten PoC-Teilnehmerservers 504 an die zweite PoC-Client-Einheit 505 weiter.
Dem Benutzer der zweiten PoC-Client-Einheit 505 wird daraufhin angezeigt, dass eine Mute-Off-Anfrage an ihn übermittelt wurde und er aufgefordert wird, Mute auszuschalten.
Der Benutzer der zweiten PoC-Client-Einheit 505 kann nun entsprechend reagieren, das heißt Mute ausschalten oder Mute weiterhin eingeschaltet lassen.
In diesem Beispiel wird angenommen, dass der Benutzer der zweiten PoC-Client-Einheit 505 seinen Mute-Zustand beendet, das heißt Mute ausschaltet, beispielsweise mittels einer entsprechenden Nachricht an den zweiten PoC-Teilnehmerserver 504.
Die zweite PoC-Client-Einheit 505 sendet nun zur Bestätigung, dass sie die Mute_Off_REQ-Nachricht 517 empfangen hat, eine Mute_Off_ACK-Nachricht 518 in Schritt 513, die in den Schritten 514, 515 und 516 mittels des zweiten PoC-Teilnehmerservers 504, des PoC-Steuerservers 503 und des ersten PoC-Teilnehmerservers 502 an die erste PoC-Client-Einheit 501 weitergeleitet wird.
Das Senden der Mute_Off_ACK-Nachricht 518 ist in einer anderen Ausführungsform optional oder wird nicht durchgeführt.
In einer Ausführungsform sendet die zweite PoC-Client-Einheit 505 analog zu der Mute_Off_ACK-Nachricht 518 eine Nachricht an die erste PoC-Client-Einheit 501, mittels welcher signalisiert wird, ob die zweite PoC-Client-Einheit 505 (nach der entsprechenden Entscheidung des Benutzers) Mute ausgeschaltet hat.
Im Weiteren werden zwei Beispiele für den Ablauf bei einer Mute-Off-Anfrage erläutert.
6 zeigt ein Nachrichtenflussdiagramm 600 gemäß einem weiteren Ausführungsbeispiel der Erfindung.
Die an dem Nachrichtenfluss beteiligten Kommunikationsnetzwerkelemente 601 bis 605 und die beteiligten Kommunikationsnetzwerke 606, 607 und 630 sind analog zu 5 angeordnet und ausgestaltet.
Die Verarbeitungsschritte 609 bis 616 werden analog zu 5 durchgeführt.
In diesem Beispiel ist die Mute_Off_REQ-Nachricht 517 gemäß einer SIP-INFO-Nachricht ausgestaltet, beispielsweise gemäß Tabelle 6.

Tabelle 6
Mittels der in dem Nachrichtenkopffeld (Header) mit der Bezeichnung Content-Type enthaltenden Zeichenkette ”application/poc-mute_off_req” (siehe Zeile 7 von Tabelle 6) wird angegeben, dass mittels der so ausgestalteten Nachricht, die als Info-Nachricht 617 bezeichnet wird, eine Mute-Off-Anfrage durchgeführt wird.
In einer anderen Ausführungsform wird die Mute_Off_REQ-Nachricht 517 mittels einer SIP-MESSAGE-Nachricht realisiert.
In einer anderen Ausführungsform enthält die je nach Realisierung als SIP-INFO-Nachricht oder als SIP-MESSAGE-Nachricht ausgestaltete Mute_Off_REQ-Nachricht 517 noch einen Nachrichten-Body in Form eines XML-Dokuments, die Informationen der Mute_Off_REQ-Nachricht 517 enthält.
Die Mute_Off_ACK-Nachricht 518 ist gemäß einer SIP-200OK-Nachricht ausgestaltet und wird als Ok-Nachricht 618 bezeichnet.
Wie erwähnt sendet in einer Ausführungsform die zweite PoC-Client-Einheit 505 analog zu der Mute_Off_ACK-Nachricht 518 eine Nachricht an die erste PoC-Client-Einheit 501, mittels welcher signalisiert wird, ob die zweite PoC-Client-Einheit 505 (nach der entsprechenden Entscheidung des Benutzers) Mute ausgeschaltet hat.
Diese (beispielsweise optionale) Nachricht zur Bestätigung aufgrund einer User-Interaktion im MMI von dem Benutzer der zweiten PoC-Client-Einheit 505 ist beispielsweise gemäß Tabelle 7 ausgestaltet.
Eine User-Interaktion des Benutzers ist beispielsweise ein „Mute off”-Befehl des Benutzers zum Ausschalten von Mute oder ein „Mute_off_req reject”-Befehl des Benutzers zum Ablehnen der Aufforderung, Mute zu deaktivieren.
Tabelle 7
In diesem Beispiel wird mittels der Zeichenkette value=”accepted” angegeben, dass die zweite PoC-Client-Einheit 505 der Mute-Off-Aufforderung, d. h. der Aufforderung, Mute zu deaktivieren, nachgegangen ist.
Die Zeichenkette value=”rejected” könnte beispielsweise anzeigen, dass der Benutzer der zweiten PoC-Client-Einheit 505 der Mute-Off-Aufforderung nicht nachgegangen ist. In dem Fall könnte beispielsweise ein Bereich mit der Bezeichnung <reason> verwendet werden, mittels welchem der Benutzer der zweiten PoC-Client-Einheit 505 der ersten PoC-Client-Einheit 501 eine Begründung dafür mitteilt, warum er der Mute-Off-Aufforderung nicht Folge leistet, beispielsweise mittels der Zeichenkette „Momentan nicht möglich, da ich in einer wichtigen Besprechung bin”.
7 zeigt ein Nachrichtenflussdiagramm 700 gemäß einem weiteren Ausführungsbeispiel der Erfindung.
Die an dem dargestellten Nachrichtenfluss beteiligten Kommunikationsnetzwerkelemente 701 bis 705 und die an dem Nachrichtenfluss beteiligten Kommunikationsnetzwerke 706, 707 und 730 sind analog zu 5 eingerichtet und angeordnet.
Die Verarbeitungsschritte 708 bis 716 werden entsprechend 5 durchgeführt.
In diesem Beispiel wird die Durchführung und Verarbeitung einer Mute-Off-Anfrage unter Verwendung von RTP/RTCP (Realtime Transport Protocol/Realtime Control Protocol) durchgeführt.
Die Mute_Off_REQ-Nachricht 517 wird mittels eines applikationsdefinierten RTCP-Packets (Application-Defined RTCP Packet, APP) realisiert, und ist beispielsweise gemäß Tabelle 8 ausgestaltet.

Tabelle 8
Der Wert des Parameters subtype sollte analog zu oben ein noch nicht anderweitig belegter, nachrichtentypspezifischer Wert sein.
Die so ausgestaltete Mute_Off_REQ-Nachricht 517 wird als RTP:APP:Mute_Off_req-Nachricht 717 bezeichnet.
Die Mute_Off_ACK-Nachricht 518 ist auf ähnliche Weise gemäß Tabelle 9 ausgestaltet.
Tabelle 9
Der Wert subtype sollte wie oben ein noch nicht anderweitig belegter, für diesen Nachrichtentyp spezifischer Wert sein.
Die so ausgestaltete Mute_Off_ACK-Nachricht 518 wird als RTP:APP:Mute_Off_res-Nachricht bezeichnet.
Eine (eventuell optionale) Nachricht, mittels welcher signalisiert wird, ob die zweite PoC-Client-Einheit 705 (nach der entsprechenden Entscheidung des Benutzers) Mute ausgeschaltet hat, ist in diesem Ausführungsbeispiel gemäß Tabelle 10 ausgestaltet.

Tabelle 10
Der Wert subtype sollte wie oben ein noch nicht anderweitig belegter, für diesen Nachrichtentyp spezifischer Wert sein.
In diesem Dokument sind folgende Veröffentlichungen zitiert:

[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

Bezugszeichenliste

100: Kommunikationssystem
101–103: PoC-Client-Einheit
104: Schnittstelle
105: PoC-Teilnehmerserver
106: PoC-Steuerserver
107: Gruppen-Management-Server
200: Nachrichtenflussdiagramm
201: PoC-Client-Einheit
202: PoC-Teilnehmerserver
203: PoC-Steuerserver
204: PoC-Teilnehmerserver
205: PoC-Client-Einheit
206: Heimnetzwerk
207: Steuernetzwerk
208–215: Verarbeitungsschritte
216: Nachricht
218–220: Nachrichten
230: Heimnetzwerk
300: Nachrichtenflussdiagramm
301: PoC-Client-Einheit
302: PoC-Teilnehmerserver
303: PoC-Steuerserver
304: PoC-Teilnehmerserver
305: PoC-Client-Einheit
306: Heimnetzwerk
307: Steuernetzwerk
308–321: Verarbeitungsschritte
322–329: Nachrichten
330: Heimnetzwerk
400: Nachrichtenflussdiagramm
401: PoC-Client-Einheit
402: PoC-Teilnehmerserver
403: PoC-Steuerserver
404: PoC-Teilnehmerserver
405: PoC-Client-Einheit
406: Heimnetzwerk
407: Steuernetzwerk
408–415: Verarbeitungsschritte
416: Nachricht
418–420: Nachrichten
430: Heimnetzwerk
500: Nachrichtenflussdiagramm
501: PoC-Client-Einheit
502: PoC-Teilnehmerserver
503: PoC-Steuerserver
504: PoC-Teilnehmerserver
505: PoC-Client-Einheit
506: Heimnetzwerk
507: Steuernetzwerk
508–516: Verarbeitungsschritte
517, 518: Nachrichten
530: Heimnetzwerk
600: Nachrichtenflussdiagramm
601: PoC-Client-Einheit
602: PoC-Teilnehmerserver
603: PoC-Steuerserver
604: PoC-Teilnehmerserver
605: PoC-Client-Einheit
606: Heimnetzwerk
607: Steuernetzwerk
608–616: Verarbeitungsschritte
617, 618: Nachrichten
630: Heimnetzwerk
700: Nachrichtenflussdiagramm
701: PoC-Client-Einheit
702: PoC-Teilnehmerserver
703: PoC-Steuerserver
704: PoC-Teilnehmerserver
705: PoC-Client-Einheit
706: Heimnetzwerk
707: Steuernetzwerk
708–716: Verarbeitungsschritte
717, 718: Nachrichten
730: Heimnetzwerk

Claims

Kommunikationssystem, das einen Server (106) und mehr als zwei Push-to-talk-over-Cellular-Client-Einheiten (101, 102, 103) aufweist, wobei – die Push-to-talk-over-Cellular-Client-Einheiten mittels je eines Push-to-talk-over-Cellular-Teilnehmerservers (105) an einer Push-to-talk-over-Cellular-Kommunikation teilnehmen; – eine erste Push-to-talk-over-Cellular-Client-Einheit eine Mensch-Maschine-Schnittstelle aufweist zum Auswählen einer zweiten Push-to-talk-over-Cellular-Client-Einheit und zum Auswählen einer Mute-Deaktivierungs-Anfrage-Funktion der ersten Push-to-talk-over-Cellular-Client-Einheit durch einen Benutzer der ersten Push-to-talk-over-Cellular-Client-Einheit, womit es dem Benutzer der ersten Push-to-talk-over-Cellular-Client-Einheit ermöglich wird, einen weiteren Push-to-talk-over-Cellular-Teilnehmer für eine momentane Übertragung von Sprachdaten in einer laufenden Push-to-talk-over-Cellular-Kommunikation zu bitten zuzuhören, falls der weitere Push-to-talk-over-Cellular-Teilnehmer Mute aktiviert hat; – die erste Push-to-talk-over-Cellular-Client-Einheit (101) eine Nachrichtenerzeugungseinheit aufweist, die eingerichtet ist, erste Nachrichten zu erzeugen, welche ersten Nachrichten Anfrageinformationen enthalten, – die zum einen spezifizieren, dass Informationen, die spezifizieren, ob die zweite Push-to-talk-over-Cellular-Client-Einheit (102) das Übersenden von Sprachdaten an die zweite Push-to-talk-over-Cellular-Client-Einheit (102) im Rahmen der Push-to-talk-over-Cellular-Kommunikation gestattet, an die erste Push-to-talk-over-Cellular-Client-Einheit (101) übertragen werden sollen, in welchem Fall die erste Nachricht als Mute-Info-Anfragenachricht eingerichtet ist; und – die zum anderen spezifizieren, dass die zweite Push-to-talk-over-Cellular-Client-Einheit (102) das Übersenden von Sprachdaten an die zweite Push-to-talk-over-Cellular-Client-Einheit (102) im Rahmen der Push-to-talk-over-Cellular-Kommunikation gestatten soll, in welchem Fall die erste Nachricht als Mute-Deaktivierungs-Anfragenachricht eingerichtet ist; und die eingerichtet ist, die ersten Nachrichten mittels des Push-to-talk-over-Cellular-Teilnehmerservers (105) der ersten Push-to-talk-over-Cellular-Client-Einheit (101) an den Server (106) zu übermitteln, – der Server (106) eine Verarbeitungseinrichtung aufweist, die eingerichtet ist, gemäß den Anfrageinformationen – Informationen, die spezifizieren, ob die zweite Push-to-talk-over-Cellular-Client-Einheit (102) das Übersenden von Sprachdaten an die zweite Push-to-talk-over-Cellular-Client-Einheit (102) im Rahmen der Push-to-talk-over-Cellular-Kommunikation gestattet, zu ermitteln und mittels einer ersten Sendeeinrichtung und mittels einer zweiten Nachricht an die erste Push-to-talk-Client-over-Cellular-Einheit (101) mittels deren Push-to-talk-over-Cellular-Teilnehmerservers (105) zu übertragen; und – eine dritte Nachricht zu erzeugen und mittels einer zweiten Sendeeinrichtung an die zweite Push-to-talk-over-Cellular-Client-Einheit (102) mittels deren Push-to-talk-over-Cellular-Teilnehmerservers (105) zu übertragen, mittels welcher dritten Nachricht die zweite Push-to-talk-over-Cellular-Client-Einheit (102) aufgefordert wird, das Übersenden von Sprachdaten an die zweite Push-to-talk-over-Cellular-Client-Einheit (102) im Rahmen der Push-to-talk-over-Cellular-Kommunikation zu gestatten; – wobei die zweite Push-to-talk-over-Cellular-Client-Einheit eine Mensch-Maschine-Schnittstelle aufweist zum Anzeigen, auf den Empfang der dritten Nachricht hin, dass eine Mute-Deaktivierungs-Anfrage an die zweite Push-to-talk-Client-Einheit übermittelt wurde und der Benutzer der zweiten Push-to-talk-over-Cellular-Client-Einheit aufgefordert wird, das Übersenden von Sprachdaten an die zweite Push-to-talk-over-Cellular-Client-Einheit zu gestalten.
Kommunikationssystem gemäß Anspruch 1, wobei die Anfrageinformationen spezifizieren, ob Informationen, die spezifizieren, ob die zweite Push-to-talk-over-Cellular-Client-Einheit das Übersenden von Sprachdaten an die zweite Push-to-talk-over-Cellular-Client-Einheit im Rahmen der Push-to-talk-over-Cellular-Kommunikation gestattet, bei einem Wechsel vom Gestatten zum Nichtgestatten und/oder vom Nichtgestatten zum Gestatten des Übersendens von Sprachdaten an die zweite Push-to-talk-over-Cellular-Client-Einheit im Rahmen der Push-to-talk-over-Cellular-Kommunikation oder nur einmalig an die erste Push-to-talk-over-Cellular-Client-Einheit übertragen werden sollen.
Kommunikationssystem gemäß Anspruch 2, wobei die Verarbeitungseinrichtung eingerichtet ist, gemäß den Anfrageinformationen bei jedem Wechsel vom Gestatten zum Nichtgestatten und/oder vom Nichtgestatten zum Gestatten des Übersendens von Sprachdaten an die zweite Push-to-talk-over-Cellular-Client-Einheit im Rahmen der Push-to-talk-over-Cellular-Kommunikation oder nur einmalig Informationen, die spezifizieren, ob die zweite Push-to-talk-over-Cellular-Client-Einheit das Übersenden von Sprachdaten an die zweite Push-to-talk-over-Cellular-Client-Einheit im Rahmen der Push-to-talk-over-Cellular-Kommunikation gestattet, an die erste Push-to-talk-over-Cellular-Client-Einheit zu übertragen.
Kommunikationssystem gemäß einem der Ansprüche 1 bis 3, wobei die zweite Push-to-talk-over-Cellular-Client-Einheit eine Signalisierungseinrichtung aufweist, die eingerichtet ist, als Reaktion auf die dritte Nachricht eine Bestätigungsnachricht an die erste Push-to-talk-over-Cellular-Client-Einheit zu übermitteln.
Kommunikationssystem gemäß einem der Ansprüche 1 bis 4, wobei die erste Nachricht und/oder die zweite Nachricht und/oder die dritte Nachricht gemäß SIP oder gemäß RTP/RTCP ausgestaltet sind.
Kommunikationssystem gemäß Anspruch 5, wobei die erste Nachricht gemäß einer SIP-SUBSCRIBE-Nachricht, einer SIP-INFO-Nachricht, einer SIP-MESSAGE-Nachricht oder einem RTCP-Packet, die zweite Nachricht gemäß einer SIP-NOTIFY-Nachricht, einer SIP-INFO-Nachricht, einer SIP-MESSAGE-Nachricht oder einem RTCP-Packet und/oder die dritte Nachricht gemäß einer SIP-INFO-Nachricht, einer SIP-MESSAGE-Nachricht oder einem RTCP-Packet ausgestaltet ist.
Kommunikationssystem gemäß einem der Anspruch 5 oder 6, wobei, im Falle der Ausgestaltung der ersten Nachricht und/oder der zweiten Nachricht und/oder der dritten Nachricht gemäß SIP, die jeweilige Nachricht Daten im XML-Format aufweist.
Verfahren zum Betreiben eines Kommunikationssystems, welches Kommunikationssystem einen Server (106) und mehr als zwei Push-to-talk-over-Cellular-Client-Einheiten (101, 102, 103) aufweist, wobei – die Push-to-talk-over-Cellular-Client-Einheiten mittels je eines Push-to-talk-over-Cellular-Teilnehmerservers (105) an einer Push-to-talk-over-Cellular-Kommunikation teilnehmen; und wobei gemäß dem Verfahren – der Benutzer einer ersten Push-to-talk-over-Cellular-Client-Einheit mittels einer Mensch-Maschine-Schnittstelle der ersten Push-to-talk-over-Cellular-Client-Einheit eine zweite Push-to-talk-over-Cellular-Client-Einheit auswählt und eine Mute-Deaktivierungs-Anfrage-Funktion der ersten Push-to-talk-over-Cellular-Client-Einheit auswählt, womit es dem Benutzer der ersten Push-to-talk-over-Cellular-Client-Einheit ermöglich wird, einen weiteren Push-to-talk-over-Cellular-Teilnehmer für eine momentane Übertragung von Sprachdaten in einer laufenden Push-to-talk-over-Cellular-Kommunikation zu bitten zuzuhören, falls der weitere Push-to-talk-over-Cellular-Teilnehmer Mute aktiviert hat; – die erste Push-to-talk-over-Cellular-Client-Einheit (101) erste Nachrichten erzeugt, welche ersten Nachrichten Anfrageinformationen enthalten, – die zum einen spezifizieren, dass Informationen, die spezifizieren, ob die zweite Push-to-talk-over-Cellular-Client-Einheit (102) das Übersenden von Sprachdaten an die zweite Push-to-talk-over-Cellular-Client-Einheit (102) im Rahmen der Push-to-talk-over-Cellular-Kommunikation gestattet, an die erste Push-to-talk-over-Cellular-Client-Einheit (101) übertragen werden sollen, in welchem Fall die erste Nachricht als Mute-Info-Anfragenachricht eingerichtet ist; und – die zum anderen spezifizieren, dass die zweite Push-to-talk-over-Cellular-Client-Einheit (102) das Übersenden von Sprachdaten an die zweite Push-to-talk-over-Cellular-Client-Einheit (102) im Rahmen der Push-to-talk-over-Cellular-Kommunikation gestatten soll, in welchem Fall die erste Nachricht als Mute-Deaktivierungs-Anfragenachricht eingerichtet ist; und die ersten Nachrichten mittels des Push-to-talk-over-Cellular-Teilnehmerservers (105) der ersten Push-to-talk-over-Cellular-Client-Einheit (101) an den Server (106) übermittelt, – der Server (106) gemäß den Anfrageinformationen aus den empfangenen ersten Nachrichten – Informationen, die spezifizieren, ob die zweite Push-to-talk-over-Cellular-Client-Einheit (102) das Übersenden von Sprachdaten an die zweite Push-to-talk-over-Cellular-Client-Einheit (102) im Rahmen der Push-to-talk-over-Cellular-Kommunikation gestattet, ermittelt und mittels einer ersten Sendeeinrichtung und mittels einer zweiten Nachricht an die erste Push-to-talk-Client-over-Cellular-Einheit (101) mittels deren Push-to-talk-over-Cellular-Teilnehmerservers (105) überträgt; und – eine dritte Nachricht erzeugt und mittels einer zweiten Sendeeinrichtung an die zweite Push-to-talk-over-Cellular-Client-Einheit (102) mittels deren Push-to-talk-over-Cellular-Teilnehmerservers (105) überträgt, mittels welcher dritten Nachricht die zweite Push-to-talk-over-Cellular-Client-Einheit (102) aufgefordert wird, das Übersenden von Sprachdaten an die zweite Push-to-talk-over-Cellular-Client-Einheit (102) im Rahmen der Push-to-talk-over-Cellular-Kommunikation zu gestatten; – mittels einer Mensch-Maschine-Schnittstelle der zweiten Push-to-talk-over-Cellular-Client-Einheit auf den Empfang der dritten Nachricht hin angezeigt wird, dass eine Mute-Deaktivierungs-Anfrage an die zweite Push-to-talk-over-Cellular-Client-Einheit übermittel wurde und der Benutzer der zweiten Push-to-talk-over-Cellular-Client-Einheit aufgefordert wird, das Übersenden von Sprachdaten an die zweite Push-to-talk-over-Cellular-Client-Einheit zu gestatten.
Server (106) des Kommunikationssystems gemäß einem der Ansprüche 1 bis 7.
Push-to-talk-over-Cellular-Client-Einheit (101, 102, 103) des Kommunikationssystems gemäß einem der Ansprüche 1 bis 7.