DE102004053597B4

DE102004053597B4 - Verfahren zum automatischen Erzeugen und/oder Steuern einer Telekommunikations-Konferenz mit einer Vielzahl von Teilnehmern, Telekommunikations-Konferenz-Endgerät und Telekommunikations-Konferenz-Servereinrichtung

Info

Publication number: DE102004053597B4
Application number: DE102004053597A
Authority: DE
Inventors: Norbert Schwagmann; Andreas Schmidt; Holger Schmidt; Marcus Dr. Benthin
Original assignee: Infineon Technologies AG
Current assignee: Intel Deutschland GmbH
Priority date: 2004-11-05
Filing date: 2004-11-05
Publication date: 2008-05-29
Anticipated expiration: 2024-11-06
Also published as: US9571291B2; US20070097886A1; US8428634B2; CN100484272C; US20130235767A1; FR2877791A1; CN1801970A; DE102004053597A1

Abstract

Verfahren zum automatischen Erzeugen und/oder Steuern einer Telekommunikations-Konferenz mit einer Vielzahl von Teilnehmern, wobei in einer elektronischen Konferenz-Bedingungs-Datei, die in einer Telekommunikations-Konferenz-Servereinrichtung gespeichert ist, mindestens eine Konferenz-Bedingung hinsichtlich des Erzeugens der Telekommunikations-Konferenz und/oder hinsichtlich der Teilnahme eines oder mehrerer Teilnehmer an der Telekommunikations-Konferenz gespeichert ist,
• bei dem für eine Mehrzahl von der Telekommunikations-Konferenz-Servereinrichtung empfangener Telekommunikations-Konferenz-Anfragen unter Verwendung der Konferenz-Bedingungs-Datei überprüft wird, ob durch Erfüllen der Telekommunikations-Konferenz-Anfragen mindestens eine gespeicherte Konferenz-Bedingung erfüllt ist, und
• bei dem für den Fall, dass bei Erfüllen der Telekommunikations-Konferenz-Anfragen die Konferenz-Bedingung erfüllt ist, die Telekommunikations-Konferenz erzeugt wird und/oder der Teilnehmer oder die Teilnehmer der Telekommunikations-Konferenz hinzugefügt werden.

Description

Die Erfindung betrifft ein Verfahren zum automatischen Erzeugen und/oder Steuern einer Telekommunikations-Konferenz mit einer Vielzahl von Teilnehmern, ein Telekommunikations-Konferenz-Endgerät sowie eine Telekommunikations-Konferenz-Servereinrichtung.
Der als Push-To-Talk over Cellular (PoC) bezeichnete Dienst ermöglicht einem Benutzer bzw. Sender nach Auswahl eines oder mehrerer Empfänger und nach erfolgtem Drücken einer speziellen Push-To-Talk over Cellular-Taste (PoC-Taste)

• Sprache
• an mehrere Empfänger gleichzeitig
• nach dem Halb-Duplex-Verfahren zu übertragen, d.h. es kann nur der Sender sprechen, die Empfänger können ihn nicht beim Sprechen unterbrechen.

Bei diesem Dienst werden die Sprachdaten üblicherweise während des Sprechens des Senders schon über das Telekommunikations-Netzwerk verteilt. Dies wird auch als „Streaming" bezeichnet. Somit ähnelt Push-To-Talk over Cellular aus Sicht des Benutzers dem üblichen CB-Funk, jedoch mit der Erweiterung, dass der Sender weltweit Empfänger, die über die Vermittlungstechnik mindestens eines Telekommunikations-Netzwerkes, vorzugsweise eines Mobilfunk-Kommunikations-Netzwerkes erreichbar sind, ansprechen kann. Voraussetzung ist jedoch, dass diese auch zu dem Zeitpunkt des Aufbaus der Kommunikationsverbindung in dem Telekommunikations-Netzwerk angemeldet sind, bei einem Mobilfunk-Kommunikations-Netzwerk bedeutet dies, dass sie angemeldet sind, anders ausgedrückt, dass sie „online" sind.
Push-To-Talk over Cellular wurde in einer ersten Version in einem Industrie-Konsortium spezifiziert und ist in [1] beschrieben. Weitere Aktivitäten befinden sich in dem Standardisierungs-Gremium Open Mobile Alliance (OMA) und 3rd Generation Partnership Project (3GPP) statt. Das Push-To-Talk over Cellular ist in dem sogenannten Packet-Switched-Domain (PS Domain, d.h. in dem paketvermittelten Bereich des Telekommunikations-Netzwerkes; als Kommunikationsnetzwerk-Protokoll wird auf Ebene der Vermittlungsschicht das Internet Protocol (IP) verwendet) realisiert.
Es gibt pro Push-To-Talk over Cellular-Gruppensitzung (Push-To-Talk over Cellular Group Session) eine zentrale Push-To-Talk over Cellular-Servereinrichtung, den sogenannten Controlling-PoC-Server. Die PoC-Client-Einrichtungen haben während einer PoC-Gruppensitzung jeweils über einen ihnen zugewiesenen sogenannten Participating-Server eine Verbindung mit dem Controlling-PoC-Server. Für die Signalisierungs-Kommunikationsverbindung zwischen einem PoC-Client und einem Participating-PoC-Server bzw. zwischen einem Participating-PoC-Server und einem Controlling PoC-Server wird beispielsweise das IP Multimedia Subsystem (IMS) verwendet, welches als Signalisierungs-Kommunikationsprotokoll das sogenannte Session Initiation Protocol (SIP) verwendet, wie in [2] beschrieben. Für die Datenübertragungs-Kommunikationsverbindung zwischen dem PoC-Client und dem Participationg-PoC-Server bzw. zwischen dem Participating-PoC-Server und dem Controlling-PoC-Server wird das sogenannte Transport Protocol for Real Time Applications (RTP) verwendet.
Bei Push-To-Talk gibt es derzeit drei unterschiedliche Arten von PoC-Gruppen (Push-To-Talk over Cellular Groups) die sich im Wesentlichen im Aufbau der PoC-Gruppensitzung unterscheiden:

• Ad-hoc-PoC-Group Session (Ad-hoc-PoC-Gruppensitzung): Vor dem Aufbau einer Ad-hoc-PoC-Gruppensitzung legt der Initiator der Ad-hoc-PoC-Gruppensitzung eine Liste von PoC-Nutzern (PoC Usern) inklusive deren Adresse, beispielsweise deren Telefonnummer als SIP-URL (Session Initiation Protocol Unique Resource Locator) oder eine SIP-Adresse als SIP-URL, fest. In diesem Zusammenhang ist anzumerken, dass die Liste von PoC-Nutzern auch nur aus einer Person bestehen kann. Die Liste wird beim Aufbau der Ad-hoc-PoC-Gruppensitzung von dem initiierenden PoC-Client zum Controlling-PoC-Server mitgesendet, welcher dann alle in der Liste enthaltenen PoC-Nutzer zu der Ad-hoc-PoC-Gruppensitzung einlädt. Eingeladene PoC-Nutzer können diese Einladung akzeptieren, ablehnen oder auch ignorieren.
• Pre-arranged-PoC-Group Session (Pre-arranged-PoC-Gruppensitzung): Für den Fall, dass man immer wieder mit den gleichen PoC-Nutzern eine PoC-Gruppensitzung führen möchte, ist es für einen PoC-Nutzer möglich, sich seine persönlichen, festen Gruppen zu definieren und dem Controlling-PoC-Server bekannt zu machen. Das sind die sogenannten Pre-arranged-PoC-Groups (Pre-arranged PoC-Gruppen). Beispielsweise kann ein PoC-Nutzer sich eine Pre-arranged-PoC-Gruppe „Freunde" mit den entsprechenden PoC-Nutzern inklusive deren Adresse, beispielsweise einer Telefonnummer SIP-URL oder einer SIP-Adresse als SIP-URL, definieren. Die Pre-arranged-PoC-Gruppe bekommt dann eine eigene Gruppen-Adresse, beispielsweise eine SIP-URL, zugeordnet. Diese Gruppen-Adresse wird beim Aufbau der Pre-arranged-PoC-Gruppensitzung vom initiierenden PoC-Client zum Controlling-PoC-Server mitgesendet, der dann alle zur Pre-arranged-PoC-Gruppe gehörigen PoC-Nutzer zu dieser Pre-arranged-PoC-Gruppensitzung einlädt. Eingeladene PoC-Nutzer können diese Einladung akzeptieren, ablehnen oder auch ignorieren.
• Chat-PoC-Group Session (Chat-PoC-Gruppensitzung): Chat-PoC-Gruppen sind ebenfalls fest definiert, dem Controlling PoC-Server bekannt und beziehen sich beispielsweise auf ein bestimmtes Diskussionsthema. Bei dieser Art von PoC-Gruppe ist es im Allgemeinen vorgesehen, dass sich ein PoC-Nutzer, der dazu berechtigt ist, selber in eine Chat-PoC-Gruppensitzung einwählt und dann mit den anderen PoC-Nutzern, die ebenfalls als PoC-Teilnehmer an dieser Chat-PoC-Gruppensitzung teilnehmen, eine PoC-Gruppensitzung führen kann. Diese Gruppensitzung funktioniert somit ähnlich, wie dies in einem sogenannten „Chatroom" im Internet vorgesehen ist.

Bei Push-To-Talk over Cellular gibt es somit zwei verschiedene Möglichkeiten, wie ein PoC-Nutzer ein PoC-Teilnehmer in einer PoC-Gruppensitzung werden kann. Entweder wählt er sich selber in eine PoC-Gruppensitzung ein (das ist der übliche Weg bei einer Chat-PoC-Gruppensitzung) oder er akzeptiert eine Einladung (das ist der übliche Weg bei einer Ad-hoc-PoC-Gruppensitzung oder bei einer Pre-arranged-PoC-Gruppensitzung).
Aus [4] ist als ein Leistungsmerkmal (Feature) bei Push-To-Talk over Cellular ein sogenannter „Session Status Notification" (Sitzungs-Status-Notifizierung)-Dienst bekannt, unter dessen Verwendung ein PoC-Nutzer darüber informiert wird, welchen Status eine PoC-Gruppensitzung aktuell hat. Zu einem solchen Status kann beispielsweise gehören, wer gerade in der PoC-Gruppensitzung PoC-Teilnehmer ist. Wenn ein PoC-Nutzer sich für einen solchen Dienst anmeldet, dann weiß er somit jederzeit darüber Bescheid, wie viele und welche PoC-Teilnehmer momentan an einer PoC-Gruppensitzung teilnehmen. Dieses optionale Leistungsmerkmal wird mit der SIP-Erweiterung SUBSCRIBE/NOTIFY realisiert, wie sie in [5] beschrieben ist.
Wenn ein PoC-Nutzer an einer Diskussion in einer bestimmten Chat-PoC-Gruppensitzung teilnehmen möchte, dann kann dieser PoC-Nutzer den Wunsch haben, dass er nur unter bestimmten Bedingungen teilnehmen möchte. Beispielsweise könnte der PoC-Nutzer nur dann an dieser Chat-PoC-Gruppensitzung teilnehmen wollen, wenn mindestens drei Leute bereits daran teilnehmen, da er der Meinung ist, dass sonst keine interessante Diskussion aufkommen kann.
Um das Einhalten einer solchen Bedingung gewährleisten zu können, könnte der PoC-Nutzer sich für das o.g. Leistungsmerkmal „Session Status Notification" anmelden und ständig, d.h. kontinuierlich, den aktuellen Status bezüglich der interessierenden Chat-PoC-Gruppensitzung beobachten.
Sobald er mittels der ihm übermittelten Session Status Notification-Nachrichten feststellt, dass seine von ihm selbst gestellte Bedingung, in diesem Beispiel also, dass mindestens drei PoC-Teilnehmer bereits an der interessierenden PoC-Gruppensitzung teilnehmen, erfüllt ist, wählt er sich selber in die entsprechende Chat-PoC-Gruppensitzung ein.
Ein anderes Szenario ist bei einer Ad-hoc-PoC-Gruppensitzung oder einer Pre-arranged-PoC-Gruppensitzung denkbar.
Wenn der PoC-Nutzer zu einer solchen Ad-hoc-PoC-Gruppensitzung oder einer Pre-arranged-PoC-Gruppensitzung eingeladen wird, dann könnte er die Einladung zunächst ablehnen, weil eine von ihm gewählte und sich selbst gestellte Bedingung, beispielsweise, dass sein Chef auch schon an dieser PoC-Gruppensitzung teilnehmen sollte, nicht erfüllt ist. Dann beobachtet er im Weiteren den Status dieser interessierenden PoC-Gruppensitzung, beispielsweise ebenfalls, indem er sich für das Leistungsmerkmal „Session Status Notification" anmeldet, und sobald sein Chef auch als PoC-Teilnehmer an der interessierenden PoC-Gruppensitzung teilnimmt, wählt er sich selber auch in diese PoC-Gruppensitzung ein.
Nachteilig an den beiden oben beschriebenen Szenarien ist insbesondere, dass der PoC-Nutzer selber ständig den aktuellen Status einer bestimmten PoC-Gruppensitzung beobachten muss und erst dann, wenn die von ihm gestellte Bedingung erfüllt ist, den Eintritt in eine ihn interessierende jeweilige PoC-Gruppensitzung beantragen kann. Auch ist nachteilig an den oben beschriebenen Vorgehensweisen, dass für den Fall, dass die Bedingung nie erfüllt ist, der Nutzer sehr viel Zeit und Energie aufgewendet hat, um ständig den Status der entsprechenden PoC-Gruppensitzung zu beobachten. Auch ist es gemäß der oben beschriebenen Vorgehensweisen möglich, dass der Benutzer, obwohl die Bedingung erfüllt ist, er aufgrund eines erst verspäteten Bemerkens, dass die Bedingung erfüllt ist, der PoC-Gruppensitzung erst verspätet oder sogar zu spät beitritt und somit möglicherweise ihn interessierende in der PoC-Gruppensitzung verteilte bzw. ausgetauschte Informationen gar nicht erhält.
[6] beschreibt eine SIP-Nachricht UPDATE und [7] beschreibt eine SIP-Nachricht INFO.
Aus [8] ist das so genannte Session Description Protocol (SDP) bekannt.
In [9] ist die SIP-Nachricht MESSAGE beschrieben.
Die oben beschriebene Problematik tritt auch in anderen Telekommunikations-Konferenzen auf, beispielsweise in einen Telekommunikations-Konferenz-System im Internet, welches beispielsweise in [10] beschrieben worden ist und als „Conferencing Framework" bezeichnet wird. Aufbauend auf dieses Telekommunikations-Konferenz-System wird zudem im Standardisierungs-Gremium 3GPP der Service IMS Conferencing spezifiziert.
Das in [10] beschriebene Telekommunikations-Konferenz-System stellt neben einem Verfahren zur Steuerung der Zugriffsrechte auf Multimedia-Telekommunikations-Konferenz-Ressourcen (auch bezeichnet als Floor Control) und der Etablierung von Konferenz-Regeln (auch bezeichnet als Conference Policy) ferner Session Initiation Protocol (SIP)-basierte Prozeduren unter anderem zur Erzeugung, zum Management, zum Eintritt und zum Verlassen von Telekommunikations-Konferenzen bereit. Ferner sind in diesem System Verfahren zur Benachrichtigung der Konferenzteilnehmer (auch bezeichnet als Conference Notification Service) über spezifische, die Telekommunikations-Konferenz betreffende Informationen und Ereignisse (Events) enthalten. Eines dieser Benachrichtigungs-Verfahren ist beispielsweise die o.g. „Session Status Notification". Innerhalb des Telekommunikations-Konferenz-Systems können beliebige Arten von Medien zwischen den Teilnehmern ausgetauscht werden und das Telekommunikations-Konferenz-System wird aus diesem Grund im Folgenden auch als Multimedia-Telekommunikations-Konferenz-System bezeichnet.
Zum Definieren unterschiedlicher Regeln ist im Rahmen des in [10] beschriebenen Multimedia-Telekommunikations-Konferenz- Systems das sogenannte Conference Policy Control Protocol (CPCP) definiert, wie in [11] beschrieben.
Druckschrift [12] beschreibt ein Gruppen-Kommunikations-Netzwerk bei dem bei einer Anfrage eines Benutzers nach einer Konferenz mit bestimmten Teilnehmern überprüft wird, ob eine Konferenz mit diesen Teilnehmern bereits besteht und der Benutzer gegebenenfalls der Konferenz hinzugefügt wird.
In [13] ist eine Kommunikationssystem beschrieben, bei dem sich ein Teilnehmergerät eines Benutzer für ein Ereignis-Paket anmelden kann, so dass der Benutzer über eine Dienstkonfiguration informiert wird. Das Kommunikationssystem kann insbesondere gemäß dem 3GPP-Standard ausgestaltet sein.
In Druckschrift [14] ist ein Kommunikationssytem beschrieben, bei dem bei der Anfrage nach einer Konferenz die gewünschten Teilnehmer sowie der gewünschte Zeitpunkt angegeben werden können. Wenn die Anfrage nach einer Konferenz nicht erfüllt werden kann, weil beispielsweise zu dem gewünschten Zeitpunkt die gewünschten Teilnehmer nicht erreichbar sind, wird die Anfrage abgelehnt.
Der Erfindung liegt das Problem zugrunde, auf für einen Benutzer einfache Art eine Telekommunikations-Konferenz unter Berücksichtigung von nutzerspezifischen Bedingungen zu erzeugen und/oder zu steuern.
Das Problem wird durch ein Verfahren zum automatischen Erzeugen und/oder Steuern einer Telekommunikations-Konferenz mit einer Vielzahl von Teilnehmern, einem Telekommunikations-Konferenz-Endgerät sowie einer Telekommunikations-Konferenz-Servereinrichtung mit den Merkmalen gemäß den unabhängigen Patentansprüchen gelöst.
Bevorzugte Ausgestaltungen der Erfindung ergeben sich aus den abhängigen Ansprüchen. Die im Folgenden beschriebenen Ausgestaltungen der Erfindung betreffen sowohl das Verfahren zum automatischen Erzeugen und/oder Steuern einer Telekommunikations-Konferenz, die Telekommunikations-Konferenz-Servereinrichtung als auch das Telekommunikations-Konferenz-Endgerät.
Bei einem Verfahren zum automatischen Erzeugen und/oder Steuern einer Telekommunikations-Konferenz mit einer Vielzahl von Teilnehmern, wobei in einer elektronischen Konferenz-Bedingungs-Datei, die in einer Telekommunikations-Konferenz-Servereinrichtung gespeichert ist, mindestens eine Konferenz-Bedingung hinsichtlich des Erzeugens der Telekommunikations-Konferenz und/oder hinsichtlich der Teilnahme eines oder mehrerer Teilnehmer an der Telekommunikations-Konferenz gespeichert ist, wird für eine Mehrzahl von der Telekommunikations-Konferenz-Servereinrichtung empfangener Telekommunikations-Konferenz-Anfragen unter Verwendung der Konferenz-Bedingungs-Datei überprüft wird, ob durch Erfüllen der Telekommunikations-Konferenz-Anfragen mindestens eine gespeicherte Konferenz-Bedingung erfüllt ist. Für den Fall, dass bei Erfüllen der Telekommunikations-Konferenz-Anfragen die mindestens eine gespeicherte Konferenz-Bedingung erfüllt ist, wird die Telekommunikations-Konferenz erzeugt und/oder der Teilnehmer oder die Teilnehmer werden der Telekommunikations-Konferenz hinzugefügt.
Bei einem Verfahren zum automatischen Erzeugen und/oder Steuern einer Telekommunikations-Konferenz mit einer Vielzahl von Teilnehmern, wobei in einer elektronischen Konferenz-Bedingungs-Datei, die in einem Teilnehmer-Endgerät eines der Teilnehmer gespeichert ist, mindestens eine Konferenz-Bedingung hinsichtlich des Erzeugens der Telekommunikations-Konferenz und/oder hinsichtlich der Teilnahme eines oder mehrerer Teilnehmer an der Telekommunikations-Konferenz gespeichert ist, wird unter Verwendung der Konferenz-Bedingungs-Datei automatisch geprüft, ob mindestens eine gespeicherte Konferenz-Bedingung erfüllt ist. Für den Fall, dass mindestens eine gespeicherte Konferenz-Bedingung erfüllt ist, wird die Telekommunikations-Konferenz erzeugt und/oder der Teilnehmer oder die Teilnehmer werden der Telekommunikations-Konferenz hinzugefügt.
Für den Fall, dass keine gespeicherte Konferenz-Bedingung erfüllt ist, können unterschiedliche Aktionen vorgesehen sein, so kann beispielsweise die Konferenz nicht erzeugt werden, eine Konferenz kann unverändert weitergeführt werden, ein Benutzer, der den Beitritt in eine Konferenz beantragt hat, kann über das Nichterfülltsein der Bedingung informiert werden, beispielsweise mit einer entsprechenden Notifizierungs-Nachricht oder die Nutzer können über das mögliche Erfülltsein einer gestellten Bedingung bei Durchführen einer oder mehrerer vorgebbarer Aktionen informiert werden.
Ein Telekommunikations-Konferenz-Endgerät weist eine Telekommunikations-Konferenzeinheit auf, die eingerichtet ist zur Kommunikation mit anderen Telekommunikations-Konferenz-Endgeräten und/oder einer Telekommunikations-Servereinrichtung in einer Telekommunikations-Konferenz. Ferner weist sie einen Speicher zum Speichern einer elektronischen Konferenz-Bedingungs-Datei auf, in welcher mindestens eine Konferenz-Bedingung hinsichtlich des Erzeugens der Telekommunikations-Konferenz und/oder hinsichtlich der Teilnahme eines oder mehrerer Teilnehmer an der Telekommunikations-Konferenz enthalten ist. Ferner ist eine mit dem Speicher gekoppelte Telekommunikations-Konferenz-Prüfeinheit vorgesehen, welche eingerichtet ist zum Prüfen, unter Verwendung der Konferenz-Bedingungs-Datei, vorzugsweise anhand der in der Konferenz-Bedingungs-Datei enthaltenen Daten, ob mindestens eine gespeicherte Konferenz-Bedingung erfüllt ist. Eine ebenfalls in dem Telekommunikations-Konferenz-Endgerät vorgesehene Telekommunikations-Konferenz-Nachrichten-Erzeugungseinheit ist derart eingerichtet, dass sie für den Fall, dass sie von der Telekommunikations-Konferenz-Prüfeinheit eine Information enthält, dass mindestens eine gespeicherte Konferenz-Bedingung erfüllt ist, eine der folgenden Nachrichten erzeugt:

• eine Konferenz-Erzeugungs-Anfrage-Nachricht, mit der das Erzeugen einer Telekommunikations-Konferenz beantragt wird, und/oder
• eine Konferenz-Beitritts-Nachricht, mit welcher der Beitritt des Telekommunikations-Konferenz-Endgeräts zu der Telekommunikations-Konferenz mitgeteilt wird.

Eine Telekommunikations-Konferenz-Servereinrichtung weist auf eine Telekommunikations-Konferenzeinheit, die eingerichtet ist zur Kommunikation mit Telekommunikations-Konferenz-Endgeräten und/oder einer oder mehrerer anderen Telekommunikations-Konferenz-Servereinrichtungen in einer Telekommunikations-Konferenz. Ferner weist sie einen Speicher zum Speichern einer elektronischen Konferenz-Bedingungs-Datei auf, in der mindestens eine Konferenz-Bedingung hinsichtlich des Erzeugens der Telekommunikations-Konferenz und/oder hinsichtlich der Teilnahme eines oder mehrerer Teilnehmer an der Telekommunikations-Konferenz enthalten ist. Mit dem Speicher ist eine Telekommunikations-Konferenz-Prüfeinheit gekoppelt, die eingerichtet ist für eine Mehrzahl von der Telekommunikations-Konferenz-Servereinrichtung empfangener Telekommunikations-Konferenz-Anfragen zu prüfen, unter Verwendung des Inhalts der Konferenz-Bedingungs-Datei, insbesondere unter Verwendung in der Konferenz-Bedingungs-Datei gespeicherten Konferenz-Bedingung(en), ob durch Erfüllen der Telekommunikations-Konferenz-Anfragen mindestens eine der gespeicherte(n) Konferenz-Bedingung(en) erfüllt ist/sind. Ferner ist eine Telekommunikations-Konferenz-Erzeugungs-/Steuerungseinheit vorgesehen, die derart eingerichtet ist, dass sie für den Fall, dass bei Erfüllen der Telekommunikations-Konferenz-Anfragen die gespeicherte Konferenz-Bedingung erfüllt ist, die Telekommunikations- Konferenz erzeugt und/oder einen Teilnehmer oder mehrere Teilnehmer der Telekommunikations-Konferenz hinzufügt.
Die Teilnehmer der Telekommunikations-Konferenz übertragen und/oder empfangen Daten bevorzugt über ein Mobilfunk-Kommunikationssystem, besonders bevorzugt gemäß einem 3GPP-Mobilfunk-Kommunikationssystem, besonders bevorzugt gemäß UMTS.
Anders ausgedrückt bedeutet dies, dass bevorzugt die Telekommunikations-Konferenz-Servereinrichtung zur Telekommunikation über ein Mobilfunksystem eingerichtet ist, dabei insbesondere bevorzugt gemäß einem 3GPP-Mobilfunksystem und dabei besonders bevorzugt gemäß UMTS.
Somit eignet sich die Erfindung insbesondere für den Einsatz in einem, vorzugsweise zellenbasierten, Mobilfunk-Kommunikationssystem. Anders ausgedrückt bedeutet dies, dass die Telekommunikations-Konferenz-Servereinrichtung somit bevorzugt ein Bestandteil eines Mobilfunk-Kommunikationssystems, besonders bevorzugt eines 3GPP-Mobilfunk-Kommunikationssystem und dabei besonders bevorzugt des sogenannten IP-Multimedia Core Network Subsystems (IMS) des UMTS-Mobilfunk-Kommunikationssystems ist.
Je nach Architektur des Telekommunikations-Konferenz-Netzwerks kann die Telekommunikations-Konferenz-Servereinrichtung auch in einem Telekommunikations-Konferenz-Endgerät integriert sein.
Ferner kann bei einer vollvermaschten Telekommunikations-Konferenz ausschließlich unter Nutzung von Telekommunikations-Konferenz-Endgeräten unter diesen sich ein Telekommunikations-Konferenz-Endgerät zu einer Telekommunikations-Konferenz-Servereinrichtung „bestellen" und die entsprechende(n) Funktionalität(en) aktivieren und bereitstellen.
In diesem Zusammenhang ist darauf hinzuweisen, dass im Rahmen dieser Beschreibung unter dem Ausdruck „Erzeugen einer Telekommunikations-Konferenz" auch das Einladen eines Teilnehmers zum Erzeugen einer Telekommunikations-Konferenz zu verstehen ist, d.h. eine Aufforderung eines zukünftigen möglichen Telekommunikations-Konferenz-Teilnehmers, die Telekommunikations-Konferenz zu erzeugen.
Ferner ist unter dem Ausdruck „Steuern einer Telekommunikations-Konferenz" im Rahmen dieser Erfindung auch das Einladen eines möglichen neuen Teilnehmers zum Beitritt einer schon erzeugten Telekommunikations-Konferenz zu verstehen ist.
Die einzelnen im Folgenden beschriebenen funktionalen Einheiten können jeweils in einzelnen voneinander getrennten Hardware-Einheiten, beispielsweise eigenständigen Rechnern bzw. Telekommunikations-Endgeräten, vorzugsweise Mobilfunk-Endgeräten, implementiert sein oder zumindest teilweise in Software, d.h. mittels Computerprogrammen, die in getrennten oder gemeinsamen Rechnereinheiten implementiert sind.
Die Erfindung eignet sich besonders für den Einsatz in einer Multimedia-Telekommunikations-Konferenz, d.h. in einer Telekommunikations-Konferenz, in der unterschiedliche Medienarten, beispielsweise Audiodaten, Videodaten und/oder textuelle Daten, zwischen den Teilnehmern der Telekommunikations-Konferenz ausgetauscht und übertragen werden.
Bevorzugt wird das Verfahren eingesetzt in einer Festnetz-Telekommunikations-Konferenz, insbesondere einer internet-basierten Festnetz-Telekommunikations-Konferenz, alternativ bevorzugt in einer Mobilfunk-Telekommunikations-Konferenz, insbesondere einer zellenbasierten Mobilfunk-Telekommunikations-Konferenz und dabei besonders bevorzugt in einer 3GPP-Mobilfunk-Telekommunikations-Konferenz, insbesondere in einer UMTS-Mobilfunk-Telekommunikations-Konferenz.
Ein besonders bevorzugtes Einsatzgebiet ist eine Push-To-Talk over Cellular-Mobilfunk-Telekommunikations-Konferenz, insbesondere eine der folgenden Arten:

• Ad-hoc-Mobilfunk-Telekommunikations-Konferenz;
• Pre-arranged-Mobilfunk-Telekommunikations-Konferenz;
• Chat-Mobilfunk-Telekommunikations-Konferenz.

Insbesondere bei einer Push-To-Talk over Cellular-Mobilfunk-Telekommunikations-Konferenz treten die im Rahmen der Beschreibungseinleitung beschriebenen Probleme der kontinuierlichen manuellen Beobachtung einer bestehenden Telekommunikations-Konferenz hinsichtlich möglicherweise erfüllter oder nicht erfüllter Bedingungen auf.
Durch die Erfindung werden anschaulich neue Mechanismen für Telekommunikations-Konferenz-Sitzungen, insbesondere für PoC-Gruppensitzungen beschrieben, mit denen ein Konferenz-Nutzer, beispielsweise ein PoC-Nutzer erst dann als Teilnehmer in eine Telekommunikations-Gruppensitzung, insbesondere einer PoC-Gruppensitzung eingebunden wird, wenn ein bestimmtes, von diesem Nutzer festgelegtes Ereignis eingetreten ist.
Beispielsweise wird ein Konferenz-Nutzer, beispielsweise ein PoC-Nutzer erst dann als Teilnehmer in eine Chat-PoC-Gruppensitzung eingebunden, wenn mindestens schon zwei weitere PoC-Teilnehmer an dieser Chat-PoC-Gruppensitzung teilnehmen.
Durch die Erfindung ist es somit erstmals möglich, automatisiert Bedingungen zum Betritt in eine Telekommunikations-Konferenz an eine entsprechende Einheit zum Erzeugen bzw. Steuern einer Telekommunikations-Konferenz zu übermitteln, von welcher sie automatisierbar verarbeitbar und kontinuierlich überprüfbar ist. Alternativ kann die Überprüfung auch in dem Telekommunikations-Endgerät stattfinden und der Benutzer über das Erfüllen der Bedingung in der Telekommunikations-Konferenz zeitgleich bzw. zeitnah informiert werden, ohne dass der Benutzer ständig den Status der interessierenden Telekommunikations-Konferenz selbst manuell überwachen müsste. Auch ist durch die Erfindung gewährleistet, dass der Nutzer zeitnah, d.h. mehr oder weniger unmittelbar nach Erfüllung der Bedingung der Telekommunikations-Konferenz, dieser beitreten oder diese Erzeugen kann. Damit wird ein unnötiger Zeitverlust hinsichtlich der Teilnahme eines Nutzers an der Telekommunikations-Konferenz vermieden.
Auf diese Weise wird die Benutzerfreundlichkeit eines Telekommunikations-Konferenz-Systems für die Benutzer erheblich erhöht.
Die Konferenz-Bedingungs-Datei kann in einem Teilnehmer-Endgerät eines Teilnehmers gespeichert sein.
In diesem Fall ist es bevorzugt, dass Statusinformation über die Telekommunikations-Konferenz einem Teilnehmer-Endgerät, in welchem die jeweilige Konferenz-Bedingungs-Datei gespeichert ist, übermittelt wird und die Prüfung von dem Teilnehmer-Endgerät durchgeführt wird unter Verwendung der empfangenen Statusinformation.
Gemäß dieser Ausgestaltung der Erfindung wird eine automatisierte endgeräteseitige Überwachung der Telekommunikations-Konferenz und über ein zeitnahes Informieren des Nutzers über das Erfülltsein der vorgegebenen Bedingung hinaus auch ein Erzeugen und/oder Steuern einer Telekommunikations-Konferenz erreicht.
Gemäß einer Ausgestaltung der Erfindung ist es vorgesehen, dass die Statusinformation über die Telekommunikations-Konferenz einem Teilnehmer-Endgerät bei Auftreten eines vorgegebenen Ereignisses, beispielsweise unter Verwendung des Dienstes „Session Status Notification" wie in [4] beschrieben, übermittelt werden. Dabei ist es bevorzugt vorgesehen, die Statusinformation über die Telekommunikations-Konferenz einem Teilnehmer-Endgerät bei Auftreten einer Statusänderung der Telekommunikations-Konferenz zu übermitteln, beispielsweise bei Beitreten oder Austreten eines Teilnehmers in bzw. aus der Telekommunikations-Konferenz.
Alternativ kann die Telekommunikations-Konferenz-Bedingungs-Datei in einer Telekommunikations-Konferenz-Servereinrichtung gespeichert sein.
In diesem Fall ist es bevorzugt vorgesehen, dass für eine Mehrzahl von der Telekommunikations-Konferenz-Servereinrichtung empfangene Telekommunikations-Konferenz-Anfragen überprüft wird, ob durch Erfüllen der Telekommunikations-Konferenz-Anfragen die Konferenz-Bedingung eines Nutzers erfüllt ist. Für den Fall, dass bei Erfüllen der Telekommunikations-Konferenz-Anfragen die Konferenz-Bedingung erfüllt ist, wird die Telekommunikations-Konferenz erzeugt und/oder werden der Teilnehmer oder die Teilnehmer der Telekommunikations-Konferenz hinzugefügt.
Auf diese Weise ist es zentralisiert möglich, selbst für den Fall, dass für eine bestehende oder noch nicht bestehende Telekommunikations-Konferenz hinsichtlich einer isolierten Betrachtung einer entsprechenden Anfragebedingung diese an sich nicht erfüllt wäre, durch Verarbeiten bzw. Analysieren und Auswerten mehrerer Anfragen und mehrerer Bedingungen von unterschiedlichen Teilnehmern diese, bei Erzeugen einer Telekommunikations-Konferenz für alle Teilnehmer die jeweiligen Bedingungen erfüllt sein könnten.
Auf diese Weise wird der Bedienerkomfort noch weiter erheblich erhöht.
Als Konferenz-Bedingung werden bevorzugt eine oder mehrere der folgenden Konferenz-Bedingungen berücksichtigt:

• eine vorgegebene Anzahl, insbesondere eine Mindest-Anzahl oder eine Maximal-Anzahl, an einer Telekommunikations-Konferenz interessierten oder teilnehmenden Teilnehmer;
• eine Identität an einer Telekommunikations-Konferenz interessierter oder teilnehmender Teilnehmer;
• ein Zeitpunkt des Erzeugens einer Telekommunikations-Konferenz;
• ein Zeitpunkt des Beendens einer Telekommunikations-Konferenz;
• eine Zeitdauer einer Telekommunikations-Konferenz;
• der Inhalt einer Telekommunikations-Konferenz;
• die Kommunikations-Intensität in einer Telekommunikations-Konferenz, insbesondere der Zeitanteil, in dem gesprochen wird, und/oder die Häufigkeit, mit der der Sprachberechtigte wechselt.

Ausführungsbeispiele der Erfindung sind in den Figuren dargestellt und werden im Folgenden näher erläutert. In den Figuren sind gleiche oder ähnliche Elemente üblicherweise mit gleichen Bezugszeichen versehen.
Es zeigen
1 ein Blockdiagramm, welches das Push-To-Talk over Cellular-Kommunikationssystem gemäß den Ausführungsbeispielen für das Push-To-Talk over Cellular-Kommunikationssystem darstellen;
2 ein Nachrichtenflussdiagramm, in dem die Verfahrensschritte gemäß einem ersten Ausführungsbeispiel der Erfindung dargestellt sind;
3 ein Nachrichtenflussdiagramm, in dem die Verfahrensschritte gemäß einer ersten Realisierungsalternative eines zweiten Ausführungsbeispiels der Erfindung dargestellt sind;
4 ein Nachrichtenflussdiagramm, in dem die Verfahrensschritte gemäß einer zweiten Realisierungsalternative des zweiten Ausführungsbeispiels der Erfindung dargestellt sind;
5 ein Nachrichtenflussdiagramm, in dem die Verfahrensschritte gemäß einem dritten Ausführungsbeispiel der Erfindung dargestellt sind; und
6 ein Telekommunikations-Konferenz-System gemäß einem weiteren Ausführungsbeispiel der Erfindung.
1 zeigt die grundlegende Architektur eines Push-To-Talk over Cellular-Mobilfunk-Telekommunikations-Konferenz-Systems 100 gemäß mehreren Ausführungsbeispielen der Erfindung.
Push-To-Talk over Cellular ist realisiert in der Packet-Switched-Domain (PS-Domain), d.h. im paketvermittelten Teil eines Mobilfunk-Telekommunikationssystems.
Als Kommunikations-Netzwerk-Protokoll wird bei Push-To-Talk over Cellular auf Ebene der Vermittlungsschicht das Internet-Protocol (IP) verwendet.
Netzwerkseitig weist das Kommunikationssystem 100 in einem Festnetzbereich 101 für jede PoC-Gruppensitzung (Push-To-Talk over Cellular-Group Session), d.h. für jede Gruppen-Kommunikationsverbindung im Rahmen einer PoC-Konferenz, eine zentrale PoC-Servereinrichtung, den sogenannten Controlling PoC-Server 102 auf.
Ferner sind für jedes PoC-Kommunikations-Endgerät, für jeden PoC-Client, jeweils eine diesem PoC-Client zugewiesene Participating-PoC-Servereinrichtung (Participating-PoC-Server) 103, 104, 105 vorgesehen und diesem zugewiesen. Die PoC-Clients, vorzugsweise Mobilfunk-Endgeräte, in denen die entsprechenden Kommunikations-Protokolle und Programme zur PoC-basierten Kommunikation realisiert sind, sind in 1 mit den Bezugszeichen 106, 107 bzw. 108 bezeichnet. Für die Signalisierungs-Kommunikationsverbindung zwischen einem jeweiligen PoC-Client 106, 107, 108 und dem jeweiligen Participating-PoC-Server 103, 104 bzw. 105 und dem Controlling-PoC-Server 102 wird gemäß diesen Ausführungsbeispielen der Erfindung das Internet Protocol Multimedia Subsystem (IMS) genutzt, welches als Signalisierungs-Kommunikationsprotokoll das Session Initiation Protocol (SIP) verwendet, wie es in [2] beschrieben ist.
Das Push-To-Talk over Cellular-Mobilfunk-Telekommunikations-Konferenz-Systems 100 ist gemäß [1] eingerichtet, bis auf die zusätzlichen Merkmale, wie sie im Folgenden näher erläutert sind.
Für die Datenübertragungs-Kommunikationsverbindung zwischen den PoC-Clients 106, 107, 108 und den jeweiligen Participating-PoC-Servern 103, 104 bzw. 105 bzw. dem Controlling-PoC-Server 102 wird das Protokoll RTP gemäß [3] verwendet.
Bei Push-To-Talk gibt es derzeit drei unterschiedliche Arten von PoC-Gruppen (Push-To-Talk over Cellular Groups) die sich im Wesentlichen im Aufbau der PoC-Gruppensitzung unterscheiden:

• Ad-hoc-PoC-Group Session (Ad-hoc-PoC-Gruppensitzung): Vor dem Aufbau einer Ad-hoc-PGC-Gruppensitzung legt der Initiator der Ad-hoc-PoC-Gruppensitzung eine Liste von PoC-Nutzern (PoC Usern) inklusive deren Adresse, beispielsweise deren Telefonnummer als SIP-URL (Session Initiation Protocol Unique Resource Locator) oder eine SIP-Adresse als SIP-URL, fest. In diesem Zusammenhang ist anzumerken, dass die Liste von PoC-Nutzern auch nur aus einer Person bestehen kann. Die Liste wird beim Aufbau der Ad-hoc-PoC-Gruppensitzung von dem initiierenden PoC-Client zum Controlling-PoC-Server mitgesendet, welcher dann alle in der Liste enthaltenen PoC-Nutzer, d.h. alle gelisteten PoC-Nutzer, zu der Ad-hoc-PoC-Gruppensitzung einlädt. Eingeladene PoC-Nutzer können diese Einladung akzeptieren, ablehnen oder auch ignorieren.
• Pre-arranged-PoC-Group Session (Pre-arranged-PoC-Gruppensitzung): Für den Fall, dass man immer wieder mit den gleichen PoC-Nutzern eine PoC-Gruppensitzung führen möchte, ist es für einen PoC-Nutzer möglich, sich seine persönlichen, festen Gruppen zu definieren und dem Controlling-PoC-Server bekannt zu machen. Das sind die sogenannten Pre-arranged-PoC-Groups (Pre-arranged PoC-Gruppen). Beispielsweise kann ein PoC-Nutzer sich eine Pre-arranged-PoC-Gruppe „Freunde" mit den entsprechenden PoC-Nutzern inklusive deren Adresse, beispielsweise einer Telefonnummer SIP-URL oder einer SIP-Adresse als SIP-URL, definieren. Die Pre-arranged-PoC-Gruppe bekommt dann eine eigene Gruppen-Adresse, beispielsweise eine SIP-URL, zugeordnet. Diese Gruppen-Adresse wird beim Aufbau der Pre-arranged-PoC-Gruppensitzung vom initiierenden PoC-Client zum Controlling-PoC-Server mitgesendet, der dann alle zur Pre-arranged-PoC-Gruppe gehörigen PoC-Nutzer zu dieser Pre-arranged-PoC-Gruppensitzung einlädt. Eingeladene PoC-Nutzer können diese Einladung akzeptieren, ablehnen oder auch ignorieren.
• Chat-PoC-Group Session (Chat-PoC-Gruppensitzung): Chat-PoC-Gruppen sind ebenfalls fest definiert, dem Controlling PoC-Server bekannt und beziehen sich beispielsweise auf ein bestimmtes Diskussionsthema. In diesem Fall kann sich jeder PoC-Nutzer, der dazu berechtigt ist, selber in eine Chat-PoC-Gruppensitzung einwählen und sich dann mit den anderen PoC-Nutzern, die ebenfalls als PoC-Teilnehmer an dieser Chat-PoC-Gruppensitzung teilnehmen, eine PoC-Gruppensitzung führen. Diese Gruppensitzung funktioniert somit ähnlich, wie dies in einem sogenannten „Chatroom" im Internet vorgesehen ist.

Somit weisen die PoC-Clients 106, 107, 108 jeweils eine Schnittstelle, vorzugsweise eine Luftschnittstelle 109, 110, 111 auf zum Bereitstellen einer Mobilfunk-Kommunikationsverbindung zu ihrem jeweiligen Participating-PoC-Server 103, 104 bzw. 105, welche wiederum eine Kommunikationsverbindung zum zentralen Controlling-PoC-Server 102 haben.
Ferner ist optional eine Floor Control-Entscheidungseinheit (Chair) 112 vorgesehen und mit dem Controlling-PoC-Server 102 gekoppelt. Der Chair 112 ist eine logische Einheit, die für das erweiterte Leistungsmerkmal „Floor Control-Entscheidung durch einen Chair" vorgesehen ist. Der Chair 112 kann in einem PoC-Client 106, 107, 108 selbst oder auch in einem Server in dem Netzwerkbereich 101 realisiert sein.
Das Interface, d.h. die Schnittstelle von einem PoC-Client 106, 107, 108 zum jeweiligen Participating-PCC-Server 103, 104 bzw. 105 kann beispielsweise beim UMTS über das Radio Access Network (RAN), das Core Network (CN), d.h. das Kernnetzwerk und das IP Multimedia Subsystem (IMS) realisiert sein. Andere Realisierungen beispielsweise mittels eines üblichen Post-Kommunikationsnetzes (PSTN) sind in einer alternativen Ausführungsform ebenfalls vorgesehen.
Erfindungsgemäß sind im Wesentlichen zwei unterschiedliche Lösungsansätze für die oben beschriebenen Problemstellungen vorgesehen und werden insbesondere im Zusammenhang mit dem Push-To-Talk over Cellular-Mobilfunk-Telekommunikations-Konferenz-Systems 100 näher beschrieben, wobei allen im Folgenden beschriebenen Ausführungsbeispielen gemein ist, dass im Folgenden beschriebene Bedingungen automatisch von einem Endgerät oder von einer Servereinrichtung überprüft werden.
Alle im Folgenden beschriebene Lösungsansätze sind grundsätzlich bei allen oben beschriebenen Arten von PoC-Gruppensitzungen anwendbar.
Daher wird im Folgenden häufig allgemein von PoC-Gruppensitzungen und nicht mehr zwischen den drei verschiedenen Arten von PoC-Gruppensitzungen unterschieden.
In diesem Fall sind die beschriebenen Ausführungsbeispiele auf alle drei oben beschriebenen PoC-Gruppensitzungen anwendbar.
Gemäß einem ersten Lösungsansatz wird der oben beschriebene Dienst „Session Status Notification" verwendet.
In den jeweiligen PoC-Client 106, 107, 108 (bzw. in einer Applikation, d.h. einem Anwendungsprogramm, welches auf den PoC-Endgerät implementiert ist, welches die benötigten Informationen von dem PoC-Client 106 erhält), kann der PoC-Nutzer eine oder mehrere oder auch eine Kombination von mehreren Bedingungen festlegen, die erfüllt sein müssen, bevor er sich in eine vorgegebene bestimmte PoC-Gruppensitzung einwählen möchte.
Die vorgegebenen Bedingungen werden in einer Konferenz-Bedingungs-Datei gespeichert, welche den PoC-Client 106, 107, 108 zugänglich sind.
Der PoC-Client 106, 107, 108 überprüft anhand der Konferenz-Bedingungs-Datei bei jeder gemeldeten Änderung des Status der entsprechenden PoC-Gruppensitzung, welcher die jeweilige Konferenz-Bedingungs-Datei zugeordnet ist, ob diese Bedingung(en) erfüllt ist/sind.
Sobald dies der Fall ist, wählt sich der PoC-Client 106, 107, 108 automatisch in die jeweilige PoC-Gruppensitzung ein und gibt den PoC-Nutzer einen entsprechenden Hinweis hierzu, beispielsweise mittels Ausgebens eines Signaltons oder eines entsprechenden Hinweises auf dem Display des PoC-Endgerätes.
Der Vorteil des ersten Lösungsansatzes liegt insbesondere darin, dass der PoC-Nutzer nicht selber ständig den Status der entsprechenden PoC-Gruppensitzung beobachten muss, sondern dass es in dem PoC-Client 106, 107, 108 einen entsprechenden Mechanismus gibt, der sich nach den Wünschen des PoC-Nutzers verhält und die jeweilige PoC-Gruppensitzung kontinuierlich automatisch überwacht.
Gemäß einem zweiten Lösungsansatz ist die erfindungsgemäße Funktionalität hingegen hauptsächlich in dem Controlling-PoC-Server 102 implementiert.
Der PoC-Nutzer wählt sich „bedingt", d.h. unter Stellen einer entsprechenden Einwählbedingung in eine bestimmte PoC-Gruppensitzung ein, sendet mit der Einwahlnachricht erfindungsgemäß zusätzlich eine, mehrere oder eine Kombination von mehreren Bedingungen mit an den Controlling-PoC-Server 102.
Falls die genannte(n) Bedingung(en) erfüllt ist/sind, wird der PoC-Nutzer sofort von den Controlling-PoC-Server 102 zu einem PoC-Teilnehmer der jeweiligen Gruppensitzung gemacht.
Ist/sind die Bedingung(en) nicht erfüllt, wird der PoC-Nutzer in einer Mögliche-Teilnehmer-Datei (Mögliche-Teilnehmer-Liste) in dem Controlling-PoC-Server 102 gespeichert und von diesem als potentieller PoC-Teilnehmer geführt, d.h. der potentielle PoC-Teilnehmer bekommt keine Sprachnachrichten aus dieser PoC-Gruppensitzung (wenn sie überhaupt läuft) zugesendet und hat auch keine Möglichkeit, selber Sprachnachrichten in die PoC-Gruppensitzung einzubringen. Der Controlling-PoC-Server 102 überprüft nun ständig, d.h. kontinuierlich, alternativ in vorgegebenen Zeitabständen, ob diese Bedingung(en) erfüllt ist/sind, die von dem jeweiligen Client vorgegeben wurden.
Sobald dies der Fall ist, wird der potentielle PoC-Teilnehmer automatisch in die PoC-Gruppensitzung einbezogen und wird somit ein ganz „normaler" PoC-Teilnehmer. Hierzu erfolgt eine entsprechende Signalisierung von dem Controlling-PoC-Server 102 zu dem entsprechenden PoC-Client 106, 107, 108.
Gemäß dem zweiten Lösungsansatz ergeben sich insbesondere folgende zusätzliche Vorteile:

• Gemäß dem zweiten Lösungsansatz ist es nicht unbedingt erforderlich, dass der PoC-Client 106, 107, 108 den Dienst „Session Status Notification" nutzt, allgemein einen Dienst, der den Client über Statusänderung in einer PoC-Gruppensitzung informiert. Dadurch wird zusätzliche (eventuell sogar sehr häufige) Signalisierung des Status der jeweiligen PoC-Gruppensitzung eingespart, was sowohl Ressourcen über die Luftschnittstelle als auch anfallende Gebühren für den PoC-Nutzer spart.
• Da die Funktionalität hauptsächlich in dem Controlling-PoC-Server 102 vorgesehen ist, kann diese einmalig zentral implementiert werden und muss nicht auf jedem einzelnen PoC-Client 106, 107, 108 vorhanden sein bzw. implementiert werden. Auch eine Pflege, d.h. insbesondere ein Update, d.h. ein Aktualisieren der entsprechenden Software ist somit sehr einfach und kostengünstig zu handhaben.
• In dem Controlling-PoC-Server 102 ist jederzeit bekannt, wer und wie viele PoC-Nutzer in einer bestimmten PoC-Gruppensitzung als potentielle PoC-Teilnehmer gelten. Dadurch können untereinander abhängige Bedingungen von verschiedenen potentiellen PoC-Teilnehmern aufgelöst werden. Ein Beispielfall ist, dass es in einer bestimmten Chat-PoC-Gruppe aktuell keine Teilnehmer gibt, es wählen sich jedoch drei PoC-Nutzer mit der Bedingung ein, dass mindestens zwei andere PoC-Teilnehmer an dieser Chat-PoC-Gruppensitzung teilnehmen. Da der Controlling-PoC-Server 102 über all die Bedingungen der drei potentiellen PoC-Teilnehmer Kenntnis hat, kann er alle drei potentielle PoC-Teilnehmer in die Chat-PoC-Gruppensitzung einwählen, womit dann auch alle Bedingungen erfüllt sind.

Eine Variante bei dem zweiten Lösungsansatz, wie er oben beschrieben wurde, ist, dass der PoC-Nutzer eine Information in dem Festnetz-Kommunikationsnetzwerk hinterlegen kann, unter welchen Bedingungen er zu einer bestimmten PoC-Gruppensitzung eingeladen werden möchte. Es können auch Bedingungen für eine Gruppe von PoC-Gruppensitzungen oder auch für alle zukünftigen PoC-Gruppensitzungen, zu denen der PoC-Nutzer eingeladen wird, festgelegt werden.
Der zusätzliche Vorteil in einer solchen Variante ist insbesondere, dass keine weitere Signalisierung erforderlich wäre, da die Bedingungen nicht jedes Mal beim bedingten Einwählen bzw. beim potentiellen Akzeptieren einer Einladung mitgeschickt werden müsste.
Im Folgenden werden einige im Weiteren und oben aufgeführte Begriffe erläutert, wie sie im Rahmen dieser Beschreibung zu verstehen sind:

• Ein PoC-Nutzer ist ein Benutzer eines Kommunikations-Endgerätes, der auf seinem Telekommunikations-Endgerät einen PoC-Client besitzt und zu einem PoC-Dienst angemeldet ist. Er ist also prinzipiell befähigt, eine PoC-Gruppensitzung zu führen.
• Ein PoC-Teilnehmer ist ein PoC-Nutzer, der erfolgreich in eine PoC-Gruppensitzung eingewählt wurde (er hat sich selber eingewählt oder er hat eine Einladung akzeptiert), d.h. er empfängt alle von den anderen PoC-Teilnehmern in dieser PoC-Gruppensitzung anfallenden Sprachdaten und hat im Allgemeinen auch die Möglichkeit, selber Sprachdaten in die PoC-Gruppensitzung einzubringen.
• Ein potentieller PoC-Teilnehmer ist ein Nutzer, der mit einer PoC-Gruppensitzung nur „assoziiert" ist, d.h. er hat sich beim Controlling-PoC-Server 102 mit einer Bedingung in eine PoC-Gruppensitzung bedingt eingewählt, wobei die Bedingung (momentan) jedoch nicht erfüllt ist. Er ist somit noch kein PoC-Teilnehmer, würde es jedoch werden, sobald die Bedingung erfüllt ist.

Unter Bezugnahme auf ein Nachrichtenflussdiagramm 200 in 2 wird ein erstes Ausführungsbeispiel der Erfindung, welches in seiner Struktur gemäß dem oben beschriebenen ersten Lösungsansatz implementiert ist, näher erläutert.
Es wird davon ausgegangen, dass ein PoC-Nutzer Lust hat, an einer Chat-PoC-Gruppensitzung mit dem Titel „Michael Jackson" teilzunehmen.
Allerdings möchte er daran nur teilnehmen, wenn sein Freund „Peter" ebenfalls in dieser Chat-PoC-Gruppensitzung ein PoC-Teilnehmer ist; außerdem hat er nur abends von 19:00 Uhr bis 20:00 Uhr Zeit dazu.
Diese beiden Bedingungen gibt er in eine Applikation, welche auf dem ersten PoC-Client 106 implementiert ist, ein und die beiden Bedingungen werden in einer entsprechenden Syntax, bevorzugt gemäß XML (Extensible Markup Language) in einer nicht dargestellten Konferenz-Bedingungs-Datei gespeichert. Es wird in den Ausführungsbeispielen davon ausgegangen, dass jeder PoC-Client 106, 107, 108 in einem Mobilfunk-Endgerät, welches gemäß UMTS eingerichtet ist, implementiert ist.
Das Eingeben und Speichern der Bedingung durch den Nutzer in den ersten PoC-Client 106 ist in 2 mit einem ersten Block 201 symbolisiert.
Um 19:00 Uhr stößt die Applikation, welche in dem ersten PoC-Client 106 implementiert ist, den ersten PoC-Client 106 an, dass er den Dienst „Session Status Notification" zu dieser angegebenen Chat-PoC-Gruppe von dem Controlling PoC-Server 102 anfordern soll.
Dazu sendet der erste PoC-Client 106 eine entsprechende SIP-SUBSCRIBE-Nachricht 202 mit dem „Conference Status Event Package" an den Controlling-PoC-Server 102.
Zudem soll er alle empfangenen Status-Informationen, die er in Form einer SIP-NOTIFY-Nachricht 203 erhält, an die Applikation in dem ersten PoC-Client 106 weitergeben. In 2 ist der Beispielfall dargestellt, dass zunächst nach Erhalt der ersten SIP-NOTIFY-Nachricht 203 eine Überprüfung der Bedingung(en) erfolgt (Prüfschritt 204) und diese negativ ausfällt, da zu diesem Zeitpunkt der PoC-Client des PoC-Nutzers „Peter" noch nicht PoC-Teilnehmer in der PoC-Gruppensitzung ist.
Zu einem nachfolgenden Zeitpunkt wählt sich der PoC-Nutzer „Peter" in die Chat-PoC-Gruppensitzung ein (Block 205) mittels einer ersten SIP-INVITE-Nachricht 206, welche als Parameter einen Identifikator der jeweiligen Chat-Gruppe enthält, in welche sich der zweite PoC-Client 107 einwählen möchte und welche von dem zweiten PoC-Client 107, welcher auf dem Mobilfunk-Endgerät des PoC-Nutzers „Peter" implementiert ist, an den Controlling-PoC-Server 102 sendet.
Der Controlling-PoC-Server 102 erzeugt die gewünschte Chat-Gruppensitzung oder fügt den PoC-Nutzers „Peter" der schon erzeugten gewünschten Chat-Gruppensitzung hinzu und bestätigt dies dem zweiten PoC-Client 107, welcher die Anforderung zu dem Erzeugen bzw. zu der Teilnahme an der PoC-Gruppensitzung gesendet hat, mittels einer ersten SIP-200-OK-Nachricht 207.
Aufgrund der Statusänderung der Telekommunikations-Konferenzen bzw. der PoC-Gruppensitzungen sendet der Controlling-PoC-Server 102 dem subscribierten PoC-Client 106 eine zweite SIP-NOTIFY-Nachricht 208, in welcher die Information enthalten ist, dass der Freund „Peter" die Chat-PoC-Sitzung als Teilnehmer „betreten" hat.
Aufgrund dieser neuen Information überprüft der erste PoC-Client 106 nunmehr unter Verwendung der Konferenz-Bedingungs-Datei und der zweiten SIP-NOTIFY-Nachricht 208, ob die Bedingung erfüllt ist (Prüfschritt 209) und, da unter den obigen Annahmen nunmehr die Bedingung erfüllt ist, erzeugt und sendet der erste PoC-Client 106 eine zweite SIP-INVITE-Nachricht 210 mit der Identifikationsangabe der Chat-Gruppe und sendet diese zu dem Controlling-PoC-Server 102.
Der Controlling-PoC-Server 102 fügt den ersten PoC-Client 106 der in der SIP-INVITE-Nachricht 210 angegebenen Chat-Gruppensitzung hinzu und bestätigt dies dem ersten PoC-Client 106 mit einer zweiten SIP-200-OK-Nachricht 211.
Nun sind sowohl der erste Client 106 als auch der zweite Client 107 PoC-Teilnehmer an der gewünschten PoC-Gruppensitzung.
3 und 4 zeigen zwei unterschiedliche Realisierungsalternativen eines zweiten Ausführungsbeispiels der Erfindung gemäß dem oben beschriebenen zweiten Lösungsansatz.
Gemäß diesem zweiten Ausführungsbeispiel wird angenommen, dass ein PoC-Nutzer Lust hat, an einer Chat-PoC-Gruppensitzung mit dem Thema „Michael Jackson" teilzunehmen.
Allerdings möchte er daran nur teilnehmen, wenn sein Freund „Peter" oder sein Kollege „Paul" ebenfalls in dieser PoC-Gruppensitzung ein PoC-Teilnehmer ist.
Er gibt diese Bedingungen in einer Applikation, implementiert auf seinem Mobilfunk-Endgerät, auf welchem auch der erste PoC-Client 106 implementiert ist, ein und startet damit seine bedingte Einwahl in die entsprechende Chat-PoC-Gruppensitzung (Block 301).
Daraufhin sendet der erste PoC-Client 106 eine erste SIP-INVITE-Nachricht 302, in welcher als Parameter die Angabe der Chat-PoC-Gruppensitzung und die Bedingungen, die der PoC-Nutzer eingegeben hat, d.h. gesetzt hat, enthalten sind. Die erste SIP-INVITE-Nachricht 302 wird von dem ersten PoC-Client 106 an den Controlling-PoC-Server 102 übertragen, welcher die empfangenen Bedingungen in einer in einem Speicher des Controlling-PoC-Servers 102 gespeicherten Konferenz-Bedingungs-Datei einträgt.
Im Folgenden ist ein beispielhafter Aufbau einer der SIP-INVITE-Nachricht 302 gemäß diesem Ausführungsbeispiel der Erfindung in XML-Format dargestellt:
Die im Vergleich zu einer üblichen INVITE-Nachricht gemäß SIP zusätzlichen Informationen, die die gesetzten Bedingungen repräsentieren, sind in obigem XML-Beispiel in Fettdruck hervorgehoben.
Nach Erhalt der ersten SIP-INVITE-Nachricht 302 überprüft der Controlling-PoC-Server 102, ob die Bedingung, dass der PoC-Nutzer „sip:my.friend.peter@umts.de" oder der PoC-Nutzer „sip:my.colleague.paul@umts.de" momentan in der entsprechenden PoC-Gruppensitzung, wie sie durch den Parameter „Chat-Group" in der SIP-INVITE-Nachricht 302 angegeben ist, PoC-Teilnehmer ist, erfüllt ist.
In dem beispielhaften Fall, dass der Freund Peter momentan an der PoC-Gruppensitzung teilnimmt, sendet der Controlling-PoC-Server 102 eine erste SIP-200-OK-Nachricht 303 an den ersten PoC-Client 106, wobei die SIP-200-OK-Nachricht 303 wie im Folgenden dargestellt erweitert wird (die Erweiterung ist durch Fettdruck markiert), wodurch der PoC-Nutzer zu einem PoC-Teilnehmer wird:
Mittels der obigen Erweiterung kann dem PoC-Nutzer mitgeteilt werden, aufgrund welcher Bedingung(en) diese tatsächliche Einwahl in die Chat-PoC-Gruppensitzung erfolgt ist. Das ist besonders interessant, wenn eine logische ODER-Verknüpfung von dem PoC-Nutzer erfolgt, wie im obigen Beispiel dargelegt.
In dem Fall, dass aktuell weder der Freund „Peter" noch der Kollege „Paul" an der PoC-Gruppensitzung teilnimmt, gibt es zwei alternative Realisierungen, d.h. Vorgehensweisen.
Die erste Realisierungsalternative (vgl. 3) besteht darin, dass bei einer Überprüfung der angegebenen Bedingungen seitens des Controlling-PoC-Servers 102, die negativ verläuft (Block 303), der Controlling-PoC-Server 102 eine erste SIP-200-OK-Nachricht 304 erzeugt und an den ersten PoC-Client 106 übermittelt. In der ersten SIP-200-OK-Nachricht 304 ist unter Verwendung des in [8] beschriebenen Session Description Protocols (SDP) die entsprechenden Medien (insbesondere Sprache) auf „inaktiv" gesetzt, d.h. der Benutzer enthält keine Sprachnachrichten und kann auch keine versenden (symbolisiert in 3 mit Block 305). Der Aufbau einer solchen (SDP-)Nachricht erfolgt gemäß [8]. Die erste SIP-200-OK-Nachricht 304 ist somit folgendermaßen ausgestaltet:
Die im Vergleich zu einer üblichen 200-OK-Nachricht gemäß SIP zusätzlichen Informationen, die das Resultat der Überprüfung der angegebenen Bedingungen repräsentieren, sind in obigem XML-Beispiel in Fettdruck hervorgehoben.
Anders ausgedrückt bedeutet dies, dass der PoC-Nutzer nun ein potentieller PoC-Teilnehmer in dieser PoC-Gruppensitzung ist, also Sprachdaten weder empfangen noch senden kann.
Wenn zu einem späteren Zeitpunkt die in der ersten SIP-INVITE-Nachricht 302 enthaltene Bedingung erfüllt ist, sendet der Controlling-PoC-Server 102 eine entsprechende SIP-Nachricht (beispielsweise eine SIP-Nachricht UPDATE, wie in [6] beschrieben, eine SIP-Nachricht INFO, wie in [7] beschrieben oder eine SIP-Nachricht RE-INVITE), in der dann mit Hilfe von SDP die Sprache auf „aktiv" gesetzt wird. Auf diese Weise wird der PoC-Nutzer dann zu einem „normalen" PoC-Teilnehmer. Auch diese Nachricht kann dann, wie oben im Zusammenhang mit der ersten SIP-200-OK-Nachricht 304 beschrieben, um das Ergebnis der Bedingungs-Überprüfung (Block 303) erweitert werden.
In 3 ist diese Vorgehensweise noch einmal näher erläutert, wobei in 3 angenommen wird, dass zu einem nach der Übermittlung der ersten SIP-200-OK-Nachricht 304 an den ersten PoC-Client 106 liegenden Zeitpunkt sich der PoC-Nutzer „Peter" in die interessierende PoC-Sitzung, d.h. in die Chat-PoC-Gruppensitzung mit dem Thema „Michael Jackson", einwählt (Block 306), indem der zweite PoC-Client 107, welcher in den Mobilfunk-Endgerät des PoC-Nutzers „Peter" implementiert ist, eine zweite SIP-INVITE-Nachricht 307 erzeugt und an den Controlling-PoC-Server 102 übermittelt. In der zweiten SIP-INVITE-Nachricht 307 ist die entsprechende PoC-Chatgruppe angegeben, welche die interessierende Chat-PoC-Gruppensitzung identifiziert, welcher der zweite PoC-Client 107 als PoC-Teilnehmer beitreten möchte.
Der Controlling-PoC-Server 102 fügt dem zweiten PoC-Client 107 der PoC-Gruppensitzung als Teilnehmer hinzu und bestätigt dies dem zweiten PoC-Client 107 mittels einer zweiten SIP-200-OK-Nachricht 308. Somit ist der zweite PoC-Client 107 und damit der PoC-Nutzer „Peter" PoC-Teilnehmer an der Chat-PoC-Gruppensitzung.
Aufgrund der Zustandsänderung der Chat-PoC-Gruppensitzung „Michael Jackson" überprüft der Controlling-PoC-Server 102 erneut, ob die in der ersten SIP-INVITE-Nachricht 302 angegebenen Bedingungen erfüllt sind (Prüfschritt 309).
Da dies nunmehr der Fall ist, weil der PoC-Nutzer „Peter" PoC-Teilnehmer dieser PoC-Gruppensitzung geworden ist, fügt der Controlling-PoC-Server 102 den ersten PoC-Client 106 der Chat-PoC-Gruppensitzung „Michael Jackson" als Teilnehmer hinzu, erzeugt eine SIP-UPDATE-Nachricht 310 und sendet diese an den ersten PoC-Client 106. In der SIP-UPDATE-Nachricht 310 ist ein (SDP-)Parameter enthalten, mit dem die Sprache „aktiv" gesetzt wird und ferner ist in dieser Nachricht das Bedingungs-Prüfergebnis enthalten.
Der erste PoC-Client 106, welcher nunmehr ebenfalls PoC-Teilnehmer an der PoC-Gruppensitzung ist, bestätigt den Empfang der SIP-UPDATE-Nachricht 310 durch Erzeugen einer dritten SIP-200-OK-Nachricht 311, welche er an den Controlling-PoC-Server 102 übermittelt.
Nunmehr sind sowohl der erste PoC-Client 106 als auch der PoC-Client 107 PoC-Teilnehmer an der gewünschten PoC-Gruppensitzung.
Gemäß der in 4 dargestellten zweiten Realisierungs-Alternative des zweiten Ausführungsbeispiels ist es bei einer negativen Bedingungs-Überprüfung (Block 303) vorgesehen, dass der Controlling-PoC-Server 102 auf die erste SIP-INVITE-Nachricht 302 eine erste SIP-200-OK-Nachricht 401 mit den Prüfungsergebnis als Nachrichtenparameter an den ersten PoC-Client 106 übermittelt und unmittelbar danach, d.h. sofort danach eine SIP-BYE-Nachricht 402 erzeugt und diese ebenfalls an den ersten PoC-Client 106 übermittelt.
Alternativ zu den SIP-Nachrichten 401, 402 übermittelt der Controlling-PoC-Server 102 eine SIP-Fehlermeldungs-Nachricht „4XX" (nicht dargestellt) an den ersten PoC-Client 106. All diese SIP-Nachrichten können ebenfalls das Ergebnis der Bedingungs-Überprüfung (Block 303) beinhalten.
Das bedeutet, dass der Controlling-PoC-Server 102 erst gar keine Verbindung auf Signalisierungsebene mit dem ersten PoC-Client 106 aufbaut.
Dennoch verfolgt der Controlling-PoC-Server 102 weiterhin für den ersten PoC-Client 106, ob die Bedingungen, die der erste PoC-Client 106 in der ersten SIP-INVITE-Nachricht 302 dem Controlling-PoC-Server 102 übermittelt hat, und dieser in der in dem Controlling-PoC-Server 102 gespeicherten Konferenz-Bedingungs-Datei gespeichert hat, zwischenzeitlich erfüllt werden.
Der PoC-Nutzer ist also auch in diesem Fall ein potentieller PoC-Teilnehmer. Sobald die Bedingung erfüllt ist, sendet der Controlling-PoC-Server 102 eine SIP-INVITE-Nachricht zu dem ersten PoC-Client 106, um den PoC-Nutzer in die gewünschte PoC-Gruppensitzung nun als „normalen" PoC-Teilnehmer hinzuzunehmen.
Wenn der erste PoC-Client 106 in der Zwischenzeit (also solange die Bedingungen noch nicht erfüllt sind und somit der erste PoC-Client 106 nicht an der PoC-Gruppensitzung teilnimmt) sein bedingtes, in der ersten SIP-INVITE-Nachricht 302 ausgedrücktes Einwählen zurücknehmen möchte, dann kann der erste PoC-Client 106 eine SIP-Nachricht MESSAGE 409, wie sie an sich in [9] beschrieben ist, zu dem Controlling-PoC-Server 102 senden, wobei die SIP-Nachricht MESSAGE 409 einen entsprechenden Hinweis beinhaltet.
Dies könnte in folgender Weise realisiert sein:
Die im Vergleich zu einer üblichen MESSAGE-Nachricht gemäß SIP zusätzlichen Informationen, die die Anfrage zum Zurücknehmen der bedingten Einwahl repräsentieren, sind in obigem XML-Beispiel in Fettdruck hervorgehoben.
In 4 ist zur näheren Erläuterung in einem Nachrichtenflussdiagramm 400 dargestellt, dass zu einem späteren Zeitpunkt, d.h. nachdem der Controlling-PoC-Server 102 dem ersten PoC-Client 106 mitgeteilt hat, dass die Bedingung nicht erfüllt sind, sich der PoC-Nutzer „Peter" in die angegebene Chat-PoC-Gruppensitzung einwählt (Block 403). Dies erfolgt, indem der zweite PoC-Client 107 eine zweite SIP-INVITE-Nachricht 404, enthaltend die Angabe der jeweiligen Chatgruppe, erzeugt und an den Controlling-PoC-Server 102 übermittelt. Der Controlling-PoC-Server 102 fügt den zweiten PoC-Client 107 und damit dem PoC-Nutzer „Peter" der angegebenen Chat-PoC-Gruppensitzung als PoC-Teilnehmer hinzu und bestätigt dies dem zweiten PoC-Client 107 mittels einer zweiten SIP-200-OK-Nachricht 405.
Aufgrund der Zustandsänderung in der PoC-Gruppensitzung „Michael Jackson" überprüft der Controlling-PoC-Server 102 erneut, ob die in der Konferenz-Bedingungs-Datei für die jeweiligen PoC-Clients enthaltenen Bedingungen nunmehr erfüllt sind (Schritt 406).
In diesem Fall ist durch den Beitritt des PoC-Nutzers „Peter" zu der Chat-PoC-Gruppensitzung die Bedingung des ersten PoC-Client 106 erfüllt. Damit fügt der Controlling-PoC-Server 102 hinzu oder lädt alternativ, wie in 4 dargestellt, den ersten PoC-Client 106 und damit den entsprechenden PoC-Nutzer zu der PoC-Gruppensitzung ein mittels einer dritten SIP-INVITE-Nachricht 407, welche der Controlling-PoC-Server 102 an den ersten PoC-Client 106 übermittelt.
Nimmt der erste PoC-Client 106 die Einladung an, so erzeugt der erste PoC-Client 106 eine dritte SIP-200-OK-Nachricht 408 und sendet diese zu dem Controlling-PoC-Server 102, welcher auf den Erhalt dieser Nachricht 408 hin den ersten PoC-Client 106 und damit den entsprechenden PoC-Nutzer der PoC-Gruppensitzung hinzufügt. Damit sind sowohl der erste PoC-Client 106 als auch der zweite PoC-Client 107 und damit der PoC-Nutzer des ersten PoC-Clients 106 und der PoC-Nutzer „Peter" Teilnehmer an der gewünschten PoC-Gruppensitzung.
Gemäß einem dritten Ausführungsbeispiel der Erfindung, welches gemäß dem zweiten Lösungsansatz realisiert ist, (nicht dargestellt in den Figuren) wird angenommen, dass in einer bestimmten Chat-PoC-Gruppensitzung momentan keine PoC-Teilnehmer vorhanden sind.
Gemäß diesem Ausführungsbeispiel der Erfindung wählt sich ein erster PoC-Nutzer mittels seines PoC-Client gemäß dem oben beschriebenen Verfahren gemäß dem zweiten Ausführungsbeispiel der Erfindung mit der Bedingung ein, dass mindestens zwei weitere PoC-Teilnehmer an der Chat-PoC-Gruppensitzung teilnehmen sollen. Da er jedoch momentan der einzige PoC-Teilnehmer wäre, wird er also nur als potentieller PoC-Teilnehmer in dieser Chat-PoC-Gruppensitzung geführt seitens des Controlling-PoC-Servers 102. Die entsprechende SIP-INVITE-Nachricht gemäß diesem Ausführungsbeispiel der Erfindung könnte wie folgt aussehen:
Die im Vergleich zu einer üblichen INVITE-Nachricht gemäß SIP zusätzlichen Informationen, die die gesetzten Bedingungen repräsentieren, sind in obigem XML-Beispiel in Fettdruck hervorgehoben.
Danach wählt sich ein zweiter PoC-Nutzer mit der gleichen Bedingung in die gleiche Chat-PoC-Gruppensitzung bedingt ein. Auch er wird nur als potentieller PoC-Teilnehmer in dieser Chat-PoC-Gruppensitzung geführt, was auch weiterhin gilt für den ersten PoC-Nutzer.
Nun wählt sich ein dritter PoC-Nutzer mit der gleichen Bedingung in die gleiche Chat-PoC-Gruppensitzung bedingt ein. Da der Controlling-PoC-Server 102 alle Bedingungen und alle Anfragen zu der PoC-Gruppensitzung kennt und in seiner Konferenz-Bedingungs-Datei gespeichert hat, überprüft und erkennt er, dass bei allen drei PoC-Nutzern die Bedingung erfüllt werden würde, wenn alle drei PoC-Nutzer in die Chat-PoC-Gruppensitzung als PoC-Teilnehmer eingewählt werden würden.
Gemäß diesem Ausführungsbeispiel der Erfindung beginnt daher der Controlling-PoC-Server gemäß dem in dem zweiten Ausführungsbeispiel dargestellten Verfahren, alle drei PoC-Nutzer als PoC-Teilnehmer zu der PoC-Gruppensitzung hinzuzunehmen.
Damit sind alle drei PoC-Nutzer in der gewünschten Chat-PoC-Gruppensitzung PoC-Teilnehmer.
In den vorherigen Beispielen wurden nur Chat-PoC-Gruppen, bei denen sich ein PoC-Client in der Regel selber einwählt, besprochen. In den folgenden Beispielen soll der Fall betrachtet werden, in dem ein PoC-Client zu einer PoC-Gruppensitzung (beispielsweise zu einer Ad-hoc-PoC-Gruppensitzung oder einer Pre-arranged-Gruppensitzung) eingeladen wird.
Gemäß einem vierten Ausführungsbeispiel der Erfindung gemäß dem oben beschriebenen zweiten Lösungsansatz ist eine Pre-arranged-Gruppensitzung für eine Arbeitsgruppe definiert, die als Mitglieder einen Chef und zwei seiner Mitarbeiter haben soll.
Der erste Mitarbeiter besitzt ein Mobilfunk-Endgerät, in dem der erste PoC-Client 106 implementiert ist, der zweite Mitarbeiter besitzt ein Mobilfunk-Endgerät, in dem der zweite PoC-Client 107 implementiert ist und der Chef besitzt ein Mobilfunk-Endgerät, in dem der dritte PoC-Client 108 implementiert ist.
Das vierte Ausführungsbeispiel ist in einem Nachrichten-Flussdiagramm 500 in 5 dargestellt.
Die Arbeitsgruppe ist durch eine Arbeitsgruppenidentität (Group Identity) mittels einer SIP-Group-Identity „sip:arbeitsgruppell@Infineon.com" definiert und somit eindeutig adressierbar. Gemäß diesem Ausführungsbeispiel initiiert der erste Mitarbeiter eine PoC-Gruppensitzung mit dieser Gruppe, indem er eine SIP-INVITE-Nachricht 501 mit der obigen SIP-Group-Identity der Arbeitsgruppe als Parameter mittels des ersten PoC-Clients 106 zu dem Controlling-PoC-Server 102 übermittelt.
Auf den Empfang der ersten SIP-INVITE-Nachricht 501 hin werden nun alle anderen Mitglieder der Arbeitsgruppe, also der Chef und der zweite Mitarbeiter, von dem Controlling-PoC-Server 102 mittels einer zweiten SIP-INVITE-Nachricht 502, welche an den zweiten PoC-Client 107 übermittelt wird bzw. einer dritten SIP-INVITE-Nachricht 503, welche an den dritten PoC-Client 108 übermittelt wird, eingeladen. Wenn ein Mitglied dieser Arbeitsgruppe dieser Einladung zu der PoC-Gruppensitzung annehmen möchte, sendet er bzw. sein PoC-Client 107, 108 eine SIP-200-OK-Nachricht als Antwort an den Controlling-PoC-Server.
Gemäß diesem Ausführungsbeispiel sendet der zweite PoC-Client 107 eine erste SIP-200-OK-Nachricht 504, in der eine Bedingung enthalten ist, womit der Fall beschrieben wird, dass der zweite Mitarbeiter nur unter einer bestimmten Bedingung an der PoC-Gruppensitzung teilnehmen möchte. In diesem Fall möchte der zweite Mitarbeiter die Einladung zu der PoC-Gruppensitzung erst dann annehmen, wenn der Chef auch (schon) in der PoC-Gruppensitzung als PoC-Teilnehmer teilnimmt. Daher fügt er der ersten SIP-200-OK-Nachricht 504 die entsprechende Bedingung in einem dafür vorgesehenen Nachrichtenfeld hinzu und sendet diese bedingte Akzeptanz zu dem Controlling-PoC-Server 102.
Ein Beispiel einer solchen SIP-Nachricht in XML mit der mittels Fettdruck symbolisierten Erweiterung ist im Folgenden dargestellt:
Wenn der Chef nun schon in der PoC-Gruppensitzung ein PoC-Teilnehmer ist, wird der zweite Teilnehmer sofort als PoC-Teilnehmer in die PoC-Gruppensitzung eingewählt.
Falls nicht, was in 5 durch den Prüfschritt (Block 505) symbolisch dargestellt ist, erfolgt eine ähnliche Vorgehensweise, wie im Zusammenhang mit Ausführungsbeispiel zwei schon beschrieben wurde.
Es gibt somit auch gemäß dem vierten Ausführungsbeispiel zwei alternative Realisierungsmöglichkeiten.
Gemäß einer ersten Realisierungsalternative sendet der Controlling PoC-Server 102 eine SIP-UPDATE-Nachricht 506 zu dem ersten PoC-Client 107, alternativ eine SIP-INFO-Nachricht oder eine SIP-RE-INVITE-Nachricht, mit der er unter Verwendung von SDP die entsprechenden Medien (insbesondere Sprache) auf „inaktiv" setzt. Auch kann das Prüfungsergebnis als zusätzliche Information in der SIP-UPDATE-Nachricht 506 (bzw. SIP-INFO-Nachricht oder SIP-RE-INVITE-Nachricht) enthalten sein.
Sobald der Chef in die PoC-Gruppensitzung als PoC-Teilnehmer eingewählt ist, sendet der Controlling-PoC-Server 102 erneut eine SIP-Nachricht, beispielsweise eine SIP-UPDATE-Nachricht, mit Hilfe derer er unter Verwendung von SDP die entsprechenden Medien (insbesondere Sprache) dann wieder auf „aktiv" setzt. Nun gilt auch der zweite Mitarbeiter bzw. der zweite PoC-Client 107 als „normaler" PoC-Teilnehmer.
In 5 ist diese Alternative dargestellt, wobei der zweite PoC-Client 107 auf den Erhalt der SIP-UPDATE-Nachricht 506 eine zweite SIP-200-OK-Nachricht 507 erzeugt und diese an den Controlling-PoC-Server 102 übermittelt.
Nachfolgend wird angenommen, dass der dritte PoC-Client 108 auf Veranlassung des PoC-Nutzers „Chef" hin, welche der PoC-Gruppensitzung beitreten möchte, eine dritte SIP-200-OK-Nachricht 508 erzeugt und diese dem Controlling-PoC-Server 102 übermittelt.
Aufgrund der Zustandsänderung in der PoC-Gruppensitzung überprüft der Controlling-PoC-Server 102 erneut alle in der Konferenz-Bedingungs-Datei gespeicherten Bedingungen für die jeweiligen PoC-Clients (Prüfschritt 509).
In diesem Fall ist nunmehr die Bedingung des zweiten PoC-Clients 107, angegeben in der ersten SIP-200-OK-Nachricht 504, erfüllt, und der zweite PoC-Client 107 erhält eine zweite SIP-UPDATE-Nachricht 510, in welcher unter Verwendung von SDP die ensprechenden Medien auf „aktiv" gesetzt werden. Außerdem ist in der SIP-UPDATE-Nachricht 510 das Prüfungsergebnis des obigen Prüfschritts 509 mit positivem Prüfergebnis enthalten.
Der zweite PoC-Client 107 erzeugt auf den Erhalt der zweiten UPDATE-Nachricht 510 hin eine vierte SIP-200-OK-Nachricht 511 und übermittelt diese an den Controlling-PoC-Server 102.
Nunmehr sind alle drei PoC-Clients 106, 107, 108 bzw. die entsprechenden PoC-Nutzer PoC-Teilnehmer an der PoC-Gruppensitzung für die Arbeitsgruppe.
Gemäß einer zweiten Realisierungsalternative des vierten Ausführungsbeispiels ist es vorgesehen, dass der Controlling-PoC-Server 102 auf das negative Prüfergebnis hin eine SIP-BYE-Nachricht sendet, die Bedingungen aber weiterhin im Auge behält, d.h. kontinuierlich überprüft.
Somit gilt der zweite Mitarbeiter als potentieller PoC-Teilnehmer.
Sobald der Chef in die PoC-Gruppensitzung als PoC-Teilnehmer eingewählt ist, sendet der Controlling-PoC-Server 102 dann erneut eine SIP-INVITE-Nachricht, optional mit dem Ergebnis der Bedingungs-Prüfung. Aufgrund des Erhalts der entsprechenden SIP-INVITE-Nachricht, sendet der PoC-Client erneut das oben beschriebene erfindungsgemäße erweiterte SIP-200-OK, womit der PoC-Client dann als PoC-Teilnehmer in die PoC-Gruppensitzung eingewählt ist, da nunmehr ja die Bedingung erfüllt ist.
Gemäß einem fünften Ausführungsbeispiel der Erfindung ist unter Verwendung einer bei OMA vorgesehene Variante „Pre-established Sessions" für den Fall, dass der PoC-Nutzer zunächst nur eine Verbindung zum Participating-PoC-Server 103, 104 bzw. 105 hat, ohne dass er in eine PoC-Gruppensitzung eingewählt ist, vorgesehen, dass er beliebig später erst auch eine Verbindung zu dem Controlling-PoC-Server 102 hat, wenn er sich in eine PoC-Gruppensitzung einwählt.
In diesen Fall würden alle erfindungsgemäßen Funktionalitäten statt in dem Controlling-PoC-Server 102 in den Participating-PoC-Servern 103, 104, 105 realisiert sein. Ferner würden die jeweiligen SIP-INVITE-Nachrichten durch eine entsprechende SIP-REFER-Nachricht zu ersetzen sein.
6 zeigt ein Mobilfunk-Multimedia-Telekommunikations-Konferenz-System 600 gemäß einem weiteren bevorzugten Ausführungsbeispiel der Erfindung.
Es ist darauf hinzuweisen, dass es sich in einer alternativen Ausgestaltung nicht um ein Mobilfunk-Multimedia-Telekommunikations-Konferenz-System handeln muss.
Die im Folgenden und oben beschriebenen Verfahren können auch in einem Festnetz-Multimedia-Telekommunikations-Konferenz-System, beispielsweise einem internet-basierten Festnetz-Multimedia-Telekommunikations-Konferenz-System realisiert sein.
In dieser alternativen Ausführungsform sind zumindest ein Teil der Telekommunikationsendgeräte als Festnetz-Telekommunikationsendgeräte eingerichtet, welche insbesondere zur Durchführung einer internet-basierten Telekommunikations-Konferenz eingerichtet sind.
Das System 600 ist für alle Ausführungsbeispiele, welche im Folgenden näher erläutert werden, identisch bis auf die unterschiedliche Ausgestaltungen des Fokusservers, der jeweils derart eingerichtet ist, dass er die Funktionalitäten der jeweiligen Ausführungsbeispiele implementiert hat.
Das Kommunikationssystem 600 ist bis auf die unten beschriebenen Änderungen gemäß den Ausführungsformen der Erfindung ausgestaltet, wie in [10] beschrieben.
Das in [10] beschriebene und in 6 dargestellte „Conferencing Framework" stellt den Benutzern, insbesondere den Mobilfunk-Endgeräten 601, 602, 603, 604 unterschiedliche Multimedia-Telekommunikations-Konferenz-Dienste bereit. Insbesondere sind, wie in [10] im Detail beschrieben, ein Dienst zur Steuerung der Zugriffsrechte auf Telekommunikations-Konferenz-Ressourcen, auch bezeichnet als Floor Control, ein Dienst zur Etablierung von Konferenz-Regeln (welche auch bezeichnet werden als Conference-Policy-Control), sowie in Form von auf dem Session Initiation Protocol (SIP) basierende Prozeduren zusätzliche Dienste zur Erzeugung, zum Management, zum Eintritt und zum Verlassen von Multimedia-Telekommunikations-Konferenzen vorgesehen.
Weiterhin stellt das Kommunikationssystem 600, wie ebenfalls in [10] beschrieben, Methoden zur Benachrichtigung der Konferenz-Teilnehmer 601, 602, 603, 604, auch bezeichnet als Conference-Notification-Service, über spezifische, eine jeweilige Multimedia-Telekommunikations-Konferenz betreffende Informationen und Ereignisse (Events) bereit. Das Konferenz-System 600 ist derart eingerichtet, dass beliebige Medienarten zwischen den Teilnehmern, d.h. zwischen den Mobilfunk-Endgeräten 601, 602, 603, 604 ausgetauscht werden können. Beispiele für eine Medienart, welche im Rahmen des Konferenz-Systems 600 übertragen und verarbeitet werden kann, sind Audiodaten, Videodaten, Instant-Messaging-Daten und Daten von Multiplayer-Spielen im Rahmen einer Gaming-Konferenz.
6 zeigt, wie oben beschrieben, das Multimedia-Telekommunikations-Konferenz-System 600 gemäß den Ausführungsbeispielen der Erfindung mit dessen einzelnen Komponenten und die Interaktion zwischen den Komponenten.
Das Multimedia-Telekommunikations-Konferenz-System 600 weist eine sternförmige Konferenz-Architektur auf, in der alle Konferenz-Teilnehmer (auch bezeichnet als User Agents), gemäß diesem Ausführungsbeispiel Mobilfunk-Endgeräte 601, 602, 603, 604 mit der Konferenz-Servereinrichtung 605, auch bezeichnet als Fokus 605, mittels SIP-Signalisierungs-Kommunikationsverbindungen 606 verbunden sind. 6 zeigt jedoch nur exemplarisch eine dieser SIP-Signalisierungs-Kommunikationsverbindungen 606.
Einer jeweiligen bestimmten Mobilfunk-Telekommunikations-Konferenz, die einem bestimmten Konferenz-Serverrechner 605, d.h. einem bestimmten Fokus, zugeordnet ist, bzw. auf ihm ausgeführt wird, ist eine eindeutige Konferenzadresse, die so genannte Conference-Unique Resource Identifier (C-URI), zugeordnet. Die C-URI repräsentiert und adressiert die jeweilige Konferenz eindeutig. Der Fokus 605 hat unter anderem indirekten Zugriff auf die Conference-Policy. Die Conference-Policy-Datei, im Folgenden auch bezeichnet als Konferenz-Regel-Datei 608, setzt sich üblicherweise logisch aus zwei Teil-Bereichen, einer Membership-Policy 609 sowie einer Media-Policy 610, zusammen. Die Conference-Policy-Datei 608 kann aber unter Umständen physikalisch auf mehrere Teildateien aufgeteilt gespeichert werden. Neben der physikalischen Trennung kann hierbei auch eine logische Aufteilung der Conference-Policy-Datei 608 erfolgen. Die Konferenz-Regel-Datei 608 wird von einem Konferenz-Regel-Server (Conference-Policy Server) 111 für eine jeweilige Konferenz exklusiv erzeugt, in 6 symbolisiert durch einen Pfeil 612. Der Fokus 605 wird über den Konferenz-Regel-Server 611 über den Inhalt und jede Änderung der Conference-Policy-Datei informiert. Denkbar ist auch, dass der Fokus 605 direkten Zugriff auf die Conference-Policy-Datei 608 hat.
Zusätzlich zu der Umsetzung dieser in der Konferenz-Regel-Datei 608 gespeicherten Konferenz-Regeln hat der Fokus 605 die Aufgabe, für die Konferenz spezifische Verteilungen der Medien-Datenströme zu sorgen.
Zum Verteilen der Medien-Datenströmen setzt der Fokus 605 so genannte Mixer 613, anders ausgedrückt Datenstrom-Mischeinrichtungen, ein, welche unter Verwendung der in der Media-Policy 610 gespeicherten Medienregeln die individuelle Zusammenstellung und die Verteilung der Medien-Datenströme auf die an der Konferenz teilnehmenden Mobilfunk-Endgeräte 601, 602, 603, 604 ausführt, in 6 symbolisiert mittels Doppelpfeilen 614, 615, 616, 617. Die Kommunikationsverbindung zwischen dem Fokus 605 und dem Mixer 613 ist mittel eines Pfeils 607 symbolisiert.
In den Mobilfunk-Endgeräten 601, 602, 603, 604 sind zur Umsetzung des Konferenzdienstes einige zusätzliche Prozeduren, Kommunikations-Protokolle und Funktionalitäten implementiert, insbesondere sind neue zusätzliche SIP-Prozeduren implementiert sowie das so genannte Binary Floor Control Protocol (BFCP), serverseitig implementiert in einem Floor Control Server 618, und das Conference Policy Control Protocol (CPCP) bzw. die jeweiligen Einheiten, welche in der Lage sind, die entsprechenden Kommunikations-Protokolle auszuführen.
Die Binary Floor Control Protocol Kommunikations-Verbindung zwischen einem ersten Mobilfunk-Endgerät 601 und dem Floor Control Server 618 ist in 1 mit einem Pfeil 619 symbolisiert.
Das in [11] beschriebene Conference Policy Control Protocol (CPCP) bietet die Möglichkeit, unterschiedliche Regeln für eine Multimedia-Telekommunikations-Konferenz zu definieren. So können beispielsweise allgemeine Konferenz-Regeln, wie z.B. die maximale Anzahl der Konferenz-Teilnehmer innerhalb der Konferenz-Regel-Datei 608 (Conference-Policy) mittels des CPCP angegeben werden. Die Konferenz-Regel-Datei 608 enthält weiterhin beispielsweise eine so genannte „Dial-out"-Liste (<dial-out-list>-Datenelement), die angibt, welche Benutzer bzw. welche Telekommunikations-Endgeräte bei einer Aktivierung einer Konferenz zu dieser eingeladen werden sollen. Die Conference-Policy enthält ferner Autorisierungs-Datenelemente, mittels derer angegeben wird, welcher Benutzer andere Benutzer in die „Dial-out"-Liste eintragen darf (<allow-modify-dol>-Datenelement).
Zum Festlegen, wer Autorisierungs-Datenelemente bearbeiten darf, ist gemäß CPCP ein übergeordnetes Autorisierungs-Datenelement vorgesehen, das den Zugriff auf alle anderen Autorisierungs-Datenelemente regelt (<allow-authorization-rules>-Datenelement).
Die Konferenz-Regel-Datei 608 wird in Form mindestens eines XML-Dokumentes (Extensible-Markup-Language-Datei) angegeben. Aufgrund der Verwendung von XML zum Beschreiben der Konferenz-Regel-Datei 608 ist es möglich, die Konferenz-Regel-Datei auf einfache Weise zu erweitern, allgemein zu ändern.
Zum Übertragen der XML-Dateien, d.h. insbesondere der Konferenz-Regel-Datei 608 bzw. zum Lesen von Daten aus der Konferenz-Regel-Datei 608 und/oder zum Schreiben von Daten in die Konferenz-Regel-Datei 608 wird das Hypertext Transport-Protocol (HTTP) verwendet.
Das Schreiben einer Konferenz-Regel-Datei 608 bzw. das Schreiben in eine Konferenz-Regel-Datei 608 erfolgt mittels eines HTTP Put Requests, wohingegen zum Lesen einer Konferenz-Regel-Datei 608 bzw. eines Teils einer Konferenz-Regel-Datei 608 ein HTTP Get Request und zum Löschen einer gesamten Konferenz-Regel-Datei 608 oder eines Teils der Konferenz-Regel-Datei 608 ein HTTP Read Request verwendet wird.
Das CPCP ermöglicht es ferner, einzelne Elemente, Attribute oder Attributwerte eines XML-Dokuments und damit der Konferenz-Regel-Datei 608 gemäß diesem Ausführungsbeispiel der Erfindung mittels des HTTP Unique Resource Locators (HTTP URL) zu adressieren.
Gemäß diesem Ausführungsbeispiel der Erfindung können in der Konferenz-Regel-Datei 608, definiert in XML, die entsprechenden Bedingungen, welche von einem Mobilfunk-Endgerät übermittelt werden, gespeichert werden und anhand der Konferenz-Regel-Datei 608 können die Mobilfunk-Endgeräte einer Konferenz hinzugefügt werden oder nicht. Die jeweiligen Kommunikations-Abläufe können analog zu den oben beschriebenen Nachrichtenflüssen erfolgen.
Auch in diesen Ausführungsbeispielen, welche auf dem in [10] beschriebenen „Conference Framework" basieren, können die die Überprüfung der jeweiligen Bedingungen realisierenden Einheiten in den Telekommunikations-Endgeräten, im Fokusservers, im Conference-Policy-Server oder in einer anderen Server-Einrichtung zentral realisiert sein.
Zusammenfassend sind folgende Aspekte der Erfindung als vorteilhaft anzusehen:

• Der PoC-Nutzer kann Bedingungen in dem PoC-Client, in dem Participating-PoC-Server oder in dem Controlling-PoC-Server festlegen, die erfüllt sein müssen, bevor er PoC-Teilnehmer in einer bestimmten PoC-Gruppensitzung wird.
• Der PoC-Client beobachtet mit Hilfe des „Session Status Notification"-Dienstes den aktuellen Status einer PoC-Gruppensitzung. Bei Erfüllung der Bedingung(en) wählt sich der PoC-Client automatisch in die PoC-Gruppensitzung ein, der PoC-Nutzer wird entsprechend informiert.
• Der PoC-Client wählt sich in eine PoC-Gruppensitzung ein und schickt dabei Bedingungen mit zum Controlling-PoC-Server (bedingte Einwahl).
• Der PoC-Client wird zu einer PoC-Gruppensitzung eingeladen und schickt dabei Bedingungen mit der Bestätigung zum Controlling-PoC-Server (bedingte Akzeptanz).
• Der Controlling-PoC-Server beobachtet ständig, ob die Bedingung(en) erfüllt ist/sind; sobald dies der Fall ist, wird der potentielle PoC-Teilnehmer zum PoC-Teilnehmer.

In diesem Dokument sind folgenden Veröffentlichungen zitiert:

[1] Push to Talk over Cellular (PoC); PoC Release 2.0 http://www.motorola.com/content/0, 2647-4398,00.htm1
[2] RFC 3261 "SIP: Session Initiation Protocol"
[3] RFC 3550 "RTP: A Transport Protocol for Real-Time Applications"
[4] Internet Draft "A Session Initiation Protocol (SIP) Event Package for Conference State"
[5] RFC 3265 "Session Initiation Protocol (SIP)-Specific Event Notification"
[6] RFC 3311 "The Session Initiation Protocol (SIP) UPDATE Method"
[7] RFC 2976 "The SIP INFO Method"
[8] RFC 2327 "SDP: Session Description Protocol"
[9] RFC 3428 "Session Initiation Protocol (SIP) Extension for Instant Messaging"
[10] J. Rosenberg, A framework for conferencing with the session initiation protocol, SIP Internet-Draft, IETF SIPPING working group: Draft-IETF-SIPPING-conferencing-framework-02, Juni 2004
[11] H. Khartabil et al., The Conference Policy Control Protocol (CPCP), XCON, Internet Draft, IETF XCON Working Group: Draft IETF-XCON-CPCP-XCAP-01, Juli 2004
[12] US 2003/0153339 A1
[13] US 2004/0205212 A1
[14] US 2004/0199580 A1

100: PoC-Telekommunikations-Konferenz-System
101: Festnetz-Kammunikations-Netzwerk
102: Controlling-PoC-Server
103: Participating-PoC-Server
104: Participating-PoC-Server
105: Participating-PoC-Server
106: PoC-Client
107: PoC-Client
108: PoC-Client
109: Luftschnittstelle
110: Luftschnittstelle
111: Luftschnittstelle
112: Chair
200: Nachrichtenfluss-Diagramm
201: Block
202: SIP-SUBSCRIBE-Nachricht
203: erste SIP-NOTIFY-Nachricht
204: Prüfschritt
205: Block
206: erste SIP-INVITE-Nachricht
207: erste SIP-200-OK-Nachricht
208: zweite SIP-NOTIFY-Nachricht
209: Prüfschritt
210: zweite SIP-INVITE-Nachricht
211: zweite SIP-200-OK-Nachricht
300: Nachrichtenfluss-Diagramm
301: Block
302: erste SIP-INVITE-Nachricht
303: Prüfschritt
304: erste SIP-200-OK-Nachricht
305: Block
306: Block
307: zweite SIP-INVITE-Nachricht
308: zweite SIP-200-OK-Nachricht
309: Prüfschritt
310: SIP-UPDATE-Nachricht
311: dritte SIP-200-OK-Nachricht
400: Nachrichtenfluss-Diagramm
401: erste SIP-200-OK-Nachricht
402: SIP-BYE-Nachricht
403: Block
404: zweite SIP-INVITE-Nachricht
405: zweite SIP-200-OK-Nachricht
406: Prüfschritt
407: dritte SIP-INVITE-Nachricht
408: dritte SIP-200-OK-Nachricht
409: SIP-MESSAGE-Nachricht
500: Nachrichtenfluss-Diagramm
501: erste SIP-INVITE-Nachricht
502: zweite SIP-INVITE-Nachricht
503: dritte SIP-INVITE-Nachricht
504: erste SIP-200-OK-Nachricht
505: Prüfschritt
506: SIP-UPDATE-Nachricht
507: zweite SIP-200-OK-Nachricht
508: dritte SIP-200-OK-Nachricht
509: Prüfschritt
510: SIP-UPDATE-Nachricht
511: vierte SIP-200-OK-Nachricht
600: Multimedia-Telekommunikations-Konferenz-System
601: Mobilfunk-Endgerät
602: Mobilfunk-Endgerät
603: Mobilfunk-Endgerät
604: Mobilfunk-Endgerät
605: Fokus
606: SIP-Signalisierungs-Kommunikations-Verbindung
607: Pfeil
608: Konferenz-Regel-Datei
609: Membership-Policy
610: Media-Policy
611: Konferenz-Regel-Server
612: Pfeil
613: Datenstrom-Mischeinrichtun
614: Doppelpfeil
615: Doppelpfeil
616: Doppelpfeil
617: Doppelpfeil
618: Floor Control Server
619: Pfeil

Claims

Verfahren zum automatischen Erzeugen und/oder Steuern einer Telekommunikations-Konferenz mit einer Vielzahl von Teilnehmern, wobei in einer elektronischen Konferenz-Bedingungs-Datei, die in einer Telekommunikations-Konferenz-Servereinrichtung gespeichert ist, mindestens eine Konferenz-Bedingung hinsichtlich des Erzeugens der Telekommunikations-Konferenz und/oder hinsichtlich der Teilnahme eines oder mehrerer Teilnehmer an der Telekommunikations-Konferenz gespeichert ist, • bei dem für eine Mehrzahl von der Telekommunikations-Konferenz-Servereinrichtung empfangener Telekommunikations-Konferenz-Anfragen unter Verwendung der Konferenz-Bedingungs-Datei überprüft wird, ob durch Erfüllen der Telekommunikations-Konferenz-Anfragen mindestens eine gespeicherte Konferenz-Bedingung erfüllt ist, und • bei dem für den Fall, dass bei Erfüllen der Telekommunikations-Konferenz-Anfragen die Konferenz-Bedingung erfüllt ist, die Telekommunikations-Konferenz erzeugt wird und/oder der Teilnehmer oder die Teilnehmer der Telekommunikations-Konferenz hinzugefügt werden.
Verfahren gemäß Anspruch 1, eingesetzt in einer Multimedia-Telekommunikations-Konferenz.
Verfahren gemäß Anspruch 1 oder 2, eingesetzt in einer Festnetz-Telekommunikations-Konferenz, insbesondere einer internet-basierten Festnetz-Telekommunikations-Konferenz, oder in einer Mobilfunk-Telekommunikations-Konferenz, insbesondere einer zellenbasierten Mobilfunk-Telekommunikations-Konferenz.
Verfahren gemäß Anspruch 1 oder 2, eingesetzt in einer 3GPP-Mobilfunk-Telekommunikations-Konferenz, insbesondere in einer UMTS-Mobilfunk- Telekommunikations-Konferenz.
Verfahren gemäß Anspruch 1 oder 2 oder 4, eingesetzt in einer Push-to-Talk-over-Cellular-Mobilfunk-Telekommunikations-Konferenz, insbesondere einer der folgenden Arten: • Ad-hoc-Mobilfunk-Telekommunikations-Konferenz; • Pre-arranged-Mobilfunk-Telekommunikations-Konferenz; • Chat-Mobilfunk-Telekommunikations-Konferenz.
Verfahren gemäß einem der Ansprüche 1 bis 5, wobei die Konferenz-Bedingungs-Datei in einem Teilnehmer-Endgerät eines Teilnehmers gespeichert ist.
Verfahren gemäß einem der Ansprüche 1 bis 6, bei dem als Konferenz-Bedingung eine oder mehrere der folgenden Konferenz-Bedingungen berücksichtigt werden: • eine vorgegebene Anzahl, insbesondere Mindest-Anzahl und/oder Maximal-Anzahl, an der Telekommunikations-Konferenz interessierten oder teilnehmenden Teilnehmer; • eine Identität an der Telekommunikations-Konferenz interessierter oder teilnehmender Teilnehmer; • ein Zeitpunkt des Erzeugens einer Telekommunikations-Konferenz; • ein Zeitpunkt des Beendens einer Telekommunikations-Konferenz; • eine Zeitdauer einer Telekommunikations-Konferenz; • der Inhalt einer Telekommunikations-Konferenz • die Kommunikations-Intensität in einer Telekommunikations-Konferenz, insbesondere der Zeitanteil, in dem gesprochen wird, und/oder die Häufigkeit, mit der der Sprachberechtigte wechselt.
Telekommunikations-Konferenz-Endgerät, • mit einer Telekommunikations-Konferenzeinheit, die eingerichtet ist zur Kommunikation mit anderen Telekommunikations-Konferenz-Endgeräten und/oder einer Telekommunikations-Konferenz-Servereinrichtung in einer Telekommunikations-Konferenz, • mit einem Speicher zum Speichern einer elektronischen Konferenz-Bedingungs-Datei, in der mindestens eine Konferenz-Bedingung hinsichtlich des Erzeugens der Telekommunikations-Konferenz und/oder hinsichtlich der Teilnahme eines oder mehrerer Teilnehmer an der Telekommunikations-Konferenz enthalten ist, • mit einer mit dem Speicher gekoppelten Telekommunikations-Konferenz-Prüfeinheit, die eingerichtet ist zum Prüfen, unter Verwendung der Konferenz-Bedingungs-Datei, ob mindestens eine gespeicherte Konferenz-Bedingung erfüllt ist, • mit einer Telekommunikations-Konferenz-Nachrichten-Erzeugungseinheit, die derart eingerichtet ist, dass sie für den Fall, dass sie von der Telekommunikations-Konferenz-Prüfeinheit eine Information erhält, dass mindestens eine gespeicherte Konferenz-Bedingung erfüllt ist, eine der folgenden Nachrichten erzeugt wird: • eine Konferenzerzeugungs-Anfrage-Nachricht, mit der das Erzeugen einer Telekommunikations-Konferenz beantragt wird, • eine Konferenzbeitritts-Nachricht, mit der der Beitritt des Telekommunikations-Konferenz-Endgeräts zu der Telekommunikations-Konferenz mitgeteilt wird.
Telekommunikations-Konferenz-Servereinrichtung, • mit einer Telekommunikations-Konferenzeinheit, die eingerichtet ist zur Kommunikation mit Telekommunikations-Konferenz-Endgeräten und/oder einer oder mehreren anderen Telekommunikations-Konferenz-Servereinrichtungen in einer Telekommunikations-Konferenz, • mit einem Speicher zum Speichern einer elektronischen Konferenz-Bedingungs-Datei, in der mindestens eine Konferenz-Bedingung hinsichtlich des Erzeugens der Telekommunikations-Konferenz und/oder hinsichtlich der Teilnahme eines oder mehrerer Teilnehmer an der Telekommunikations-Konferenz enthalten ist, • mit einer mit dem Speicher gekoppelten Telekommunikations-Konferenz-Prüfeinheit, die eingerichtet ist für eine Mehrzahl von der Telekommunikations-Konferenz-Servereinrichtung empfangener Telekommunikations-Konferenz-Anfragen zu prüfen, unter Verwendung der Konferenz-Bedingungs-Datei, ob durch Erfüllen der Telekommunikations-Konferenz-Anfragen mindestens eine gespeicherte Konferenz-Bedingung erfüllt ist, und • mit einer Telekommunikations-Konferenz-Erzeugungs-/Steuerungseinheit, die derart eingerichtet ist, dass sie für den Fall, dass bei Erfüllen der Telekommunikations-Konferenz-Anfragen die Konferenz-Bedingung erfüllt ist, die Telekommunikations-Konferenz erzeugt und/oder einen Teilnehmer oder mehrere Teilnehmer der Telekommunikations-Konferenz hinzufügt.
Verfahren zum automatischen Erzeugen und/oder Steuern einer Telekommunikations-Konferenz mit einer Vielzahl von Teilnehmern, wobei in einer elektronischen Konferenz-Bedingungs-Datei, die in einem Teilnehmer-Endgerät eines der Teilnehmer gespeichert ist, mindestens eine Konferenz-Bedingung hinsichtlich des Erzeugens der Telekommunikations-Konferenz und/oder hinsichtlich der Teilnahme eines oder mehrerer Teilnehmer an der Telekommunikations-Konferenz gespeichert ist, • bei dem unter Verwendung der Konferenz-Bedingungs-Datei geprüft wird, ob mindestens eine gespeicherte Konferenz-Bedingung erfüllt ist, und • bei dem für den Fall, dass mindestens eine gespeicherte Konferenz-Bedingung erfüllt ist, die Telekommunikations-Konferenz erzeugt wird und/oder der Teilnehmer oder die Teilnehmer der Telekommunikations-Konferenz hinzugefügt werden.
Verfahren gemäß Anspruch 10, • bei dem Statusinformation über die Telekommunikations-Konferenz einem Teilnehmer-Endgerät übermittelt wird, und • bei dem die Prüfung von dem Teilnehmer-Endgerät durchgeführt wird unter Verwendung der empfangenen Statusinformation.
Verfahren gemäß Anspruch 11, bei dem Statusinformation über die Telekommunikations-Konferenz einem Teilnehmer-Endgerät bei Auftreten eines vorgegebenen Ereignisses übermittelt wird.
Verfahren gemäß Anspruch 12, bei dem Statusinformation über die Telekommunikations-Konferenz einem Teilnehmer-Endgerät bei Auftreten einer Statusänderung der Telekommunikations-Konferenz übermittelt wird.