PatentDe  


Dokumentenidentifikation DE102005042141A1 15.03.2007
Titel Konferenz-Kommunikationssystem, Verfahren zum Betreiben eines Konferenz-Kommunikationssystems, Notifizierungseinrichtung und Verfahren zum Notifizieren eines Kommunikationsendgeräts
Anmelder Infineon Technologies AG, 81669 München, DE
Erfinder Schmidt, Andreas, 38124 Braunschweig, DE;
Schwagmann, Norbert, 26892 Lehe, DE;
Schmidt, Holger, 38102 Braunschweig, DE
Vertreter Viering, Jentschura & Partner, 80538 München
DE-Anmeldedatum 05.09.2005
DE-Aktenzeichen 102005042141
Offenlegungstag 15.03.2007
Veröffentlichungstag im Patentblatt 15.03.2007
IPC-Hauptklasse H04M 3/56(2006.01)A, F, I, 20051017, B, H, DE
Zusammenfassung Es wird ein Konferenz-Kommunikationssystem mit einer Konferenz-Servereinheit beschrieben, die eine Konferenz für ein erstes und ein zweites Kommunikationsendgerät bereitgestellt. Das Konferenz-Kommunikationssystem weist eine Notifizierungseinrichtung auf, die eingerichtet ist, eine Notifizierungsnachricht gemäß einem Mediendatenübertragungs-Steuerungsprotokoll zu erzeugen, mittels welcher signalisiert wird, ob von dem ersten Kommunikationsendgerät versendete Mediendaten an das zweite Kommunikationsendgerät weitergeleitet wurden.

Beschreibung[de]

Die Erfindung betrifft ein Konferenz-Kommunikationssystem, ein Verfahren zum Betreiben eines Konferenz-Kommunikationssystems, eine Notifizierungseinrichtung und ein Verfahren zum Notifizieren eines Kommunikationsendgeräts.

Im Rahmen von Konferenz-Kommunikationsdiensten wird es mehreren Teilnehmern einer Konferenz ermöglicht, mittels Kommunikationsendgeräten miteinander zu kommunizieren.

Damit eine geordnete Kommunikation im Rahmen einer Konferenz ermöglicht wird, haben typischerweise nicht alle Teilnehmer der Konferenz gleichzeitig das Recht zu kommunizieren, das heißt Audio-Nachrichten (oder auch Video-Nachrichten etc.) an die anderen Konferenzteilnehmer zu senden. Das Kommunikationsrecht, das heißt das Recht zu kommunizieren, wird nach bestimmten Regeln an die Konferenzteilnehmer vergeben. Diese Vergabe wird als "Floor Control" bezeichnet. Die Regeln werden als "Floor Policy" bezeichnet.

Bei Kommunikationssystemen in großen Konferenzräumen, also bei fest installierten Konferenz-Kommunikationssystemen, werden den Konferenzteilnehmern Mikrofone und Lautsprecher zur sprachlichen Kommunikation zur Verfügung gestellt. Damit ein Konferenzteilnehmer eine Audio-Nachricht an die anderen Konferenzteilnehmer übermitteln kann, muss dabei das Mikrofon des Konferenzteilnehmers aktiviert sein. Typischerweise werden, wenn ein Mikrofon aktiviert ist, alle anderen Mikrofone gesperrt, das heißt, dass das, was in die anderen Mikrofone gesprochen wird, nicht mittels der Lautsprecher ausgegeben wird. In manchen Fällen ist noch ein weiteres Mikrofon aktiviert, beispielsweise das des Konferenzleiters.

Es sind ferner Kommunikationssysteme bekannt, die es weit voneinander entfernten (Konferenz-)Teilnehmern ermöglichen, mittels einer Telefon-Konferenz oder einer Video-Konferenz miteinander zu kommunizieren. Solche Konferenzen können beispielsweise mittels eines IMS (Internet Protocol Multimedia Subsystem) bereitgestellt werden. Bei solchen Kommunikationssystemen wird es typischerweise den Teilnehmern ermöglicht, gleichzeitig Audio-Nachrichten oder Nachrichten anderer Art (Videonachrichten etc.) zu übermitteln.

Bei Mobilfunk-Kommunikationssystemen sind Kommunikationsdienste bekannt, die, wie ein Konferenzkommunikationssystem in einem Konferenzraum oder wie die Kommunikation mittels Walkie-Talkies, zu einem Zeitpunkt nur das Übermitteln von Audio-Nachrichten eines einzigen Teilnehmers an die anderen Konferenzteilnehmer ermöglichen. Diese Kommunikationsdienste sind unter der Bezeichnung Push-to-Talk (PTT) bekannt, wie beispielsweise der Kommunikationsdienst "Direct Connect", der von dem Unternehmen Nextel in den USA angeboten wird, oder der Kommunikationsdienst PoC (Push to Talk over Cellular), der von der OMA (Open Mobile Alliance) spezifiziert wird.

Ähnlich dem oben beschriebenen Konferenz-Kommunikationssystem, das in einem Konferenzraum verwendet wird, muss ein Konferenzteilnehmer bei PTT eine spezielle Taste, typischerweise an seinem Mobilfunk-Teilnehmergerät, betätigen, damit es ihm ermöglicht wird, Audio-Nachrichten zu übermitteln. Während der Übermittlung von Audio-Nachrichten dieses Konferenzteilnehmers ist die Übertragung von Audio-Nachrichten anderer Konferenzteilnehmer gesperrt, das heißt anderen Konferenzteilnehmern wird es nicht ermöglicht, Audio-Nachrichten an Konferenzteilnehmer zu übertragen.

In Konferenz-Kommunikationssystemen, wie sie von der IETF (Internet Engineering Task Force) vorgeschlagen werden, wird die Vergabe des Kommunikationsrechts mittels des BFCP (Binary Floor Control Protocol) gesteuert, siehe [1]. Bei derzeitigen PTT-Kommunikationssystemen, d.h. bei Kommunikationssystemen, mittels welchen ein Push-To-Talk-Kommunikationsdienst bereitgestellt wird, wird das Kommunikationsrecht unter Verwendung des RTCP (Real Time Control Protocol) angefordert und vergeben siehe [2] und [3]. Auch hier kann alternativ die Vergabe des Kommunikationsrechts mittels BFCP gesteuert werden.

Es ist ferner bekannt, dass die Teilnehmer einer Konferenz über den Zustand der Konferenz durch eine Notifizierung informiert werden können. Beispielsweise kann den Teilnehmern mitgeteilt werden, welcher Teilnehmer das Kommunikationsrecht für ein bestimmtes Medium (Audio, Video, ...) anfordert. Notifizierungen werden in Konferenz-Kommunikationssystemen, wie sie von der IETF vorgeschlagen werden, gemäß SIP (Session Initiation Protocol) durchgeführt, siehe [4]. In derzeitigen PTT-Kommunikationssystemen werden die Teilnehmer unter Verwendung von RTCP darüber notifiziert, welchem der Teilnehmer das Kommunikationsrecht zugeteilt wird, siehe [2].

Bei Konferenz-Kommunikationssystemen kann es ferner vorgesehen sein, dass Informationen über den Zustand von Teilnehmern versendet werden. Beispielsweise kann anderen Teilnehmern mitgeteilt werden, wenn ein Teilnehmer nicht mehr erreichbar ist, weil dass von ihm zur Teilnahme an der Konferenz verwendete Kommunikationsendgerät ausgeschaltet wurde oder der Teilnehmer im Moment keine von anderen Teilnehmern versendeten Kommunikationsdaten empfangen möchte. Möglichkeiten, Informationen über den Zustand von Teilnehmern zu versenden, werden unter dem Begriff "Presence" zusammengefasst.

Konferenz-Kommunikationssysteme nach dem Vorschlag der IETF und PTT-Kommunikationssysteme weisen eine zentralisierte Architektur auf, vergleiche [5] und [6]. Das heißt, dass die Benutzer solcher Kommunikationssysteme nicht direkt miteinander kommunizieren, sondern mittels eines zentralen Serverrechners. Wird zur Kommunikation ein "mobiles" Kommunikationssystem verwendet, beispielsweise ein Mobilfunk-Kommunikationssystem, so ist der zentrale Serverrechner typischerweise im nicht mobilen Teil des Kommunikationssystems angeordnet, beispielsweise im Kernnetzwerk (Core Network) im Falle eines Mobilfunk-Kommunikationssystems gemäß dem UMTS (Universal Mobile Telecommunications System)-Standard.

In PTT-Kommunikationssystemen weist der zentrale Serverrechner eine sogenannte Controlling Function und typischerweise mehrere, mit der Controlling Function kommunizierende Participating Functions auf. Jedem Teilnehmer einer mittels des zentralen Serverrechners bereitgestellten Konferenz (bzw. dem von ihm verwendeten Kommunikationsendgerät) ist eine Participating Function zugeordnet. Die Controlling Function weist eine Funktionalität auf, die der PTT-Sitzung, d.h. der Konferenz, zugeordnet sind. Eine Participating Function weist eine Funktionalität auf, die dem Teilnehmer zugeordnet ist, der der Participating Function zugeordnet ist. Eine Participating Function, die einem Teilnehmer zugeordnet ist, kann somit als Teil des von dem Teilnehmer zur Teilnahme an der Konferenz verwendeten Kommunikationsendgeräts angesehen werden. Die Participating Function ist jedoch im Falle eines mobilen Kommunikationssystems im nicht mobilen Teil des Kommunikationssystems angeordnet.

Die Controlling Function und die Participating Function des Teilnehmers der PTT-Sitzung können durch unterschiedliche PTT-Serverrechner realisiert werden. Dies ist z.B. dann der Fall, wenn die PTT-Sitzung mittels eines Kommunikationsnetzwerks erzeugt wurde, das nicht das Heimnetzwerk des Teilnehmers ist. In diesem Fall wird die Participating Function mittels eines PTT-Serverrrechners des eigenen Netzbetreibers, d.h. des Betreibers des Heimnetzwerks des Teilnehmers, realisiert. Die Controlling Function der PTT-Sitzung wird dagegen mittels eines PTT-Serverrechners des fremden Netzbetreibers realisiert, d.h. des Netzbetreibers des Kommunikationsnetzwerks, mittels welchem die PTT-Sitzung erzeugt wurde. Im Rahmen der PTT-Sitzung kommuniziert der Teilnehmer mittels einer Kommunikationsverbindung zwischen dem PTT-Serverrechner des eigenen Netzbetreibers und dem PTT-Serverrechner des fremden Netzbetreibers.

Ein Benutzer eines PTT-Kommunikationssystems kann auch Teilnehmer mehrerer PTT-Sitzungen gleichzeitig sein. In diesem Fall besteht eine Kommunikationsverbindung zwischen einer dem Benutzer zugeordneten Participating Function zu den Controlling Functions aller PTT-Sitzungen, an denen der Benutzer teilnimmt.

Ist ein Benutzer Teilnehmer mehrerer PTT-Sitzungen, so legt er eine der PTT-Sitzungen als primäre Sitzung fest. Die anderen der PTT-Sitzungen werden als sekundäre PTT-Sitzungen festgelegt. Werden sowohl in einer sekundären PTT-Sitzung als auch in einer primären PTT-Sitzung, an denen der Benutzer teilnimmt, von anderen Teilnehmern Kommunikationsdaten (Audiodaten, Videodaten, etc.) versendet, so leitet die dem Teilnehmer zugeordnete Participating Function nur die im Rahmen der primären PTT-Sitzung versendeten Kommunikationsdaten an den Teilnehmer weiter. Nur wenn im Rahmen der primären PTT-Sitzung keine Kommunikationsdaten von anderen Teilnehmern versendet werden, werden Kommunikationsdaten an den Teilnehmer weitergeleitet, die im Rahmen einer sekundären PTT-Sitzung versendet werden.

Da die Participating Functions zu einem Zeitpunkt immer nur Kommunikationsdaten an den Teilnehmer versendet, die in einer einzigen PTT-Sitzung versendet werden, und nicht etwa gleichzeitig Kommunikationsdaten an den Teilnehmer versendet, die in zwei verschiedenen PTT-Sitzungen versendet werden, kann es vorkommen, dass im Rahmen einer PTT-Sitzung Kommunikationsdaten versendet werden, die von keinem Teilnehmer der PTT-Sitzung empfangen werden, obwohl Teilnehmer der PTT-Sitzung vorhanden sind. Somit kann bei einer PTT-Sitzung der Sender von Kommunikationsdaten nie sicher sein, dass die Kommunikationsdaten von den Teilnehmern empfangen werden, beispielsweise Sprachnachrichten von den anderen Teilnehmern gehört werden.

Es besteht daher die Möglichkeit, dass sich der Sender von Kommunikationsdaten in einer PTT-Sitzung gemäß dem Session Initiation Protocol (SIP) notifizieren lässt, ob von ihm versendete Audiodaten von den jeweiligen Participating Functions an die anderen Teilnehmer der PTT-Sitzung weitergeleitet werden. Der Versender der Audiodaten wird notifiziert, wenn er zu sprechen beginnt oder bevor er zu sprechen beginnt. Wenn die von einem Teilnehmer versendeten Kommunikationsdaten an keinen anderen Teilnehmer weitergeleitet werden, so kann dem Teilnehmer das Kommunikationsrecht entzogen werden.

Der Erfindung liegt das Problem zugrunde, eine gegenüber dem Stand der Technik effizientere Möglichkeit zu schaffen, im Rahmen von Konferenzsystemen Teilnehmer zu notifizieren, ob von den Teilnehmern versendete Kommunikationsdaten an andere Teilnehmer weitergeleitet werden.

Das Problem wird durch ein Konferenz-Kommunikationssystem, ein Verfahren zum Betreiben eines Konferenz-Kommunikationssystems, eine Notifizierungseinrichtung und ein Verfahren zum Notifizieren eines Kommunikationsendgeräts mit den Merkmalen gemäß den unabhängigen Patentansprüchen gelöst.

Es wird ein Konferenz=Kommunikationssystem mit einer Konferenz-Servereinheit, die eingerichtet ist, eine Konferenz für ein erstes Kommunikationsendgerät und ein zweites Kommunikationsendgerät bereitzustellen, und mit einer Weiterleitungseinrichtung zum Weiterleiten von Mediendaten im Rahmen der Konferenz bereitgestellt. Das erste Kommunikationsendgerät ist eingerichtet zum Übermitteln von Mediendaten an die Weiterleitungseinrichtung zum Weiterleiten an das zweite Kommunikationsendgerät. Das Konferenz-Kommunikationssystem weist eine Notifizierungseinrichtung auf, die eingerichtet ist, eine Notifizierungsnachricht gemäß einem Mediendatenübertragungs-Steuerungsprotokoll zum Steuern eines Mediendatenübertragungsprotokolls zu erzeugen, mittels welcher signalisiert wird, ob die Mediendaten an das zweite Kommunikationsendgerät weitergeleitet wurden.

Ferner werden ein Verfahren zum Betreiben eines Konferenz-Kommunikationssystems, eine Notifizierungseinrichtung und ein Verfahren zum Notifizieren eines Kommunikationsendgeräts gemäß dem oben beschriebenen Konferenz-Kommunikationssystem bereitgestellt.

Eine der Erfindung zu Grunde liegende Idee kann darin gesehen werden, dass eine Notifizierung eines Teilnehmers einer Konferenz bezüglich der Weiterleitung von von dem Teilnehmer versendeten Mediendaten an andere Teilnehmer der Konferenz mittels eines Mediendatenübertragungs-Steuerungsprotokolls, beispielsweise mittels des Real-Time-Kontrollprotokolls (Real Time Control Protocol, RTCP), also mittels Real-Time-Control-Protocol-Paketen (vorzugsweise des Pakettyps für anwendungsspezifische Funktionen (APP) des Real-Time-Kontrollprotokolls), realisiert wird.

Mittels der Notfifizierungsnachricht kann auch signalisiert werden, ob die Mediendaten von dem zweiten Kommunikationsendgerät empfangen wurden. Damit wird insbesondere impliziert, dass die Mediendaten an das zweite Kommunikationsendgerät weitergeleitet wurden.

Im Falle einer Push-to-talk-Kommunikationssitzung schafft die Erfindung eine effiziente Möglichkeit einen Teilnehmer einer Push-to-talk-Kommunikationssitzung darüber zu informieren, ob von ihm im Rahmen der Push-to-talk-Kommunikationssitzung versendete Mediendaten an andere Teilnehmer der Push-to-talk-Kommunikationssitzung weitergeleitet werden, was beispielsweise nicht der Fall ist, wenn einer der anderen Teilnehmer die Push-to-talk-Kommunikationssitzung als sekundäre Push-to-talk-Kommunikationssitzung festgelegt hat und im Rahmen der von ihm als primäre Push-to-talk-Kommunikationssitzung festgelegten Push-to-talk-Kommunikationssitzung Mediendaten an ihn weitergeleitet werden.

Weiterbildungen der Erfindung ergeben sich aus den abhängigen Ansprüchen. Die weiteren Ausgestaltungen der Erfindung, die im Zusammenhang mit dem Konferenz-Kommunikationssystem beschrieben sind, gelten sinngemäß auch für das Verfahren zum Betreiben eines Konferenz-Kommunikationssystems, die Notifizierungseinrichtung und das Verfahren zum Notifizieren eines Kommunikationsendgeräts.

Das Konferenz-Kommunikationssystem weist beispielsweise eine Sendeeinrichtung auf, die eingerichtet ist, die Notifizierungsnachricht an das erste Kommunikationsendgerät zu übermitteln.

Die Notifizierungsnachricht kann auch an andere Kommunikationsendgeräte übermittelt werden, beispielsweise an Kommunikationsendgeräte, die von anderen Teilnehmern als dem Benutzer des ersten Kommunikationsendgeräts verwendet werden aber auch an andere Geräte, die nicht direkt an der Konferenz beteiligt sind, beispielsweise an Kommunikationsendgeräte von Benutzern, die keine Teilnehmer der Konferenz sind.

Das Mediendatenübertragungsprotokoll ist in einer Ausführungsform ein Echtzeit-Mediendatenübertragungsprotokoll. Beispielsweise ist das Mediendatenübertragungs-Steuerungsprotokoll RTCP.

Die Verwendung von RTCP (Real Time Control Protocol) hat den Vorteil, das die Notifizierungsnachricht mit geringer Größe realisiert werden kann. Da beispielsweise im Falle eines Push-to-talk-Kommunikationssystems ohnehin eine RTCP-Kommunikationsverbindung besteht, muss nicht extra eine RTCP-Kommunikationsverbindung zur Übermittlung der Notifizierungsnachricht aufgebaut werden.

Durch Verwendung von RTCP ist insbesondere eine effizientere Notifizierung möglich, als sie mittels SIP (Session Initiation Protocol) erreicht werden kann.

Die Konferenz-Servereinheit weist in einer Ausführungsform die Weiterleitungseinrichtung auf.

Die Mediendaten sind beispielsweise Audiodaten, Videodaten oder Bilddaten.

Mittels der Notifizierungsnachricht kann signalisiert werden, ob die Mediendaten von dem zweiten Kommunikationsendgerät in ausreichender Qualität empfangen wurden, ob die Mediendaten von dem zweiten Kommunikationsendgerät ausgegeben wurden und/oder ob der Benutzer des zweiten Kommunikationsendgeräts den Empfang der Mediendaten bestätigt hat.

Beispielsweise versendet das erste Kommunikationsendgerät Empfangsbestätigungen, die von der Notifizierungseinrichtung (beispielsweise von der Participating Function im Falle eines PTT-Kommunikationssystems) ausgewertet werden. Nur wenn bestätigt wird, dass die Mediendaten von dem ersten Kommunikationsendgerät empfangen worden sind, wird (beispielsweise eine Controlling Function) notifiziert, das die Mediendaten erfolgreich weitergeleitet wurden. Dies hat den Vorteil, dass im Falle von Datenübertragungsfehlern, beispielsweise durch Unterbrechung einer Kommunikationsverbindung, nicht fälschlich signalisiert wird, dass die Mediendaten von dem ersten Kommunikationsendgerät empfangen worden sind.

Die Konferenz ist beispielsweise eine Push-to-talk (PTT)-Kommunikationssitzung. Das Konferenz-Kommunikationssystem kann gemäß dem IETF (Internet Engineering Task Force)-Standard für Konferenzsysteme ausgestaltet sein.

Im Falle einer PTT-Kommunikationssitzung kann eine einem Kommunikationsendgerät zugeordnete Participating Function sehr einfach feststellen, im Rahmen welcher Konferenz das Kommunikationsendgerät Daten empfängt, indem sie feststellt, welche Mediendaten an das Kommunikationsendgerät weitergeleitet werden. Die für die Erzeugung der Notifizierungsnachricht erforderlichen Informationen können also auf einfache und schnelle Weise bestimmt werden.

Das Konferenz-Kommunikationssystem weist in einer Ausführungsform ein weiteres Kommunikationsendgerät und eine weitere Notifizierungseinrichtung auf, die eingerichtet ist, eine weitere Notifizierungsnachricht gemäß dem Mediendatenübertragungs-Steuerungsprotokoll zu erzeugen, mittels welcher signalisiert wird, ob die Mediendaten an das weitere Kommunikationsendgerät weitergeleitet wurden.

In einer Ausführungsform werden die Notifizierungsnachricht und die weitere Notifizierungsnachricht an eine Verarbeitungseinrichtung übermittelt und die Verarbeitungseinrichtung ist eingerichtet, basierend auf der Notifizierungsnachricht und der weiteren Notifizierungsnachricht eine Gesamt-Notifizierungsnachricht zu erzeugen und an das erste Kommunikationsendgerät zu übermitteln.

Durch Zusammenfassen von Notifizierungsnachrichten zu einer Gesamt-Notifizierungsnachricht, im Falle von RTCP zu einem RTCP-Paket, kann gegenüber dem Fall, dass die Notifizierungsnachrichten einzeln an das erste Kommunikationsendgerät übermittelt werden, Übertragungskapazität eingespart werden.

Mittels der Gesamt-Notifizierungsnachricht kann der Benutzer des ersten Kommunikationsendgeräts beispielsweise darüber informiert werden, an welche Teilnehmer der Konferenz von ihm versendete Mediendaten (beispielsweise Sprachnachrichten) weitergeleitet worden sind.

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 Nachrichten-Flussdiagramm gemäß einem Ausführungsbeispiel der Erfindung.

4 zeigt ein Nachrichtenflussdiagramm gemäß einem Ausführungsbeispiel der Erfindung.

5 zeigt ein Nachrichtenflussdiagramm gemäß einem Ausführungsbeispiel der Erfindung.

6 zeigt einen Nachrichtenflussdiagramm gemäß einem Ausführungsbeispiel der Erfindung.

7 zeigt ein Nachrichtenflussdiagramm gemäß einem Ausführungsbeispiel der Erfindung.

1 zeigt ein Kommunikationssystem 100 gemäß einem Ausführungsbeispiel der Erfindung.

Mittels des Kommunikationssystems 100 können PTT-Konferenzen für eine Mehrzahl von Benutzern bereitgestellt werden. Ein erster Benutzer verwendet ein erstes Kommunikationsendgerät 101, ein zweiter Benutzer verwendet ein zweites Kommunikationsendgerät 102, ein dritter Benutzer verwendet ein drittes Kommunikationsendgerät 103, ein vierter Benutzer verwendet ein viertes Kommunikationsendgerät 104, ein fünfter Benutzer verwendet ein fünftes Kommunikationsendgerät 105, ein sechster Benutzer verwendet ein sechstes Kommunikationsendgerät 106 und ein siebter Benutzer verwendet ein siebtes Kommunikationsendgerät 107.

Das erste Kommunikationsendgerät 101 ist mittels einer ersten Participating Function 108 mit einer ersten Controlling Function 109 gekoppelt, das zweite Kommunikationsendgerät 102 ist mittels einer zweiten Participating Function 110 mit der ersten Controlling Function 109 gekoppelt, das dritte Kommunikationsendgerät 103 ist mittels einer dritten Participating Function 111 mit der ersten Controlling Function 109 gekoppelt, das vierte Kommunikationsendgerät 104 ist mittels einer vierten Participating Function 112 mit der ersten Controlling Function 109 gekoppelt, das fünfte Kommunikationsendgerät 105 ist mittels einer fünften Participating Function 113 mit einer zweiten Controlling Function 114 gekoppelt, das sechste Kommunikationsendgerät 106 ist mittels einer sechsten Participating Function 115 mit der zweiten Controlling Function 114 gekoppelt und das siebte Kommunikationsendgerät 107 ist mittels einer siebten Participating Function 116 mit der zweiten Controlling Function 114 gekoppelt.

Die erste Participating Function 108, die zweite Participating Function 110, die dritte Participating Function 111 und die vierte Participating Function 112 sowie die erste Controlling Function 109 werden mittels eines ersten PTT (Push To Talk)-Serverrechners 117 realisiert. Die fünfte Participating Function 113, die sechste Participating Function 115, die siebte Participating Function 116 und die zweite Controlling Function 114 werden mittels eines zweiten PTT-Serverrechners 118 realisiert.

Die erste Controlling Function 109 stellt eine erste PTT-Sitzung, das heißt eine Push-to-talk-Konferenz, für das erste Kommunikationsendgerät 101, das zweite Kommunikationsendgerät 102, das dritte Kommunikationsendgerät 103 und das vierte Kommunikationsendgerät 104 (beziehungsweise für die entsprechenden Benutzer) bereit. Die zweite Controlling Function 114 stellt eine zweite PTT-Sitzung für das fünfte Kommunikationsendgerät 105, das sechste Kommunikationsendgerät 106 und das siebte Kommunikationsendgerät 107 (beziehungsweise für die entsprechenden Benutzer) bereit.

Im Rahmen der ersten PTT-Sitzung und der zweiten PTT-Sitzung senden und empfangen die jeweiligen Teilnehmer Kommunikationsdaten (Mediendaten). In diesem Ausführungsbeispiel wird im Rahmen der PTT-Sitzungen mittels Audiodaten kommuniziert.

Der erste Teilnehmer, d.h. der Benutzer des ersten Kommunikationsendgeräts 101, wählt sich nun zusätzlich zu der ersten PTT-Sitzung auch in die zweite PTT-Sitzung ein. Dazu baut die erste Participating Function 108 eine Kommunikationsverbindung 119 zu der zweiten Controlling Function 114 auf. Die zweite Controlling Function 114 wird wie erwähnt von dem zweiten PTT-Serverrechner 118 realisiert. Die erste Participating Function 108 wird jedoch weiterhin von dem ersten PTT-Serverrechner 117 realisiert.

Es wird angenommen, dass der erste Teilnehmer die zweite PTT-Sitzung als primäre Sitzung ausgewählt hat und die erste PTT-Sitzung als sekundäre Sitzung ausgewählt hat. Dies bedeutet, dass alle im Rahmen der zweiten PTT-Sitzung versendeten Audio-Nachrichten (außer die von dem ersten Teilnehmer selbst versendeten Audio-Nachrichten) an das erste Kommunikationsendgerät 101 weitergeleitet werden. Audio-Nachrichten, die im Rahmen der ersten PTT-Sitzung versendet werden, werden jedoch nur dann an das erste Kommunikationsendgerät 101 weitergeleitet, wenn im Rahmen der zweiten PTT-Sitzung gegenwärtig keine Audio-Nachrichten versendet werden.

Zunächst wird angenommen, dass im Rahmen der zweiten PTT-Sitzung keine Audio-Nachricht versendet wird, und dass der zweite Teilnehmer, d.h. der Benutzer des zweiten Kommunikationsgeräts 102 im Rahmen der ersten PTT-Sitzung eine Audio-Nachricht versenden möchte.

Der entsprechende Nachrichtenfluss ist in 2 dargestellt.

2 zeigt ein Nachrichtenflussdiagramm 200 gemäß einem Ausführungsbeispiel der Erfindung.

Der dargestellte Nachrichtenfluss findet zwischen dem zweiten Kommunikationsendgerät 102, der ersten Controlling Function 109, der ersten Participating Function 108 und dem ersten Kommunikationsendgerät 101 statt.

Der zweite Teilnehmer drückt eine an dem zweiten Kommunikationsendgerät 102 vorgesehene PTT-Taste und beginnt zu sprechen. Das zweite Kommunikationsendgerät 102 erzeugt entsprechende Sprachdaten 201, die von dem zweiten Kommunikationsendgerät 102 mittels der zweiten Participating Function 110 an die erste Controlling Function 109 gesendet werden, welche die Sprachdaten 201 an die erste Participating Function 108 weiterleitet. Die erste Participating Function 108 leitet die Sprachdaten 201 an das erste Kommunikationsendgerät 101 weiter und sendet eine Notifizierungsnachricht 202 an die erste Controlling Function 109, mittels welcher die erste Controlling Function 109 darüber notifiziert wird, dass die Sprachdaten 201 an das erste Kommunikationsendgerät 101 weitergeleitet werden.

Die Pfeile 203 symbolisieren den jeweiligen Beginn der Übermittlung der Sprachdaten 201 (SAD: Start of Audio Data). Die Notifizierungsnachricht 202 wird in diesem Ausführungsbeispiel von der ersten Participating Function 108 versendet, sobald die erste Participating Function 108 mit dem Senden der Sprachdaten 201 an das erste Kommunikationsendgerät 101 begonnen hat. Die Notifizierungsnachricht 202 ist gemäß dem RTCP (Real Time Control Protocol) ausgestaltet, beispielsweise wie in Tabelle 1 gezeigt.

In Tabelle 1 (und bei den folgenden Tabellen, falls ein entsprechender Eintrag vorhanden ist) bedeuten:

  • V=2: Versionsnummer des RTP (Real Time Protocol)
  • P: Indikator für Padding
  • 01010: Subtyp der Nachricht, in diesem Beispiel bedeutet der Beispielwert 01010, dass es sich bei der Nachricht um eine Notifizierung über den Empfang von Audiodaten handelt (es können auch andere Werte verwendet werden).
  • PT=APP=204: Indikator dafür, dass es sich um eine Applikations-definierte RTCP-Nachricht handelt
  • Length: Gibt die Menge der Nachricht ab dem Length-Feld in Wörtern (32 Bit) an.
  • SSRC: Gibt den Synchronisation Source der Participating Function an, die die Nachricht versendet. Die SSRC identifiziert einen Sender eines Medien-Stroms eindeutig und wird in dem zu der RTCP-Nachricht gehörenden RTP-Paketen definiert.
  • Name=PoC1: Applikations-definierter Nachrichten-Name (PoC1=PTT over Cellular Version 1)
  • SDES CNAME item followed by SDES NAME item: CNAME und NAME des Kommunikationsendgeräts, an das Kommunikationsdaten weitergeleitet werden, worüber mittels der Nachricht notifiziert wird (in diesem Beispiel des ersten Kommunikationsendgeräts 101). CNAME und NAME sind SDES (Source Description RTCP Packets) Items, die in SDES RTCP-Paketen definiert werden um einen RTP-Teilnehmer zu beschreiben. CNAME ist ein eindeutiger Name des RTP-Teilnehmers, der auch außerhalb spezifischer RTP-Sessions weiter besteht, beispielsweise ist er zusammengesetzt aus einem User-Namen und einer Host-IP (Internet Protocol)-Adresse. NAME ist ein beliebiger Name des RTT-Teilnehmers, der typischerweise von dem RTP-Teilnehmers selbst definiert wird. NAME muss den RTP-Teilnehmer nicht eindeutig identifizieren. Wie bei SDES RTCP-Paketen wird die Liste der SDES Items CNAME und NAME durch ein SDES Item vom Typ 00000000 sindeutig abgeschlossen. Die Liste wird anschließend bis zu vielfachen von 32 Bit durch Padding von Nullen aufgefüllt (siehe [3]).

Auch die dritte Participating Function 111 und die vierte Participating Function 112 senden analog zu der Notifizierungsnachricht 202 entsprechende Notifizierungen an die erste Controlling Function 109. Die erste Controlling Function sammelt alle Notifizierungen. Das heißt, dass die erste Controlling Function 109 wartet, bis sie Notifizierungen für alle Teilnehmer außer für den Benutzer des zweiten Kommunikationsendgeräts 102 von den den Teilnehmern zugeordneten Participating Functions empfangen hat. Dies ist in 3 dargestellt.

3 zeigt ein Nachrichten-Flussdiagramm 300 gemäß einem Ausführungsbeispiel der Erfindung.

Der dargestellte Nachrichtenfluss findet zwischen der ersten Controlling Function 109, der ersten Participating Function 108, der zweiten Participating Function 110, der dritten Participating Function 111 und der vierten Participating Function 112 statt.

Die von dem zweiten Kommunikationsendgerät 102 versendeten Sprachdaten 201 werden von der ersten Controlling Function 109 an die erste Participating Function 108, die dritte Participating Function 111 und die vierte Participating Function 112 gesendet (die Pfeile 305 symbolisieren den jeweiligen Beginn der Übermittlung der Sprachdaten 201). Die erste Participating Function 108 bestätigt mittels einer ersten Notifizierungsnachricht 301, dass sie die Sprachdaten 201 an das erste Kommunikationsendgerät 101 weiterleitet, sobald sie mit der Weiterleitung beginnt. Analog sendet die dritte Participating Function 111 eine zweite Notifizierungsnachricht 302 und die vierte Participating Function 112 sendet eine dritte Notifizierungsnachricht 303. Nachdem die erste Controlling Function 109 die Notifizierungen in Form der Notifizierungsnachrichten 301, 302, 303 erhalten hat, kombiniert sie die Notifizierungen zu einer Gesamt-Notifizierungsnachricht 304 und sendet diese an die zweite Participating Function 110.

Die erste Notifizierungsnachricht 301, die zweite Notifizierungsnachricht 302 und die dritte Notifizierungsnachricht 303 werden derart zu der Gesamt-Notifizierungsnachricht 304 kombiniert, dass die entsprechenden Notifizierungen über die Weiterleitung der von dem zweiten Kommunikationsendgerät versendeten Audiodaten in einer ersten Liste zusammengefasst werden. In dem Fall, dass eine der Participating Functions 108, 111, 112 die Kommunikationsdaten nicht an das entsprechende Kommunikationsendgerät 101, 103, 104 weiterleitet (wie er in einem unten beschriebenen Beispiel auftritt), notifiziert sie mittels der von ihr gesendeten Notifizierungsnachricht 301, 302, 303 die erste Controlling Function 109 darüber, dass sie die Kommunikationsdaten nicht weiterleitet. Notifizierungen darüber, dass die Kommunikationsdaten nicht weitergeleitet wurden, werden von der ersten Controlling Function 109 in einer zweiten Liste zusammengefasst. Die erste Liste und die zweite Liste sind in der vierten Notifizierungsnachricht 304 enthalten. Die vierte Notifizierungsnachricht 304 ist gemäß RTCP ausgestaltet, beispielsweise wie in Tabelle 2 dargestellt.

In Tabelle 2 ist

  • 01010: Subtyp der Nachricht, in diesem Beispiel bedeutet der Beispielwert 01010, dass es sich bei der Nachricht um eine Notifizierung über den Empfang von Audiodaten handelt (es können auch andere Werte verwendet werden).
  • list 1 of SDES CNAME item followed by SDES NAME item: Liste von Paaren der CNAMEs und NAMEs der Kommunikationsendgeräte, an die die Kommunikationsdaten weitergeleitet werden (das heißt eine Angabe der ersten Liste). Die Liste wird durch ein SDES Item vom Typ 00000000 eindeutig abgeschlossen.
  • list 2 of SDES CNAME item followed by SDES NAME item: Liste von Paaren der CNAMEs und NAMEs der Kommunikationsendgeräte, an die die Kommunikationsdaten nicht weitergeleitet werden (das heißt eine Angabe der zweiten Liste). Die Liste wird durch ein SDES Item vom Typ 00000000 eindeutig abgeschlossen. Die Liste wird anschließend durch Padding von Nullen bis zu vielfachen von 32 Bit aufgefüllt.

Nun wird angenommen, dass im Rahmen der zweiten PTT-Sitzung der siebte Teilnehmer, d.h. der Benutzer des siebten Kommunikationsendgeräts 107 Sprachdaten versendet, die, da der erste Teilnehmer die zweite PTT-Sitzung als primäre Sitzung festgelegt hat, an das erste Kommunikationsendgerät 101 weitergeleitet werden.

Dies wird im Folgenden mit Bezug auf 4 erläutert.

4 zeigt ein Nachrichtenflussdiagramm 400 gemäß einem Ausführungsbeispiel der Erfindung.

Der dargestellte Nachrichtenfluss findet zwischen dem zweiten Kommunikationsendgerät 102, der ersten Controlling Function 109, der ersten Participating Function 108, dem ersten Kommunikationsendgerät 101 und der zweiten Controlling Function 114 statt.

Die zweite Controlling Function 114 empfängt Sprachdaten 401 von dem siebten Kommunikationsendgerät 107 und leitet diese an die erste Participating Function 108 weiter. Die erste Participating Function 108 leitet die Sprachdaten 401 an das erste Kommunikationsendgerät 101 weiter und zeigt dies der zweiten Controlling Function 114 mittels einer ersten Notifizierungsnachricht 402 an.

Versendet nun das zweite Kommunikationsendgerät 102 im Rahmen der ersten PTT-Sitzung weitere Sprachdaten 403, so werden diese von der ersten Controlling Function 109 an die erste Participating Function 108 weitergeleitet, die erste Participating Function 108 leitet die weiteren Sprachdaten 403 jedoch nicht an das erste Kommunikationsendgerät 101weiter, da bereits im Rahmen der zweiten PTT-Sitzung (und somit der primären PTT-Sitzung des ersten Kommunikationsendgeräts 101) versendete Sprachdaten an das erste Kommunikationsendgerät 101 weitergeleitet werden.

Entsprechend notifiziert die erste Participating Function 108 die erste Controlling Function 109 mittels einer zweiten Notifizierungsnachricht 404, dass die weiteren Sprachdaten 403 nicht an das erste Kommunikationsendgerät 101 weitergeleitet werden.

Die zweite Notifizierungsnachricht 404 ist beispielsweise wie die Gesamt-Notifizierungsnachricht 304 gemäß Tabelle 2 ausgestaltet, wobei in list 2 of SDES CNAME item followed by SDES NAME item nur der erste Teilnehmer eingetragen ist.

Die erste Notifizierungsnachricht 402 ist beispielsweise wie oben gemäß Tabelle 1 ausgestaltet.

Die Pfeile 405 symbolisieren den Beginn der jeweiligen Übertragung von Sprachdaten.

Nun wird angenommen, dass das Versenden von Kommunikationsdaten im Rahmen der zweiten PTT-Sitzung beendet wird. Der entsprechende Nachrichtenfluss wird im Folgenden mit Bezug auf 5 erläutert.

5 zeigt ein Nachrichtenflussdiagramm 500 gemäß einem Ausführungsbeispiel der Erfindung.

Der dargestellte Nachrichtenfluss findet zwischen dem zweiten Kommunikationsendgerät 102, der ersten Controlling Function 109, der ersten Participating Function 108, dem ersten Kommunikationsendgerät 101 und der zweiten Controlling Function 114 statt.

Das siebte Kommunikationsendgerät 107 beendet das Senden der Sprachdaten 401 im Rahmen der zweiten PTT-Sitzung. Somit erfolgt das Ende des Weiterleitens der Sprachdaten von der ersten Participating Function 108 zu dem ersten Kommunikationsendgerät 101, was in 5 durch den Block 501 angedeutet ist (EAD: End of Audio Data). Es wird angenommen, dass in der zweiten PTT-Sitzung nun keine Kommunikationsdaten mehr versendet werden.

Dementsprechend leitet die erste Participating Function 108 die von dem zweiten Kommunikationsendgerät 102 versendeten weiteren Sprachdaten 403 nun an das erste Kommunikationsendgerät 101 weiter (der Pfeil 503 symbolisiert den Beginn dieser Datenübertragung). Ferner informiert die erste Participating Function 108 die erste Controlling Function 109 mittels einer Notifizierungsnachricht 502, dass die weiteren Sprachdaten 403 an das erste Kommunikationsendgerät 101 weitergeleitet werden.

Nun wird angenommen, dass im Rahmen der zweiten PTT-Sitzung erneut Kommunikationsdaten von dem siebten Kommunikationsendgerät 107 versendet werden. Der entsprechende Nachrichtenfluss ist in 6 dargestellt.

6 zeigt einen Nachrichtenflussdiagramm 600 gemäß einem Ausführungsbeispiel der Erfindung.

Der dargestellte Nachrichtenfluss findet zwischen dem zweiten Kommunikationsendgerät 102, der ersten Controlling Function 109, der ersten Participating Function 108, dem ersten Kommunikationsendgerät 101, der zweiten Controlling Function 114 und dem siebten Kommunikationsendgerät 107 statt. Das siebte Kommunikationsendgerät 107 versendet Sprachdaten 601 im Rahmen der zweiten PTT-Sitzung. Die Sprachdaten 601 werden von der zweiten Controlling Function 114 an die erste Participating Function 108 weitergeleitet. Die erste Participating Function 108 beendet daraufhin das Weiterleiten der von dem zweiten Kommunikationsendgerät 102 versendeten weiteren Sprachdaten 403 an das erste Kommunikationsendgerät 101, was in 6 durch Block 602 angedeutet ist.

Anschließend beginnt die erste Participating Function 108 die Sprachdaten 601 an das erste Kommunikationsendgerät 101 weiterzuleiten und notifiziert die zweite Controlling Function 114 mittels einer ersten Notifizierungsnachricht 603 darüber, dass die Sprachdaten 601 an das erste Kommunikationsendgerät 101 weitergeleitet werden. Ferner notifiziert die erste Participating Function 108 die erste Controlling Function 109 mittels einer zweiten Notifizierungsnachricht 604 darüber, dass die von dem zweiten Kommunikationsendgerät 102 versendeten weiteren Sprachdaten 403 nicht mehr an das erste Kommunikationsendgerät 101 weitergeleitet werden.

Analog zu oben symbolisieren die Pfeile 605 den Beginn der jeweiligen Datenübertragung.

7 illustriert das Vorgehen in dem Fall, dass eine Controlling Function von einer Participating Function nicht notifiziert wird.

7 zeigt ein Nachrichtenflussdiagramm 700 gemäß einem Ausführungsbeispiel der Erfindung.

Der dargestellte Nachrichtenfluss findet zwischen der ersten Controlling Function 109, der ersten Participating Function 108 und dem ersten Kommunikationsendgerät 101 statt.

Die erste Controlling Function 109 versendet Audiodaten 701 an die erste Participating Function 108, welche die Audiodaten 701 an das erste Kommunikationsendgerät 101 weiterleitet. Dementsprechend versendet die erste Participating Function 108 eine erste Notifizierungsnachricht 702 an die erste Controlling Function 109. Es wird angenommen, dass die Notifizierungsnachricht 702 jedoch nicht von der ersten Controlling Function 109 empfangen wird, beispielsweise weil die erste Notifizierungsnachricht 702 durch einen Übertragungsfehler verloren geht. Es kann auch sein, dass die erste Notifizierungsnachricht 702 gar nicht erst von der ersten Participating Function 108 versendet wird, da die Audiodaten 701, beispielsweise aufgrund eines Datenübertragungsfehlers, nicht von der ersten Participating Function 108 empfangen wurden. In jedem Fall empfängt die erste Controlling Function 109 somit keine Notifizierung von der ersten Participating Function 108, die anzeigt, ob die Audiodaten 701 an das erste Kommunikationsendgerät 101 weitergeleitet werden. Nach einer gewissen Wartezeit T fordert deshalb die erste Controlling Function 109 mittels einer Notifizierungs-Anforderungsnachricht 703 eine Notifizierung von der Participating Function 108 an. Als Reaktion darauf versendet die Participating Function 108 eine zweite Notifizierungsnachricht 704 als Wiederholung der ersten Notifizierungsnachricht 702.

Die Notifizierungs-Anforderungsnachricht 703 ist in diesem Ausführungsbeispiel gemäß RTCP ausgestaltet und wird gemäß RTCP versendet und ist beispielsweise gemäß Tabelle 3 ausgestaltet.

Die Zeichenkette 01011 in Tabelle 3 zeigt an, dass es sich bei der gemäß Tabelle 3 ausgestalteten Nachricht um eine Notifizierungs-Anforderungsnachricht handelt, dieser Wert ist nur ein Beispielwert, es können auch andere Werte verwendet werden. SSRC ist die Synchronisation Source des Medienstroms der Controlling Function, die die Notifizierungs-Anforderung versendet und identifiziert die Controlling Function und den Medienstrom eindeutig.

In einer Ausführungsform ist es vorgesehen, dass Notifizierungen an einen Teilnehmer über die Weiterleitungen von Mediendaten versendet werden, wenn der Teilnehmer selbst noch keine Mediendaten versendet. Die Notifizierungen geben somit an, ob von dem Teilnehmer versendete Mediendaten an andere Teilnehmer (derselben PTT-Sitzung) weitergeleitet werden würden, wenn der Teilnehmer Mediendaten versenden würde.

In einer Ausführungsform ist es vorgesehen, dass an einen Teilnehmer das Kommunikationsrecht, d.h. das Recht, Kommunikationsdaten (Mediendaten) im Rahmen einer PTT-Sitzung zu versenden, nicht vergeben wird, wenn von ihm versendete Kommunikationsdaten an keinen weiteren Teilnehmer der PTT-Sitzung weitergeleitet werden würden. Werden Kommunikationsdaten, die von einem Teilnehmer versendet werden, nicht mehr an andere Teilnehmer weitergeleitet (beispielsweise da die anderen Teilnehmer jetzt Kommunikationsdaten im Rahmen ihrer jeweiligen primären anderen PTT-Sitzung empfangen), kann dem Teilnehmer das Kommunikationsrecht durch den entsprechenden PTT-Serverrechner entzogen werden (dies wird als revoke bezeichnet).

Ferner kann es vorgesehen sein, dass Notifizierungen nur dann versendet werden, wenn Kommunikationsdaten an einen Teilnehmer weitergeleitet werden und somit nicht Notifizierungen darüber versendet werden, dass Kommunikationsdaten nicht an einen Teilnehmer weitergeleitet werden. Im Gegensatz zu dem obigen Ausführungsbeispiel darf die entsprechende Controlling Function jedoch in diesem Fall nicht auf Notifizierungen von allen Teilnehmern warten, bevor eine Gesamt-Notifizierung erstellt wird und an den Teilnehmer, der die Kommunikationsdaten versendet, übermittelt wird. Statt dessen versendet die Controlling Function beispielsweise immer nach einer festgelegten Zeitdauer nach dem Versenden der Kommunikationsdaten eine Gesamt-Notifizierung an den Teilnehmer, der die Kommunikationsdaten versendet. Alternativ kann die Controlling Function immer nach dem Empfang einer Notifizierung von einem Teilnehmer eine Notifizierung an den Teilnehmer, der die Kommunikationsdaten versendet, übermitteln.

In einer Ausführungsform, in der sowohl Notifizierungen darüber, dass Kommunikationsdaten an Teilnehmer weitergeleitet werden, als auch Notifizierungen, dass Kommunikationsdaten nicht an Teilnehmer weitergeleitet werden, versendet werden, kann auch vorgesehen sein, dass die Controlling Function eine Gesamt-Notifizierung versendet, wenn die Controlling Function eine Notifizierung von einer Participating Function erhält. Es werden also nicht nur dann Gesamt-Notifizierungen an den Teilnehmer, der Kommunikationsdaten versendet, übermittelt, wenn die Controlling Function Notifizierungen darüber empfängt, dass die Kommunikationsdaten weitergeleitet werden, sondern auch dann, wenn sie Notifizierungen darüber empfängt, das Kommunikationsdaten nicht weitergeleitet werden.

Es kann auch vorgesehen sein, dass eine Participating Function nur dann eine Notifizierung versendet, wenn sie Kommunikationsdaten nicht an den entsprechenden Teilnehmer weiterleitet und nicht, wenn sie Kommunikationsdaten weiterleitet.

Es kann auch vorgesehen sein, dass eine kombinierte (Gesamt-)Notifizierung immer nur dann versendet wird, wenn sich der Zustand, an welche Teilnehmer versendete Kommunikationsdaten im Rahmen der PTT-Sitzung weitergeleitet werden, geändert hat. Beispielsweise kann es sein, dass die Weiterleitung von Kommunikationsdaten an einen Teilnehmer, die im Rahmen der von ihm als sekundäre PTT-Sitzung festgelegten PTT-Sitzung versendet werden, zu einem Zeitpunkt beendet wird, da zu dem Zeitpunkt im Rahmen der primären PTT-Sitzung des Teilnehmers das Versenden von Kommunikationsdaten beginnt, die an ihn weitergeleitet werden. Über diesen Wechsel des Empfangsstatus (oder Weiterleitungsstatus) des Teilnehmers kann der Versender der Kommunikationsdaten, die im Rahmen der sekundären Sitzung des Teilnehmers versendet werden, informiert werden.

Auch bei einem Wechsel des Versenders von Kommunikationsdaten im Rahmen der sekundären Sitzung werden die versendeten Kommunikationsdaten nicht an den Teilnehmer weitergeleitet. In diesem Fall wird beispielsweise nur eine Notifizierung versendet darüber, dass die Kommunikationsdaten nicht an den Teilnehmer weitergeleitet werden, und nicht jedes Mal Notifizierungen versendet, wenn der Versender innerhalb der sekundären PTT-Sitzung wechselt.

Bei den oben beschriebenen Ausführungsbeispielen werden von einer Participating Function Notifizierungen darüber versendet, ob im Rahmen einer PTT-Sitzung versendete Kommunikationsdaten von der Participating Function an ein Kommunikationsendgerät weitergeleitet werden. Analog können Notifizierungen darüber versendet werden

  • 1) ob die weitergeleiteten Kommunikationsdaten tatsächlich von dem Kommunikationsendgerät in ausreichender Qualität empfangen worden sind. Die Qualität der Übertragung der Kommunikationsdaten kann aus den RTCP-Receiver Reports des Kommunikationsendgeräts, die an die Participating Function gesendet werden, gefolgert werden, kann aber auch mittels spezieller RTCP-Pakete signalisiert werden. Eine entsprechende Notifizierung wird dann von der Participating Function an die entsprechende Controlling Function übermittelt.
  • 2) ob die weitergeleiteten Kommunikationsdaten tatsächlich von dem Kommunikationsendgerät für den Benutzer des Kommunikationsendgeräts ausgegeben wurden (im Falle von Sprachdaten beispielsweise abgespielt wurden). Dazu meldet das Kommunikationsendgerät mittels einer entsprechenden Nachricht den Empfang der Kommunikationsdaten der Participating Function. Die Nachricht ist beispielsweise gemäß Tabelle 1 ausgestaltet.
  • 3) ob der Teilnehmer, d.h. der Benutzer des Kommunikationsendgeräts, den Empfang der Kommunikationsdaten bestätigt hat. Dazu meldet das Kommunikationsendgerät den Empfang der Kommunikationsdaten erst dann der Participating Function, wenn der Teilnehmer den Empfang bestätigt hat, beispielsweise durch Betätigen einer speziellen Taste an dem Kommunikationsendgerät. Das Kommunikationsendgerät meldet dies der Participating Function mittels einer Nachricht, die beispielsweise gemäß Tabelle 1 ausgestaltet ist.

Es kann auch vorgesehen sein, dass die Art des Empfangs der Kommunikationsdaten (d.h. von der Participating Function weitergeleitet, in ausreichender Qualität empfangen, Kommunikationsdaten ausgegeben oder Empfang der Kommunikationsdaten durch die Teilnehmer bestätigt) in den Notifizierungen angegeben ist. Dies wird beispielsweise in einer Notifizierung gemäß RTCP mittels eines Elements „Received Type" angezeigt.

Statt Notifizierungen automatisch bei bestimmten Ereignissen zu versenden (beispielsweise wie oben beschrieben, immer dann, wenn ein Teilnehmer mit dem Versenden von Kommunikationsdaten beginnt oder wenn sich der Empfangsstatus eines Teilnehmers ändert, d.h. wenn einem Teilnehmer zunächst die Kommunikationsdaten nicht weitergeleitet wurden und jetzt weitergeleitet werden oder umgekehrt) kann es auch vorgesehen sein, Notifizierungen nur oder zusätzlich auf Anforderung zu versenden. Eine Anforderung nach einer Notifizierung kann beispielsweise gemäß Tabelle 3 ausgestaltet sein. Eine Notifizierung kann durch eine Controlling Function von einer Participating Function angefordert werden oder durch eine Participating Function von der Controlling Function oder von dem der Participating Function zugeordneten Kommunikationsendgerät angefordert werden oder durch ein Kommunikationsendgerät von der dem Kommunikationsendgerät zugeordneten Participating Function angefordert werden.

Es kann auch vorgesehen sein, dass Notifizierungen periodisch wiederholt vorgenommen werden. Periodische Notifizierungen können zusätzlich zu Ereignis-getriggerten oder angeforderten Notifizierungen vorgenommen werden. Die periodischen Notifizierungen werden nur während der Übermittlung von Kommunikationsdaten vorgenommen. Periodische Notifizierungen können beispielsweise mittels einer Nachricht angefordert werden, die gemäß Tabelle 4 ausgestaltet ist.

Die Bit-Kombination 01100 zeigt den Subtyp der Nachricht an, nämlich dass es sich um eine periodische Notifizierungs-Anforderung handelt (wie oben können auch andere Werte verwendet werden). Der Wert period gibt an, mit welcher Periode die angeforderten periodischen Notifizierungen versendet werden sollen (in ms). Der Wert wird als positiver 32 Bit-Integer-Wert angegeben. Der Wert 0 bedeutet einmalige Notifizierung.

Das in Tabelle 4 dargestellte Nachrichtenformat entspricht dem in Tabelle 3 dargestellten Nachrichtenformat mit zusätzlicher Periodizitäts-Angabe (durch den Wert Period). Periodische Notifizierungen können durch die Controlling Function von einer Participating Function angefordert werden oder durch eine Participating Function von der Controlling Function oder dem der Participating Function zugehörigen Kommunikationsendgerät oder durch das Kommunikationsendgerät von der dem Kommunikationsendgerät zugehörigen Participating Function.

In den Notifizierungsnachrichten gemäß RTCP können die Kommunikationsendgeräte, an die die Kommunikationsdaten gegebenenfalls weitergeleitet werden, auch durch andere Identifikatoren als CNAME und NAME identifiziert werden. Zur Identifizierung der Kommunikationsendgeräte können beispielsweise auch andere SDES Items der RTP-Spezifikation (siehe [3]) verwendet werden.

In diesem Dokument sind folgende Veröffentlichungen zitiert:

  • [1] IETF Internet Draft "The Binary Floor Control Protocol (BFCP)" (draft-ietf-xcon-bfcp-02.txt), Oktober 2004
  • [2] Open Mobile Alliance: "PoC User Plane Version 1", Candidate Version 1.0, April 2005
  • [3] IETF Request For Comments RFC3550, "RTP: A Transport Protocol for Real-Time Applications" (rfc3550), Juli 2003
  • [4] IETF Internet Draft " A Session Initiation Protocol (SIP) Event Package for Conference State" (draft-ietf-sipping-conference-package-06.txt), Oktober 2004
  • [5] IETF Internet Draft " A Framework for Conferencing with the Session Initiation Protocol" (draft-ietf-sipping-conferencing-framework-00.txt), Mai 2003
  • [6] Open Mobile Alliance: "Push to talk over Cellular (PoC)-Architecture", Draft Version 1.0, Nov. 2004

100
Kommunikationssystem
101–107
Kommunikationsendgeräte
108
Participating Function
109
Controlling Function
110–113
Participating Functions
114
Controlling Function
115, 116
Participating Functions
117, 118
PTT-Serverrechner
119
Kommunikationsverbindung
200
Nachrichtenflussdiagramm
201
Sprachdaten
202
Notifizierungsnachricht
203
Pfeile
300
Nachrichtenflussdiagramm
301–303
Notifizierungsnachrichten
304
Gesamtnotifizierungsnachricht
305
Pfeile
400
Nachrichtenflussdiagramm
401
Sprachdaten
402
Notifizierungsnachricht
403
weitere Sprachdaten
404
Notifizierungsnachricht
405
Pfeile
500
Nachrichtenflussdiagramm
501
Block
502
Notifizierungsnachricht
503
Pfeil
600
Nachrichtenflussdiagramm
601
Sprachdaten
602
Block
603,604
Notifizierungsnachrichten
605
Pfeile
700
Nachrichtenflussdiagramm
701
Audiodaten
702
Notifizierungsnachricht
703
Notifizierungs-Anforderungsnachricht
704
Notifizierungsnachricht


Anspruch[de]
Konferenz-Kommunikationssystem

– mit einer Konferenz-Servereinheit, die eingerichtet ist, eine Konferenz für ein erstes Kommunikationsendgerät und ein zweites Kommunikationsendgerät bereitzustellen;

– mit einer Weiterleitungseinrichtung zum Weiterleiten von Mediendaten im Rahmen der Konferenz;

– wobei das erste Kommunikationsendgerät eingerichtet ist zum Übermitteln von Mediendaten an die Weiterleitungseinrichtung zum Weiterleiten an das zweite Kommunikationsendgerät;

– wobei das Konferenz-Kommunikationssystem eine Notifizierungseinrichtung aufweist, die eingerichtet ist, eine Notifizierungsnachricht gemäß einem Mediendatenübertragungs-Steuerungsprotokoll zum Steuern eines Mediendatenübertragungsprotokolls zu erzeugen, mittels welcher signalisiert wird, ob die Mediendaten an das zweite Kommunikationsendgerät weitergeleitet wurden.
Konferenz-Kommunikationssystem gemäß Anspruch 1, das eine Sendeeinrichtung aufweist, die eingerichtet ist, die Notifizierungsnachricht an das erste Kommunikationsendgerät zu übermitteln. Konferenz-Kommunikationssystem gemäß Anspruch 1 oder 2, wobei das Mediendatenübertragungsprotokoll ein Echtzeit-Mediendatenübertragungsprotokoll ist. Konferenz-Kommunikationssystem gemäß einem der Ansprüche 1 bis 3, wobei das Mediendatenübertragungs-Steuerungsprotokoll RTCP ist. Konferenz-Kommunikationssystem gemäß einem der Ansprüche 1 bis 4, wobei die Konferenz-Servereinheit die Weiterleitungseinrichtung aufweist. Konferenz-Kommunikationssystem gemäß einem der Ansprüche 1 bis 5, wobei die Mediendaten Audiodaten, Videodaten oder Bilddaten sind. Konferenz-Kommunikationssystem gemäß einem der Ansprüche 1 bis 6, wobei mittels der Notifizierungsnachricht signalisiert wird, ob die Mediendaten von dem zweiten Kommunikationsendgerät in ausreichender Qualität empfangen wurden, ob die Mediendaten von dem zweiten Kommunikationsendgerät ausgegeben wurden und/oder ob der Benutzer des zweiten Kommunikationsendgeräts den Empfang der Mediendaten bestätigt hat. Konferenz-Kommunikationssystem gemäß einem der Ansprüche 1 bis 7, wobei die Konferenz eine Push-to-talk-Kommunikationssitzung ist. Konferenz-Kommunikationssystem gemäß einem der Ansprüche 1 bis 8, wobei das Konferenz-Kommunikationssystem ein weiteres Kommunikationsendgerät und eine weitere Notifizierungseinrichtung aufweist, die eingerichtet ist, eine weitere Notifizierungsnachricht gemäß dem Mediendatenübertragungs-Steuerungsprotokoll zu erzeugen, mittels welcher signalisiert wird, ob die Mediendaten an das weitere Kommunikationsendgerät weitergeleitet wurden. Konferenz-Kommunikationssystem gemäß Anspruch 9, wobei die Notifizierungsnachricht und die weitere Notifizierungsnachricht an eine Verarbeitungseinrichtung übermittelt werden und die Verarbeitungseinrichtung eingerichtet ist, basierend auf der Notifizierungsnachricht und der weiteren Notifizierungsnachricht eine Gesamt-Notifizierungsnachricht zu erzeugen und an das erste Kommunikationsendgerät zu übermitteln. Verfahren zum Betreiben eines Konferenz-Kommunikationssystems mit einer Konferenz-Servereinheit, die eingerichtet ist, eine Konferenz für ein erstes Kommunikationsendgerät und ein zweites Kommunikationsendgerät bereitzustellen, und einer Weiterleitungseinrichtung zum Weiterleiten von Mediendaten im Rahmen der Konferenz, bei dem

– das erste Kommunikationsendgerät Mediendaten an die Weiterleitungseinrichtung zum Weiterleiten an das zweite Kommunikationsendgerät übermittelt;

– eine Notifizierungsnachricht gemäß einem Mediendatenübertragungs-Steuerungsprotokoll zum Steuern eines Mediendatenübertragungsprotokolls erzeugt wird, mittels welcher signalisiert wird, ob die Mediendaten an das zweite Kommunikationsendgerät weitergeleitet wurden;

– die Notifizierungsnachricht an das erste Kommunikationsendgerät übermittelt wird.
Notifizierungseinrichtung eines Konferenz-Kommunikationssystems, welches Konferenz-Kommunikationssystem

– eine Konferenz-Servereinheit aufweist, die eingerichtet ist, eine Konferenz für ein erstes Kommunikationsendgerät und ein zweites Kommunikationsendgerät bereitzustellen und

– eine Weiterleitungseinrichtung zum Weiterleiten von Mediendaten im Rahmen der Konferenz aufweist

– wobei die Notifizierungseinrichtung eingerichtet ist, eine Notifizierungsnachricht gemäß einem Mediendatenübertragungs-Steuerungsprotokoll zum Steuern eines Mediendatenübertragungsprotokolls zu erzeugen, mittels welcher signalisiert wird, ob Mediendaten, die von dem ersten Kommunikationsendgerät an die Weiterleitungseinrichtung zum Weiterleiten an das zweite Kommunikationsendgerät übermittelt wurden, an das zweite Kommunikationsendgerät weitergeleitet wurden.
Verfahren zum Notifizieren eines Kommunikationsendgeräts eines Konferenz-Kommunikationssystems, welches Konferenz-Kommunikationssystem

– eine Konferenz-Servereinheit aufweist, die eingerichtet ist, eine Konferenz für das Kommunikationsendgerät und ein weiteres Kommunikationsendgerät bereitzustellen und

– eine Weiterleitungseinrichtung zum Weiterleiten von Mediendaten im Rahmen der Konferenz aufweist

– wobei eine Notifizierungseinrichtung eine Notifizierungsnachricht gemäß einem Mediendatenübertragungs-Steuerungsprotokoll zum Steuern eines Mediendatenübertragungsprotokolls erzeugt, mittels welcher signalisiert wird, ob Mediendaten, die von dem Kommunikationsendgerät an die Weiterleitungseinrichtung zum Weiterleiten an das weitere Kommunikationsendgerät übermittelt wurden, an das weitere Kommunikationsendgerät weitergeleitet wurden.






IPC
A Täglicher Lebensbedarf
B Arbeitsverfahren; Transportieren
C Chemie; Hüttenwesen
D Textilien; Papier
E Bauwesen; Erdbohren; Bergbau
F Maschinenbau; Beleuchtung; Heizung; Waffen; Sprengen
G Physik
H Elektrotechnik

Anmelder
Datum

Patentrecherche

Patent Zeichnungen (PDF)

Copyright © 2008 Patent-De Alle Rechte vorbehalten. eMail: info@patent-de.com