DE102004026785A1

DE102004026785A1 - Kommunikationssystem, Kommunikationsendgerät, Konferenzsteuereinheit, Verfahren zum Steuern eines Kommunikationssystems, Verfahren zum Steuern eines Kommunikationsendgeräts und Verfahren zum Steuern einer Konferenzsteuereinheit

Info

Publication number: DE102004026785A1
Application number: DE102004026785A
Authority: DE
Inventors: Holger Schmidt; Martin Hans; Mark Beckmann
Original assignee: Infineon Technologies AG
Current assignee: Infineon Technologies AG
Priority date: 2004-06-02
Filing date: 2004-06-02
Publication date: 2006-01-19
Anticipated expiration: 2024-06-03
Also published as: US20060153352A1; CN101621500A; CN1722670A; CN100438418C; DE102004026785B4

Abstract

Es wird ein Kommunikationssystem mit einem Konferenzserver und einer Konferenzsteuereinheit beschrieben, an die eine Call-Control-Protokoll-Nachricht übermittelt wird, die spezifiziert, ob ein Kommunikationsendgerät einer Konferenz hinzugefügt werden soll und/oder eine Konferenz erzeugt werden soll und/oder eine Konferenz beendet werden soll und/oder Informationen über mindestens eine der von dem Konferenzserver bereitgestellten Konferenzen an ein Kommunikationsendgerät übertragen werden sollen.

Description

Die Erfindung betrifft ein Kommunikationssystem, ein Kommunikationsendgerät, eine Konferenzsteuereinheit, ein Verfahren zum Steuern eines Kommunikationssystems, ein Verfahren zum Steuern eines Kommunikationsendgeräts und ein Verfahren zum Steuern einer Konferenzsteuereinheit.
Das 3rd Generation Partnership Project (3GPP) hat einen Standard für die sogenannte Internet-Protokoll-Multimedia-Core Network-Subsystem (IMS)-Architektur entwickelt.
Ein IMS, das heißt ein Kommunikationsnetz gemäß diesem von dem 3GPP entwickelten IMS-Standard, ermöglicht es verschiedene Kommunikationsdienste auf Basis des Internet-Protokolls (IP) einem mobilen Endgerät bereitzustellen.

Solche Kommunikationsdienste sind beispielsweise Voice-over-Internet-Protocol (VoIP), Videotelephonie und Conferencing, beispielsweise Telefonkonferenzen.

Gemäß IMS basiert die Datenübertragung für die Kommunikationsdienste auf dem Internet-Protokoll. Dadurch ist es möglich, Kommunikationsdienste mittels allen paketbasierten Kommunikationssystemen, beispielsweise einem Wireless-Local-Area-Network (W-LAN), dem GPRS (General Packet Radio Service) und dem UMTS (Universal Mobile Telecommunications System) bereitzustellen.

Insbesondere ermöglicht es ein IMS, eine Vielzahl von Kommunikationsdiensten einer breiten Anwenderbasis zugänglich zu machen.

Der (IMS-)Konferenzservice wird neben einem Verfahren zur Rechtevergabe (Floor Control) und der Etablierung von Konferenzregeln (Conference Policy Control Protocol) auch Prozeduren, die auf dem SIP(Session Initiation Protocol) basieren, aufweisen, unter anderem wird er Prozeduren zur Erzeugung, zum Verwalten (Management), zur Beendigung, zum Eintritt und zum Verlassen von Multimedia-Konferenzen bereitstellen.

Weiterhin wird der Konferenzdienst Methoden zur Benachrichtigung der Konferenzteilnehmer über spezifische, die Konferenz betreffende Informationen und Ereignisse (Events) bereitstellen.

Im Rahmen dieses Konferenzservice können Medien verschiedener Art zwischen den Teilnehmern einer Konferenz ausgetauscht werden.

Beispielsweise können Audio-Konferenzen, Video-Konferenzen, Instant-Messaging-Konferenzen, das sind beispielsweise Chat-Konferenzen, und Gaming(Spiel)-Konferenzen bereitgestellt werden.

In [1] wird eine sternförmige Konferenzarchitektur eines Kommunikationssystems beschrieben, in der alle Konferenzteilnehmer mit einem Konferenzsteuerprogramm, das die Konferenz steuert und das auf einem so genannten (Conference)-Focus ausgeführt wird, mittels Signalisierungsverbindungen gekoppelt sind. Der Focus stellt somit eine logische Einheit im IMS dar.

Einer bestimmten Konferenz, die einem bestimmten Focus zugeordnet ist, das heißt von ihm gesteuert und ausgeführt wird, ist eine Konferenzadresse, welche hier als C-URI (Conference Uniform Ressource Indicator) bezeichnet wird, zugeordnet.

Die Konferenzadresse repräsentiert die Konferenz und ein Nutzer des Kommunikationssystems kann unter der Verwendung der Konferenzadresse beispielsweise der Konferenz beitreten.

Der Focus hat unter anderem Zugriff auf die Konferenzregeln (Conference Policy), welche ein CPS (Conference Policy Server) verwaltet.

Neben der Umsetzung der Konferenzregeln hat der Focus die Aufgabe für die konferenzspezifische Verteilung der Medieninhalte an die Konferenzteilnehmer zu sorgen.

Hierzu verwendet der Focus so genannte Mixer, welche gemäß den Medienregeln (Media Policy), welche ein Teil der Konferenzregeln sind, mittels des Focus gesteuert werden und welche die individuelle Zusammenstellung und die Verteilung der Medieninhalte an die Konferenzteilnehmer ausführen.

In [2] ist ein Verfahren zur Erzeugung (Create) einer Konferenz und zum Eintritt (Join) in eine Konferenz unter Verwendung der Adresse des Focus, die im Folgenden auch als Conference-URI oder C-URI bezeichnet wird, spezifiziert.

Dieses Verfahren weist das Risiko einer Kollision auf, wenn Bereiche von Konferenzadressen reserviert werden.

Dies äußert sich derart, dass ein Nutzer, der eine neue Konferenz erzeugen möchte, möglicherweise zu einer bereits bestehenden Konferenz hinzugefügt wird, anstatt dass eine neue Konferenz erzeugt wird, wie im Folgenden genauer erläutert wird.

Zur Erzeugung einer Konferenz werden in [2] zwei SIP-Prozeduren, das heißt zwei auf dem SIP basierende Prozeduren spezifiziert.

Gemäß dem ersten Verfahren sendet der Nutzer, der die Konferenz erzeugen will, eine "SIP INVITE" Nachricht, wie es in [3] beschrieben ist, an die Conference-Factory-URI.

Die Conference-Factory-URI ist die Adresse eines Konferenzservers, das heißt eines Servers, der Konferenzen mit zugehörigem Focus erstellen und verwalten kann.

Gemäß [4] resultiert der erfolgreiche Aufbau einer SIP Session mit dem Konferenzserver in der Erzeugung eines Focus, einer diesem zugeordneten C-URI und somit einer Konferenz.

Gemäß dem zweiten in [2] spezifizierten Verfahren zur Erzeugung einer Konferenz wird eine zuvor reservierte C-URI verwendet.

Zu einer reservierten C-URI existiert in diesem Fall auch ein dieser Adresse zugeordneter Focus. Zur Erzeugung einer Konferenz sendet der Nutzer unter Verwendung der C-URI wie oben eine "SIP-INVITE"-Nachricht in diesem Fall direkt an den Focus.

Gemäß [2] wird nach dem Erhalt dieser Nachricht eine Konferenz erzeugt, wenn diese noch nicht existiert. Damit werden die für eine Konferenz erforderlichen Ressourcen reserviert und anschließend freigeschaltet.

Falls ein Nutzer in eine bereits bestehende Konferenz eintreten möchte, sendet der Nutzer bzw. das von ihm verwendete Endgerät ebenfalls eine "SIP- INVITE" Nachricht an die C-URI. Der dieser C-URI zugeordnete Focus fügt den Nutzer nach Erhalt dieser Nachricht der bereits bestehenden und mittels der C-URI spezifizierten Konferenz hinzu.

Aus der Sicht des Nutzers besteht zwischen dem Verfahren zur Erzeugung einer Konferenz und dem Verfahren zum Eintritt in eine Konferenz kein Unterschied (vergleiche [2]).

Für den Focus besteht ein Unterschied darin, dass er eine reservierte Konferenz aktiviert oder einen Nutzer einer bestehenden Konferenz hinzufügt.

Es ist möglich, was auch in [4] beschrieben ist, dass ganze Adressbereiche für Konferenzen reserviert werden, beispielsweise eine komplette Domain (beispielsweise conf.vodafone.com) oder Subdomains (beispielsweise der Adressbereich von conference1@conf.vodafone.com bis conference9999@conf.vodafone.com).

Diese reservierten Adressbereiche können für Konferenzen verwendet werden.

In diesem Fall kann es allerdings zu Kollisionen kommen. Ist bereits eine Konferenz mit einer spezifischen C-URI (beispielsweise conference666@conf.vodafone.com) von einem Nutzer aktiviert, das heißt erzeugt, worden, so führt der Versuch eines anderen Nutzers eine Konferenz mit demselben Namen bzw. C-URI zu erzeugen dazu, dass dieser Nutzer der bereits unter diesem Namen bzw. Adresse existierenden Konferenz hinzugefügt wird.

Auf diese Weise entstehen Kollisionen zwischen der Konferenzerzeugung (Create) und dem Beitritt zu einer bestehenden Konferenz (Join).

Es existiert weiterhin kein Verfahren zur Abfrage der von einem Konferenz-Server verwalteten und bereitgestellten Konferenzen mittels auf SIP basierenden Prozeduren.

Ferner ist es gemäß der derzeitigen Spezifikation des IMS-Konferenzservice (siehe [2]) an Hand der "SIP- INVITE" Nachricht nicht möglich zu unterscheiden, ob ein Konferenzteilnehmer eine Konferenz verlassen möchte oder ob er die gesamte Konferenz beenden möchte.

Eine Beendigung einer Konferenz durch einen Nutzer würde bedeuten, dass alle Teilnehmer aus der Konferenz entfernt werden. Dies ist gleichbedeutend mit der Auflösung der Signalisierungsverbindung (SIP Session) zwischen den Konferenzteilnehmern und dem Focus.

Gemäß dem in [2] beschriebenen Stand der Technik wird eine Konferenz jedoch erst beendet, wenn alle Teilnehmer die Konferenz verlassen haben. Dies ist insbesondere dann von Nachteil, wenn ein Nutzer eine Konferenz erzeugt hat und für diese die Kosten übernimmt aber nicht sicherstellen kann, dass, wenn er die Konferenz verlässt, die Konferenz auch wirklich beendet wird.

In [1], [2] und [4] ist ein Verfahren zur Beendigung der Teilnahme eines Nutzers an einer Konferenz mittels SIP Nachrichten beschrieben worden.

Dazu wird der SIP Dialog und damit die SIP Session zwischen dem Konferenzteilnehmer und dem Focus mittels einer "SIP-BYE" Nachrichtbeendet.

Auf diese Weise ist, wie oben erwähnt wurde, bisher nur die Beendigung der Konferenzteilnahme eines einzelnen Konferenzteilnehmers möglich, die Konferenz aber besteht i.a. weiterhin, wenn noch weitere Teilnehmer in der Konferenz vorhanden sind.

Es kann zwar i.a. eine entsprechende Konferenzregel (Conference Policy) vorgegeben werden, die besagt, dass die gesamte Konferenz beendet wird, sobald ein bestimmter Teilnehmer die Konferenz verlassen hat, es ist jedoch kein auf dem SIP basierendes Verfahren zur Beendigung einer Konferenz bekannt (vergleiche [1]).

Diese Möglichkeit der Beendigung einer Konferenz unter Verwendung einer Konferenzregel setzt voraus, dass der die Konferenz erzeugende Benutzer die Konferenzregeln beeinflussen kann oder dass diese mit geeigneten Standardwerten initialisiert werden.

Dies ist gemäß dem IMS-Standard jedoch nicht in allen Fällen gegeben.

Die Unterstützung des CPCP (Conference Policy Control Protocol), das heißt des Protokolls zur Manipulation der Konferenzregeln, ist gemäß [2] nur optional.

Selbst wenn ein Benutzer dieses Protokoll unterstützt, das heißt das Protokoll in dem vom Benutzer verwendeten Kommunikationsendgerät implementiert ist, kann er das CPCP gemäß der IMS-Rel-6-Architektur prinzipiell nur einsetzen, wenn die Konferenz in seinem H-PLMN (Home Public Public Land Mobile Network), das heißt in seinem Heimatnetzwerk, erzeugt wurde.

Im Allgemeinen wird eine Konferenz also nur beendet, wenn, wie oben erwähnt, alle Teilnehmer der Konferenz die Konferenz verlassen haben.

Dies ist nicht nur aus Tarifierungsgründen, wie oben beschrieben, besonders nachteilig, sofern ein Nutzer die Konferenz bezahlt, sondern auch in Hinblick auf die Vollständigkeit der SIP-Prozeduren und der SIP-Funktionalität innerhalb des Konferenzdienstes des IMS.

In [5] ist ein Verfahren beschrieben, mittels welchem ein Nutzer, bzw. der von dem Nutzer verwendete UAC (User Agent Client), Präferenzen angeben kann, wie seine Anfrage behandelt werden soll.

Hierbei können zwei Typen von Präferenzen unterschieden werden.

Präferenzen des ersten Typs werden als "Request-Handling-Preferences" bezeichnet und geben dem Server spezielle Anweisungen, wie die Anfrage (Request) zu behandeln ist.

Diese Anweisungen geben beispielsweise an, dass die Anfrage gleichzeitig an unterschiedliche Kontaktadressen und damit Kommunikationsendgeräte eines von dem Benutzer angerufenen Teilnehmers geleitet werden soll, was als "forking" bezeichnet wird, oder dass die unterschiedlichen Kontaktadressen nacheinander kontaktiert werden sollen, was als "search sequentially" bezeichnet wird.

Die Anweisungen werden hierbei in dem Nachrichtenkopffeld (Header) mit der Bezeichnung "Request-Disposition" einer SIP Anfrage (SIP-Request) übertragen.

Präferenzen des zweiten Typs werden als "Feature-Preferences" bezeichnet und ermöglichen es dem Nutzer, der einen SIP Request sendet, einen Satz von Features anzugeben, der beschreibt, welche Eigenschaften der UA (User Agent) des angerufenen Teilnehmers aufweisen soll.

Ein SIP fähiges Kommunikationsendgerät, dass SIP Anfragen sendet (SIP Requests) und auf Anfragen mit SIP Antworten (SIP Responses) antwortet, wird als SIP UA (User Agent) bezeichnet. Ein UA weist also einen UAC (User Agent Client), der Anfragen senden kann, und einen UAS (User Agent Server), der Anfragen beantworten kann, auf. Im Folgenden wird vorausgesetzt, dass jedes Kommunikationsendgerät einen UA enthält.

Zur Übertragung von Feature-Preferences werden das Nachrichtenkopffeld mit der Bezeichnung "Accept-Contact" und das Nachrichtenkopffeld mit der Bezeichnung "Reject-Contact" verwendet.

Die Angabe der Eigenschaften bzw. der Feature-Preferences erfolgt mittels so genannter "Feature Tags", das heißt mittels bestimmter Kennzeichen (Tags) in den genannten Nachrichtenkopffeldern.

In [6] werden verschiedene Basis-Tags (Base Tags) spezifiziert.

Es ist jedoch im Rahmen des IETF-Standards zulässig weitere Tags zu definieren.

Die Auswertung der angegebenen Eigenschaften kann gemäß [5] sowohl von einem speziellen SIP Server, dem SIP-Registrar, bei dem sich Nutzer, die das IMS nutzen möchten, anmelden bzw. registrieren, als auch von einem UAS selbst durchgeführt werden.

Ein UA kann seine Eigenschaften mittels der Parameter des Nachrichtenkopffeldes mit der Bezeichnung "Contact-Header" zum SIP-Registrar oder zu einem anderen UA übertragen.

Während des Aufbaus einer Session können somit die von einem anrufenden Nutzer geforderten Eigenschaften mit den Eigenschaften des jeder Kontaktadresse des angerufenen Nutzers zugeordneten UA vom SIP-Registrar miteinander verglichen werden.

Anschließend wird derjenige UA (und die entsprechende Kontaktadresse) ausgewählt, dessen Eigenschaften den von dem anrufenden Nutzer geforderten Eigenschaften am besten entsprichen.

Zu dieser Kontaktadresse wird die Anfrage des anrufenden Nutzers weitergeleitet.

In [1], [2] und [4] wird dieses Verfahren zur Angabe verwendet, dass ein UA ein Focus ist. Hierzu fügt der UA das in [6] angegebene Feature-Tag mit der Bezeichnung "isfocus", welches ein Base-Tag ist, als Parameter in das Contact- Header-Nachrichtenkopffeld einer SIP-Nachricht, die an einen anderen UA übertragen wird, ein. Der andere UA, der die SIP-Nachricht mit dem entsprechenden "Contact-Header" empfängt, erkennt, dass der UA, der die SIP-Nachricht geschickt hat, ein Focus ist und entsprechende Funktionen aufweist.

In [7] ist die sogenannte SIP-REFER-Methode beschrieben, mittels welcher, wie auch in [1] und [2] beschrieben, ein Konferenzteilnehmer einen Focus auffordern kann eine innerhalb einer REFER-Nachricht angegebene SIP-Nachricht, beispielsweise eine BYE-Nachricht oder eine INVITE-Nachricht, wie sie weiter unten beschrieben werden, an eine in der REFER-Nachricht angegebene Adresse, z.B. in Form einer SIP URI, zu senden.

Mittels der SIP-REFER Nachricht kann der Focus von einem Konferenzteilnehmer beispielsweise aufgefordert werden eine SIP-INVITE Nachricht an einen bestimmen Nutzer bzw. dessen UA zu senden. Dieser Nutzer wird auf diese Weise aufgefordert in die Konferenz einzutreten.

Der Nutzer wird somit von dem Konferenzteilnehmer eingeladen, der die REFER-Nachricht an den Focus gesendet hat.

In [8] sind die Architektur und die Prozeduren des IMS beschrieben (Stage 2).

In [9] ist ein Konferenzverwaltungsprogramm beschrieben, dass einen Dienst zur bedingten Beendigung von Konferenzen bereitstellt.

Der Erfindung liegt das Problem zu Grunde, Kollisionen beim Erzeugen von Konferenzen und beim Eintritt in Konferenzen zu vermeiden, die Abfrage von Informationen über die von einem Konferenzserver verwalteten Konferenzen zu ermöglichen, sowie die Beendigung einer Konferenz durch einen Nutzer mittels SIP Nachrichten zu ermöglichen.

Die Aufgabe wird durch ein Kommunikationssystem, ein Kommunikationsendgerät, eine Konferenzsteuereinheit, ein Verfahren zum Steuern eines Kommunikationssystems, ein Verfahren zum Steuern eines Kommunikationsendgeräts und ein Verfahren zum Steuern einer Konferenzsteuereinheit mit den Merkmalen gemäß den unabhängigen Patentansprüchen gelöst.

Es wird ein Kommunikationssystem bereitgestellt, das einen Konferenzserver, eine Konferenzsteuereinheit und mindestens ein Kommunikationsendgerät aufweist, wobei der Konferenzserver eingerichtet ist, mindestens eine Konferenz für eine Mehrzahl von Kommunikationsendgeräten bereitzustellen; das mindestens eine Kommunikationsendgerät eine Nachrichtenerzeugungseinheit aufweist, die eingerichtet ist, eine Call-Control-Protokoll-Nachricht zu erzeugen, welche Call-Control-Protokoll-Nachricht Steuerinformation enthält, die spezifiziert, ob das mindestens eine Kommunikationsendgerät einer Konferenz hinzugefügt werden soll und/oder eine Konferenz erzeugt werden soll und/oder eine Konferenz beendet werden soll und/oder Informationen über mindestens eine der von dem Konferenzserver bereitgestellten Konferenz an das mindestens eine Kommunikationsendgerät übertragen werden sollen; die Konferenzsteuereinheit eine Ermittlungsvorrichtung aufweist, die eingerichtet ist, aus der Nachricht die Steuerinformation zu ermitteln; die Konferenzsteuereinheit eine Steuervorrichtung aufweist, die eingerichtet ist, gemäß der ermittelten Steuerinformation das mindestens eine Kommunikationsendgerät einer Konferenz hinzuzufügen und/oder eine Konferenz zu erzeugen und/oder eine Konferenz zu beenden und/oder Informationen über mindestens eine der von dem Konferenzserver bereitgestellten Konferenz an das mindestens eine Kommunikationsendgerät zu übertragen.

Ferner werden ein Kommunikationsendgerät, eine Konferenzsteuereinheit, ein Verfahren zum Steuern eines Kommunikationssystems, ein Verfahren zum Steuern eines Kommunikationsendgeräts und ein Verfahren zum Steuern einer Konferenzsteuereinheit gemäß dem oben beschriebenen Kommunikationssystem bereitgestellt.

In einer Ausführungsform realisiert die Konferenzsteuereinheit einen Focus.

In einer anderen Ausführungsform ist die Konferenzsteuereinheit ein Teil des Konferenzservers.

Anschaulich kann die Erfindung darin gesehen werden, dass die gemäß Standards für Kommunikationssysteme, beispielsweise dem IETF- oder dem 3GPP-Standard, zulässigen Signalisierungsmöglichkeiten verwendet werden oder im Rahmen des Standards zulässig erweitert werden, um eine gegenüber dem Standard neue Funktionalität zu erreichen.

Mittels der Erfindung ist es insbesondere möglich, die oben beschriebene Kollision zwischen dem Erzeugen einer neuen Konferenz und dem Beitritt zu einer bestehenden Konferenz aufzulösen, da mittels der Steuerinformation spezifiziert ist, ob der Nutzer an einer existierenden Konferenz teilnehmen möchte oder eine neue Konferenz erzeugen möchte.

Ferner ist es möglich Informationen über die von einem Konferenzserver verwalteten Konferenzen unter Verwendung eines Kommunikationsendgeräts abzufragen.

Ferner ist es möglich, dass ein Nutzer eine Konferenz beendet, und insbesondere, dass der Nutzer die Beendigung einer Konferenz explizit anweist. Diese Funktionalität ist besonders dann wichtig, wenn der Nutzer der Erzeuger einer Konferenz ist und für die Konferenz zeitbasiert bezahlen muss.

Bevorzugte Weiterbildungen der Erfindung ergeben sich aus den abhängigen Ansprüchen. Die weiteren Ausgestaltungen der Erfindung, die im Zusammenhang mit dem bereitgestellten Kommunikationssystem beschrieben sind, gelten sinngemäß auch für das bereitgestellte Kommunikationsendgerät, die Konferenzsteuereinheit, das bereitgestellte Verfahren zum Steuern eines Kommunikationssystems, das bereitgestellte Verfahren zum Steuern eines Kommunikationsendgeräts und das bereitgestellte Verfahren zum Steuern einer Konferenzsteuereinheit.

Es wird bevorzugt, dass die Call-Control-Protokoll-Nachricht gemäß dem SIP-Protokoll ausgestaltet ist.

In diesem Fall kommunizieren bei einer bereitgestellten Konferenz eine Mehrzahl von Kommunikationsendgeräten, die verschiedene Daten, beispielsweise in Form eines Chats oder eines Video-Streamings, austauschen. Die Gesamtheit der mittels des SIP Protokolls aufgebauten Medienströme wird auch als Multimedia-Session bezeichnet.

In einer Ausführungsform ist die Steuerinformation in Form eines Feature-Tags in der Call-Control-Protokoll-Nachricht enthalten.

In einer Ausführungsform ist das Kommunikationssystem gemäß einem 3GPP-Standard ausgestaltet.

In einer Ausführungsform ist das Feature-Tag ein in dem IETF-Standard oder dem 3GPP-Standard vorgesehenes Feature-Tag.

In einer weiteren Ausführungsform ist das Feature-Tag ein gegenüber dem IETF-Standard oder gegenüber dem 3GPP-Standard neu definiertes Feature-Tag.

Beispielsweise wird ein gegenüber dem IETF und dem 3GPP-Standard neues Feature-Tag, beispielsweise mit der Bezeichnung "Join" oder "Create" zur Auflösung der Kollision bei der Erzeugung einer Konferenz und zum Beitritt in eine bereits bestehende Konferenz verwendet.

In einem anderen Ausführungsbeispiel wird ein gegenüber dem IETF bzw. 3GPP-Standard neues Feature Tag, beispielsweise mit der Bezeichnung "Terminate" oder "Continue" zur Unterscheidung, ob ein Konferenzteilnehmer die Konferenz verlassen oder beenden möchte, verwendet.

In einem anderen Ausführungsbeispiel wird ein gegenüber dem IETF bzw. 3GPP-Standard neues Feature-Tag zur impliziten Abfrage von Informationen über die von einem Conference-Server verwalteten Konferenzen verwendet.

Vorzugsweise ist das Feature-Tag in dem Accept-Contact-Nachrichtenkopffeld oder in dem Reject-Contact-Nachrichtenkopffeld der Call-Control-Protokoll-Nachricht enthalten.

Beispielsweise wird zur Auflösung der Kollision bei der Erzeugung einer Konferenz und zum Beitritt in eine bereits bestehende Konferenz eine Nachricht von dem Kommunikationsendgerät erzeugt, die das gemäß dem IETF bzw. 3GPP-Standard vorgesehene isfocus-Feature-Tag im Accept-Contact-Nachrichtenkopffeld oder im Reject-Contact-Nachrichtenkopffeld enthält.

In einem anderen Ausführungsbeispiel wird das isfocus-Feature-Tag im Accept-Contact-Nachrichtenkopffeld oder im Reject-Contact-Nachrichtenkopffeld zur Unterscheidung, ob ein Konferenzteilnehmer die Konferenz verlassen oder beenden möchte verwendet.

Es wird bevorzugt, dass die Steuerinformation in Form einer Referenzierung in der Call-Control-Protokoll-Nachricht enthalten ist.

Beispielsweise wird zur Signalisierung, dass eine Konferenz beendet werden soll, von dem Kommunikationsendgerät eine SIP REFER-Nachricht erzeugt und an die C-URI gesendet, in der die C-URI der zu beendenden Konferenz und die Zeichenkette "method=BYE" im Refer-To-Nachrichtenkopffeld enthalten sind.

Ferner wird bevorzugt, dass die Referenzierung mindestens einen Platzhalter aufweist.

Beispielsweise wird zur Signalisierung, dass eine Konferenz beendet werden soll, von dem Kommunikationsendgerät eine REFER-Nachricht erzeugt und an die C-URI gesendet, die Platzhalter (Wildcards, z.B. "*" oder "?") und die Zeichenkette "method=BYE" enthält, so dass mittels des Refer-To-Nachrichtenkopffeldes der REFER-Nachricht alle Kommunikationsendgeräte mit Adressen aus einem bestimmten Adressbereich referenziert werden. Auf diese Weise wird angegeben, dass diese referenzierten Kommunikationsendgeräte nicht weiter an einer zu beendenden Konferenz teilnehmen sollen. Dies resultiert bei geeigneter Wahl des Adressbereichs in der impliziten Beendigung der Konferenz.

Anschaulich bewirkt das Senden einer Nachricht, die eine Referenzierung mit Platzhaltern enthält, an den Focus, dass eine dem Wert eines Parameters "method" entsprechende Nachricht, beispielsweise eine BYE-Nachricht an alle Kommunikationsendgeräte, die an der Konferenz teilnehmen, gesendet wird, wodurch die Kommunikationsendgeräte angewiesen werden, die Konferenz zu verlassen und somit implizit die Konferenz beendet wird.

In einer anderen Ausführungsform wird der Konferenzserver selbst mittels des Refer-to-Nachrichtenkopffeldes referenziert, wodurch er angewiesen wird die Konferenz zu beenden.

Vorzugsweise weist die Referenzierung eine oder mehrere Parameterwerte auf.

Beispielsweise wird zur Singalisierung, dass eine Konferenz beendet werden soll, von dem Kommunikationsendgerät eine REFER-Nachricht erzeugt, die neben der Angabe der C-URI im Refer-To-Nachrichtenkopffeld mittels der Zeichenkette "method=BYE" den Wert "BYE" des Parameters "method" enthält sowie einen zusätzlichen Parameter in Form einer Zeichenkette, beispielsweise "terminate".

Vorzugsweise ist die Referenzierung in dem Refer-to-Nachrichtenkopffeld enthalten.

In einer alternativen Ausführungsform ist die Call-Control-Protokoll-Nachricht gemäß dem H.323-Protokoll ausgestaltet.

Es ist bevorzugt, dass die von dem Konferenzserver mindestens eine bereitgestellte Konferenz eine Multimedia-Konferenz, beispielsweise eine Audio-Konferenz, eine Video-Konferenz, eine Instant-Messaging-Konferenz, z.B. eine Chat-Konferenz, oder eine Gaming(Spiel)-Konferenz, ist.

Ausführungsbeispiele der Erfindung sind in den Figuren dargestellt und werden im Weiteren näher erläutert.
1 zeigt ein Kommunikationssystem gemäß einem Ausführungsbeispiel der Erfindung;
2 zeigt ein Nachrichtenflussdiagramm gemäß einem Ausführungsbeispiel der Erfindung;
3 zeigt ein Nachrichtenflussdiagramm gemäß einem Ausführungsbeispiel der Erfindung;
4 zeigt ein Nachrichtenflussdiagramm gemäß einem Ausführungsbeispiel der Erfindung.
1 zeigt ein Kommunikationssystem 100 gemäß einem Ausführungsbeispiel der Erfindung.
Das Kommunikationssystem 100 ist gemäß de von 3GPP beschriebenen UMTS-Arichtektur ausgeführt, deren integraler Bestandteil das IMS, siehe beispielsweise [8], ist.
Ein Kommunikationsendgerät 101 ist mittels eines Zugangsnetzes 102 mit einem IMS 111 gekoppelt.
Das Zugangsnetz 102 kann beispielsweise ein Mobilfunkkommunikationsnetzwerk gemäß dem UMTS-Standard, d.h. ein Universal Terrestrial Access Network, das mittels einer Packet-Switched-Domain den Zugang des Kommunikationsendgeräts zum IMS 111 ermöglicht, oder ein Zugangsnetz gemäß dem GSM-Standard, d.h. ein GSM EDGE Radio Access Network, sein.
Das Zugangsnetz 102 kann auch ein Festnetz sein, beispielsweise kann das Kommunikationsendgerät 101 eine Vorrichtung aufweisen, die einen Zugang zu dem Internet erlaubt, beispielsweise ein DSL(Digital Subscriber Line)-Modem. In diesem Beispiel ist das Kommunikationsendgerät mittels dem Internet mit dem IMS 111 gekoppelt.
Entsprechend der Ausgestaltung des Zugangsnetzes 102 ist das Kommunikationsendgerät 101 beispielsweise ein Mobiltelefon oder ein Computer mit oder ohne Mobilfunkmodul.
In diesem Ausführungsbeispiel ist das Zugangsnetz 102 ein Mobilfunk-Kommunikationssystem gemäß dem UMTS-Kommunikationsstandard.
Ein Mobilfunknetz 112 des Zugangsnetzes 102 weist die Architektur eines UMTS-Funknetzes, das auch als UMTS-Terrestrial-Radio-Access-Network (UTRAN) bezeichnet wird, auf.
Das Zugangsnetz weist eine PS-Domain 140 auf, die aus den Komponenten SGSN (Serving GPRS Support Node), GGSN (Gateway GPRS Support Node) besteht und die Schnittstelle für paketvermittelte Verbindungen zwischen dem Mobilfunknetz 112 und externen paketbasierten Datennetzen, wie beispielsweise dem Internet, bildet und den Zugang zum IMS 111 realisiert.
Entsprechend führt die PS-Domain 140 alle Funktionen aus, um den Transport von paketvermittelten Daten zu gewährleisten.
Weiterhin ermöglicht es den Transport von Signalisierungsnachrichten zum IMS.
Das Zugangsnetz weist ferner ein HLR 141 auf, das eine zentrale Datenbank ist, in der alle Informationen von Teilnehmern gespeichert sind, die unter anderem zum Verbindungsaufbau und zur Führung von Diensten erforderlich sind.
Mittels des Zugangsnetzes 102 ist das Kommunikationsendgerät 102 mit einem P-CSCF (CSCF: Call Session Control Function, P-CSCF: Proxy-CSCF) 103 des IMS 111 gekoppelt.
Der P-CSCF 103 dient als Vermittlungsstelle und ist mit einem DNS (Domain Name Server) 104 und einem I-CSCF (Interrogating-CSCF) 105 gekoppelt.
Der I-CSCF 105 ist mit einem HSS 106 (Home Subscriber Server) 106 und einem S-CSCF (Serving-CSCF) 107 gekoppelt.
Der S-CSCF 107 ist mit einer Mehrzahl von Anwendungsservern (AS, Applikation Server) gekoppelt, von denen nur ein Anwendungsserver 138 dargestellt ist.
Der S-CSCF 107 ist ferner mit einem MRFC (Media Resource Function Controller) 142 gekoppelt.
Mittels des Anwendungsservers 138 und dem MRFC 142 sind ein Konferenzserver und mindestens ein Focus realisiert.
Das Kommunikationsendgerät 101, das Zugangsnetz 102, der P-CSCF 103 und der DNS 104 sind Teile des besuchten Netzwerks (V-PLMN) 109.
Der I-CSCF 105, das HSS 106, der S-CSCF 107 und der Anwendungsserver AS 138 sind Teile des Heim-Kommunikationsnetzwerks (H-PLMN) 108.
Der P-CSCF 103, der I-CSCF 105, der HSS 106 und der S-CSCF 107 sind ein Teil des IMS (IP Multimedia Core Network Subsystem) 111, wie beispielsweise in [8] beschrieben.
Mittels des Kommunikationsendgeräts 101 kann ein Nutzer die Kommunikationsdienste des IMS 111 nutzen, beispielsweise eine " Instant-Message" an ein weiteres mit dem Kommunikationssystem 100 gekoppeltes Kommunikationsendgerät senden oder eine Konferenz mit Nutzern anderer mit dem Kommunikationssystem 100 gekoppelter Kommunikationsendgeräte durchführen.
2 zeigt ein Nachrichtenflussdiagramm 200 gemäß einem Ausführungsbeispiel der Erfindung.
Der in 2 dargestellte Nachrichtenfluss findet zwischen einem Kommunikationsendgerät 201, einem P-CSCF 202, welche Teil eines besuchten Netzwerks 203 sind, einem S-CSCF 204, welcher Teil des Heimnetzwerks des Kommunikationsendgeräts 205 ist und einem Anwendungsserver 206, welcher Teil des Heimnetzwerks des Anwendungsservers 207 ist, statt. Der Anwendungsserver wird im Folgenden in Kombination mit einem MRFC gesehen.
Der Anwendungsserver 206 hat in diesem Ausführungsbeispiel die Funktion eines Konferenzserver und mindestens eines Focus.
Das mit Bezug auf 2 beschriebene Ausführungsbeispiel wird dazu verwendet, die oben beschriebenen Kollision zwischen der Erzeugung einer Konferenz unter Verwendung einer C-URI und dem Beitritt zu einer bereits bestehenden Konferenz unter Verwendung einer C-URI aufzulösen.
In Schritt 208 sendet der Nutzer des Kommunikationsgeräts 201 mittels des Kommunikationsgeräts 201 eine SIP "INVITE" Nachricht mittels des P-CSCF 202 an die C-URI und somit an den AS 206. Dabei wird die INVITE-Nachricht in den folgenden Schritten mittels der dargestellten Netzwerkelemente zum AS 206 geleitet.
Die INVITE-Nachricht ist gemäß Tabelle 1 ausgestaltet.

Tabelle 1 (SDP (Session Description Protocol) nicht gezeigt)
Insbesondere weist die INVITE-Nachricht ein Nachrichtenkopffeld mit der Bezeichnung "Accept-Contact" auf und das "isfocus"-Feature-Tag ist gesetzt (siehe Zeile 18 von Tabelle 1).
In Schritt 209 leitet der P-CSCF 202 unter Verwendung der in der INVITE-Nachricht angegebenen C-URI (siehe Zeile 9 von Tabelle 1) die INVITE-Nachricht an den S-CSCF 204 weiter.
In Schritt 210 leitet der S-CSCF 204 unter Verwendung der in der INVITE-Nachricht angegebenen C-URI die INVITE-Nachricht an den Anwendungsserver 206 weiter, der den angegebenen C-URI entsprechenden Focus 216 bereitstellt.
In Schritt 211 prüft der Focus 216, ob die INVITE-Nachricht das isfocus-Feature-Tag aufweist.
Weist die INVITE-Nachricht das isfocus-Feature-Tag auf, so wird der Focus 216 angewiesen, eine der angegebenen C-URI entsprechende Konferenz zu erzeugen bzw. zu aktivieren.
Weist die INITE-Nachricht das isfocus-Feature-Tag nicht auf, so wird der Focus 216 angewiesen, den Nutzer zu der mittels der C-URI angegebenen Konferenz hinzuzufügen.
Da in diesem Beispiel die INVITE-Nachricht das isfocus-Feature-Tag aufweist, wird der Focus 216 angewiesen, die angegebene Konferenz zu aktivieren bzw. zu erzeugen.
Somit signalisiert das Kommunikationsendgerät 201 unter Verwendung des isfocus-Feature-Tags dem Focus 216, dass es selber eine reservierte Konferenz aktivieren möchte und nicht einer bestehenden Konferenz hinzugefügt werden möchte.
In Schritt 212 prüft der Focus 216, ob eine ihm zugeordnete und der C-URI entsprechende Konferenz bereits erzeugt wurde.
In diesem Beispiel wird angenommen, dass die der C-URI, welche conference666@mrfc2.home2.net (siehe Tabelle 1) ist, entsprechende Konferenz bereits zuvor von einem anderen Nutzer aktiviert wurde und daher bereits verwendet wird.
Der Focus 216 fügt das Kommunikationsendgerät 201 somit nicht zu der bereits bestehenden Konferenz hinzu, sondern er antwortet dem Kommunikationsendgerät 201 mit einer Fehlermeldung in Form einer SIP "4xx" Nachricht, die in Schritt 213 an den S-CSCF 204 übertragen wird.
In Schritt 214 leitet der S-CSCF 204 die 4xx-Nachricht an den P-CSCF 202 weiter, welcher die 4xx-Nachricht in Schritt 215 an das Kommunikationsendgerät 201 überträgt.
Das Kommunikationsendgerät 201 kann nun eine andere C-URI in dem für Konferenzen reservierten Adressbereich auswählen, um eine neue Konferenz zu erzeugen. Mit dieser neu ausgewählten C-URI kann das Kommunikationsendgerät 201 anschließend einen neuen Versuch zur Erzeugung und Aktivierung einer Konferenz durchführen.
Die Verwendung des isfocus-Feature-Tags ermöglicht somit die Unterscheidung, ob der Nutzer eine Konferenz erzeugen will oder einer bereits bestehenden Konferenz beitreten will.
In einer anderen Ausführungsform setzt das Kommunikationsendgerät das isfocus-Feature-Tag in dem Accept-Contact-Nachrichtenkopffeld, wenn der Benutzer der mittels der C-URI angegebenen Konferenz beitreten will.
In einer anderen Ausführungsform wird ein gegenüber dem Standard neu definiertes Feature-Tag definiert, das wie das isfocus-Feature-Tag wie oben beschrieben verwendet wird.
Beispielsweise wird ein "Join"-Feature-Tag oder ein "Create"-Feature-Tag definiert, wobei das Kommunikationsendgerät das Create-Feature-Tag in dem Accept-Contact-Nachrichtenkopffeld setzt, das heißt einfügt, wenn der Nutzer einer der angegebenen C-URI entsprechenden Konferenz erzeugen will und das Join-Feature-Tag in dem Accept-contact-Nachrichtenkopffeld setzt, wenn der Nutzer der der angegebenen C-URI entsprechenden Konferenz beitreten will.
In einer anderen Ausführungsform wird anstatt des Accept-Contact-Nachrichtenkopffeldes das Reject-Contact-Nachrichtenkopffeld verwendet.
Mit diesem Nachrichtenkopffeld wird, wie oben erläutert, gemäß [5] spezifiziert, welche Eigenschaften ein UA nicht aufweisen soll. Das Reject-Contact-Nachrichtenkopffeld kann analog zu dem Accept-Contact-Nachrichtenkopffeld verwendet werden, beispielsweise kann, wenn der Nutzer einer Konferenz beitreten will, die in Schritt 208 übertragene Nachricht derart ausgestaltet sein, dass sie ein Reject-Contact- Nachrichtenkopffeld aufweist, in dem das isfocus-Feature-Tag gesetzt ist.
Analog können die oben erwähnten Alternativen unter Verwendung des Reject-Contact-Nachrichtenkopffeldes eingesetzt werden.
Bei Verwendung des Reject-Contact-Nachrichtenkopffeldes weist die Verwendung von gegenüber dem Standard neu definierten Feature-Tags Vorteile auf, da auf diese Weise Mehrdeutigkeiten vermieden werden.
Die mit Bezug auf 2 beschriebene Ausführungsform kann, wenn sie leicht abgeändert wird, auch dazu verwendet werden, unter Verwendung von SIP-Prozeduren Informationen über die vcn einem Konferenzserver verwalteten Konferenzen abzufragen. In diesem Fall wird die Nachricht allerdings an die Conference Factory URI gesendet.
In der im Folgenden beschriebenen Ausführungsform wird hierzu ein gegenüber dem Standard neu definiertes Feature-Tag mit der Bezeichnung "fetch" verwendet.
Der Nachrichtenfluss in dieser Ausführungsform ist analog zu der mit Bezug auf 2 beschriebenen Ausführungsform.
Weist die INVITE-Nachricht im Accept-Contact-Nachrichtenkopffeld, die in diesem Fall an den Anwendungsserver 206 und nicht wie oben direkt an einen von dem Anwendungsserver 206 erzeugten Focus 216, geschickt wird, das fetch-Feature-Tag auf, so erzeugt der Anwendungsserver 206 eine Konferenz und sendet dem Kommunikationsendgerät (UE) 201 Informationen über die von dem Conference-Server verwalteten Konferenzen zu.
Hierzu werden im Nachrichtenkörper einer Antwort-Nachricht des Conference-Servers auf die INVITE-Nachricht Informationen über die vom Conference-Server verwalteten Konferenzen übertragen, beispielsweise eine Liste der von dem Conference-Server verwalteten Konferenzen.
Die Antwort-Nachricht kann die "200 OK"-Nachricht sein, oder eine andere, beispielsweise eine vorläufige, Antwort-Nachricht.
Die Antwort-Nachricht kann beispielsweise folgende Informationen über die von dem Conference-Server verwalteten Konferenzen enthalten:

– die Adresse der jeweiligen Konferenz, das heißt die C-URI der Konferenz
– die URI des UA, der die Konferenz erzeugt hat
– eine Beschreibung der Konferenz, wie beispielsweise das Thema der Konferenz.

Somit ist die Abfrage von Informationen über die von einem Konferenzserver verwalteten Konferenzen in die Prozedur zur Erzeugung einer Konferenz integriert.
3 zeigt ein Nachrichtenflussdiagramm 300 gemäß einem Ausführungsbeispiel der Erfindung.
Der in 3 dargestellte Nachrichtenfluss findet zwischen einem Kommunikationsendgerät 301, einem P-CSCF 302, welche Teil eines besuchten Netzwerks 303 sind, einem S-CSCF 304 und einem Anwendungsserver 306, welche Teil des Heimnetzwerks des Kommunikationsendgeräts 305 sind, statt.
Der Anwendungsserver 306 ist in diesem Ausführungsbeispiel ein Konferenzserver.
Mittels der im Folgenden beschriebenen Ausführungsform kann eine Konferenz unter Verwendung von SIP-Nachrichten beendet werden.
In Schritt 308 sendet der Nutzer des Kommunikationsgeräts 301 mittels des Kommunikationsgeräts 301 eine Nachricht mit der Bezeichnung "BYE", die die Angabe einer C-URI enthält, an den P-CSCF 302.
Die BYE-Nachricht ist gemäß Tabelle 2 ausgestaltet. Insbesondere weist die BYE-Nachricht ein Nachrichtenkopffeld mit der Bezeichnung "Accept-Contact" auf und das "isfocus" Feature-Tag ist gesetzt (siehe Zeile 11 von Tabelle 2).

Tabelle 2
In Schritt 309 leitet der P-CSCF 302 unter Verwendung der in der BYE-Nachricht angegebenen C-URI (siehe Zeile 6 von Tabelle 2) die BYE-Nachricht an den S-CSCF 304 weiter.
In Schritt 310 leitet der S-CSCF 304 unter Verwendung der in der BYE-Nachricht angegebenen C-URI die BYE-Nachricht an den Anwendungsserver 306 weiter, der den Focus 316 bereitstellt, der die über die C-URI addressierte Konferenz bereitstellt.
In Schritt 311 prüft der Focus 316, ob die BYE-Nachricht das isfocus-Feature-Tag aufweist.
Weist die BYE-Nachricht das isfocus-Feature-Tag auf, so beendet der Focus 316 die über die C-URI referenzierte bzw. addressierte Konferenz. Dabei werden alle Konferenzteilnehmer aus der Konferenz entfernt Weist die BYE-Nachricht das isfocus-Feature-Tag nicht auf, so entfernt der Focus 316 den Nutzer 301 aus der Konferenz.
Da in diesem Beispiel die BYE-Nachricht das isfocus-Feature-Tag aufweist, wird der Focus 316 angewiesen, die der C-URI entsprechende Konferenz zu beenden und alle Teilnehmer aus der Konferenz zu entfernen.
In Schritt 312 antwortet der Focus 316 dem Kommunikationsendgerät 301 mittels einer Nachricht mit der Bezeichnung "200 OK", die an den S-CSCF 304 übertragen wird.
In Schritt 313 leitet der S-CSCF 304 die "200 OK"-Nachricht an den P-CSCF 302 weiter, welcher die "200 OK"-Nachricht in Schritt 314 an das Kommunikationsendgerät 301 überträgt.
In diesem Beispiel wird angenommen, dass neben dem Nutzer, der das Kommunikationsendgerät 301 verwendet, noch weitere Teilnehmer in der Konferenz sind.
Da in diesem Beispiel die BYE-Nachricht das isfocus-Feature-Tag aufweist, beendet in Schritt 315 der Focus die Konferenz, in dem er die jeweiligen SIP-Dialoge mit den anderen Konferenzteilnehmern beendet.
Die Verwendung des isfocus-Feature-Tags im Accept-Contact-Nachrichtenkopffeld der BYE-Nachricht ermöglicht in dieser Ausführungsform somit die Unterscheidung des Falls, dass der Nutzer seine Teilnahme an der Konferenz beenden will, sowie des Falls, dass der Nutzer die Konferenz beenden will, was einschließt, dass er seine Teilnahme an der Konferenz beenden will.
Wie bei der mit Bezug auf 2 beschriebenen Ausführungsform bestehen verschiedene Alternativen zu der mit Bezug auf 3 beschriebenen Ausführungsform.
Insbesondere besteht die Möglichkeit, analog zu der mit Bezug auf 2 beschriebenen Ausführungsform statt dem isfocus-Feature-Tag gegenüber dem Standard neu definierte Feature-Tags zur Signalisierung zu verwenden, beispielsweise mit der Bezeichnung "terminate" zum Anzeigen, dass die Konferenz beendet werden soll oder mit der Bezeichnung "continue" zum Anzeigen, dass der Nutzer die Konferenz verlassen will, die Konferenz aber nicht beendet werden soll.
4 zeigt ein Nachrichtenflussdiagramm 400 gemäß einem Ausführungsbeispiel der Erfindung.
Der in 4 dargestellte Nachrichtenfluss findet zwischen einem Kommunikationsendgerät 401, einem P-CSCF 402, welche Teil eines besuchten Netzwerks 403 sind, einem S-CSCF 404 und einem Anwendungsserver 406, welche Teil des Heimnetzwerks des Kommunikationsendgeräts 405 sind, statt.
Der Anwendungsserver 406 ist in diesem Ausführungsbeispiel ein Konferenzserver.
Die im Folgenden beschriebenen Ausführungsform ist eine Alternative zu der mit Bezug auf 3 beschriebenen Ausführungsform zum Beenden einer Konferenz.
Bei der im Folgenden beschriebenen Ausführungsform wird die in [7] beschriebene SIP-REFER-Methode zur Beendigung einer Konferenz verwendet.
In Schritt 407 sendet der Nutzer des Kommunikationsgeräts 401 mittels des Kommunikationsgeräts 401 eine SIP "REFER" Nachricht, die eine C-URI enthält, an den P-CSCF 402.
Die REFER-Nachricht ist gemäß Tabelle 3 ausgestaltet.

Tabelle 3
Insbesondere weist die REFER-Nachricht ein Nachrichtenkopffeld mit der Bezeichnung "Refer-To" auf, wie es in [7] definiert ist, und dieses Nachrichtenkopffeld enthält die C-URI und den Wert "BYE" eines Parameters mit der Bezeichnung "method", das heißt das Nachrichtenkopffeld enthält die Zeichenkette "method=BYE" (siehe Zeile 13 von Tabelle 3).
In Schritt 408 leitet der P-CSCF 402 unter Verwendung der in der REFER-Nachricht angegebenen C-URI (siehe Zeile 9 von Tabelle 3) die REFER-Nachricht an den S-CSCF 404 weiter.
In Schritt 409 leitet der S-CSCF 404 unter Verwendung der in der REFER-Nachricht angegebenen C-URI die REFER-Nachricht an den Anwendungsserver 406 weiter, der den der angegebenen ersten C-URI entsprechenden Focus 421 bereitstellt.
In Schritt 410 prüft der Focus 421, ob das Refer-to-Nachrichtenkopffeld in der REFER-Nachricht die C-URI und die Zeichenkette "method=BYE" enthält.
Enthält das Refer-to-Nachrichtenkopffeld in der REFER-Nachricht die C-URI und die Zeichenkette "method=BYE" so beendet der Focus 421 die der C-URI entsprechende Konferenz.
In Schritt 411 übermittelt der Focus 421 dem Kommunikationsendgerät 401 eine Bestätigung für den Erhalt der REFER-Nachricht mittels einer "202 Accepted" SIP Nachricht, die an den S-CSCF 404 übertragen wird.
In Schritt 412 leitet der S-CSCF 404 die Accepted-Nachricht an den P-CSCF 402 weiter, welcher die Accepted-Nachricht in Schritt 413 an das Kommunikationsendgerät 401 überträgt.
Da in diesem Beispiel in der REFER-Nachricht die C-URI und die Zeichenkette "method=BYE" enthalten sind, beendet in Schritt 414 der Focus die Konferenz, indem er die SIP Dialoge zu allen Konferenzteilnehmern beendet und die für die Konferenz belegten Ressourcen freigibt.
Insbesondere wird die Teilnahme des Nutzers, der das Kommunikationsendgerät 401 verwendet, beendet. Deshalb überträgt in Schritt 415 der Focus 421 eine Nachricht mit der Bezeichnung "BYE", an den S-CSCF 304 zur Weiterleitung an das Kommunikationsendgerät 401.
In Schritt 416 leitet der S-CSCF 404 die BYE-Nachricht an den P-CSCF 402 weiter, welcher die BYE-Nachricht in Schritt 417 an das Kommunikationsendgerät 401 überträgt.
In Schritt 418 bestätigt das Kommunikationsendgerät den Erhalt der BYE-Nachricht, indem es eine Nachricht mit der Bezeichnung "200 OK" an den P-CSCF 402 zur Weiterleitung an den Anwendungsserver 406 überträgt.
In Schritt 419 leitet der P-CSCF 402 die OK-Nachricht an den S-CSCF 404 weiter, welcher die OK-Nachricht in Schritt 420 an den Focus 421 überträgt.
Gemäß [7] kann im Refer-to-Nachrichtenkopffeld ein generischer Parameter verwendet werden.
In einer weiteren Ausführungsform, welche eine Variante der mit Bezug auf 4 beschriebenen Ausführungsform ist, wird der generische Paramter dazu verwendet dem Focus 421 anzuzeigen, dass die mittels der angegebenen C-URI referenzierte Konferenz beendet werden soll.
Der Nachrichtenfluss in der Ausführungsform ist analog zu der mit Bezug auf 4 beschriebenen Ausführungsform.
Die REFER-Nachricht ist jedoch gemäß Tabelle 4 ausgestaltet.

Tabelle 4
In der Variante wird jedoch zusätzlich der generische Parameter beispielsweise auf den Wert "terminate" gesetzt, (siehe Zeile 13 der Tabelle 4).
Die Zeichenkette "terminate" weist den Konferenzserver an, die der angegebenen C-URI entsprechende Konferenz zu beenden.
In einer weiteren Ausführungsform ist der Nachrichtenfluss ebenfalls analog zu der mit Bezug auf 4 beschriebenen Ausführungsform ausgestaltet, die REFER-Nachricht ist jedoch gemäß Tabelle 5 ausgestaltet.

Tabelle 5
Insbesondere werden Platzhalter, so genannte Wildard, innerhalb des Refer-To-Nachrichtenkopffeldes verwendet (siehe Zeile 13 der Tabelle 5).
Der Platzhalter "*@*" referenziert alle Adressbereiche.
Mit Hilfe von Platzhaltern ist es auch möglich einzelne Adressbereiche, beispielsweise mittels "*@t-mobile.de", zu referenzieren.
Nach Empfang der REFER-Nachricht überträgt der Focus 421 an alle Konferenzteilnehmer eine BYE-Nachricht, da die Kommunikationsendgeräte aller Konferenzteilnehmer mittels des Platzhalters *@* referenziert werden.
Durch die Übertragung einer BYE-Nachricht an alle Teilnehmer werden alle Teilnehmer aus der Konferenz entfernt, was zu einer Beendigung der Konferenz führt.
Dies wird wie beschrieben mittels einer einzigen von dem Nutzer gesendeten REFER-Nachricht erreicht.
Auf diese Weise wird eine implizite Beendigung der Konferenz mittels SIP-Nachrichten erreicht.
In diesem Dokument sind folgende Veröffentlichungen zitiert:

[1] IETF SIPPING Working Group: draft-ietf-sipping-conferencing-framework-01
[2] 3GPP TR29.847: Conferencing based on SIP, SDP and other protocols
[3] RFC 3261: SIP: Session Initiation Protocol
[4] IETF SIPPING Working Group: draft-ietf-sipping-cc-conferencing-03
[5] IETF SIP Working Group: draft-ietf-sip-callerprefs-10
[6] IETF SIP Working Group: draft-ietf-sip-callee-caps-03
[7] IETF RFC 3515: The SIP Refer Method
[8] 3GPP TS 23.228: IP multimedia subsystem; Stage 2
[9] US 5,737,530

100: Kommunikationssystem
101: Mobilfunk-Teilnehmergerät
102: Zugangsnetz
103: P-CSCF
104: DNS
105: I-CSCF
106: HSS
107: S-CSCF
108: H-PLMN
109: V-PLMN
111: IMS
112: Mobilfunknetz
138: Anwendungsserver
140: PS-Domain
141: HLR
142: MRFC
200: Nachrichtenflussdiagramm
201: Kommunikationsendgerät
202: P-CSCF
203: besuchtes Netzwerk
204: S-CSCF
205: Heimnetzwerk des Kommunikationsendgeräts
206: Anwendungsserver
207: Heimnetzwerk des Anwendungsservers
208–215: Verarbeitungsschritte
216: Focus
300: Nachrichtenflussdiagramm
301: Kommunikationsendgerät
302: P-CSCF
303: besuchtes Netzwerk
304: S-CSCF
305: Heimnetzwerk des Kommunikationsendgeräts
306: Anwendungsserver
308–315: Verarbeitungsschritte
316: Focus
400: Nachrichtenflussdiagramm
401: Kommunikationsendgerät
402: P-CSCF
403: besuchtes Netzwerk
404: S-CSCF
405: Heimnetzwerk des Kommunikationsendgeräts
406: Anwendungsserver
407–420: Verarbeitungsschritte
421: Focus

Claims

Kommunikationssystem, das einen Konferenzserver, eine Konferenzsteuereinheit und mindestens ein Kommunikationsendgerät aufweist, wobei – der Konferenzserver eingerichtet ist, mindestens eine Konferenz für eine Mehrzahl von Kommunikationsendgeräten bereitzustellen; – das mindestens eine Kommunikationsendgerät eine Nachrichtenerzeugungseinheit aufweist, die eingerichtet ist, eine Call-Control-Protokoll-Nachricht zu erzeugen, welche Call-Control-Protokoll-Nachricht Steuerinformation enthält, die spezifiziert, ob – das mindestens eine Kommunikationsendgerät einer Konferenz hinzugefügt werden soll und/oder – eine Konferenz erzeugt werden soll und/oder – eine Konferenz beendet werden soll und/oder – Informationen über mindestens eine der von dem Konferenzserver bereitgestellten Konferenz an das mindestens eine Kommunikationsendgerät übertragen werden sollen; – die Konferenzsteuereinheit eine Ermittlungsvorrichtung aufweist, die eingerichtet ist, aus der Nachricht die Steuerinformation zu ermitteln; – die Konferenzsteuereinheit eine Steuervorrichtung aufweist, die eingerichtet ist, gemäß der ermittelten Steuerinformation – das mindestens eine Kommunikationsendgerät einer Konferenz hinzuzufügen und/oder – eine Konferenz zu erzeugen und/oder – eine Konferenz zu beenden und/oder – Informationen über mindestens eine der von dem Konferenzserver bereitgestellten Konferenz an das mindestens eine Kommunikationsendgerät zu übertragen.
Kommunikationssystem gemäß Anspruch 1, wobei die Call-Control-Protokoll-Nachricht gemäß dem SIP-Protokoll ausgestaltet ist.
Kommunikationssystem gemäß Anspruch 1 oder 2, wobei die Steuerinformation in Form eines Feature-Tags in der Call-Control-Protokoll-Nachricht enthalten ist.
Kommunikationssystem gemäß Anspruch 3, wobei das Kommunkationssystem gemäß einem 3GPP-Standard ausgestaltet ist.
Kommunikationssystem gemäß Anspruch 4, wobei das Feature-Tag ein in dem IETF-Standard oder 3GPP-Standard vorgesehenes Feature-Tag ist.
Kommunikationssystem gemäß Anspruch 4, wobei das Feature-Tag ein gegenüber dem IETF-Standard oder gegenüber dem 3GPP-Standard neu definiertes Feature-Tag ist.
Kommunikationssystem gemäß einem der Ansprüche 4 bis 6, wobei das Feature-Tag in dem Accept-Contact-Nachrichtenkopffeld oder in dem Reject-Contact-Nachrichtenkopffeld der Call-Control-Protokoll-Nachricht enthalten ist.
Kommunikationssystem gemäß Anspruch 1 oder 2, wobei die Steuerinformation in Form einer Referenzierung in der Call-Control-Protokoll-Nachricht enthalten ist.
Kommunikationssystem gemäß Anspruch 8, wobei die Referenzierung mindestens einen Platzhalter aufweist.
Kommunikationssystem gemäß Anspruch 8 oder 9, wobei die Referenzierung eine oder mehrere Parameterwerte aufweist.
Kommunikationssystem gemäß einem der Ansprüche 8 bis 10, wobei das Kommunkationssystem gemäß einem 3GPP-Standard ausgestaltet ist.
Kommunikationssystem gemäß Anspruch 11, wobei die Referenzierung in dem Refer-to-Nachrichtenkopffeld enthalten ist.
Kommunikationssystem gemäß Anspruch 1, wobei die Call-Control-Protokoll-Nachricht gemäß dem H.323-Protokoll ausgestaltet ist.
Kommunikationssystem gemäß einem der Ansprüche 1 bis 13, wobei die mindestens eine von dem Konferenzserver bereitgestellte Konferenz eine Multimedia-Konferenz ist.
Verfahren zum Steuern eines Kommunikationssystems, welches Kommunikationssystem einen Konferenzserver, welcher eingerichtet ist, mindestens eine Konferenz für eine Mehrzahl von Kommunikationsendgeräten bereitzustellen, eine Konferenzsteuereinheit und mindestens ein Kommunikationsendgerät aufweist, wobei gemäß dem Verfahren – das mindestens eine Kommunikationsendgerät eine Call-Control-Protokoll-Nachricht erzeugt, welche Call-Control-Protokoll-Nachricht Steuerinformation enthält, die spezifiziert, ob – das mindestens eine Kommunikationsendgerät einer Konferenz hinzugefügt werden soll und/oder – eine Konferenz erzeugt werden soll und/oder – eine Konferenz beendet werden soll und/oder – Informationen über mindestens eine der von dem Konferenzserver bereitgestellten Konferenz an das mindestens eine Kommunikationsendgerät übertragen werden sollen; – die Konferenzsteuereinheit aus der Nachricht die Steuerinformation ermittelt; – die Konferenzsteuereinheit gemäß der ermittelten Steuerinformation – das mindestens eine Kommunikationsendgerät einer Konferenz hinzufügt und/oder – eine Konferenz erzeugt und/oder – eine Konferenz beendet und/oder – Informationen über mindestens eine der von dem Konferenzserver bereitgestellten Konferenz zu dem mindestens einen Kommunikationsendgerät überträgt.
Kommunikationsendgerät eines Kommunikationssystems, welches Kommunikationssystem einen Konferenzserver aufweist, der eingerichtet ist, mindestens eine Konferenz für eine Mehrzahl von Kommunikationsendgeräten bereitzustellen, wobei – das Kommunikationsendgerät eine Nachrichtenerzeugungseinheit aufweist, die eingerichtet ist, eine Call-Control-Protokoll-Nachricht zu erzeugen, welche Call-Control-Protokoll-Nachricht Steuerinformation enthält, die spezifiziert, ob – das Kommunikationsendgerät einer Konferenz hinzugefügt werden soll und/oder – eine Konferenz erzeugt werden soll und/oder – eine Konferenz beendet werden soll und/oder – Informationen über mindestens eine der von dem Konferenzserver bereitgestellten Konferenz an das Kommunikationsendgerät übertragen werden sollen;
Verfahren zum Steuern eines Kommunikationsendgeräts eines Kommunikationssystems, welches Kommunikationssystem einen Konferenzserver aufweist, der eingerichtet ist, mindestens eine Konferenz für eine Mehrzahl von Kommunikationsendgeräten bereitzustellen, wobei gemäß dem Verfahren – das Kommunikationsendgerät eine Call-Control-Protokoll-Nachricht erzeugt, welche Call-Control-Protokoll-Nachricht Steuerinformation enthält, die spezifiziert, ob – das Kommunikationsendgerät einer Konferenz hinzugefügt werden soll und/oder – eine Konferenz erzeugt werden soll und/oder – eine Konferenz beendet werden soll und/oder – Informationen über mindestens eine der von dem Konferenzserver bereitgestellten Konferenz an das Kommunikationsendgerät übertragen werden sollen;
Konferenzsteuereinheit eines Kommunikationssystems, das mindestens ein Kommunikationsendgerät und einen Konferenzserver aufweist, welcher eingerichtet ist, mindestens eine Konferenz für eine Mehrzahl von Kommunikationsendgeräten bereitzustellen, wobei – die Konferenzsteuereinheit eine Ermittlungsvorrichtung aufweist, die eingerichtet ist, aus einer empfangenen Nachricht Steuerinformation, die spezifiziert, ob – das mindestens eine Kommunikationsendgerät einer Konferenz hinzugefügt werden soll und/oder – eine Konferenz erzeugt werden soll und/oder – eine Konferenz beendet werden soll und/oder – Informationen über mindestens eine der von dem Konferenzserver bereitgestellten Konferenz an das mindestens eine Kommunikationsendgerät übertragen werden sollen; zu ermitteln; – die Konferenzsteuereinheit eine Steuervorrichtung aufweist, die eingerichtet ist, gemäß der ermittelten Steuerinformation – das mindestens eine Kommunikationsendgerät einer Konferenz hinzuzufügen und/oder – eine Konferenz zu erzeugen und/oder – eine Konferenz zu beenden und/oder – Informationen über mindestens eine der von dem Konferenzserver bereitgestellten Konferenz an das mindestens eine Kommunikationsendgerät zu übertragen.
Verfahren zum Steuern einer Konferenzsteuereinheit eines Kommunikationssystems, das mindestens ein Kommunikationsendgerät und einen Konferenzserver aufweist, welcher Konferenzserver eingerichtet ist, mindestens eine Konferenz für eine Mehrzahl von Kommunikationsendgeräten bereitzustellen, wobei gemäß dem Verfahren – die Konferenzsteuereinheit aus einer empfangenen Nachricht Steuerinformation, die spezifiziert, ob – das mindestens eine Kommunikationsendgerät einer Konferenz hinzugefügt werden soll und/oder – eine Konferenz erzeugt werden soll und/oder – eine Konferenz beendet werden soll und/oder – Informationen über mindestens eine der von dem Konferenzserver bereitgestellten Konferenz an das mindestens eine Kommunikationsendgerät übertragen werden sollen; ermittelt; – die Konferenzsteuereinheit gemäß der ermittelten Steuerinformation – das mindestens eine Kommunikationsendgerät einer Konferenz hinzufügt und/oder – eine Konferenz erzeugt und/oder – eine Konferenz beendet und/oder – Informationen über mindestens eine der von dem Konferenzserver bereitgestellten Konferenz an das mindestens eine Kommunikationsendgerät überträgt.