Beschreibung

Verfahren zur Kommunikation zwischen Endgeräten in SIP-Netzen

Die vorliegende Erfindung betrifft ein Verfahren zur Kommunikation zwischen Endgeräten in SIP-Netzen nach dem Oberbegriff des Patentanspruches 1 sowie einen dazugehörigen Applikationsserver nach dem Patentanspruch 8.

Neuere Kommunikationsarchitekturen sehen die Trennung vermittlungstechnischer Netzwerke in verbindungsdienstbezogene Einheiten und den Transport der Nutzinformationen (Bearer Control) vor. Hieraus resultiert eine Dekomposition/ Trennung von Verbindungsaufbau und Medium- bzw. Beareraufbau. Die ü- bertragung der Nutzinformationen (Durchschaltung des Nutzkanals) kann dabei über unterschiedliche hochbitratige Transporttechnologien wie z.B. ATM, IP oder Frame Relay vorgenommen werden.

Mit einer derartigen Trennung sind die gegenwärtig in Schmalbandnetzen geführten Telekommunikationsdienste auch in Breitbandnetzen zu realisieren. Dabei werden die Teilnehmer entweder direkt (z.B. über ein DSSl-Protokoll) oder über als Media Gateway Controller (MGC) ausgebildete Vermittlungsstellen (z. B. über ein ISUP-Protokoll) angeschlossen. Die Nutzinformationen selbst werden über von Media Gateways (MG) in die jeweils benutzte Transporttechnologie umgewandelt .

Die Steuerung der Media Gateways können von jeweils zugeordneten Media Gateway Controllern (MGC) durchgeführt werden. Zur Steuerung der Media Gateways verwenden die Media Gateway Controller normierte Protokolle, wie z. B. das MGCP Protokoll oder das H.248 Protokoll. Zur Kommunikation untereinander verwenden die Media Gateway Controller ein durch die ITU standardisiertes BICC (Bearer Independent CaIl Control) Protokoll, das aus einer Mehrzahl von standardisierten Protokollen gebildet ist und somit eine Protokollfamilie umfasst.

Ein dem BICC Protokoll adäquates Protokoll ist bei dem IETF Standardisierungsgremium mit dem SIP Protokoll (S_ession Initiation Protocol, RFC3261) bzw. dem Zusatz SIP-T (RFC3204 )/ SIP-I entstanden. Mit letzteren können ISUP-Nachrichten - im Gegensatz zum SIP Protokoll - übertragen werden. Die übertragung der

ISUP-Nachrichten erfolgt im allgemeinen durch Tunnel, d.h. durch transparentes Durchreichen.

Der Verbindungsaufbau zwischen zwei oder mehreren SIP-Teilnehmern erfolgt unter Zuhilfenahme von

SIP-Protokollelementen. Hierbei werden unter anderem SDP (Session Description Protocol gemäss IETF-Standard RFC 2327) Daten ausgetauscht. SDP-Daten sind (Bearer-) endpunktbezogene Daten, die Informationen über Codecs, IP-Port, IP-Adresse usw. enthalten. Soll eine Verbindung zwischen einem SIP-Teilnehmer und einem H.323 oder TDM/ ISDN Teilnehmer erstellt werden, müssen diese SIP-Protokollelemente in den beteiligten Media Gateway Controllern entsprechend in H.323-, TDM- oder ISDN Protokollelemente umgesetzt werden. Beispielsweise bedeutet dies für einen aus der SIP Welt gerufenen TDM Teilnehmer, dass die in der TDM Welt verwendeten ISUP-Nachrichten wie beispielsweise die ISUP-Nachricht IAM (Initial Address Message) , erzeugt und diesem zugeführt werden muss.

Erste grundsätzliche Betrachtungen haben innerhalb der ITU-T zur Draft Recommendation Q.1912.5 „Interworking SIP and BICC/ ISUP" geführt. Hierbei wurden auch schon erste überlegungen bezüglich der aus der ISDN Welt bekannten Supplementary Services gemacht. Gleichzeitig werden Dienste, die im bei dem IETF Standardi- sierungsgremium entstandenen SIP-Protokoll RFC 3261 (Juni 2002) beschrieben sind, weiter detailliert und/oder erweitert/eingeschränkt. Dabei wird ein Konzept namens „Forking" eingeführt, bei welchem für eine Einladungsmeldung INVITE von einem erstem Teilnehmer (Alice) an einen zweiten Teilnehmer (Bob) bzw. aus einem Proxy-Server zwischen beiden Teilnehmern eine andere Routing-Entscheidung vorgenommen werden kann. Eine derartige Gabelung wird dabei durchgeführt, indem die Anmel- de-Meldung INVITE z. B. an einen Voicemail-Server (privaten

Anrufbeantworter vom Bob) oder an eine weitere Endstelle vom Bob (berufliches Telefon, PDA, Mailbox eines Computers, Fax, etc) parallel geleitet wird, so dass Bob erreicht wird. Nimmt dann Bob an seinem beruflichen Telefon ab, wird eine Zusage-Rückmeldung 200 OK mit der SDP von dem beruflichen Telefon zum Endgerät von Alice gesendet. Dieser Vorgang setzt seitens des Endgeräts von Alice eine Unterstützung zur Forkingsdurchführung voraus.

In einem weiteren Protokoll RFC 3841 (August 2004) vom Stan- dardisierungsgremium IETF werden weiterhin sogenannte „Caller Preferences for SIP" beschrieben, wobei z. B. Einstellungswünsche von einem ersten anrufenden Teilnehmer (caller = Alice) im Bezug auf einer Routing-Wahl über ein Proxy- bzw. Redi- rect-Server definiert sind. Beispielsweise wenn der erste Teilnehmer mit einem zweiten Teilnehmer (callee = Bob) direkt sprechen möchte, wünscht er sich nicht, mit dem Anrufbeantworter oder der Mailbox des zweiten Teilnehmers in Kontakt gesetzt zu werden. Daher wird das Forking in einem Headersatz „Re- quest-Disposition" mit der fork-directive in der SIP Meldung, vorzugsweise INVITE, seitens des ersten Teilnehmers abgestellt bzw. in dem Routing verwaltenden Proxy-Server unterdrückt (siehe Absatz 7.1 in RFC3841) , so dass lediglich genau ein Audio oder Video basierte Verbindung angestrebt wird (auch andere Kommunikationsdienste, die noch nicht bekannt sind, sollten nicht ausgeschlossen werden) . Solche Richtlinien (directives) müssen am Proxy-Server beachtet werden, auch wenn z.B. anstelle einer telefonischen Audio-Kommunikation eine sofortige Video basierte Kommunikation gemäss einem signalisierten Resour- cen-Identifizierer (URI = Uniform Resource Identifiers) des zweiten Teilnehmers (callee) angeboten werden könnte. Damit schränkt sich das mögliche Kommunikationsprotokoll erheblich ein.

Der Erfindung liegt die Aufgabe zugrunde, einen Weg aufzuzeigen, aufgrund eines abgestellten Forking eine Einschränkung der

Kommunikationsmöglichkeit (en) bei einer SIP-basierten Kommunikation zwischen zwei Teilnehmern zu vermeiden.

Die Erfindung wird ausgehend von den im Oberbegriff des Verfahrenspatentanspruches 1 angegebenen Merkmale durch die in den kennzeichnenden Teilen beanspruchten Merkmale gelöst. Ebenfalls wird die Erfindung über einen durch Patentanspruch 8 dargestellten Applikationsserver zur Durchführung des Verfahrens gelöst.

Es wird ein Verfahren zur Kommunikation zwischen einem Endgerät eines ersten Teilnehmers und (gemäss einem Internetprotokoll - wie SIP - signalisierbaren) Endgeräten eines zweiten Teilnehmers vorgeschlagen, demgemäss:

- ein erster Anruf vom ersten Teilnehmer an den zweiten Teilnehmer eingeleitet wird, indem eine Einlade-Meldung aus dem Endgerät des ersten Teilnehmers an den zweiten Teilnehmer übermittelt wird; diese übermittlung kann über einen Proxy-Server erfolgen, jedoch auch könnte es durch ein Software am ersten Teilnehmer abgehandelt worden sein (z.B. Skype®) ; zumindest im SIP-Protokoll ist der Proxy notwendig, denn dort liegen z. B. Teilnehmerdaten z.B. für eine Authentifizierung vor, vielleicht kann es andere Signalisierungen geben, die ähnliche Daten enthalten, oder auf Aktionen verzichten können, ,

- seitens des ersten Teilnehmers eine Anforderung zur Durchführung eines Forking auf Endgeräte des zweiten Teilnehmers ausgeschlossen wird, d.h. der erste Teilnehmer ein Forking nicht unterstützt oder abgestellt hat.

Dadurch dass eine Zusatzanwendung (z.B. als Software oder Computerprogramm in einem Applikationsserver) mit einer weiteren, schaltbaren Anforderung zur Durchführung eines ge- zwungenen Forking bis zu den Endgeräten des zweiten Teilnehmers ausgeführt wird, werden erfindungsgemäß potentielle Antworten mit Kommunikationsinformationen wie Signalisierungsdaten aus den geforkten Endgeräten des zweiten Teilnehmers über die Zusatzanwendung an den ersten Teilnehmer signalisiert/gemeldet.

Daher wird vorteilhafterweise eine ursprüngliche Einschränkung von Dialogressourcen vermieden, falls eine Forking seitens des ersten Teilnehmers (z.B. in seinem SIP-basierten Headersatz mit

gemäss IETF-Standard RFC3841) abgestellt bzw. nicht unterstützt wird.

Die Zusatzanwendung weist also eine effektive Mappingfunkti- onalität auf, aus welcher ein Einladung/Antwort-basiertes Dialog zwischen dem ersten Teilnehmer und wählbaren Endgeräten des zweiten Teilnehmers entsteht.

In anderen Worten wird mit der Zusatzanwendung angestrebt, dass, auch wenn der erste Teilnehmer ein Forking gemäss den bekannten IETF-Standarten RFC3261 und RFC3841 verboten hat, das Forking im Hintergrund durchgeführt wird, ohne weitere aufwendigere änderungen im aktuellen SIP-Protokoll . Es werden tatsächlich nur bestehende SIP-protokollierte Befehle, nun aus und in der Zusatzanwendung, verwendet. Dies wird im Folgenden näher erläutert. Insbesondere da unterschiedliche Antworten (18x, provisional responses und 200 OK für eine initiierte Meldung INVITE) von den verschiedenen Endgeräten des zweiten Teilnehmers in die Zusatzanwendung ankommen werden, kann eine Aktuali- sierung-Meldung (UPDATE) in Verbindung mit unterschiedlichen SDP der Endgeräte des zweiten Teilnehmers auf diese Nachricht (UPDATE) bei dem Abschnitt zwischen dem ersten Teilnehmer und der Zusatzanwendung gemappet werden. Falls eine solche Aktualisierungsmeldung (UPDATE) vom ersten Teilnehmer nicht unterstützt wird, muss mit einer Zusage-Meldung (200 OK) zur Anmelde-MeIdüng (INVITE) das letzte gültige SDP eines Endgeräts des zweiten Teilnehmers gesendet werden, oder anschließend eine neue An- melde-Meldung (re-INVITE) mit dem letzten gültigen SDP des Endgeräts des zweiten Teilnehmers gesendet werden.

Die Zusatzanwendung kann in einem Modul des Netzwerkes (Applikationsserver, MG, CMN, Proxy-Server, Endgerät, etc) oder auch in einer weiteren externen z. B. durch/über das SIP Protokoll zuschaltbaren Einheit gespeichert und dort ausgeführt werden, z. B. als Code-programmiertes Software. Sie sollte nach Detektion einer INVITE-Meldung aus einem Teilnehmer zu einem weiteren Teilnehmer mit unterdrückter Forking-Einstellung seitens des ersten Teilnehmers ausführbar sein.

Damit kann mittels einem Applikationsserver eine Durchführung des erfindungsgemäßen Verfahrens erfolgen. Bei dem Applikationsserver ist die Zusatzanwendung gespeichert und ausführbar. Der Applikationsserver verwaltet den Austausch der Kommunikationsinformationen (zumindest der Signalisierungsdaten) zwischen dem ersten Teilnehmer und den Endgeräten des zweiten Teilnehmers. Dies setzt voraus, dass im Applikationsserver zumindest eine Anruf-Information über eine Unterdrückung (bzw. Durchführung) eines Forking seitens des ersten Teilnehmers und, bei erfindungsgemäßen Durchführung des Forking in der Zusatzanwendung, alle Antworten von Endgeräten des zweiten Teilnehmers der Zusatzanwendung zugeführt werden sollen.

Die Erfindung wird im Folgenden anhand der Zeichnung näher erläutert. Dabei zeigen:

FIGUR 1: ein Kommunikationssystem mit SIP-Teilnehmern;

FIGUR 2: skizzierte Schritte des erfindungsgemäßen Verfahrens .

Die Figur 1 zeigt dabei ein Kommunikationssystem zwischen einem ersten rufenden SIP-Teilnehmer A mit mindestens einem SIP-basierten Endgerät und einem zweiten anzurufenden Teilnehmer B mit mehreren Endgeräten Bl, B2, B3, zwischen denen ein Internetnetz IP als Bearer IP für die übertragung von Nutzinformationen angeordnet ist.

Die SIP-geeigneten Endgeräte der beiden Teilnehmer A, B sind mit Transit-Vermittlungsstellen TX verbunden. Die SIP-Endgeräte sind üblicherweise an SIP-Proxy (Proxy-Server) „angeschlossen" bzw. dort registriert, wobei es natürlich schon auch sein kann, dass vielleicht auch in Zukunft ein Teilnehmer aus einem PSTN-Netzwerk über ein SIP/PSTN-ISDN übergangsamt bzw. Ortsvermittlungsstellen LE durch eine geforkten Anmelde-Meldung (INVITE) angerufen werden könnte.

In den Transit-Vermittlungsstellen TX wird nun die Trennung zwischen Signalisierungsinformationen (bzw. einem Signali-

sierungspfad) und Nutzinformationen durchgeführt. Die Signa- lisierungsinformationen werden von der Transit-Vermittlungsstelle TX unmittelbar über ein SIP-Protokoll einem jeweils zugeordneten SIP-Client SIP A, SIP B zugeführt. Die SIP-clients sind z. B. Server, Proxy-Server, redirect-Server, etc bzw. können entlang des Signalisierungspfads mit einem oder mehreren weiteren Proxy-Server in Verbindung sein. Die Nutzinformationen werden zu einem (eingangsseitig angeordneten) Media Gateway MG (MG A oder MG B) übertragen, das als Schnittstelle zwischen z.B. TDM-Netz und einem ATM- bzw. IP- übertragungsnetz fungiert und werden über das betreffende übertragungsnetz paketorientiert übertragen. Das Media Gateway MG A wird von einem Controller des SIP Clients SIP A ebenso gesteuert, wie das Media Gateway MG B vom einem Controller des SIP Clients SIP B. Im Falle einer übertragung der Nutzinformationen vom Media Gateway MG A zum Media Gateway MG B werden die Nutzinformationen wieder unter Steuerung des dem Media Gateway MG B zugeordneten SIP Clients SIP B in einen TDM Datenstrom umgewandelt und einem (kein Forking) oder mehreren (mit Forking) den in Frage kommenden Endgeräten des zweiten Teilnehmers B zugeführt werden. Die zwischen dem Controllern der SIP-Clients SIP A, SIP B und dem jeweils zugeordneten Media Gateway ü- bertragenen Daten werden von einem standardisierten Protokoll unterstützt. Dieses kann auch beispielsweise das MGCP oder das H.248 Protokoll sein. Zwischen den beiden Controllern wird jedoch hier gemäß vorliegendem Ausführungsbeispiel das SIP Protokoll verwendet. In den Signalisierungspfad können noch weitere Einrichtungen wie SIP-Proxies für das Routing geschaltet sein. Ein derartiges Routing-Server SIP Proxy wird hier die Kommu- nikation zwischen Endgeräten der beiden Teilnehmer A, B unterstützen. Es soll auch betrachtet werden, dass der erste Teilnehmer A beispielhaft an einem Proxy-Server SIP Proxy registriert sei, und den zweiten Teilnehmer B mit seinen möglicherweise mehreren Endgeräten von einem weiteren Pro- xy-Server SIP Proxy, verwaltet wird. Eine solche Unterstützung ist in den bisher zitierten Standardisierungsberichten RFC 3261 und 3841 ausführlich beschrieben.

In Figur 2 wird nun gemäss Figur 1 das Verfahren zur Kommunikation zwischen einem Endgerät eines ersten Teilnehmers A und gemäss einem Internetprotokoll signalisierbaren Endgeräten Bl, B2, B3, ... eines zweiten Teilnehmers B skizziert. Dabei werden folgende grundsätzliche Schritte durchgeführt:

- ein erster Anruf vom ersten Teilnehmer A wird z. B. an das erste Endgerät Bl des zweiten Teilnehmers B eingeleitet, indem eine Einlade-Meldung INVITE aus dem Endgerät des ersten Teilnehmers A an das erste Endgerät Bl, vorzugsweise über einen Proxy-Server SIP Proxy (dies ist aber nicht unbedingt notwendig, da die im Folgenden beschriebene Zusatzanwendung eine Registrierung und eine Addresse des Endgerätes kennt) , übermittelt wird,

- seitens des ersten Teilnehmers A (in seinem SDP bzw. Headersatz) eine Anforderung zur Durchführung eines Forking auf mehrere Endgeräte des zweiten Teilnehmers B wird jedoch ausgeschlossen, d. h. dass aufgrund eines Forking-Verbots bzw. einer Forking-Unfähigkeit NO FORK nur eines der Endgeräte Bl, B2, B3 angerufen werden kann/soll,

- eine Zusatzanwendung AS mit einer weiteren, schaltbaren Anforderung FORK zur Durchführung eines gezwungenen Forking wird nun, vorzugsweise über den Proxy-Server SIP Proxy (dies ist aber nicht unbedingt notwendig, da die Zusatzanwendung eine Registrierung und eine Addresse des Endgerätes kennt) , bis zu den Endgeräten Bl, B2, B3 des zweiten Teilnehmers B ausgeführt, derart dass potentielle Antworten mit Kommunikationsinformationen (= SIP-basierte Signalisierungsdaten 200 OK, 18x, SDPl, SDP2, SDP3, etc nach u.a. RFC3261, RFC3262, RFC3264 (PRACK, „reliable responses" und „offer/answer" werden aus übersichtlichkeitsgründen wegegelassen, aber angenommen/vorausgesetzt und RFC3311) aus den geforkten (= gabe- lungsförmig angerufenen) Endgeräten Bl, B2, B3 des zweiten Teilnehmers B über die Zusatzanwendung AS an den ersten Teilnehmer A signalisiert werden.

Dadurch dass anstelle des ersten Teilnehmers A die Zusatzanwendung AS ein Forking trotzdem einleitet, werden alle Endgeräte Bl, B2, B3 zumindest an der Zusatzanwendung AS durch Signalisierung informiert bzw. wird es ermöglicht, dass im Falle von SIP-Telefonen alle Endgeräte Bl, B2, B3 eine Anruf-Anfrage vom ersten Teilnehmer A erhalten. Die Zusatzanwendung kann beispielsweise in einem Applikationsserver gespeichert und ausführbar sein, über welchen einen Austausch der Kommunikationsinformationen zwischen dem ersten Teilnehmer A und den Endgeräten des zweiten Teilnehmers (B) Verwaltungsmäßig ermöglicht wird. Der Applikationsserver kann Teil eines Servers (SIP-Server, Proxy-Server, Netzwerkmanagement CMN, etc) oder eine bereits zum SIP-Kommunikationspfaden nebengeordnete Einheit sein, oder eine speziell zu diesem Zweck in den Kom- munikationspfad dynamisch hinzufügbare Einheit sein.

Im Folgenden wird ausführlicher das Verfahren gemäss Figur 2 näher beschrieben. Sechs Verfahrenschritte 1 bis 6 sind dargestellt, die einen Hin- und Rückweg von Signalisierungsdaten (u. a. INVITE, UPDATE, 18x) zwischen dem ersten Teilnehmer A und dem ersten Endgerät Bl (Schritte 1-2) , dem zweiten Endgerät B2 (Schritte 3-4) und dem dritten Endgerät B3 (Schritte 5-6) darstellen. Entlang der drei Hin- und Rückwege werden die Signalisierungsdaten über die Zusatzanwendung AS ein- und ausgehen.

Im Schritt 1 soll bei unterdrücktem Forking NO FORK die An- melde-Meldung INVITE mit SDP (in diesem Bespiel wird die Meldung INVITE mit angehängtem SDP gewählt, aber es gibt in SIP-Protokoll auch Fälle ohne SDP in der Meldung INVITE, was hier nicht ausgeschlossen werden soll/darf) des ersten Teilnehmers A über die Zusatzanwendung AS an das erste Endgerät Bl übermittelt werden. Da die Anmelde-Meldung INVITE über die Zusatzanwendung AS geführt ist/wird, wird ein Forking FORK aus der Zusatzan- wendung eingeleitet, so dass jeweils eine Anmelde-Meldung INVITE jeweils an ein mögliches Endgerät Bl, B2, B3 mit SDP vom ersten Teilnehmer A gesendet wird.

Es kann sein, dass das erste Endgerät Bl auf die Anmelde-Meldung INVITE zuerst reagiert. Dabei sendet es z. B. eine Meldung 18x (= „provisional response/ request received, continuing to process the request", RFC 3261) mit Signalisierungsdaten SDPl (Session Description Protocol aus Bl) über die Zusatzanwendung AS an den ersten Teilnehmer A (siehe Schritt 2) . Gleichzeitig setzt das erste Endgerät Bl ein eigenes TO-tag auf (= „early dialogue" mit Bl) 18x. Es kann jedoch auch sein, dass das erste Endgerät Bl noch kein SDP mitsendet. Die Zusatzanwendung AS gibt zumindest die Meldung 18x an den ersten Teilnehmer A weiter, bei welchem bei Erhalt der Meldung 18x (mit oder ohne SDP) ein Dialog mit dem ersten Endgerät Bl aufbauen kann.

Im Schritt 3 wird nun eine neu entstehende (da geforkte) An- melde-Meldung INVITE aus der Zusatzanwendung AS an das zweite Endgerät B2 übermittelt, wobei das Senden dieser zweiten An- melde-Meldung INVITE parallel oder sequentiell erfolgen kann.

In der Zwischenzeit (z. B. als der Dialog von A mit Bl entstehen sollte) kommt eine weitere Rückmeldung 18x mit SDP2 aus dem geforkten, zweiten Endgerät B2 in die forking-verursachende Zusatzanwendung AS. Dabei wird auch das zweite Endgerät B2 ein eigenes TO-tag auf („early dialogue" mit B2) 18x setzen (Schritt 4) . Dabei kann es auch sein, dass das zweite Endgerät B2 noch kein SDP mitsendet.

Da die Zusatzanwendung AS aber geforkt hat, und der erste Teilnehmer A dies aber nicht wollte, sendet die Zusatzanwendung AS erfindungsgemäß eine Aktualisierung-Meldung UPDATE für den schon vorher entstanden Dialog zwischen A und Bl, falls ein SDP2 in der Antwort von B2 stand (eine PRACK, RFC3262 und UPDATE Unterstützung des ersten Teilnehmers A ist hier vorausgesetzt; zur Klarheit wird PRACK weggelassen) . Falls UPDATE nicht un- terstützt wird, muss die Zusatzanwendung AS gegebenenfalls bis zu einer Meldung 200 OK warten, um das SDP2 des zweiten Endgeräts B2 nach A zusenden, Andersfall erhält der erste Teilnehmer A das

Dialog-Angebot des zweiten Endgeräts B2 mit der Aktualisierung-Meldung UPDATE und SDP2.

In der Zwischenzeit kann auch, wie für das zweite Endgerät B2, eine Rückmeldung 18x mit SDP3 vom mit einer Anmelde-Meldung INVITE geforkten (Schritt 5) , dritten Endgerät B3 an die Zu- atzanwendung AS ankommen (Schritt 6) . Dabei wird das dritte Endgerät B3 ein eigenes TO-tag auf (early dialogue mit B3) . Es kann auch sein, dass das dritte Endgerät B3 noch kein SDP mitsendet.

Die Zusatzanwendung AS hat die Kenntnis, dass schon ein Angebot/Antwort Zyklus in Richtung des ersten Teilnehmers A angestoßen wurde, aber noch nicht abgeschlossen wurde, und sie muss diesen Zyklus abwarten, bevor eine neue Aktualisierung-Meldung UPDATE mit dem SDP3 von B3 zum ersten Teilnehmer A gesendet wird (gemäss IETF-Standard RFC3264 mit SDP of- fer/answer) . Falls kein SDP3 in der Rückmeldung 18x des dritten Endgeräts B3 war, braucht es keine Aktualisierung-Meldung UPDATE, so dass über eine 18x der erste Dialog zwischen A und Bl bestehend bleibt und wieder verwendet wird (weil aus Sicht des ersten Teilnehmers A das Forking nicht erlaubt war) .

Nun wird der erste Teilnehmer mit einer Erfolg-Meldung 200 OK („success / the action was successfully received, understood und accepted", RFC3261) antworten können. Diese Meldung wird in die Zusatzanwendung AS zugeführt. Falls sich die in der Zusatzanwendung AS mitgesendete Antwort-Signalisierungsinformation SDP in der Meldung 200 OK nicht geändert hat, wäre dieses Zyklus abgeschlossen. Falls sich die in der Zusatzanwendung AS mitgesendete Antwort-Signalisierungsinformation SDP (SDP1->SDP2) geändert haben sollte, muss dies an dem entsprechenden Endgerät des zweiten Teilnehmers B in einem weiteren Zyklus mitgeteilt werden. Dabei kann der erste Teilnehmer A über eine Meldung 200 OK auf die Meldung UPDATE mit z. B. SDP2 des zweiten Endgeräts B2 zu sagen.

Nun kann die Zusatzanwendung AS gegebenenfalls die Aktualisierung-Meldung UPDATE (die zuvor noch nicht gesendet werde konnte) wegen dem dritten Endgerät B3 nun gesendet werden (Schritt 6) . Da die Zusatzanwendung AS aber geforkt hat, und der erste Teilnehmer A dies aber nicht unterstützte, sendet die Zusatzanwendung AS erfindungsgemäß eine Aktualisierung-Meldung UPDATE für den schon vorher entstanden Dialog zwischen dem ersten Teilnehmer A und dem ersten Endgerät Bl, falls ein SDP (SDP3) in der Antwort von B3 stand. (PRACK und UPDATE Unterstützung des ersten Teilnehmers A sind auch vorausgesetzt, zur Klarheit ist PRACK weggelassen) . Falls die Aktualisierung-Meldung UPDATE nicht unterstützt wird, muss die Zusatzanwendung AS gegebenenfalls bis zu einer Meldung 200 OK warten, um das SDP von Bl nach A zusenden.

Weiterhin empfängt der erste Teilnehmer A eine neue UPDATE-Meldung mit SDP als Angebot für eine Antwort (Meldung 200 OK auf die Meldung UPDATE) an die Zusatzanwendung AS. Die Zusatzanwendung AS erhält die Antwort vom ersten Teilnehmer A. Falls sich die SDP-basierte Antwort in der Meldung 200 OK nicht geändert hat, wäre dieses Zyklus abgeschlossen. Falls sich das SDP geändert haben sollte, muss dies aus dem dritten Endgerät B3 in einem weiteren Zyklus mitgeteilt werden.

Wenn nun das zweite Endgerät B2 mit einer Meldung 200 OK auf die Anmelde-Meldung INVITE antwortet, wird dies an die Zusatzanwendung AS übermittelt. Da dem ersten Teilnehmer A vom vorherigen Zyklus noch das SDP3 vom dritten Endgerät B3 bekannt ist, muss dies entweder wiederum auf die dortigen Aktualisierung-Meldung UPDATE gemapped werden (diesmal mit dem gespeichertem SDP2 des zweiten Endgerätes B2) und auch einer Meldung 200 OK auf die Anmelde-Meldung INVITE, oder auf eine Meldung 200 OK und hinterher eine re-INVITE mit dem ebengenannten SDP2. Demgemäss kann der erste Teilnehmer A mit dem zweiten Endgerät B2 te- lefonieren. Weiterhin können die anderen Endgeräte Bl, B3 auch noch immer eine Meldung 200 OK senden.

Einer Zusatzanwendungslogik bleibt es dann überlassen, ob diese späteren Meldungen 200 OK nicht zum Erfolg führen sollen, in dem

diesen Endgeräten dann eine Abschied-Meldung (BYE) gesendet soll, damit nur die Verbindung zwischen A und B2 letztendlich bestehen bleibt, oder ob eine weitere Zusatzanwendungsausprägung dann erlaubt, die verschiedenen Call-Legs (=Anruf-Abschnitte) weiter hin- und herzuschalten, bis das gewünschte Endgerät des Teilnehmers B gefunden ist. Dies könnte durch Zuhilfenahme von einem Call-Hold-Prozess dann gesteuert und bewerkstelligt werden. Dies ist jedoch unwahrscheinlich, weil der zweite Teilnehmer B, der eine Forking override-Berechtigung hat, kann/wird nicht an allen seinen Endgeräten abheben.

Zusammengefasst kann, bei einem bestehenden Dialog zwischen dem ersten Teilnehmer A und einem Endgerät (z.B. Bl) des zweiten Teilnehmers B sowie bei Erhalt eines Kommunikationsangebots (Meldung 18x) eines weiteren Endgeräts (z.B. B2) des zweiten Teilnehmers B, die Zusatzanwendung AS eine Aktualisierung-Meldung UPDATE an den ersten Teilnehmer A übermitteln. Bei keiner Unterstützung dieser Aktualisierung-Meldung UPDATE am ersten Teilnehmer A muss eine erneute Anmelde-Meldung „Re-INVITE" vom ersten Teilnehmer A an das weitere Endgerät des zweiten Teilnehmers (B) übermittelt werden. D. h., wenn der erste Teilnehmer A eine Aktualisierung-Meldung UPDATE nicht unterstützt, dann muss die erneute Anmelde-Meldung „re-INVITE" gesendet werden, aber erst nachdem die Zusage-Meldung 200 OK für die ursprüngliche Anmelde-Meldung INVITE gesendet wurde. Auf der anderen Seite, könnte der erste Teilnehmer A in der SDP-Antwort (SDP-answer) in der Zusage-Meldung 200 OK als Antwort auf eine Aktualisierung-Meldung UPDATE mit SDP-Angebot (SDP-offer) eine neue Antwort (answer) gegeben haben (neuer CODEC, port, IP-adresse) , sodass die Zusatzanwendung AS selbst eine Aktualisierung-Meldung UPDATE in Richtung des beteiligten Teilnehmers B senden muss, damit die beteiligten Endgeräte beide das richtige Verständnis über das verwendete SDP haben.

Die Zusatzanwendung AS verwaltet daher den Austausch von aktualisierten Signalisierungsdaten bzw. Kommunikationsinformationen zwischen den Endgeräten der beiden Teilnehmer A, B,

vorzugsweise gemäss RFC 3261, RFC3311, RFC3262, RFC3264 IETF über ihre σSession Description ^rotocols RFC2327 (SDP) .

Das Internetprotokoll zwischen den SIP-Endgeräte ist vor- zugsweise als SIP oder SIP-T oder SIP-I Protokoll ausgebildet.

Die Endgeräte der Teilnehmer A, B können jedoch auch als ISDN-, POTS-, H.323-, ISUP- oder BICC-basierte Endgeräte ausgebildet sein. Das hier SIP-orientierte Verfahren eignet sich genauso für die dementsprechenden Kommunikationsprotokolle. Beispielsweise kann die Zusatzanwendung AS in einem SIP oder ISDN Interwor- kingpunkt oder gegebenenfalls in einer separaten physikalischen logischen Einheit angeordnet sein.

Die Zusatzanwendung bzw. die Mappingfunktionalität kann in den Einrichtungen CSCF, BGCF des IMS Systems gemäß 3GPP TS 23.002 V6.5.0 (2004-06) Standard oder einem Application Server, oder auch in einer Einrichtung MGCF angeordnet sein.