DE102005039669B3

DE102005039669B3 - Verfahren zum rechnergestützten Erstellen einer Abstimmungs-Nachricht, Verfahren zum rechnergestützten Ermitteln mindestens eines Abstimmungs-Ergebnisses, Verfahren zum rechnergestützten Bearbeiten einer Abstimmungs-Nachricht, Transportprotokoll-Steuerungsprotokoll-Einheit, Konferenz-Abstimmungs-Auswerte-Einheit, Konferenz-Servereinheit und Kommunikations-Endgerät

Info

Publication number: DE102005039669B3
Application number: DE102005039669A
Authority: DE
Inventors: Andreas Schmidt; Norbert Schwagmann; Holger Schmidt
Original assignee: Infineon Technologies AG
Current assignee: Intel Deutschland GmbH
Priority date: 2005-08-22
Filing date: 2005-08-22
Publication date: 2007-01-04
Anticipated expiration: 2025-08-23
Also published as: FR2889900A1; GB2429614B; CN1925410B; GB2429614C; CN1925410A; GB2429614A; US20070058796A1; GB0615118D0

Abstract

Eine Abstimmungs-Nachricht, welche eine Abstimmungs-Frage enthält, wird gemäß einem Transportprotokoll-Steuerungsprotokoll, beispielsweise gemäß dem Real-Time Transport Control Protocol, kodiert und im Rahmen einer Konferenz zum Initiieren einer Abstimmung gesendet.

Description

Die Erfindung betrifft ein Verfahren zum rechnergestützten Erstellen einer Abstimmungs-Nachricht, ein Verfahren zum Ermitteln mindestens eines Abstimmungs-Ergebnisses mindestens einer Abstimmung, ein Verfahren zum rechnergestützten Bearbeiten einer Abstimmungs-Nachricht, Transport-Steuerungsprotoll-Einheiten, eine Konferenz-Abstimmungs-Auswerte-Einheit, eine Konferenz-Servereinheit sowie ein Kommunikations-Endgerät.

In einem modernen Kommunikationssystem ist es häufig wünschenswert, eine Konferenz zwischen mehreren Teilnehmern, anders ausgedrückt zwischen mehreren Kommunikations-Endgeräten, im Rahmen des Kommunikationssystems bereitzustellen. Ein Kommunikationssystem, welches ein solches Konferenz-System bereitstellt, ermöglicht es, unter Verwendung von Kommunikations-Endgeräten zwischen mehreren Nutzern zu kommunizieren.

Unter einem Konferenz-System wird im Folgenden beispielsweise ein Internet Protocol-basiertes Konferenz-System verstanden oder ein so genanntes Push-to-Talk-System, allgemein jedes System, bei welchem es ermöglicht ist, dass Kommunikations-Endgeräte im Rahmen eines Kommunikationssystems innerhalb einer Kommunikations-Konferenz miteinander kommunizieren, das heißt Daten zwischen den Kommunikations-Endgeräten übertragen können.

Unter einem Push-to-Talk-Kommunikationssystem (PTT-Kommunikationssystem) ist beispielsweise das Kommunikationssystem „Direct Connect" von der Firma Nextel in den USA oder das Push-to-Talk over Cellular (PoC)-Kommunikationssystem der Open Mobile Alliance (OMA) zu verstehen, wobei ein PTT-Kommunikationssystem ein Mehrteilnehmer-Kommunikationssystem für Mobilfunk-Kommunikations-Endgeräte, beispielsweise für Mobilfunk-Telefone ist. Wie analog zu der Handhabung von Walkie-Talkies, betätigt ein Sprecher üblicherweise eine spezielle Taste an seinem Mobilfunk-Kommunikations-Endgerät, um ein Sprechrecht anzufordern und daraufhin Sprach-Nachrichten an andere Mobilfunk-Kommunikations-Endgeräte im Rahmen der PPT-Kommunikationssitzung zu übermitteln. Die Übertragung von Nachrichten anderer Nutzer von anderen Mobilfunk-Kommunikations-Endgeräten ist während dieser Zeit gesperrt. Somit handelt es sich bei einem PTT-Kommunikationssystem üblicherweise um ein Halb-Duplex-Kommunikationssystem.

In einem Konferenz-System gemäß einem Verschlag der IETF (Internet Engineering Task Force), wie es in [1] beschrieben ist oder auch in einem derzeitigen Push-to-Talk-Kommunikationssystem werden die zu übertragenden Medien-Daten, beispielsweise Audiodaten und/oder Videodaten und/oder Standbilddaten und/oder textuelle Daten, mittels des so genannten Real-Time Transport Protocols (RTP) übertragen (vergleiche [1], [2]). Die Medien-Datenströme werden mittels des so genannten Real-Time Transport Control Protocol (RTCP) kontrolliert, wie beispielsweise in [3] beschrieben ist.

Sowohl ein Konferenz-System gemäß [1] als auch ein Push-to-Talk-Kommunikationssystem haben eine zentralisierte Architektur (vergleiche [1], [2]). Anders ausgedrückt bedeutet dies, dass die Teilnehmer eines solchen Konferenz-Systems nicht direkt miteinander kommunizieren, sondern dass die Kommunikation mittels einer zentralen Servereinheit erfolgt. Die zentrale Servereinheit, auch bezeichnet als Konferenz-Servereinheit, ist in einem Mobilfunk-Kommunikationssystem in dem nicht-mobilen Bereich des Kommunikationsnetzes, beispielsweise bei UMTS (Universal Mobile Telecommunications System) in dem Kernnetzwerk (Core Network), angeordnet.

In [4] ist ein Kommunikationssystem für mehrere Teilnehmer beschrieben, in welchem eine Abstimmungsfunktion zum Abstimmen über eine vorgebbare Frage, bereitgestellt wird. Die Abstimmungsfunktionen sind gemäß [4] mit einem speziellen Protokoll für Abstimmungs-Nachrichten realisiert.

Gemäß [5] ist es alternativ bekannt, Abstimmungs-Nachrichten unter Verwendung von RTP zu versenden.

Weiterhin ist es aus [6] bekannt, Abstimmungen durch Verwendung gemeinsam genutzter Zähler, welche auch als „Shared Counter" bezeichnet werden, zu realisieren.

Ferner ist in [7] ein Format zum Darstellen einer absoluten Zeitangabe, auch bezeichnet als Network Time Protocol, beschrieben.

Ferner beschreibt [8] die so genannte Backus Naur Form (BNF).

Weiterhin kann in einem Push-to-Talk-Kommunikationssystem der Anfrageknopf der Teilnehmer-Kommunikations-Endgeräte für eine einfache (zweiwertige) Abstimmung verwendet werden.

Druckschrift [9] beschreibt ein Kommunikationssystem mit mehreren Kommunikationsendgeräten. Jedes Kommunikationsendgerät kann so konfiguriert werden, dass ein Benutzer eine Antwort im Rahmen eines Kommunikations-Ereignisses eingeben kann. Alternativ können die Kommunikationsendgeräte als Basisstationen konfiguriert werden. Auf diese Weise wird eine hohe Flexibilität erreicht und es ist keine dedizierte Basisstation für ein Kommunikations-Ereignis erforderlich.

In [10] ist ein Multimedia-Server offenbart, der eingerichtet ist zum Verwalten einer Multimedia-Konferenz und einen Speicher zum Speichern von Aktions-Anforderungen aufweist. Weiterhin sind Benutzer-Endgeräte vorgesehen, mit denen Benutzer Aktions-Aufrufe eingeben können, beispielsweise mittels einer Spracheingabe oder einer Texteingabe, worauf zugehörige Aktions-Anforderungen gestartet werden.

Der Erfindung liegt das Problem zu Grunde, auf einfache Weise das Durchführen einer rechnergestützten Abstimmung in einem Konferenz-System zu ermöglichen.

Das Problem wird durch ein Verfahren zum rechnergestützten Erstellen einer Abstimmungs-Nachricht, durch ein Verfahren zum rechnergestützten Ermitteln mindestens eines Abstimmungs-Ergebnisses, durch ein Verfahren zum rechnergestützten Bearbeiten einer Abstimmungs-Nachricht, durch Transportprotokoll-Steuerungsprotokoll-Einheiten, durch eine Konferenz-Abstimmungs-Auswerte-Einheit, durch eine Konferenz-Servereinheit sowie durch ein Kommunikations-Endgerät mit den Merkmalen gemäß den unabhängigen Patentansprüchen gelöst.

Bei einem Verfahren zum rechnergestützten Erstellen einer Abstimmungs-Nachricht in einer Konferenz zwischen mehreren Kommunikations-Endgeräten wird die Abstimmungs-Nachricht gemäß einem Transportprotokoll-Steuerungsprotokoll, beispielsweise einem Echtzeit-Transportprotokoll-Steuerungsprotokoll, mittels welchem ein Transportprotokoll, beispielsweise ein Echtzeit-Transportprotokoll, gesteuert wird, kodiert, wobei eine mindestens eine Abstimmungs-Frage oder mindestens eine Abstimmungs-Antwort identifizierende Information der Abstimmungs-Nachricht hinzugefügt wird.

Bei einem Verfahren zum Ermitteln mindestens eines Abstimmungs-Ergebnisses mindestens einer Abstimmung in einer Konferenz zwischen mehreren Kommunikations-Endgeräten wird mindestens eine empfangene Abstimmungs-Antwort-Nachricht, welche gemäß einem Transportprotokoll-Steuerungsprotokoll, beispielsweise einem Echtzeit-Transportprotokoll-Steuerungsprotokoll, mittels welchem ein Transportprotokoll, beispielsweise ein Echtzeit-Transportprotokoll, gesteuert wird, kodiert ist, dekodiert, wobei die Abstimmungs-Antwort-Nachricht mindestens eine Antwort auf die mindestens eine Abstimmungs-Frage der Abstimmung enthält. Die mindestens eine Antwort wird aus der dekodierten Abstimmungs-Antwort-Nachricht ermittelt und unter Verwendung der mindestens einen ermittelten Antwort wird das mindestens eine Abstimmungs-Ergebnis ermittelt.

Bei einem Verfahren zum Bearbeiten einer Abstimmungs-Nachricht in einer Konferenz zwischen mehreren Kommunikations-Endgeräten wird eine gemäß einem Transportprotokoll-Steuerungsprotokoll, beispielsweise eine gemäß einem Echtzeit-Transportprotokoll-Steuerungsprotokoll, mittels welchem ein Transportprotokoll, beispielsweise ein Echtzeit-Transportprotokoll, gesteuert wird, kodierte Abstimmungs-Nachricht empfangen und es wird eine mindestens eine Abstimmungs-Frage und/oder eine mindestens eine Abstimmungs-Antwort identifizierende Information, welche in der Abstimmungs-Nachricht enthalten ist, aus der Abstimmungs-Nachricht ermittelt. Die mindestens eine Abstimmungs-Frage und/oder mindestens eine Abstimmungs-Antwort werden/wird einem Benutzer eines an der Abstimmung teilnehmenden Kommunikations-Endgeräts dargestellt und ein Benutzer gibt mindestens eine Antwort auf die mindestens eine Abstimmungs-Frage ein, anders ausgedrückt stimmt gemäß der Abstimmungs-Frage ab. Ferner wird eine Abstimmungs-Antwort-Nachricht gemäß einem Transportprotokoll-Steuerungsprotokoll, beispielsweise einem Echtzeit-Transportprotokoll-Steuerungsprotokoll, mittels welchem ein Transportprotokoll, beispielsweise ein Echtzeit-Transportprotokoll, gesteuert wird, kodiert, wobei eine die mindestens eine Antwort auf die mindestens eine Abstimmungs-Frage identifizierende Information der Abstimmungs-Antwort-Nachricht hinzugefügt wird.

Gemäß einem anderen Aspekt der Erfindung wird eine Transportprotokoll-Steuerungsprotokoll-Einheit, beispielsweise eine Echtzeit-Transportprotokoll-Steuerungsprotokoll-Einheit, bereitgestellt, welche eingerichtet ist zum Erstellen einer Abstimmungs-Nachricht in einer Konferenz zwischen mehreren Kommunikations-Endgeräten, wobei die Abstimmungs-Nachricht gemäß einem Transportprotokoll-Steuerungsprotokoll, beispielsweise einem Echtzeit-Transportprotokoll-Steuerungsprotokoll, mittels welchem ein Transportprotokoll, beispielsweise ein Echtzeit-Transportprotokoll, gesteuert wird, kodiert wird, wobei eine mindestens eine Abstimmungs-Frage und/oder eine mindestens eine Abstimmungs-Antwort identifizierende Information der Abstimmungs-Nachricht hinzugeführt wird.

Gemäß einem anderen Aspekt der Erfindung ist eine Konferenz-Abstimmungs-Auswerte-Einheit vorgesehen mit einer Transportprotokoll-Steuerungsprotokoll-Einheit, beispielsweise einer Echtzeit-Transportprotokoll-Steuerungsprotokoll-Einheit, eingerichtet zum Dekodieren mindestens einer Abstimmungs-Antwort-Nachricht, welche gemäß einem Transportprotokoll-Steuerungsprotokoll, beispielsweise einem Echtzeit-Transportprotokoll-Steuerungsprotokoll, mittels welchem ein Transportprotokoll, beispielsweise ein Echtzeit-Transportprotokoll, gesteuert wird, kodiert ist. Ferner ist eine Ermittlungs-Einheit zum Ermitteln mindestens einer Antwort auf mindestens eine eine Abstimmungs-Frage identifizierende Information aus der dekodierten Abstimmungs-Antwort-Nachricht vorgesehen, sowie eine Abstimmungs-Auswerte-Einheit, welche eingerichtet ist zum Ermitteln eines Abstimmungs-Ergebnisses unter Verwendung der mindestens einen die Antwort auf mindestens eine Abstimmungs-Frage identifizierenden Information.

Eine Konferenz-Servereinheit weist eine oben beschriebene Konferenz-Abstimmungs-Auswerte-Einheit auf.

Weiterhin ist eine Transportprotokoll-Steuerungsprotokoll-Einheit, beispielsweise eine Echtzeit-Transportprotokoll-Steuerungsprotokoll-Einheit, vorgesehen, welche eingerichtet ist zum Erstellen einer Abstimmungs-Antwort-Nachricht in einer Konferenz zwischen mehreren Kommunikations-Endgeräten, wobei die Abstimmungs-Antwort-Nachricht gemäß einem Transportprotokoll-Steuerungsprotokoll, beispielsweise einem Echtzeit-Transportprotokoll-Steuerungsprotokoll, mittels welchem ein Transportprotokoll, beispielsweise ein Echtzeit-Transportprotokoll, gesteuert wird, kodiert wird, wobei eine mindestens eine Abstimmungs-Antwort auf mindestens eine Abstimmungs-Frage identifizierende Information der Abstimmungs-Antwort-Nachricht hinzugefügt wird.

Ein Kommunikations-Endgerät weist eine Konferenz-Einheit auf, welche eingerichtet ist zur Teilnahme an, anders ausgedrückt zum Bereitstellen, einer Konferenz mit mindestens einem anderen Kommunikations-Endgerät. Ferner ist eine erste Transportprotokoll-Steuerungsprotokoll-Einheit, beispielsweise eine Echtzeit-Transportprotokoll-Steuerungsprotokoll-Einheit, vorgesehen, welche eingerichtet ist zum Dekodieren mindestens einer Abstimmungs-Nachricht, welche gemäß einem Tramsport-Steuerungsprotokoll, beispielsweise einem Echtzeit-Transportprotokoll-Steuerungsprotokoll, mittels welchem ein Transportprotokoll, beispielsweise ein Echtzeit-Transportprotokoll, gesteuert wird, kodiert ist. Ferner weist das Kommunikations-Endgerät eine Ermittlungs-Einheit zum Ermitteln mindestens einer eine Abstimmungs-Frage und/oder mindestens eine Abstimmungs-Antwort identifizierenden Information aus der dekodierten Abstimmungs-Nachricht auf sowie eine Darstellungs-Einheit zum Darstellen der ermittelten Information oder der daraus ermittelten mindestens einen Abstimmungs-Frage und/oder mindestens einen Abstimmungs-Antwort an einen Benutzer. Eine Eingabe-Einheit ist vorgesehen zum Eingeben mindestens einer Antwort auf die mindestens eine Abstimmungs-Frage. Weiterhin ist eine zweite Transportprotokoll-Steuerungsprotokoll-Einheit, beispielsweise eine zweite Echtzeit-Transportprotokoll-Steuerungsprotokoll-Einheit, vorgesehen, welche eingerichtet ist zum Erstellen einer Abstimmungs-Antwort-Nachricht in einer Konferenz zwischen mehreren Kommunikations-Endgeräten, wobei die Abstimmungs-Antwort-Nachricht gemäß einem Transportprotokoll-Steuerungsprotokoll, beispielsweise einem Echtzeit-Transportprotokoll-Steuerungsprotokoll, mittels welchem ein Transportprotokoll, beispielsweise ein Echtzeit-Transportprotokoll, gesteuert wird, kodiert wird, wobei eine die mindestens eine Antwort auf die mindestens eine Abstimmungs-Frage identifizierende Information der Abstimmungs-Antwort-Nachricht hinzugefügt wird.

Anschaulich kann ein Aspekt der Erfindung darin gesehen werden, dass im Rahmen einer Kommunikations-Konferenz zwischen mehren Kommunikations-Endgeräten in einem Kommunikationssystem eine Abstimmungsmöglichkeit als Kommunikationsdienst bereitgestellt wird, wobei die im Rahmen der Abstimmung relevante Information, beispielsweise die Abstimmungs-Frage und/oder mögliche vorgegebene oder auch von einem Benutzer eines teilnehmenden Kommunikationsgerät frei definierte Abstimmungs-Antwort(en) übermittelt werden/wird unter Verwendung eines Transportprotokoll-Steuerungsprotokolls, beispielsweise einem Echtzeit-Transportprotokoll-Steuerungsprotokoll.

Auf diese Weise ist es verglichen mit dem Stand der Technik erstmals erreicht, dass nicht ein proprietäres Protokoll, wie gemäß [4] vorgesehen werden muss, sondern dass ein Transportprotokoll-Steuerungsprotokoll verwendet werden kann, was hinsichtlich der Leistungsfähigkeit des gesamten Datenaustauschs erhebliche Verbesserungen mit sich bringt.

Anders ausgedrückt wird gemäß einem Aspekt der Erfindung in einem Kommunikationssystem, welches ein Transportprotokoll-Steuerungsprotokoll, beispielsweise ein Echtzeit-Transportprotokoll-Steuerungsprotokoll, verwendet, eine Abstimmungs-Nachricht bzw. Abstimmungs-Nachrichten als Nachrichten gemäß dem Transportprotokoll-Steuerungsprotokoll, beispielsweise dem Echtzeit-Transportprotokoll-Steuerungsprotokoll, versendet.

In einer Abstimmungs-Nachricht können eine oder mehrere Abstimmungs-Fragen oder eine oder mehrere Abstimmungs-Antworten, welche ein Benutzer, welcher an der Abstimmung teilnimmt, auswählen kann, enthalten sein.

Die Abstimmungs-Antwort-Nachricht kann eine oder mehrere Antworten auf die Abstimmungs-Frage enthalten, beispielsweise eine von dem Benutzer frei formulierbare Antwort, alternativ eine Auswahlinformation über eine ausgewählte, dem Benutzer zur Auswahl vorgegebene Antwort.

Die Information, welche die Abstimmungs-Frage, beziehungsweise die Abstimmungs-Antwort identifiziert, kann ein Verweis zu einer in einer anderen Servereinheit gespeicherten Abstimmungs-Frage beziehungsweise Abstimmungs-Antwort sein, in welchem Fall beispielsweise eine eindeutige Adressierung auf die Frage beziehungsweise Antwort vorgesehen ist, beispielsweise unter Verwendung eines Unique Resource Identifiers (URI), die Information kann aber auch die Abstimmungs-Frage beziehungsweise die Abstimmungs-Antwort selbst sein, welche in der jeweiligen Abstimmungs-Nachricht beziehungsweise in der Abstimmungs-Antwort-Nachricht enthalten sein kann.

Beispielhafte Ausgestaltungen der Erfindung ergeben sich aus den abhängigen Ansprüchen.

Als Echtzeit-Transportprotokoll-Steuerungsprotokoll kann das Real-Time Transport Control Protocol (RTCP) verwendet werden.

Als Echtzeit-Transportprotokoll kann das Real-Time Transport Protocol (RTP) verwendet werden.

Die Abstimmung kann im Rahmen einer Halb-Duplex-Konferenz durchgeführt werden, beispielsweise im Rahmen einer Push-to-Talk-Konferenz, wie beispielsweise einer „Direct Connect"-Konferenz oder einer Push-to-Talk over Cellular-Konferenz (PoC-Konferenz).

Alternativ kann die Abstimmung im Rahmen einer Internet Protocol-basierten Konferenz oder unter Verwendung des Internet Conferencing Frameworks, wie es beispielsweise in [1] beschrieben ist, durchgeführt werden.

Die mindestens eine Abstimmungs-Antwort-Nachricht kann im Rahmen des Verfahrens zum rechnergestützten Ermitteln mindestens eines Abstimmungs-Ergebnisses von einer Konferenz-Servereinheit empfangen werden und/oder das mindestens eine Abstimmungs-Ergebnis kann von einer Konferenz-Servereinheit ermittelt werden.

In einer anderen Ausgestaltung des Verfahrens zum rechnergestützten Ermitteln mindestens eines Abstimmungs-Ergebnisses ist es vorgesehen, dass das ermittelte mindestens eine Abstimmungs-Ergebnis an mindestens ein an der Konferenz teilnehmendes Kommunikations-Endgerät übermittelt wird, beispielsweise an das Kommunikations-Endgeräte, welches die mindestens eine Abstimmung initiiert hat. Diese Ausgestaltung der Erfindung kann anschaulich darin gesehen werden, dass die Konferenz-Servereinheit oder auch eine andere Einheit, welche das Abstimmungs-Ergebnis ermittelt, dieses an ein oder mehrere andere Kommunikations-Endgeräte weiterleitet, wobei vorgesehen sein kann, dass nur das Kommunikations-Endgerät, welches die mindestens eine Abstimmung initiiert hat, das Recht hat, das Abstimmungs-Ergebnis zu erhalten. Alternativ kann es jedoch vorgesehen sein, dass alle an der Abstimmung teilnehmenden Kommunikations-Endgeräte das Abstimmungs-Ergebnis übermittelt bekommen. Die jeweiligen Rechte können von dem die Abstimmung initiierenden Kommunikations-Endgerät vorgebbar sein, alternativ kann die Konferenz-Servereinheit oder die das Abstimmungs-Ergebnis ermittelnde Einheit diese Rechte vorgeben.

Gemäß einer anderen Ausgestaltung des Verfahrens zum rechnergestützten Ermitteln mindestens eines Abstimmungs-Ergebnisses wird die mindestens eine Abstimmungs-Antwort-Nachricht von einer Konferenz-Servereinheit empfangen und die Abstimmungs-Antwort-Nachricht und/oder eine mindestens eine in der Abstimmungs-Antwort-Nachricht enthaltene Abstimmungs-Antwort-Information wird an mindestens ein an der Konferenz teilnehmendes Kommunikations-Endgerät übermittelt, beispielsweise an das Kommunikations-Endgerät, welches die Abstimmung initiiert hat.

Gemäß einer Ausgestaltung des Verfahrens zum Bearbeiten einer Abstimmungs-Nachricht ist es vorgesehen, dass die Abstimmungs-Antwort-Nachricht zu einer Konferenz-Servereinheit gesendet wird.

Die Echtzeit-Transportprotokoll-Steuerungsprotokoll-Einheiten können gemäß dem Real-Time Transport Control Protocol (RTCP) eingerichtet sein.

Ausführungsbeispiele der Erfindung sind in den Figuren dargestellt und werden im Folgendem näher erläutert.
Es zeigen
1 eine Architektur eines Push-to-Talk-Kommunikationssystem gemäß einem Ausführungsbeispiel der Erfindung; und
2 ein Nachrichtenfluss-Diagramm, in welchem der Nachrichtenfluss im Rahmen eines Abstimmungs-Vorganges gemäß einem Ausführungsbeispiel der Erfindung dargestellt ist.
Im Folgenden wird als Ausführungsbeispiel ein Push-to-Talk over Cellular-Kommunikationssystem (PoC-Kommunikationssystem) 100 beschrieben (vgl. 1), wobei darauf hinzuweisen ist, dass in einer alternativen Ausführungsform auch ein anderes Push-to-Talk-Kommunikationssystem oder auch ein anderes Kommunikationssystem, beispielsweise ein anderes Halb-Duplex-Kommunikationssystem eingesetzt werden kann oder das Kommunikations-Konferenz-System gemäß dem IETF Conferencing Framework, wie es in [1] beschrieben wird.
Das Push-to-Talk over Cellular-Kommunikationssystem 100 ist ausgestaltet, wie in [2] beschrieben.
Im Folgenden wird davon ausgegangen, dass in einer Push-to-Talk-Konferenz, die von einer zentralen Push-to-Talk-Servereinheit 101 bereitgestellt wird, vier Mobilfunk-Kommunikations-Endgeräte, welche jeweils einen Push-to-Talk over Cellular-Client enthalten, und welche zur Kommunikation gemäß [2] eingerichtet sind, eine Push-to-Talk-Konferenz untereinander aufgebaut haben.
Unter einer Halb-Duplex-Konferenz ist eine Konferenz zu verstehen, bei der höchstens ein teilnehmendes Kommunikations-Endgerät und nicht mehrere Kommunikations-Endgeräte gleichzeitig ein Sprechrecht erhalten. Zu einem Zeitpunkt hat somit nur ein Kommunikations-Endgerät beispielsweise ein Sprechrecht, allgemein ausgedrückt, das Recht, Daten in die Kommunikations-Konferenz einzubringen und an die anderen teilnehmenden Kommunikations-Endgeräte zu übermitteln. Die anderen Kommunikations-Endgeräte können die eingebrachten Daten lediglich empfangen und ohne eigenes Sprechrecht beziehungsweise ohne eigenes Kommunikationsrecht keine Daten, insbesondere auch keine Sprach-Nachrichten in die Kommunikations-Konferenz, beispielsweise eine Telekommunikations-Konferenz, einbringen.
In der von der Push-to-Talk over Cellular-Konferenz-Servereinheit 101 bereitgestellten Konferenz nehmen vier Mobilfunk-Kommunikations-Endgeräte 102, 103, 104,105, nämlich ein erstes Mobilfunk-Kommunikationsgerät 102, ein zweites Mobilfunk-Kommunikationsgerät 103, ein drittes Mobilfunk-Kommunikationsgerät 104 und ein viertes Mobilfunk-Kommunikationsgerät 105, an der Konferenz teil. Jedes Mobilfunk-Kommunikations-Endgerät 102, 103, 104,105 ist mittels einer jeweiligen bidirektionalen Mobilfunk-Kommunikationsverbindung 106, 107, 108, 109 mit der Konferenz-Servereinheit 101 verbunden und kann somit Daten im Rahmen der Konferenz von den anderen Mobilfunk-Kommunikations-Endgeräten empfangen beziehungsweise, wenn das jeweilige Mobilfunk-Kommunikations-Endgerät das Kommunikationsrecht zugewiesen bekommen hat, kann es an die anderen Mobilfunk-Kommunikations-Endgeräte Daten senden.
Gemäß diesem Ausführungsbeispiel der Erfindung werden zwischen den Mobilfunk-Kommunikations-Endgeräten 102, 103, 104, 105 Sprachnachrichten, anders ausgedrückt Audio-Nachrichten, übertragen, wobei darauf hinzuweisen ist, dass in einer alternativen Konferenz auch andere Medien-Daten übermittelt werden können, beispielsweise Video-Daten und/oder Standbild-Daten und/oder textuelle Daten.
Die Audio-Daten werden unter Verwendung des so genannten Real-Time Transport Protocols (RTP), als Echtzeit-Transportprotokoll zwischen den Mobilfunk-Kommunikations-Endgeräten 102, 103, 104, 105 übertragen. Die Datenströme, das heißt gemäß diesem Ausgangsbeispiel der Erfindung die Audio-Daten, werden unter Verwendung des Real-Time Transport Control Protocol (RTCP) als Echtzeit-Transportprotokoll-Steuerungsprotokoll kontrolliert.
Ein erster Teilnehmer T1, dass heißt der Nutzer des ersten Mobilfunk-Kommunikations-Endgeräts 102, initiiert gemäß diesem Ausführungsbeispiel der Erfindung eine Abstimmung unter den Teilnehmern der Push-to-Talk-Kommunikationssitzung, anschaulich einer Push-to-Talk-Konferenz, indem er eine Abstimmungs-Frage versendet (vergleiche Nachrichtenfluss-Diagramm 200 in 2). Die Abstimmungs-Frage wird in eine Abstimmungs-Nachricht 201 eingefügt, welche von dem ersten Teilnehmer T1 unter Verwendung des ersten Mobilfunk-Kommunikations-Endgeräts 102 erzeugt wird.
Die Abstimmungs-Nachricht 201 weist das in der folgenden Tabelle 1 dargestellte Nachrichtenformat auf und ist gemäß RTCP kodiert. Die Abstimmungs-Nachricht 201 enthält eine Abstimmungs-Frage als Text und Angaben über mögliche Abstimmungs-Antworten. Außerdem ist in der Abstimmungs-Nachricht 201 angegeben, in welchem Zeitraum Antworten auf die Abstimmungs-Frage im Rahmen der gestarteten Abstimmung akzeptiert werden.
Tabelle 1: Format der RTCP-Nachricht zur Initiierung einer Abstimmung
Die Felder der in Tabelle 1 dargestellten RTCP-Nachricht bedeuten im Einzelnen:

• V=2: RTP-Versions-Nummer;
• P: Indikator für Padding;
• 10100: Subtyp der Nachricht, 10100 bedeutet „Voting_Question". Der angegebene Wert ist nur ein Beispielwert und kann auch anders gewählt werden;
• PT=APP=204: Indikator für Applikations-definierte RTCP-Nachricht;
• Length: Länge der Nachricht nach dem length-Feld in Wörtern (32Bit);
• SSRC Synchronisation Source des initiierenden PoC-Teilnehmers. Die SSRC identifiziert den Sender von Medien-Strömen eindeutig; sie wird in den 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 Teilnehmerendgerätes, das die Abstimmung initiiert. CNAME und NAME sind so genannte SDES items, die in SDES RTCP-Paketen definiert werden, um einen RTP-Teilnehmer zu beschreiben; CNAME ist ein eindeutiger Name des Teilnehmers, der auch außerhalb spezifischer RTP-Sessions weiter besteht (z.B. zusammengesetzt aus user name und host IP-Adresse); NAME ist ein beliebiger Name des Teilnehmers, der typischerweise vom Teilnehmer selbst angegeben wird; NAME muss den 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 eindeutig abgeschlossen; die Liste wird anschließend bis zu Vielfachen von 32 Bit mit Nullen gepadded, wie in [3] beschrieben;
• Voting question length: Länge des „voting question text"-Feldes in Bytes; das „voting question length"-Feld umfasst 16 Bit;
• Voting question text: Text zur Spezifizierung der Abstimmungs-Initiierung;
• Padding: Nullen zum Auffüllen des „voting question length und text"-Feldes auf ganzzahlige Vielfache von 32 Bits.

Das „Voting question text"-Feld der Abstimmungs-Nachricht 201 hat beispielsweise den folgenden Inhalt:
Wie heißt der welt-höchste Berg?;123456789;123458470; Auswahltyp; 1; Mont Blanc; Mount Everest; Brocken
Der Inhalt bedeutet:

• Abstimmungsfrage = Wie heißt der welt-höchste Berg?
• Abstimmungszeitraum = von 123456789 bis 123458470 (die Zeitangaben sind absolute Zeitangaben im Network-Time-Protocol (NTP) Time-Stamp-Format wie sie in [7] definiert ist, wobei anzumerken ist, das auch eine relative Zeitangabe, beispielsweise eine relative Zeitangabe ausgehend von dem Zeitpunkt des Sendens der Abstimmungs-Nachricht oder des Erstellens der Abstimmungs-Nachricht 201 in einer alternativen Ausführungsform sein kann;
• Typ der Antworten auf die Frage = Auswahltyp (das heißt, dass von mehreren möglichen Antworten auszuwählen ist);
• Anzahl der auszuwählenden Antworten = 1
• Mögliche Antworten = Mount Blanc; Mount Everest; Brocken.

Die Abstimmungs-Nachricht 201 wird mittels einer in jedem der Mobilfunk-Kommunikations-Endgeräte 102, 103, 104, 105 vorgesehenen RTCP-Einheit gemäß dem RTCP-Format von dem ersten Mobilfunk-Kommunikations-Endgerät 102 kodiert.
Ferner weist jedes Mobilfunk-Kommunikations-Endgerät 102, 103, 104, 105 eine zweite RTCP-Einheit zum Dekodieren einer empfangenen, gemäß dem RTCP-Format kodierten Nachricht auf. Die beiden Einheiten können in einer RTCP-Einheit integriert vorgesehen sein.
Die Abstimmungs-Nachricht 201 wird an die Konferenz-Servereinheit 101 übermittelt, welche auf den Empfang der Abstimmungs-Nachricht 201 hin weitere Abstimmungs-Nachrichten, wiederum gemäß dem RTCP-Format mittels einer in der Konferenz-Servereinheit 101 vorgesehenen RTCP-Einheit erzeugt und diese an die anderen an der Konferenz teilnehmenden Mobilfunk-Kommunikations-Endgeräte 103, 104, 105 übermittelt.
Wie in 2 dargestellt ist, erzeugt die Konferenz-Servereinheit 101 somit eine zweite Abstimmungs-Nachricht 202 und sendet diese an das zweite Mobilfunk-Kommunikations-Endgerät 103 und somit an den zweiten Teilnehmer T2. Ferner erzeugt die Konferenz-Servereinheit 101 eine dritte Abstimmungs-Nachricht 203 und übermittelt diese an das dritte Kommunikations-Endgerät 104 beziehungsweise an den dritten Teilnehmer T3. Weiterhin erzeugt die Konferenz-Servereinheit 101 eine vierte Abstimmungs-Nachricht 204 und übermittelt diese an das vierte Mobilfunk-Kommunikations-Endgerät 105 beziehungsweise an den vierten Teilnehmer T4.
Die erzeugten Abstimmungs-Nachrichten 202, 203 sowie 204 sind gemäß diesem Ausführungsbeispiel der Erfindung mit der empfangenen Abstimmungs-Nachricht 201 identisch.
Nach Erhalt der jeweiligen Abstimmungs-Nachricht 202, 203, beziehungsweise 204 dekodieren die RTCP-Einheiten die jeweils empfangene Abstimmungs-Nachricht 202, 203, 204 und ermitteln aus der dekodierten Abstimmungs-Nachricht jeweils die Abstimmungs-Frage (Abstimmungs-Frage) und stellen diese mittels einer Darstellungs-Einheit, beispielsweise mittels eines Bildschirms (für visuelle Information) oder mittels eines Lautsprechers (für Audio-Informationen) dem jeweiligen Teilnehmer T2, T3, T4, dar.
Im einfachsten Fall wird die Abstimmungs-Frage in Form eines Fragetextes den Teilnehmern T2, T3, T4 auf dem jeweiligen Bildschirm des jeweiligen Mobilfunk-Kommunikations-Endgeräts 103, 104, 105 angezeigt. Außerdem werden die möglichen Abstimmungs-Antworten, welche ebenfalls in den Abstimmungs-Nachrichten 202, 203, 204 enthalten sind und von den RTCP-Einheiten der Mobilfunk-Kommunikations-Endgeräte 103, 104, 105 ermittelt werden, den Teilnehmern T2, T3, T4 dargestellt. Gemäß diesem Ausführungsbeispiel der Erfindung werden die drei möglichen Antworten (das heißt „Mont Blanc", „Mount Everest", „Brocken") textuell dargestellt mit der Möglichkeit, einen der Texte unter Verwendung von so genannten „Radio-Buttons", das heißt mittels eines Auswahlelements, in dem aus einer Mehrzahl von möglichen auszuwählenden Elementen jeweils nur genau ein Element ausgewählt werden kann, auszuwählen. In alternativen Ausführungsformen ist es vorgesehen, auch mehrere mögliche Antworten auszuwählen, in diesem Fall unter Verwendung von anderen Auswahlelementen, welche dem jeweiligen Teilnehmer T2, T3, T4 auf Ihrem jeweiligen Bildschirm ihres jeweiligen Mobilfunk-Kommunikations-Endgeräts 103, 104, 105 dargestellt werden. Jedes Mobilfunk-Kommunikations-Endgerät 103, 104, 105 ermittelt aus der jeweiligen Abstimmungs-Nachricht 202, 203, 204 die Zeit, in welcher noch eine Antwort ausgewählt werden kann und damit, ob überhaupt noch eine Antwort ausgewählt werden kann. Kann eine Antwort noch ausgewählt werden, das heißt ist die Antwortzeit noch nicht abgelaufen, so zeigen die Mobilfunk-Kommunikations-Endgeräte 103, 104, 105 dies optional dem jeweiligen Teilnehmer T2, T3, T4 auf dem Bildschirm an, beispielsweise, durch ein eigenes Ikon, durch Hervorheben eines bestimmten Anzeigebereichs oder auch durch Hervorheben eines bestimmten Teils des Textes, welcher dem jeweiligen Teilnehmer T2, T3, T4 dargestellt wird. Beispielsweise ist es vorgesehen, dass ein Mobilfunk-Kommunikations-Endgerät 103, 104, 105 es mittels eines blinkenden Textes im Rahmen der Darstellung dem Teilnehmer T2, T3, T4 anzeigt, dass (noch) geantwortet werden kann. Während der Antwort-Phase, dass heißt so lange, bis die Antwortzeit, wie sie beispielsweise in der obigen Abstimmungs-Nachricht in Tabelle 1 beispielhaft dargestellt ist, noch nicht abgelaufen ist, ist es optional vorgesehen, dass kontinuierlich die noch verbleibende Zeit dem Teilnehmer T2, T3, T4 zur Auswahl der Antwort angezeigt wird.
In diesem Ausführungsbeispiel wird angenommen, dass der zweite Teilnehmer T2 mittels entsprechender Eingabe in das zweite Mobilfunk-Kommunikations-Endgerät 103 die zweite der möglichen Antworten auswählt. Daraufhin erzeugt das zweite Mobilfunk-Kommunikations-Endgerät 103 eine erste Abstimmungs-Antwort-Nachricht 205 gemäß dem RTCP-Format und sendet diese an die Konferenz-Servereinheit 101.
Ein beispielhaftes Format der ersten Abstimmungs-Antwort-Nachricht 205 ist in der folgenden Tabelle 2 dargestellt:
Tabelle 2: Format der RTCP-Nachricht zur Beantwortung einer Abstimmungs-Frage
Die Felder der in Tabelle 2 dargestellten RTCP-Nachricht bedeuten im Einzelnen:

• V=2: RTP-Versions-Nummer;
• P: Indikator für Padding;
• 10101: Subtyp der Nachricht, 10101 bedeutet „Voting_Answer"; der angegebene Wert ist nur ein Beispielwert und kann auch anders gewählt werden;
• PT=APP=204: Indikator für Applikations-definierte RTCP-Nachricht;
• Length: Länge der Nachricht nach dem length-Feld in Wörtern (32Bit);
• SSRC: Synchronisation Source des antwortenden PoC-Teilnehmers; die SSRC identifiziert den Sender von Medien-Strömen eindeutig; sie wird in den 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 Teilnehmerendgerätes, das antwortet; CNAME und NAME sind so genannte SDES items, die in SDES RTCP-Paketen definiert werden, um einen RTP-Teilnehmer zu beschreiben; CNAME ist ein eindeutiger Name des Teilnehmers, der auch außerhalb spezifischer RTP-Sessions weiter besteht (z.B. zusammengesetzt aus user name und host IP-Adresse); NAME ist ein beliebiger Name des Teilnehmers, der typischerweise vom Teilnehmer selbst angegeben wird; NAME muss den 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 eindeutig abgeschlossen; Die Liste wird anschließend bis zu Vielfachen von 32 Bit mit Nullen gepadded, wie in [3] beschrieben;
• Voting answer length: Länge des „voting answer text"-Feldes in Bytes. Das „voting answer length"-Feld umfasst 16 Bit;
• Voting answer text: Text zur Spezifizierung der Abstimmungs-Antwort;
• Padding: Nullen zum Auffüllen des „voting answer length und text"-Feldes auf ganzzahlige Vielfache von 32 Bits.

Gemäß diesem Ausführungsbeispiel der Erfindung wird ohne Einschränkung der Allgemeingültigkeit zusätzlich angenommen, dass nach einer kurzen Zeit der zweite Teilnehmer seine Meinung hinsichtlich der Antwort-Auswahl ändert und dass er seine Antwort auf die dritte mögliche Antwort revidiert und dass er die Antwort „Brocken" auswählt. Die optionale Möglichkeit der Korrektur einer Antwort, anders ausgedrückt ein erneutes Auswählen einer anderen Abstimmungs-Antwort und das entsprechende Übermitteln dieser Information an die Konferenz-Servereinheit 101 ist so lange möglich, so lange die mögliche Antwort-Zeit noch nicht abgelaufen ist.
Die Information, welche die Abstimmungs-Frage, beziehungsweise die Abstimmungs-Antwort identifiziert, kann ein Verweis zu einer in einer anderen Servereinheit gespeicherten Abstimmungs-Frage beziehungsweise Abstimmungs-Antwort sein, in welchem Fall beispielsweise eine eindeutige Adressierung auf die Frage beziehungsweise Antwort vorgesehen ist, beispielsweise unter Verwendung eines Unique Resource Identifiers (URI), alternativ kann die Abstimmungs-Frage beziehungsweise die Abstimmungs-Antwort selbst in der jeweiligen Abstimmungs-Nachricht beziehungsweise in der Abstimmungs-Antwort-Nachricht enthalten sein. In der Abstimmungs-Antwort-Nachricht ist es alternativ vorgesehen, lediglich einen eindeutigen Identifier, welcher auf Grund einer vorgegebenen Zuordnung in der Konferenz-Servereinheit schon bekannt ist, zu verwenden zur Identifizierung der jeweiligen Abstimmungs-Antwort, welche von dem Teilnehmer ausgewählt worden ist.
Nach Auswahl der neuen Antwort seitens des zweiten Teilnehmers T2 erzeugt das zweite Mobilfunk-Kommunikations-Endgerät 102 eine zweite Abstimmungs-Antwort-Nachricht 206 und überträgt diese ebenfalls zu der Konferenz-Servereinheit 101.
Das „Voting Answer Text"-Feld der ersten Abstimmungs-Antwort-Nachricht 205 weißt beispielsweise folgenden Inhalt auf:
Auswahltyp; 1;2
Der Inhalt bedeutet:

• Typ der Antworten = Auswahltyp (das heißt, dass aus mehreren Antwortmöglichkeiten ausgewählt wurde);
• Anzahl der ausgewählten Antworten = 1;
• Nummer der ausgewählten Antworten = 2 (die Nummer bezieht sich auf die in der Abstimmungs-Frage, das heißt in der Abstimmungs-Nachricht angegebene Reihenfolge der möglichen Antworten (das heißt der Abstimmungs-Antworten in der jeweiligen Abstimmungs-Nachricht 201, 202, 203, 204), wobei gemäß diesem Ausführungsbeispiel der Erfindung die Abstimmungs-Antwort „Mount Everest" gewählt wurde).

Ferner wird gemäß diesem Ausführungsbeispiel angenommen, dass der dritte Teilnehmer T3 zunächst die erste mögliche Abstimmungs-Antwort auswählt (das heißt die Abstimmungs-Antwort „Mont Blanc"). Auf die von dem dritten Teilnehmer T3 getätigte Auswahl hin erzeugt das dritte Mobilfunk-Kommunikations-Endgerät 104 eine dritte Abstimmungs-Antwort-Nachricht 207 gemäß RTCP und übermittelt dieses RTCP-Datenpaket an die Konferenz-Servereinheit 101. Gemäß diesem Ausführungsbeispiel wird der dritte Teilnehmer T3 ebenfalls unsicher und nimmt seine Antwort, das heißt seine zuvor getätigte Auswahl, zurück, indem er eine Antwort-Rücknahme-Nachricht initiiert, welche von dem dritten Mobilfunk-Kommunikations-Endgerät 104 als Abstimmungs-Antwort-Rücknahme-Nachricht 208 erzeugt wird und an die Konferenz-Servereinheit 101 übermittelt wird. Die Abstimmungs-Antwort-Rücknahme-Nachricht 208 wird ebenfalls gemäß dem RTCP kodiert und an die Konferenz-Servereinheit 101 übertragen.
Ein beispielhafter Aufbau des Formats der Abstimmungs-Antwort-Rücknahme-Nachricht 208 ist in der folgenden Tabelle 3 dargestellt.
Tabelle 3: Format der RTCP-Nachricht zur Rücknahme einer Abstimmungs-Antwort
Die Felder der in Tabelle 3 dargestellten RTCP-Nachricht bedeuten im Einzelnen:

• V=2: RTP-Versions-Nummer;
• P: Indikator für Padding;
• 10110: Subtyp der Nachricht, 10110 bedeutet „Voting_Answer_Delete"; der angegebene Wert ist nur ein Beispielwert und kann auch anders gewählt werden;
• PT=APP=204: Indikator für Applikations-definierte RTCP-Nachricht;
• Length: Länge der Nachricht nach dem length-Feld in Wörtern (32Bit);
• SSRC: Synchronisation Source des PoC-Teilnehmers, der seine Antwort zurücknimmt; die SSRC identifiziert den Sender von Medien-Strömen eindeutig; sie wird in den 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 Teilnehmerendgerätes, das seine Antwort zurücknimmt; CNAME und NAME sind so genannte SDES items, die in SDES RTCP-Paketen definiert werden, um einen RTP-Teilnehmer zu beschreiben; CNAME ist ein eindeutiger Name des Teilnehmers, der auch außerhalb spezifischer RTP-Sessions weiter besteht (z.B. zusammengesetzt aus user name und host IP-Adresse); NAME ist ein beliebiger Name des Teilnehmers, der typischerweise vom Teilnehmer selbst angegeben wird; NAME muss den 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 eindeutig abgeschlossen; die Liste wird anschließend bis zu Vielfachen von 32 Bit mit Nullen gepadded, wie in [3] beschrieben.

Es wird ferner gemäß dem Ausführungsbeispiel angenommen, das der dritte Teilnehmer T3 keine weiteren Abstimmungs-Antwort-Nachrichten versendet.
Weiterhin wird angenommen, dass der vierte Teilnehmer T4 unsicher ist und seine Antwort erst nach der vorgesehenen Antwort-Periode auswählt und erst dann eine entsprechende, vierte Abstimmungs-Antwort-Nachricht 209 initiiert, welche von dem vierten Mobilfunk-Kommunikations-Endgerät 105 dann erzeugt wird und an die Konferenz-Servereinheit 101 übermittelt wird. Die Antwort, das heißt die Abstimmungs-Antwort-Nachrichten 205, 206, 207, 208, 209 werden von der Konferenz-Servereinheit 101 innerhalb der vorgesehenen Antwort-Zeit gesammelt. Wenn alle Antwort-Nachrichten bei der Konferenz-Servereinheit 101 eingetroffen sind oder, wenn die Antwort-Zeitperiode abgelaufen ist, fasst die Konferenz-Servereinheit 101 die innerhalb der Antwort-Periode getroffenen Antworten zu einer Abstimmungs-Nachricht, im Folgenden auch bezeichnet als Abstimmungs-Zusammenfassungs-Nachricht 210 zusammen und kodiert diese und überträgt diese gemäß dem RTCP an das die Abstimmung initiierende Mobilfunk-Kommunikations-Endgerät, gemäß dieser Ausführungsform der Erfindung an das erste Mobilfunk-Kommunikations-Endgerät 102.
Ein Beispiel des Formats der Abstimmungs-Zusammenfassungs-Nachricht 210 ist in der folgenden Tabelle 4 beispielhaft dargestellt.
Tabelle 4: Format der RTCP-Nachricht zur Zusammenfassung mehrerer Abstimmungs-Antworten
Die Felder der in Tabelle 4 dargestellten RTCP-Nachricht bedeuten im Einzelnen:

• V=2: RTP-Versions-Nummer;
• P: Indikator für Padding;
• 10101: Subtyp der Nachricht, 10101 bedeutet „Voting_Answer"; der angegebene Wert ist nur ein Beispielwert und kann auch anders gewählt werden;
• PT=APP=204: Indikator für Applikations-definierte RTCP-Nachricht;
• Length: Länge der Nachricht nach dem length-Feld in Wörtern (32Bit);
• SSRC: Synchronisation Source des PTT-Servers, der die Zusammenfassungs-Nachricht verschickt; die SSRC identifiziert den Sender von Medien-Strömen eindeutig; sie wird in den 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 Teilnehmerendgerätes, das geantwortet hat; CNAME und NAME sind so genannte SDES items, die in SDES RTCP-Paketen definiert werden, um einen RTP-Teilnehmer zu beschreiben; CNAME ist ein eindeutiger Name des Teilnehmers, der auch außerhalb spezifischer RTP-Sessions weiter besteht (z.B. zusammengesetzt aus user name und host IP-Adresse); NAME ist ein beliebiger Name des Teilnehmers, der typischerweise vom Teilnehmer selbst angegeben wird; NAME muss den 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 eindeutig abgeschlossen; die Liste wird anschließend bis zu Vielfachen von 32 Bit mit Nullen gepadded, wie in [3] beschrieben;
• Voting answer length: Länge des „voting answer text"-Feldes in Bytes; das „voting answer length"-Feld umfasst 16 Bit;
• Voting answer text: Text zur Spezifizierung der Abstimmungs-Antwort;
• Padding: Nullen zum Auffüllen des „voting answer length und text"-Feldes auf ganzzahlige Vielfache von 32 Bits.

Pro Teilnehmer-Antwort werden ein „SDES items"-, ein „voting answer length"-, ein „voting answer text"- und gegebenenfalls ein padding-Feld übertragen.
Abstimmungs-Antwort-Nachrichten, die außerhalb der vorgesehenen Antwort-Zeitperiode bei der Konferenz-Servereinheit 101 eingetroffen sind, wie beispielsweise die vierte Abstimmungs-Antwort-Nachricht 209 von dem vierten Mobilfunk-Kommunikations-Endgeräts 105, werden in der Abstimmungs-Zusammenfassungs-Nachricht 210 nicht berücksichtigt.
Die Konferenz-Servereinheit 101 versendet die Abstimmungs-Zusammenfassungs-Nachricht 210 gemäß dem RTCP an das erste Mobilfunk-Kommunikations-Endgerät 102 und damit an den ersten Teilnehmer T1, da er die Abstimmung, initiiert hatte. Das erste Mobilfunk-Kommunikations-Endgerät 102 dekodiert die empfangene Abstimmungs-Zusammenfassungs-Nachricht und ermittelt aus dieser die Zusammenfassung der Antworten und wertet somit die empfangenen Antworten maschinell automatisch aus und versendet das Ergebnis beispielsweise unter Verwendung des Short Message Service (SMS) als entsprechende SMS-Nachrichten an die Teilnehmer T2, T3, T4 der Abstimmung (in 2 nicht dargestellt).
Es ist in diesem Zusammenhang anzumerken, dass Abstimmungs-Nachrichten auch andere Typen von Antworten verwenden können als den im obigen Beispiel angegebenen „Auswahltyp". Als mögliche Antwort-Typen können vorgesehen sein:

• Menge von Texten („Auswahltyp")
• Ganzzahl von ... bis ...,
• Reelle Zahl von ... bis ...,
• Beliebiger Text,
• ...

Eine Abstimmungs-Nachricht hat allgemein das in obiger Tabelle 1 dargestellte bevorzugte Format. In dem dortigen Beispiel enthält das Feld „voting question text" die Details der Frage in Textform. Die allgemeine Syntax des „voting question text"-Feldes wird im Folgenden entsprechend der in [8] definierten so genannten Backus Naur Form (BNF) beschrieben.
Mittels des „="-Zeichens werden Elemente definiert;
„[", „]" bedeuten optionale Elemente;
"*" definiert Wiederholungen;
„/" trennt alternative Elemente.
Abstimmungsfrage = Fragetext „;" Antworten [„;" Antwortzeit]
Fragetext = Text
Text = *ALPHANUM
Antworten = AntwortTyp „;" Antwortanzahl [„;" Parameter]
AntwortTyp = „AuswahlTyp"/„GanzzahlTyp"/„relleZahlTyp"/„TextTyp"
Antwortanzahl = posGanzzahl
Parameter = (Text *(„;" Text))/Grenzen
Grenzen = (Ganzzahl Ganzzahl)/(reelleZahl reelleZahl)
Antwortzeit = Anfangszeit „;" Endzeit
Anfangszeit = posGanzzahl
Endzeit = posGanzzahl
posGanzzahl = 1*NUM
Ganzzahl = [„+"/„–„] 1*NUM
reelleZahl = [„+"/„–„] 1*NUM [„." 1*NUM]
Dabei bedeutet „ALPHANUM" ein alphanumerisches Zeichen und NUM eine Ziffer.
In einer alternativen Ausführungsform der Erfindung ist die Angabe der Antwort-Zeit nicht vorgesehen. In diesem Fall wird als Antwort-Zeitperiode eine unbegrenzte Zeitdauer ab dem aktuellen Zeitpunkt beziehungsweise die Zeit der Push-to-Talk-Kommunikationssitzung angenommen, dass heißt die Zeit bis zu der die Konferenz läuft. Dies ist insbesondere in dem Fall sinnvoll, wenn die Auswertung die Antworten von allen Teilnehmern erfordert oder, wenn der Auswertungs-Zeitpunkt zum Frage-Zeitpunkt noch nicht feststeht.
Wenn als Antwort-Zeitperiode eine inkonsistente Zeitperiode angegeben wird, dass heißt beispielsweise wenn der Startzeitpunkt zeitlich nach dem Endzeitpunkt liegt (Startzeit ≥ Endzeit), so wird als Antwort-Zeitperiode ebenfalls eine unbegrenzte Zeitdauer ab dem aktuellen Zeitpunkt, beziehungsweise die Zeit der Push-to-Talk-Kommunikationssitzung angenommen.
Entsprechend den in einer Abstimmungs-Frage-Nachricht möglichen Antwort-Typen, können auch in einer Abstimmungs-Antwort-Nachricht, verschiedene Antwort-Typen verwendet werden.
Obige Tabelle 2 zeigt das allgemeine Format einer Abstimmungs-Antwort-Nachricht gemäß diesen Ausführungsbeispielen der Erfindung. Die allgemeine Syntax des „voting answer"-Feldes ist durch folgende Backus Naur Form gegeben:
Antwort = AntwortTyp „;" Antwortanzahl „;" Werte
AntwortTyp = „AuswahlTyp"/„GanzzahlTyp"/„relleZahlTyp"/„TextTyp"
Antwortanzahl = posGanzzahl
Werte = Wert *(„;" Wert)
Wert = posGanzzahl/Ganzzahl/reelleZahl/Text
posGanzzahl = 1*NUM
Die Konferenz-Servereinheit (PTT-Servereinheit) 101 fasst mehrere Antworten der Teilnehmer in der Abstimmungs-Zusammenfassungs-Nachricht gemäß Tabelle 4 zusammen. Die Abstimmungs-Zusammenfassungs-Nachricht 210 wird an den Abstimmungsleiter, das heißt an den Teilnehmer, der die Frage gestellt hat, gesendet. In der Abstimmungs-Zusammenfassungs-Nachricht 210 werden die Antworten der Teilnehmer in der Reihenfolge Ihres Eintreffens bei der Konferenz-Servereinheit 101 aufgelistet. Dies ermöglicht es, auch die Reihenfolge der Antworten bei der Antwort-Auswertung zu berücksichtigen. Dies ist beispielsweise für die Realisierung von Reaktions-Spielen von Bedeutung. In einer alternativen Ausführungsform der Erfindung kann es vorgesehen sein, der jeweiligen Antwort eine Zeitangabe zuzuordnen und zusammen mit der Abstimmungs-Zusammenfassungs-Nachricht zu übermitteln, mit welchen angegeben wird, wann die jeweilige Abstimmungs-Antwort-Nachricht bei der Konferenz-Servereinheit 101 eingegangen ist, oder zu welchem Zeitpunkt die Abstimmungs-Antwort-Nachricht von dem jeweiligen Mobilfunk-Kommunikations-Endgerät gesendet wurde.
Fragen können von dem Abstimmungsleiter auch wieder zurückgenommen werden. Um dies zu tun, erzeugt das Mobilfunk-Kommunikations-Endgerät des Abstimmungsleiters die in der folgenden Tabelle 5 gezeigte Nachricht und sendet sie an die Konferenz-Servereinheit 101. Die Konferenz-Servereinheit 101 verteilt diese Nachricht dann an die Teilnehmer beziehungsweise deren Mobilfunk-Kommunikations-Endgeräte. Die Rücknahme einer Abstimmung beendet die Abstimmung.
Die folgende Tabelle 5 zeigt das Format der Abstimmungs-Rücknahme-Nachricht gemäß einem Ausführungsbeispiel der Erfindung:
Tabelle 5: Format der RTCP-Nachricht zur Rücknahme einer Abstimmungs-Frage
Die Felder der in Tabelle 5 dargestellten RTCP-Nachricht bedeuten im Einzelnen:

• V=2: RTP-Versions-Nummer;
• P: Indikator für Padding;
• 10111: Subtyp der Nachricht, 10111 bedeutet „Voting_Question_Delete"; der angegebene Wert ist nur ein Beispielwert und kann auch anders gewählt werden;
• PT=APP=204: Indikator für Applikations-definierte RTCP-Nachricht;
• Length: Länge der Nachricht nach dem length-Feld in Wörtern (32Bit);
• SSRC: Synchronisation Source des PoC-Teilnehmers, der seine Frage zurücknimmt; die SSRC identifiziert den Sender von Medien-Strömen eindeutig; sie wird in den 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 Teilnehmerendgerätes, das seine Frage zurücknimmt; CNAME und NAME sind so genannte SDES items, die in SDES RTCP-Paketen definiert werden, um einen RTP-Teilnehmer zu beschreiben; CNAME ist ein eindeutiger Name des Teilnehmers, der auch außerhalb spezifischer RTP-Sessions weiter besteht (z.B. zusammengesetzt aus user name und host IP-Adresse); NAME ist ein beliebiger Name des Teilnehmers, der typischerweise vom Teilnehmer selbst angegeben wird; NAME muss den 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 eindeutig abgeschlossen; die Liste wird anschließend bis zu Vielfachen von 32 Bit mit Nullen gepadded, wie in [3] beschrieben.

Eine Abstimmung zurückzunehmen kann beispielsweise dann sinnvoll sein, wenn bereits ausreichend viele Antworten von Teilnehmern an der Abstimmung gegeben wurden, obwohl die Antwort-Zeitperiode noch nicht abgelaufen ist und noch nicht alle Teilnehmer geantwortet haben. Wie viele Antworten, das heißt wie viele Abstimmungs-Antwort-Nachrichten schon eingegangen sind, kann der Abstimmungsleiter mit der weiter unten definierten und detailliert beschriebenen Nachricht zur Abfrage von Zwischen-Ergebnissen feststellen.
Eine Frage kann auch aus anderen Gründen zurückgenommen werden, etwa, weil die Frage nicht mehr sinnvoll oder interessant erscheint.
Eine bereits versendete Antwort kann von dem Teilnehmer, der die Antwort versendet hatte auf zwei unterschiedliche Arten wieder zurückgenommen werden. Zum einen kann der Teilnehmer beziehungsweise dessen Mobilfunk-Kommunikations-Endgerät eine erneute Abstimmungs-Antwort-Nachricht senden. Dadurch wird die alte Antwort außer Kraft gesetzt. Es hat immer nur die zuletzt gesendete Abstimmungs-Antwort-Nachricht Gültigkeit. Zum anderen kann der Teilnehmer beziehungsweise dessen Mobilfunk-Kommunikations-Endgeräte die in Tabelle 3 gezeigte Nachricht an die Konferenz-Servereinheit 101 senden. Dadurch nimmt der Teilnehmer beziehungsweise sein Mobilfunk-Kommunikations-Endgerät seine Antwort zurück, ohne sie durch eine andere zu ersetzen. Der Antwort-Status des Teilnehmers entspricht dem Antwort-Status eines Teilnehmers, der keine Antwort gegeben hat.
Der Abstimmungsleiter, beziehungsweise sein Mobilfunk-Kommunikations-Endgerät muss nicht warten, bis alle Teilnehmer geantwortet haben oder die Antwort-Phase der Abstimmung abgelaufen ist, um ein Abstimmungs-Ergebnis zu erhalten. Der Abstimmungsleiter kann vielmehr schon während der Antwort-Phase der Abstimmung ein Zwischen-Ergebnis der Abstimmung anfordern, indem er die in Tabelle 6 gezeigte Nachricht gemäß dem RTCP an die Konferenz-Servereinheit 101 versendet.
Die folgende Tabelle 6 zeigt das Format einer Zwischen-Ergebnis-Anforderungs-Nachricht gemäß dem RTCP gemäß einem Ausführungsbeispiel der Erfindung:
Tabelle 6: Format der RTCP-Nachricht zur Rücknahme einer Abstimmungs-Frage
Die Felder der in Tabelle 6 dargestellten RTCP-Nachricht bedeuten im Einzelnen:

• V=2: RTP-Versions-Nummer;
• P: Indikator für Padding;
• 11000: Subtyp der Nachricht, 11000 bedeutet „Voting_Answers_Request"; der angegebene Wert ist nur ein Beispielwert und kann auch anders gewählt werden;
• PT=APP=204: Indikator für Applikations-definierte RTCP-Nachricht;
• Length: Länge der Nachricht nach dem length-Feld in Wörtern (32Bit);
• SSRC: Synchronisation Source des PoC-Teilnehmers, der die bisher gegebenen Antworten anfordert; die SSRC identifiziert den Sender von Medien-Strömen eindeutig; sie wird in den 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 Teilnehmerendgerätes, das die bisher gegebenen Antworten anfordert; CNAME und NAME sind so genannte SDES items, die in SDES RTCP-Paketen definiert werden, um einen RTP-Teilnehmer zu beschreiben; CNAME ist ein eindeutiger Name des Teilnehmers, der auch außerhalb spezifischer RTP-Sessions weiter besteht (z.B. zusammengesetzt aus user name und host IP-Adresse); NAME ist ein beliebiger Name des Teilnehmers, der typischerweise vom Teilnehmer selbst angegeben wird; NAME muss den 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 eindeutig abgeschlossen; die Liste wird anschließend bis zu Vielfachen von 32 Bit mit Nullen gepadded, wie in [3] beschrieben.

Die Konferenz-Servereinheit 101 prüft auf den Erhalt der Zwischen-Ergebnis-Anforderungs-Nachricht zunächst, ob der anfragende Teilnehmer berechtigt ist, Ergebnisse oder Zwischen-Ergebnisse der Abstimmung anzufordern. Wenn der Teilnehmer beziehungsweise dessen Mobilfunk-Kommunikations-Endgerät dazu berechtigt ist, weil er beispielsweise, wie in diesem Fall angenommen, der Initiator der Abstimmung ist, antwortet die Konferenz-Servereinheit 101 mit einer Abstimmungs-Zusammenfassungs-Nachricht, wie oben in Tabelle 4 dargestellt, die alle bis zum Zeitpunkt der Abfrage-Nachricht abgegebenen Antworten enthält.
Die Darstellung der möglichen Antworten einer Abstimmung ist dem Kommunikations-Endgerät überlassen. Insbesondere können die Auswahl-Typ-Antworten des obigen Beispiels auch durch andere Mittel als durch Radio-Buttons auswählbar gemacht werden, beispielsweise mittels eines Pop-up-Menüs oder mittels einer frei-wählbaren Eingabe von Textinformation.
Gemäß einer anderen Ausgestaltung der Erfindung ist es vorgesehen, dass die Antworten einer Abstimmung in einem anderen Kommunikations-Endgerät ausgewertet werden, und nicht in einem Teilnehmer-Kommunikations-Endgerät. Sie können alternativ auch in einem Netzwerk-Element ausgewertet werden. Zu diesem Zweck dient das Netzwerk-Element als Teilnehmer an der Push-to-Talk-Kommunikations-Sitzung und initiiert die Abstimmung und das Versenden der Abstimmungs-Frage an die Teilnehmer der Push-to-Talk-Kommunikations-Sitzung.
Anstatt die Abstimmung, wie im obigen Beispiel durch den Abstimmungsleiter beziehungsweise dessen Mobilfunk-Kommunikations-Endgerät auszuwerten und das Ergebnis mittels SMS an die Teilnehmer zu verteilen, kann der Abstimmungsleiter die Abstimmungs-Zusammenfassungs-Nachricht der Abstimmung direkt an die Teilnehmer weiterleiten.
Die Frage einer Abstimmung kann einem Teilnehmer alternativ auch als Audio-Datenstrom präsentiert werden. Dies kann auf folgende verschiedene Arten durchgeführt werden:

1. Zum einen kann eine in Textform empfangene Frage durch das Teilnehmer-Kommunikations-Endgerät in Audio-Daten umgewandelt und von diesem ausgegeben werden.
2. Zum anderen kann in der Abstimmungs-Nachricht anstelle einer textuellen Abstimmungs-Frage ein Audio-Datenstrom übermittelt werden, welcher inhaltlich die Abstimmungs-Frage repräsentiert. Das Format der Abstimmungs-Nachricht ist in diesem Fall entsprechend zu erweitern, so dass auch andere Datenformate, beispielsweise andere Medien-Datenströme übertragen werden können. Ebenso kann die Abstimmungs-Frage auch durch andere Medienformen präsentiert werden, beispielsweise bildlich oder als Film.
3. Die Abstimmungs-Frage kann auch mittels eines Push-to-Talk-Talk Bursts versendet werden. Dabei wird die in dem Beispiel beschriebene Abstimmungs-Frage-Nachricht versendet, wobei die Abstimmungs-Frage-Nachricht zusätzlich einen Hinweis enthält, dass die Abstimmungs-Frage (nur oder auch) in Form des aktuellen Talk-Bursts versendet wird.

Es kann alternativ vorgesehen sein, in der Abstimmungs-Zusammenfassungs-Nachricht der Push-to-Talk-Konferenz-Servereinheit nicht nur die bisher gegebenen Antworten zusammenzufassen, sondern darüber hinaus auch anzugeben, welche Kommunikationssitzungs-Teilnehmer bislang noch nicht geantwortet haben. Zur Übertragung dieser Information kann ebenfalls das in obiger Tabelle 4 gezeigte Format einer Abstimmungs-Zusammenfassungs-Nachricht verwendet werden. Für die Teilnehmer, die noch nicht geantwortet haben, werden ebenfalls Einträge gemacht, und zwar mit den Werten: „Voting Answer Length"-Feld = 0 und „Voting Answer Text"-Feld = leer.
Oftmals wird der Leiter einer Abstimmung nicht selbst abstimmen beziehungsweise antworten. Prinzipiell kann aber auch der Abstimmungsleiter an seiner eigenen Abstimmung teilnehmen. Dann sollte die Abstimmungs-Applikation des Teilnehmer-Kommunikations-Endgeräts des Abstimmungsleiters dem Abstimmungsleiter während der Antwort-Zeitperiode keine Informationen über bisherige Abstimmungs-Antworten zur Verfügung stellen.
Anstatt die Zeitdauer einer Abstimmung in der Abstimmungs-Frage-Nachricht durch absolute Zeiten anzugeben, kann die Zeitdauer auch relativ zur aktuellen Zeit angegeben werden. Alternativ können auch Ereignisse als zeitliche Begrenzung der Abstimmung angegeben werden, beispielsweise kann das Ende der Abstimmung durch die Abgabe von Antworten von mindestens n Teilnehmern definiert sein. Es kann auch ein anderes als das NTP-Time Stamp Format, wie es in [7] beschrieben ist, für Zeitangaben verwendet werden.
Die Konferenz-Servereinheit 101 kann in der Abstimmungs-Zusammenfassungs-Nachricht auch die Zeitpunkte der einzelnen Teilnehmer-Antworten übermitteln. Das Format der Abstimmungs-Zusammenfassungs-Nachricht kann dazu gemäß folgender Tabelle 7 erweitert werden:
Tabelle 7: Format der RTCP-Nachricht zur Beantwortung einer Abstimmungs-Frage mit Zeitangabe
Die Felder der in Tabelle 7 dargestellten RTCP-Nachricht bedeuten im Einzelnen:

• V=2: RTP-Versions-Nummer;
• P: Indikator für Padding;
• 11001: Subtyp der Nachricht, 11001 bedeutet „Voting_Answer" mit Zeitangabe; der angegebene Wert ist nur ein Beispielwert und kann auch anders gewählt werden;
• PT=APP=204: Indikator für Applikations-definierte RTCP-Nachricht;
• Length: Länge der Nachricht nach dem length-Feld in Wörtern (32Bit);
• SSRC: Synchronisation Source des antwortenden PoC-Teilnehmers. Die SSRC identifiziert den Sender von Medien-Strömen eindeutig; sie wird in den 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 Teilnehmerendgerätes, das antwortet; CNAME und NAME sind so genannte SDES items, die in SDES RTCP-Paketen definiert werden, um einen RTP-Teilnehmer zu beschreiben; CNAME ist ein eindeutiger Name des Teilnehmers, der auch außerhalb spezifischer RTP-Sessions weiter besteht (z.B. zusammengesetzt aus user name und host IP-Adresse); NAME ist ein beliebiger Name des Teilnehmers, der typischerweise vom Teilnehmer selbst angegeben wird; NAME muss den 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 eindeutig abgeschlossen; die Liste wird anschließend bis zu Vielfachen von 32 Bit mit Nullen gepadded, wie in [3] beschrieben;
• Voting answer time: Zeitpunkt der Antwort im NTP time stamp Format;
• Voting answer length: Länge des „voting answer text"-Feldes in Bytes; das „voting answer length"-Feld umfasst 16 Bit;
• Voting answer text: Text zur Spezifizierung der Abstimmungs-Antwort;
• Padding: Nullen zum Auffüllen des „voting answer length und text"-Feldes auf ganzzahlige Vielfache von 32 Bits.

Die Angabe von Antwort-Zeiten ermöglicht eine genauere Auswertung der Reaktionszeiten der Teilnehmer, beispielsweise für Spiele.
Innerhalb einer Push-to-Talk-Kommunikationssitzung können auch mehrere Abstimmungen gleichzeitig durchgeführt werden. Um die RTCP-Nachrichten der verschiedenen Abstimmungen unterscheiden zu können, erhalten sie Zusatzfelder, welche die Abstimmungen identifizieren.
Die folgende Tabelle 8 zeigt eine entsprechende Erweiterung des Formats der Abstimmungs-Nachrichten:
Tabelle 8: Erweiterung der Abstimmungs-Nachrichten um einen Abstimmungs-Identifikator
Die Felder der in Tabelle 8 dargestellten RTCP-Nachricht bedeuten im Einzelnen:

• V=2: RTP-Versions-Nummer;
• P: Indikator für Padding;
• XXXXX: Subtyp der Nachricht, Wert je nach Abstimmungs-Nachricht;
• PT=APP=204: Indikator für Applikations-definierte RTCP-Nachricht;
• Length: Länge der Nachricht nach dem length-Feld in Wörtern (32Bit);
• SSRC: Synchronisation Source des Senders (Teilnehmerendgerät oder PTT-Server); die SSRC identifiziert den Sender von Medien-Strömen eindeutig; sie wird in den 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 Senders (Teilnehmerendgerät oder PTT-Server); CNAME und NAME sind so genannte SDES items, die in SDES RTCP-Paketen definiert werden, um einen RTP-Teilnehmer zu beschreiben; CNAME ist ein eindeutiger Name des Teilnehmers, der auch außerhalb spezifischer RTP-Sessions weiter besteht (z.B. zusammengesetzt aus user name und host IP-Adresse); NAME ist ein beliebiger Name des Teilnehmers, der typischerweise vom Teilnehmer selbst angegeben wird; NAME muss den 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 eindeutig abgeschlossen; die Liste wird anschließend bis zu Vielfachen von 32 Bit mit Nullen gepadded, wie in [3] beschrieben;
• SSRC of voting initiator: SSRC des Teilnehmers, der die Abstimmung initiiert hat;
• Voting ID: Eine Zahl zur eindeutigen Identifizierung der Abstimmung unter den Abstimmungen des initiierenden Teilnehmers;
• Additional data: Weitere Informationen der Abstimmungs-Nachricht; die Informationen hängen vom Subtyp der Nachricht ab; sie entsprechen den Zusatz-Informationen, die in den oben definierten Abstimmungs-Nachrichten (ohne Abstimmungs-Identifikator) angegeben sind.

Die Identifikation der Abstimmungen setzt sich aus der SSRC des jeweiligen Abstimmungs-Initiators und einer zusätzlichen Abstimmungsnummer zusammen. Wenn ein Teilnehmer zum zweiten Mal die Abstimmungs-Nummer einer bereits laufenden Abstimmung in einer Abstimmungs-Frage verwendet, wird die erste Abstimmung der beiden Abstimmungen beendet und die zweite Abstimmung wird initiiert.
Die Antwort auf eine Auswahl-Frage kann alternativ auch als Text gegeben werden. Das dem obigen Beispiel entsprechende „Voting Answer Text"-Feld lautet dann: Texttyp;1;Mount Everest
Als mögliche Antworten können auch weitere als die anderen, oben angegebenen Antwort-Typen definiert sein, beispielsweise die Aufnahme einer Sprachnachricht.
Als mögliche Antworten können auch andere Medien als Text verwendet werden, beispielsweise Bilder oder Sprachnachrichten.
Das „voting question text"-Feld und das „voting answer text"-Feld einer RTCP-Abstimmungs-Frage-Nachricht beziehungsweise einer RTCP-Abstimmungs-Antwort kann auch anders formatiert sein als in den obigen Beispielen angegeben.
In einer alternativen Ausführungsformen der Erfindung ist eine Anwendung nicht nur in einem Push-to-Talk-Kommunikationssystem zur Übertragung von Audio-Daten vorgesehen, sondern auch der Einsatz in einem Push-to-Talk-Kommunikationssystem zur Übertragung anderer Daten, insbesondere zur Übertragung von anderen Mediendaten.
Ferner ist alternativ das Kommunikationssystem, beispielsweise das Konferenz-System nicht als Push-to-Talk-Kommunikationssystem eingerichtet, sondern als ein anderes Konferenz-System, welches das RTCP, allgemein ein Echtzeit- Transportprotokoll-Steuerungsprotokoll, verwendet, insbesondere als Kommunikationssystem mit einem Konferenz-System gemäß der IETF, beispielsweise wie es in [1] beschrieben ist.
Ferner können Abstimmungen mittels RTCP verwendet werden, um darüber abzustimmen, welcher Teilnehmer als nächster das Sprechrecht bekommen soll (Floor Control). Dazu nimmt ein maschineller Teilnehmer als Abstimmungsleiter an der Kommunikation teil. Er initiiert die Abstimmung darüber, welcher als nächster das Sprechrecht zugewiesen bekommen soll, und wertet die gegebenen Antworten aus. Der maschinelle Teilnehmer sollte berechtigt sein, das Sprechrecht vergeben zu dürfen, das heißt anders ausgedrückt, er weist die Funktion des so genannten „Floor Chair" auf. Je nach Ergebnis der Auswertung vergibt der maschinelle Teilnehmer das Sprechrecht.
Ein Aspekt der Erfindung ist darin zu sehen, in einem Kommunikationssystem, welches das Real-Time Control Protocol (RTCP) verwendet, Abstimmungs-Nachrichten als spezielle RTCP-Datenpakete zu versenden.
Internet Protocol-basierte Kommunikationssysteme (wie beispielsweise Push-to-Talk-Kommunikationssysteme oder auf dem Internet Protocol (IP) basierende Konferenz-Systeme) nutzen meist das Real-Time Transport Protocol (RTP), um Mediendaten zu übertragen. Die RTP-Kommunikationsverbindungen werden mit Hilfe des RTCPs kontrolliert. Gemäß einem Aspekt der Erfindung werden die RTCP-Kommunikationsverbindungen genutzt zur Übertragung spezieller RTCP-Nachrichten für Abstimmungs-Funktionalitäten.
Es werden gemäß einem anderen Aspekt der Erfindung spezielle RTCP-Nachrichten für die Übertragung der Abstimmungsfrage, der Abstimmungsantworten und die Rücknahme von Abstimmungsfragen und Abstimmungsantworten festgelegt.
Vorteil der Festlegung der speziellen Abstimmungs-Nachrichten ist, dass die Abstimmung maschinell ausgewertet werden kann. Sind die möglichen auswählbaren Antworten nicht festgelegt, so kann es vorgesehen sein, dass in der Auswerte-Einheit eine Parser-Einheit enthalten ist, welche automatisiert die im Freitext gegebenen Antworten analysiert und daraus das Abstimmungs-Ergebnis ermittelt.
Die Abstimmungs-Nachrichten haben ein einfaches Format und sind Text-basiert, was den Vorteil hat, dass die Nachrichten leicht lesbar und kurz sind.
Die zentrale Konferenz-Servereinheit des Kommunikationssystems führt die Abstimmungs-Antworten in einer RTCP-Nachricht zusammen. Die Konferenz-Servereinheit informiert den Abstimmungsleiter mittels Versendens einer Abstimmungs-Zusammenfassungs-Nachricht über das Abstimmungsergebnis. Dies hat den Vorteil, dass die Konferenz-Servereinheit zur Benachrichtigung des Abstimmungsleiters über das Abstimmungsergebnis nur eine Nachricht versenden muss. Dadurch, dass die Abstimmungsergebnisse zentral gesammelt und gespeichert werden, können Abstimmungs-(Zwischen-)Ergebnisse vorteilhaft auch durch ein anforderndes Teilnmehmer-Kommunikations-Endgerät abgefragt werden.
Die Abstimmungsergebnisse können durch ein Teilnehmer-Kommunikations-Endgerät oder durch ein Element in dem Kommunikationsnetzwerk ausgewertet werden. Dies hat den Vorteil, dass die Architektur des Abstimmungs-Kommunikationssystems flexibel festgelegt werden kann.
In diesem Dokument sind folgende Veröffentlichungen zitiert:

[1] J. Rosenberg, IETF Internet-Draft, A Framework for Conferencing with the Session Initiation Protocol, draft-ietf-sipping-conferencing-framework-00.txt, Mai 2003;
[2] Open Mobile Alliance: "Push to talk over Cellular (PoC) – Architecture", Candidate Version 1.0, April 2005;
[3] H. Schulzrinne et al, IETF Request For Comments RFC 3550, RTP: A Transport Protocol for Real-Time Applications, Juli 2003;
[4] J. Vogel, RTP/I Payload Type Definition for Feedback Tools, Universität Mannhein, 2001;
[5] R. Parviainen, multicast Interactive Radio, Centre for Distance-spanning Technology, Department of Computer Science, Luleå University of Technology, 971 87 Luleå, Sweden, erhältlich im Internet unter: http://www.cdt.luth.se/~rolle/docs/pajava/mir.html.
[6] Wen-Tsuen Chen et al, On the Design of a High-Speed Network Environment for Multimedia Applications, Proc. Natl. Sci. Counc. ROC (A), Vol. 23, Nr. 1, Seiten 111 bis 124, 1999, erhältlich im Internet unter: http://nr.stic.gov.tw/ejournal/ProceedingA/v23n1/111-124.pdf.
[7] D. Mills, IETF Request For Comments RFC 1305, Network Time Protocol (Version 3) Specification, Implementation and Analysis, März 1992;
[8] D.Crocker et al., IETF Request For Comments RFC 2234, Augmented BNF for Syntax Specifications: ABNF, November 1997
[9] US 2004/0033478 A1
[10] US 2004/0249884 A1

100: Push-to-Talk over Cellular Konferenzsystem
101: Push-to-Talk over Cellular-Servereinheit
102: Erstes Mobilfunk-Kommunikations-Endgerät
103: Zweites Mobilfunk-Kommunikations-Endgerät
104: Drittes Mobilfunk-Kommunikations-Endgerät
105: Viertes Mobilfunk-Kommunikations-Endgerät
106: Mobilfunk-Kommunikationsverbindung
107: Mobilfunk-Kommunikationsverbindung
108: Mobilfunk-Kommunikationsverbindung
109: Mobilfunk-Kommunikationsverbindung
200: Nachrichten-Fluss-Diagramm
201: Erste Abstimmung-Nachricht
202: Zweite Abstimmung-Nachricht
203: Dritte Abstimmung-Nachricht
204: Vierte Abstimmung-Nachricht
205: Erste Abstimmung-Antwort-Nachricht
206: Zweite Abstimmung-Antwort-Nachricht
207: Dritte Abstimmung-Antwort-Nachricht
208: Abstimmung-Antwort-Rücknahme-Nachricht
209: Vierte Abstimmung-Antwort-Nachricht
210: Abstimmung-Zusammenfassungs-Nachricht

Claims

Verfahren zum rechnergestützten Erstellen einer Abstimmungs-Nachricht in einer Konferenz zwischen mehreren Kommunikations-Endgeräten, bei dem die Abstimmungs-Nachricht gemäß einem Transportprotokoll-Steuerungsprotokoll, mittels welchem ein Transportprotokoll gesteuert wird, codiert wird, wobei eine mindestens eine Abstimmungs-Frage und/oder eine mindestens eine Abstimmungs-Antwort identifizierende Information der Abstimmungs-Nachricht hinzugefügt wird.
Verfahren zum rechnergestützten Ermitteln mindestens eines Abstimmungs-Ergebnisses mindestens einer Abstimmung in einer Konferenz zwischen mehreren Kommunikations-Endgeräten, • bei dem mindestens eine empfangene Abstimmungs-Antwort-Nachricht, welche gemäß einem Transportprotokoll-Steuerungsprotokoll, mittels welchem ein Transportprotokoll gesteuert wird, codiert ist, decodiert wird, wobei die Abstimmungs-Antwort-Nachricht mindestens eine Antwort auf die mindestens eine Abstimmungs-Frage der Abstimmung enthält, • bei dem die mindestens eine Antwort aus der decodierten Abstimmungs-Antwort-Nachricht ermittelt wird, • bei dem unter Verwendung der mindestens einen Antwort mindestens ein Abstimmungs-Ergebnis ermittelt wird.
Verfahren gemäß Anspruch 1 oder 2, bei dem als Transportprotokoll-Steuerungsprotokoll ein Echtzeit-Transportprotokoll-Steuerungsprotokoll verwendet wird, mittels welchem ein Echtzeit-Transportprotokoll gesteuert wird.
Verfahren gemäß Anspruch 3, bei dem als Echtzeit-Transportprotokoll-Steuerungsprotokoll das Real-Time Transport Control Protocol verwendet wird.
Verfahren gemäß Anspruch 3 oder 4, bei dem als Echtzeit-Transportprotokoll das Real-Time Transport Protocol verwendet wird.
Verfahren gemäß einem der Ansprüche 1 bis 5, bei dem die mindestens eine Abstimmung in einer Halb-Duplex-Konferenz durchgeführt wird.
Verfahren gemäß Anspruch 6, bei dem die mindestens eine Abstimmung in einer Push-to-Talk-Konferenz durchgeführt wird.
Verfahren gemäß Anspruch 7, bei dem die mindestens eine Abstimmung in einer Push-to-Talk over Cellular-Konferenz durchgeführt wird.
Verfahren gemäß einem der Ansprüche 1 bis 6, bei dem die mindestens eine Abstimmung in einer Internet Protocol-basierten Konferenz durchgeführt wird.
Verfahren gemäß einem der Ansprüche 2 bis 9, • bei dem die mindestens eine Abstimmungs-Antwort-Nachricht von einer Konferenz-Servereinheit empfangen wird, und/oder • bei dem das mindestens eine Abstimmungs-Ergebnis von einer Konferenz-Servereinheit ermittelt wird.
Verfahren gemäß einem der Ansprüche 2 bis 10, bei dem das ermittelte mindestens eine Abstimmungs-Ergebnis an mindestens ein an der Konferenz teilnehmendes Kommunikations-Endgerät übermittelt wird.
Verfahren gemäß Anspruch 11, bei dem das ermittelte mindestens eine Abstimmungs-Ergebnis an das Kommunikations-Endgerät übermittelt wird, welches die mindestens eine Abstimmung initiiert hat.
Verfahren gemäß einem der Ansprüche 2 bis 9, • bei dem die mindestens eine Abstimmungs-Antwort-Nachricht von einer Konferenz-Servereinheit empfangen wird, und • bei dem die Abstimmungs-Antwort-Nachricht und/oder mindestens eine in der Abstimmungs-Antwort-Nachricht enthaltene Abstimmungs-Antwort-Information an mindestens ein an der Konferenz teilnehmendes Kommunikations-Endgerät übermittelt wird.
Verfahren gemäß Anspruch 13, bei dem die ermittelte Abstimmungs-Antwort-Nachricht und/oder mindestens eine in der Abstimmungs-Antwort-Nachricht enthaltene Abstimmungs-Antwort-Information an das Kommunikations-Endgerät übermittelt wird, welches die Abstimmung initiiert hat.
Verfahren zum rechnergestützten Bearbeiten einer Abstimmungs-Nachricht in einer Konferenz zwischen mehreren Kommunikations-Endgeräten, • bei dem eine gemäß einem Transportprotokoll-Steuerungsprotokoll, mittels welchem ein Transportprotokoll gesteuert wird, codierte Abstimmungs-Nachricht empfangen wird, • bei dem eine mindestens eine Abstimmungs-Frage und/oder eine mindestens eine Abstimmungs-Antwort identifizierende Information, welche in der Abstimmungs-Nachricht enthalten ist, aus der Abstimmungs-Nachricht ermittelt wird, • bei dem einem Benutzer eines an der Abstimmung teilnehmenden Kommunikations-Endgeräts die mindestens eine Abstimmungs-Frage und/oder mindestens eine Abstimmungs-Antwort dargestellt wird, und • bei dem ein Benutzer mindestens eine Antwort auf die mindestens eine Abstimmungs-Frage eingibt, • bei dem eine Abstimmungs-Antwort-Nachricht gemäß einem Transportprotokoll-Steuerungsprotokoll, mittels welchem ein Transportprotokoll gesteuert wird, codiert wird, wobei eine die mindestens eine Antwort auf die mindestens eine Abstimmungs-Frage identifizierende Information der Abstimmungs-Antwort-Nachricht hinzugefügt wird.
Verfahren gemäß Anspruch 15, bei dem als Transportprotokoll-Steuerungsprotokoll ein Echtzeit-Transportprotokoll-Steuerungsprotokoll verwendet wird, mittels welchem ein Echtzeit-Transportprotokoll gesteuert wird.
Verfahren gemäß Anspruch 15 oder 16, bei dem die Abstimmungs-Antwort-Nachricht zu einer Konferenz-Servereinheit gesendet wird.
Verfahren gemäß Anspruch 16 oder 17, bei dem als Echtzeit-Transportprotokoll-Steuerungsprotokoll das Real-Time Transport Control Protocol verwendet wird.
Verfahren gemäß einem der Ansprüche 16 bis 18, bei dem als Echtzeit-Transportprotokoll das Real-Time Transport Protocol verwendet wird.
Verfahren gemäß einem der Ansprüche 15 bis 19, bei dem die mindestens eine Abstimmung in einer Halb-Duplex-Konferenz durchgeführt wird.
Verfahren gemäß Anspruch 20, bei dem die mindestens eine Abstimmung in einer Push-to-Talk-Konferenz durchgeführt wird.
Verfahren gemäß Anspruch 21, bei dem die mindestens eine Abstimmung in einer Push-to-Talk over Cellular-Konferenz durchgeführt wird.
Verfahren gemäß einem der Ansprüche 15 bis 20, bei dem die mindestens eine Abstimmung in einer Internet Protocol-basierten Konferenz durchgeführt wird.
Transportprotokoll-Steuerungsprotokoll-Einheit, eingerichtet zum Erstellen einer Abstimmungs-Nachricht in einer Konferenz zwischen mehreren Kommunikations-Endgeräten, wobei die Abstimmungs-Nachricht gemäß einem Transportprotokoll-Steuerungsprotokoll, mittels welchem ein Transportprotokoll gesteuert wird, codiert wird, wobei eine mindestens eine Abstimmungs-Frage und/oder eine mindestens eine Abstimmungs-Antwort identifizierende Information der Abstimmungs-Nachricht hinzugefügt wird.
Transportprotokoll-Steuerungsprotokoll-Einheit gemäß Anspruch 24, eingerichtet als Echtzeit-Transportprotokoll-Steuerungsprotokoll-Einheit, eingerichtet zum Erstellen einer Abstimmungs-Nachricht in einer Konferenz zwischen mehreren Kommunikations-Endgeräten, wobei die Abstimmungs-Nachricht gemäß einem Echtzeit-Transportprotokoll-Steuerungsprotokoll, mittels welchem ein Echtzeit-Transportprotokoll gesteuert wird, codiert ist.
Transportprotokoll-Steuerungsprotokoll-Einheit gemäß Anspruch 25, eingerichtet gemäß dem Real-Time Transport Control Protocol.
Konferenz-Abstimmungs-Auswerte-Einheit, • mit einer Transportprotokoll-Steuerungsprotokoll-Einheit, eingerichtet zum Decodieren mindestens einer Abstimmungs-Antwort-Nachricht, welche gemäß einem Transportprotokoll-Steuerungsprotokoll, mittels welchem ein Transportprotokoll gesteuert wird, codiert ist, • mit einer Ermittlungseinheit zum Ermitteln mindestens einer eine Antwort auf mindestens eine Abstimmungs-Frage identifizierenden Information aus der decodierten Abstimmungs-Antwort-Nachricht, • mit einer Abstimmungs-Auswerteeinheit, welche eingerichtet ist zum Ermitteln eines Abstimmungs-Ergebnisses unter Verwendung der mindestens einen die Antwort auf mindestens eine Abstimmungs-Frage identifizierenden Information.
Konferenz-Abstimmungs-Auswerte-Einheit gemäß Anspruch 27, wobei die Transportprotokoll-Steuerungsprotokoll-Einheit eingerichtet ist als Echtzeit-Transportprotokoll-Steuerungsprotokoll-Einheit.
Konferenz-Abstimmungs-Auswerte-Einheit gemäß Anspruch 28, wobei die Echtzeit-Transportprotokoll-Steuerungsprotokoll-Einheit eingerichtet ist gemäß dem Real-Time Transport Control Protocol.
Konferenz-Servereinheit mit einer Konferenz-Abstimmungs-Auswerte-Einheit gemäß einem der Ansprüche 27 bis 29.
Transportprotokoll-Steuerungsprotokoll-Einheit, eingerichtet zum Erstellen einer Abstimmungs-Antwort-Nachricht in einer Konferenz zwischen mehreren Kommunikations-Endgeräten, wobei die Abstimmungs-Antwort-Nachricht gemäß einem Transportprotokoll-Steuerungsprotokoll, mittels welchem ein Transportprotokoll gesteuert wird, codiert wird, wobei eine mindestens eine Abstimmungs-Antwort auf mindestens eine Abstimmungs-Frage identifizierende Information der Abstimmungs-Antwort-Nachricht hinzugefügt wird, codiert ist.
Transportprotokoll-Steuerungsprotokoll-Einheit gemäß Anspruch 31, eingerichtet als Echtzeit-Transportprotokoll-Steuerungsprotokoll-Einheit, eingerichtet zum Erstellen einer Abstimmungs-Antwort-Nachricht in einer Konferenz zwischen mehreren Kommunikations-Endgeräten, wobei die Abstimmungs-Nachricht gemäß einem Echtzeit-Transportprotokoll-Steuerungsprotokoll, mittels welchem ein Echtzeit-Transportprotokoll gesteuert wird.
Transportprotokoll-Steuerungsprotokoll-Einheit gemäß Anspruch 31 oder 32, eingerichtet gemäß dem Real-Time Transport Control Protocol.
Kommunikations-Endgerät, • mit einer Konferenz-Einheit, welche eingerichtet ist zum Bereitstellen einer Konferenz mit mindestens einem anderen Kommunikations-Endgerät, • mit einer ersten Transportprotokoll-Steuerungsprotokoll-Einheit, eingerichtet zum Decodieren mindestens einer Abstimmungs-Nachricht, welche gemäß einem Transportprotokoll-Steuerungsprotokoll, mittels welchem ein Transportprotokoll gesteuert wird, codiert ist, • mit einer Ermittlungseinheit zum Ermitteln mindestens einer eine Abstimmungs-Frage und/oder mindestens einer eine Abstimmungs-Antwort identifizierenden Information aus der decodierten Abstimmungs-Nachricht, • mit einer Darstellungseinheit zum Darstellen der ermittelten Information oder der daraus ermittelten mindestens einen Abstimmungs-Frage und/oder mindestens einen Abstimmungs-Antwort an einen Benutzer, • mit einer Eingabeeinheit zum Eingeben mindestens einer Antwort auf die mindestens eine Abstimmungs-Frage, • mit einer zweiten Transportprotokoll-Steuerungsprotokoll-Einheit, welche eingerichtet ist zum Erstellen einer Abstimmungs-Antwort-Nachricht in einer Konferenz zwischen mehreren Kommunikations-Endgeräten, wobei die Abstimmungs-Antwort-Nachricht gemäß einem Transportprotokoll-Steuerungsprotokoll, mittels welchem ein Transportprotokoll gesteuert wird, codiert wird, wobei eine die mindestens eine Antwort auf die mindestens eine Abstimmungs-Frage identifizierende Information der Abstimmungs-Antwort-Nachricht hinzugefügt wird.