Die vorliegende Erfindung bezieht sich auf Sitzungseinleitungsprotokoll (SIP, Englisch: Session Initiation Protocol)-Signalgebung und genauer auf Signalgebung, die von so genannten SIP-Explodern verarbeitet und erzeugt wird.

Um die Bereitstellung von Multimedia-Diensten über die Paketschaltungs- bzw. paketvermittelte „Domäne" (Englisch: Packet Switched „Domain") zu unterstützen, hat das 3rd Generation Partnership Project (3GPP) (übersetzt: Partnerschaftsprojekt für die dritte Generation), das für die 3G-Standards verantwortlich ist, ein so genanntes IP Multimedia Core Network Subsystem (IMS) (übersetzt: Internet Protocol Multimedia-Kern-Netzwerk Teilsystem) entwickelt. IMS kommuniziert mit dem Paketschaltungs-Zugangsnetz (Englisch: Packet Switched Access Network) (z.B. GPRS) und enthält alle Elemente, die verwendet werden, um IP-basierte Multimedia-Dienste bereitzustellen. Für einen Anruf von Mobiltelefon zu Mobiltelefon, wobei angenommen ist, dass die Mobiltelefone verschiedenen Netzen angehören, wird ein IMS im Heimnetz (Englisch: Home Network) eines jeden Mobiltelefons bereitgestellt. Jedes IMS ist mit dem GPRS-Netz seines Heimnetzes verbunden. Das Basisprotokoll für Multimedia-Dienste ist das IETF-Sitzungseinleitungsprotokoll (SIP, Englisch: IETF Session Initiation Protokoll)-RFC3261. SIP ermöglicht es einem anrufenden Teilnehmer, eine paketvermittelte Sitzung zu einem angerufenen Teilnehmer herzustellen (durch das Benutzen von in den Benutzerendgeräten installierten, so genannter SIP-Benutzer-Agenten (UAs, Englisch: User-Agents)), obwohl der anrufende Teilnehmer die momentane IP-Adresse des angerufenen Teilnehmers vor dem Initiieren des Anrufs nicht kennt. SIP stellt eine andere Funktionalität bereit, einschließlich des Verhandelns der Sitzungsparameter (z.B. Quality of Service (übersetzt: Dienstqualität) und Codecs, mit Hilfe des Session Description Protocol (übersetzt: Sitzungsbeschreibungsprotokoll), der Steuerung der stattfindenden Sitzungen sowie des Beendens der Sitzungen.

SIP ist selbstverständlich für die Verwendung mit jeder IP-basierten Netzarchitektur ausgelegt und nicht auf 3G-Netze beschränkt. Insbesondere kann SIP verwendet werden, um Sitzungen über das Internet oder IP LANs/WANs herzustellen und zu steuern.

Das Konzept der des SIP-„Exploders" bzw. der SIP-Aufschlüsselungsvorrichtung wurde kürzlich vorgestellt, um verschiedene Funktionalitäten und Dienste, einschließlich Präsenz-Dienste, Push to Talk over Cellular (PoC), Push to Show, etc. zu unterstützen. Diese Funktionalitäten/Dienste haben die Notwendigkeit gemeinsam, Nachrichten an Mitglieder vorbestimmter Empfängergruppen oder Ad-Hoc-Empfängergruppen zu liefern. Der SIP-Exploder ist ein Konzept, das den E-Mail-Diensten entlehnt ist, bei denen eine ähnliche Notwendigkeit entsteht, d.h. die gleichen E-Mail-Nachrichten müssen an Mitglieder von vorbestimmten Mailing-Listen geliefert werden, oder an eine Anzahl von Zieladressen, die in der Nachricht selbst enthalten sind. Der SIP-Exploder ist berücksichtigt in: (1) IETF: Requirements for Session Initiation Protocol (SIP) Exploder Invocation (übersetzt: IETF: Anforderungen für den Aufruf des Sitzungseinleitungs-Protokoll-(SIP)Exploders), draft-camarillo-sipping-exploders-01.txt; (2) IETF: Session Initiation Protocol (SIP) Exploder Invocation (übersetzt: IETF: Aufreuf des Sitzungseinleitungs-Protokoll-(SIP)-Exploders), draft-camarillo-sipping-exploders-01.txt; (3) IETF: Session Initiation Protocol (SIP) Exploder Invocation (übersetzt: Aufruf des Sitzungseinleitungs-Protokoll-(SIP)-Exploders), draft-camarillo-sipping-exploders-solution-00.txt. Der SIP-Exploder erkennt Listen-Bezeichner bzw. -Identifikatoren, in denen SIP-allgemeine Ressourcenbezeichner (URIs, Englisch: Universal Resource Indentifiers) enthalten sind, und agiert demgemäß. Beispielsweise wird der URI sip:list33@somedomain.com (wobei der Teil „somedomain.com" das Heimnetz identifiziert, in dem der sich Exploder befindet) als Verweis auf die Listennummer 33 erkannt. Der SIP-Exploder dupliziert dann die assoziierte Nachricht für jedes Mitglied dieser Liste, und leitet die Nachrichten an die Anrufbearbeitung/Sitzungserkennungsfunktion (S-CSCF, Englisch: Serving Call/Session Control Function) zur Übertragung an ihre Zielorte weiter.

1 veranschaulicht eine typische IMS-Architektur, in welcher ein Proxy-CSCF (P-CSCF) 1 von dem IMS 2 mit einem Benutzerendgerät 3 über ein Paketschaltungs-Zugangsnetz 1 kommuniziert. Der P-CSCF 1 leitet SIP-Signalnachrichten weiter an einen S-CSCF 5, der unter anderem für das Aufrechterhalten von Daten an dem momentanen Standort des Benutzerendgerätes 3 verantwortlich ist. Als Beispiel kann sich ein P-CSCF in einem besuchten Netz oder im Heimnetz befinden, während der S-CSCF sich im Heimnetz des mobilen Endgerätes befinden kann. Die Signalgebung wird durch den S-CSCF an ihren Zielort weitergeleitet, welcher Zielort einen weiteren S-CSCF in dem Ziel-Heimnetz und einen weiteren P-CSCF am besuchten Ziel oder Heimnetz beinhalten könnte.

Eine Anzahl von Anwendungsservern (AS) 6 sind mit dem S-CSCF 5 verknüpft. Diese AS stellen dem IMS verschiedene intelligente Dienste bereit. Der oben vorgestellte SIP-Exploder ist in solch einem AS implementiert.

Es könnte der Fall sein, dass eine Liste, die von einem SIP-Exploder gehalten wird, URIs enthält, die anderen Netzen angehören. Einige dieser URIs können selbst Listen entsprechen bzw. mit Listen korrespondieren, deren Mitglieder nur den Explodern dieser andern Netze bekannt sind. 2 veranschaulicht ein Szenario, bei dem eine Anzahl von IP-basierten Netzen (1 bis 4) Benutzer- und Signalgebungsdaten austauschen, wobei jedes Netz einen SIP-Exploder umfasst. Der Einfachheit halber wurden die SIP-Server (P-CSCF und S-CSCF), die Zugangsnetze und andere Zwischenknoten weggelassen.

Für jedes Netz ist eine Anzahl von Benutzerendgeräten gezeigt, von denen jedes mit dem zugehörigen SIP-Exploder über das Paketschaltungs-Zugangsnetz und das IMS kommuniziert: Der Exploder 1 bedient eine Anzahl von Benutzerendgeräten, die als Endgeräte 1.1, 1.2, 1.3 und 1.4 bezeichnet sind, der Exploder 2 bedient zwei Endgeräte, die als Endgerät 2.1. und Endgerät 2.2. bezeichnet sind, usw. Wenn das Endgerät 1.1 eine Nachricht an eine von Exploder 1 als Host gehaltene Liste schicken will, stellt der Exploder 1 den Exploder-Dienst für dieses Endgerät bereit, d.h. Senden eines Exemplars der SIP-Nachricht an jeden der Listeneinträge.

3 veranschaulicht ein Beispiel eines Betriebs der Exploder, bei dem ein potenziell signifikantes Problem auftritt. In diesem Beispiel ist angenommen, dass das Endgerät 1.1. eine an sip:list1@exploder1 adressierte SIP-INVITE-Anfrage sendet. Die INVITE-Anfrage ist in 3 als Schritt 1 angegeben. Der Exploder 1 empfängt die INVITE-Anfrage (weitergeleitet von dem S-CSCF gemäß der Anwendung eines vorbestimmten Regelsatzes, z.B. Leite an einen Listensatz adressierte Nachrichten an Exploder 1 weiter), die an Liste1 (list1) adressiert ist (Anmerkungen des Übersetzers: 1. Die englischen Ausdrücke „list1" etc. werden nachfolgend mit „Liste1" oder „list1" übersetzt, nicht jedoch in den Adressen, dort bleibt list1 etc.. 2. Der englische Ausdruck „Terminal" wird nachfolgend mit „Endgerät" übersetzt, ausgenommen in den Adressen, dort bleibt „terminal".). Da dies der erste Exploder in dem Pfad ist, wirkt der Exploder 1 als Master (manchmal „Focus" genannt) der Sitzung: diese Rolle ist in dem Fall relevant, in dem ein Mechanismus zum Verwalten der „Floor Control" (übersetzt etwa: Plenarsteuerung) angewendet wird. (Floor Contrl kann beispielsweise verwendet werden, um es nur einem Benutzerendgerät zu gestatten, innerhalb einer Sitzung zu jeder gegebenen Zeit „zu sprechen"). Der Exploder 1 sendet eine INVITE-Anfrage an jeden der Einträge in der Liste1. In diesem Beispiel enthält die Liste1 vier Einträge, die lokalen Endgeräte 1.3 und 1.4, das sich in der Domäne von Exploder 2 befindliche Endgerät 2.2, und eine zum Exploder 2 gehörende Liste2. Während hier das Beispiel der SIP-INVITE-Nachricht verwendet wird, gilt diese Diskussion gleichermaßen für andere SIP-Abläufe wie SUBSCRIBE, MESSAGE, etc.

Ein erstes Problem bei diesem Ablauf tritt auf, weil der Exploder 1 zwei verschiedene INVITE-Anfragen an Empfänger innerhalb des gleichen Netzes senden muß. Die INVITE-Anfragen, die an Terminal 2.2. und list2@eploder2 adressiert sind, folgen dem gleichen Pfad zum gleichen Netz. Dies stellt keine optimale Nutzung von Ressourcen dar. Während das Senden von nur zwei verschiedenen INVITEs kein großes Problem darstellen mag, steht möglicherweise die benötigte Bandbreite und Prozessorleistung nicht zur Verfügung, wenn die Anzahl der Empfänger im Zielnetzwerk hoch (z.B. einige Hundert) ist.

Wenn ferner der in 3 veranschaulichte Ablauf betrachtet wird, empfängt der Exploder 2 die INVITE-Anfragen (Nachrichten 4 und 5). Eine Anfrage ist an das Endgerät 2.2 adressiert und wird an dieses Endgerät als Nachricht 6 geliefert. Die andere Anfrage ist an die Liste2 (bzw. list2) in diesem lokalen Exploder 2 adressiert. Liste2 enthält drei Einträge: das lokale Endgerät 2.1, das entfernte Endgerät 3.4 in der Domäne von Exploder 3 und eine zum Exploder 3 gehörende Liste3. Deshalb generiert der Exploder 2 die Nachrichen 7, 8 und 9. Der gleiche Mangel an effizienter Nutzung von Ressourcen ist auch hier vorhanden: Die Nachrichten 8 und 9 werden dupliziert, obwohl sie den gleichen Satz an Knoten durchlaufen müssen. In ähnlicher Weise empfängt der Exploder 3 die INVITE-Anfragen (Nachrichten 8 und 9). Eine Anfrage ist an das Endgerät 3.4 adressiert und wird als Nachricht 10 geliefert. Die andere Anfrage ist an die Liste3 am lokalen Exploder 3 adressiert. Die Liste3 enthält zwei Einträge: das lokale Endgerät 3.2 und das Endgerät 4.2 am Exploder 4. Diese ergeben die Nachrichten 11 und 12.

Ein zweites Problem, das als Ergebnis des herkömmlichen Ablaufs auftritt, ist der lange Pfad der SIP-Signalgebung, der zwischen den Rand-Endpunkten erzeugt wird. Beispielsweise muss die SIP-Nachricht, wenn das Endgerät 4.2 irgendeine mit der hergestellten Sitzung in Verbindung stehende SIP-Nachricht sendet, den Exploder 4, Exploder 3, Exploder 2, Exploder 1 durchlaufen, bis sie schließlich an das Endgerät 1.1 geliefert wird. Dies ist notwendig, vorausgesetzt dass jeder Exploder, aus SIP-Sicht, ein UA Client oder Server ist, der mit einem bestimmten Abschnitt (Englisch: Leg) der Sitzung assoziiert ist.

Dies schafft ein Problem für Echtzeit-Anwendungen, die SIP beinhalten (aber nicht darauf beschränkt sind). Wenn ein Floor Control Mechanismus installiert ist, und die Floor-Control Signalgebung (Englisch: Floor Control Signalling) dem anfänglichen Signalgebungspfad folgt, wird der Exploder 1 als Floor-Steuerungsmanager agieren. Endgeräte, die auf dem Signalpfad „weit entfernt" sind, werden den Floor von dem Master-Exploder der Sitzung (Exploder) her anfragen müssen, und diese Anfrage wird Zeit brauchen, um die Kette von Explodern zu durchlaufen. Als Folge davon können Benutzer keine wirkliche Echtzeit-Erfahrung machen.

Ein drittes Problem beim herkömmlichen Ablauf wird nun mit Verweis auf 4, die auf den Ablauf aus 3 folgt, identifiziert. Es wird angenommen, dass die Liste3 im Exploder 3 zwei Einträge enthält: einen, der auf das lokale Endgerät 3.2 hinweist, und einen, der auf eine Liste1 am Exploder 1 hinweist. Der Exploder 3 sendet die INVITE-Anfrage an list1@exploder1 (Nachricht 12 in 4). Wenn der Exploder 1 die INVITE-Anfrage empfängt, ist er nicht in der Lage, zu bestimmen, dass das INVITE bereits aufgeschlüsselt bzw. „explodiert", und von der gleichen Liste (Nachricht 1) ausgeführt wurde, so das der Exploder 1 den Prozess erneut startet und ein Exemplar der INVITE-Anfrage an die vier Einträge der Liste1 sendet. So ist der Signalgebungsverlauf in eine Schleife eingetreten.

Es wird festgestellt, dass eine einzelne SIP-Nachricht, die von einem initiierenden Endgerät gesendet wird, vielfältige Zieladressen enthalten kann, von denen keine eine Listenadresse ist. Nichtsdestoweniger könnten in diesem Szenario ähnliche Probleme wie die oben identifizierten auftreten, z.B. vielfältige Nachrichten, die an das gleiche Zielnetz gesendet werden.

Es wird ebenso als günstig angesehen werden, dass die initiierende Nachricht eine Nachricht vom Typ SIP EXPLODE sein kann, die eine weitere komplette SIP-Nachricht oder ein Fragment einer weiteren SIP-Nachricht (z.B. INVITE) zusammen mit einer Sammlung von Zieladressen trägt. Der empfangende Exploder sendet die gekapselte INVITE-Nachricht an die verschiedenen Zieladressen an diesen Benutzer. Erneut treten wahrscheinlich die oben identifizierten Probleme auf, wenn SIP-EXPLODE-Nachrichten auf diese Weise verwendet werden.

Es ist Ziel der vorliegenden Erfindung, es zu ermöglichen, dass Verkehr zwischen Domänen (Englisch: Interdomain Traffic) auf effiziente Weise mit einer minimalen Anzahl von Nachrichten transportiert wird. Die Anzahl der Nachrichten, die zwischen zwei Domänen ausgetauscht werden, sollte nicht von der Anzahl der Empfänger abhängen. Die Echtzeit-Charakteristik der Signalgebung darf nicht abhängig sein von der Anzahl der Exploder, die in einer Sitzung mit mehreren Teilnehmern involviert sind, und darf nicht negativ beeinflusst werden durch das Vorhandensein von mehreren Explodern in der Sitzung. Es sollte hier einen Mechanismus geben, um Schleifen zu erkennen und zu vermeiden, die durch die Konkatenation bzw. Verkettung mehrerer Listen entsteht.

Nach dem ersten Aspekt der vorliegenden Erfindung wird ein Verfahren bereitgestellt zum Liefern eines Exemplars einer Sitzungseinleitungsprotokoll-Nachricht, SIP-Nachricht, an jedes einer Vielzahl von Endgeräten in einem Multimedia-Kommunikationssystem, das Verfahren umfassend:

Empfangen der Nachricht an einem ersten SIP-Exploder;

Gruppieren von Zieladressen, die für die SIP-Nachricht nach ihren Netzdomänen definiert sind; und

für jede Gruppe von Zieladressen, die einer Domäne entsprechen bzw. mit einer Domäne korrespondieren, die mit einem weiteren SIP-Exploder assoziiert ist, Weiterleiten eines einzelnen Exemplars der Nachricht an diesen Exploder, wobei die Nachricht sämtliche der Zieladressen der Gruppe enthält.

Typischerweise ist der SIP-Exploder ein Anwendungsserver, der SIP-Nachrichten über einen SIP-Proxyserver empfängt und sendet. In dem Beispiel einer 3G-Implementierung der Erfindung, kann der SIP-Proxyserver ein Serving Call/Session Control Function (S-CSCF) sein. Der S-CSCF leitet wahlweise SIP-Nachrichten an die Exploder nach einem vorbestimmten Regelsatz weiter. Selbstverständlich kann der Exploder in manchen Implementierungen SIP-Nachrichten direkt von dem SIP-Endgerät empfangen.

Eine Zieladresse kann die Adresse eines Endgerätebenutzers oder eine Identifikation einer Liste von Endgerätebenutzern und/oder anderen Listen sein.

In dem Fall, dass eine SIP-Nachricht im Zielfeld eine Liste enthält, werden die Mitglieder der Liste vom Exploder identifiziert, wenn die Liste zur gleichen Domäne gehört wie der Exploder, und die Nachricht wird zu jedem der identifizierten Mitglieder gesendet.

Die Nachricht, die am ersten SIP-Exploder empfangen wird, kann innerhalb einer Nachricht vom Typ SIP EXPLODE transportiert werden, in diesem Fall können die Zieladressen in der SIP-EXPLODE-Nachricht enthalten sein.

Nach einem zweiten Aspekt der vorliegenden Erfindung wird ein Verfahren zum Liefern eines Exemplars einer Sitzungseinleitungsprotokoll-Nachricht, SIP-Nachricht, an jedes einer Vielzahl von Endgeräten in einem Multimedia-Kommunikationssystem bereitgestellt, das Verfahren umfassend:

Empfangen einer SIP-Nachricht an einem ersten SIP-Exploder, wobei die Nachricht als Zieladresse eine Adresse einer Liste enthält, die mit einem weiteren SIP-Exploder assoziiert ist;

Weiterleiten eines Exemplars der Nachricht an den weiteren SIP-Exploder, wobei die Nachricht als Zieladresse die Listenadresse enthält;

an dem weiteren SIP-Exploder, Bestimmen ob die Liste eine Zieladresse enthält, die mit einem weiteren Exploder assoziiert ist und, wenn ja, Zurückgeben einer SIP-REFER-Nachricht an den ersten Exploder, wobei die REFER-Nachricht diese Zieladresse enthält.

Nach einem dritten Aspekt der vorliegenden Erfindung wird ein Verfahren bereitgestellt zum Liefern einer SIP-Nachricht an eine Vielzahl von Endgeräten in einem Multimedia-Kommunikationssystem, das das Sitzungseinleitungsprotokoll (SIP) verwendet, das Verfahren umfassend:

für eine gegebene SIP-Nachricht, an einem SIP-Exploder Aufzeichnen der Zieladressen, an die diese Nachricht von diesem Exploder gesendet wurde, und Vergleichen der Zieladressen, die mit nachfolgenden Anfragen, die gleiche Nachricht zu senden, assoziiert ist, mit der aufgezeichneten Adressen, um das Senden von doppelten Nachrichten an die gleichen Zieladressen zu vermeiden.

In einer Ausführungsform sind der erste, zweite und dritte Aspekt der Erfindung in einem einzigen System implementiert. Andere Ausführungsformen können nur einen oder zwei Aspekte verwerten.

Andere Aspekte der Erfindung sind in den beigefügten Ansprüchen dargelegt.

1 veranschaulicht schematisch die IMS-Architektur;

2 veranschaulicht schematisch eine Umgebung mit mehreren Netzen, in der jedes Netz seinen eigenen SIP-Exploder aufweist;

3 veranschaulicht die SIP-Signalgebung, die mit dem Einrichten einer Multimediasitzung in der Umgebung aus 2 assoziiert ist;

4 veranschaulicht einen modifizierten SIP-Signalgebungsablauf, der mit dem Einrichten einer Multimediasitzung in der Umgebung aus 2 assoziiert ist; und

5 veranschaulicht weiter den modifizierten SIP-Signal-gebungsablauf aus 4.

Hier wird ein neuer Ablauf zur Verarbeitung von SIP-Nachrichten beschrieben, der darauf abzielt, die oben genannten Probleme der herkömmlichen Abläufe zu lösen. Die Grundsätze der Lösung sind:

• 1. Der erste Exploder in jeder Kette wird als „Master"-Exploder der Sitzung angewiesen.
• 2. Nachfolgende Exploder werden als „Slave"-Exploder angewiesen.
• 3. Der Master-Exploder darf ein Exemplar der SIP-Nachricht an lokale Ressourcen sowie an Ressourcen in verschiedenen Netzen (z.B. unter der Steuerung durch andere Exploder) senden.
• 4. Ein Master-Exploder, der ein Exemplar einer SIP-Anfrage an eine Anzahl von Ressourcen sendet, sendet ein einziges Exemplar der SIP-Anfrage pro Zielnetz, wobei die Anfrage an den Exploder gesendet wird, der das Zielnetz steuert und jeden der beabsichtigen Endbenutzer in diesem Zielnetz identifiziert.
• 5. Ein Slave-Exploder, der eine SIP-Anfrage empfängt, darf ein Exemplar der SIP-Nachricht nur an seine lokalen Ressourcen senden. Wenn aufgrund einer Listenerweiterung der Slave-Exploder ein Exemplar der SIP-Anfrage an Ressourcen senden muss, die nicht unter seiner eigenen Steuerung sind, sendet er eine SIP-REFER-Anfrage zurück an den Master-Exploder, wobei die REFER-Anfrage die Liste der externen Ressourcen enthält, die kontaktiert werden müssen.
• 6. Ein Master-Exploder, der eine SIP-REFER-Anfrage empfängt, die ein oder mehrere Ziele identifiziert, generiert ein Exemplar der anfänglichen SIP-Anfrage und sendet es an das richtige Ziel bzw. die richtigen Ziele mit den gleichen Einschränkungen wie oben unter Punkt 3 und 4 beschrieben.
• 7. Der Master-Exploder hält Aufzeichnungen aller der Zieladressen bereit, an die er Nachrichten gesendet hat, um es zu ermöglichen, das ein Senden von doppelten Nachrichten an den gleichen Benutzer vermieden wird, z.B. wenn ein Benutzer zwei geschachtelten Listen angehört.

Das Konzept des SIP-Exploders wurde oben vorgestellt. Listen werden an Exploder durch die Verwendung mehrerer verschiedener Mechanismen definiert. Beispielsweise könnte sich ein Benutzer auf eine Webseite einloggen und seine Listen interaktiv verwalten. Alternativ könnte ein spezifisches Protokoll verwendet werden. Die IETF arbeitet an einem Protokoll, nämlich XCAP (XML Configuration Access Protocol) (übersetzt: XML Konfigurationszugangsprotokoll), das die Funktionalität der Listenkonfiguration bereitstellt. 3GPP hat eine Schnittstelle zwischen dem Anwendungsserver (der Exploder ist ein Anwendungsserver) und den IMS-Endgeräten definiert. Diese Schnittstelle wird Ut Schnittstelle genannt, und das Protokoll wird als XCAP bezeichnet. Noch eine weitere Alternative ist es, dass Netzwerkadministratoren Listen verwalten.

5 veranschaulicht den vorgeschlagenen Ablauf, wobei wieder das Beispiel der SIP-INVITE-Nachricht verwendet wird. Es wird angenommen, dass die Nachricht die gleichen Eigenschaften aufweist, wie die Nachricht, die in dem Beispiel verwendet wird, das mit Verweis auf die 2 und 3 beschrieben ist. Das Endgerät 1.1 sendet die an list1@exploder1 adressierte SIP-INVITE-Anfrage. Da Exploder1 der erste Exploder in der Kette ist, übernimmt er die Rolle des Master-Exploders für die Sitzung, und signalisiert seine Rolle in den SIP-Nachrichten, die er nachfolgend sendet. Dies kann erreicht werden durch Verwenden des existierenden „Ist Focus" Parameters, der in dem SIP-Kontakt-Nachrichtenkopf (Englisch: SIP Contact Header) enthalten sind. Wenn ein Benutzeragent einen „Ist Focus" Parameter in diesen Nachrichtenkopf einfügt, signalisiert er, dass er als ein Focus für ein zentralisertes Konferenzsystem agiert. Der „Ist Focus"-Parameter ist definiert in: draft-ietf-sip-callee-caps-02.txt.

Der Exploder 1 empfängt die INVITE-Anfrage (Nachricht 1 in 5) und evaluiert den Inhalt von Liste1 (Anmerkung des Übersetzers: Liste1 = list1, Liste2 = list2, etc.). Liste1 enthält Einträge für zwei lokale Endgeräte, so dass der Exploder 1 eine INVITE-Anfrage an jedes dieser Endgeräte sendet (Nachrichten 2 und 3). Liste1 enthält auch zwei Einträge, die zu der gleichen administrativen Domäne gehören, d.h. „Exploder2". Diese beiden Einträge sind terminal2.2@exploder2 und list2@exploder2. Der Exploder 1 sendet eine einzelne INVITE-Anfrage (Nachricht 4), die sowohl an terminal2.2@exploder2 als auch an list2@exploder2 adressiert ist.

Der Exploder 2 empfängt die INVITE-Anfrage (Nachricht 4), die sowohl an das lokale Endgerät 2.2 als auch an Liste2 adressiert ist. Er bestimmt aus der Nachricht 4, dass er nicht der Master-Exploder der Sitzung ist, somit übernimmt er die Rolle des Slave-Exploders der Sitzung. Der Exploder 2 generiert dann eine INVITE-Anfrage und sendet sie an das Endgerät 2.2 (Nachricht 5). Dann evaluiert der Exploder 2 die Liste2 und findet drei Einträge: eine davon ist lokal (Endgerät 2.1), die anderen beiden sind es nicht, (terminal3.4@exploder3 und list3@exploder3). Da der Exploder 2 die Rolle des Slave-Exploders der Sitzung übernommen hat, generiert er nur ein Exemplar der INVITE-Anfrage für das lokale Endgerät: Er generiert keine Exemplare der INVITE-Anfrage für Einheiten (Englisch: Entities), die sich ausserhalb seiner eigenen Steuerung befinden. Stattdessen sendet er eine SIP-REFER-Anfrage [IETF: The Session Initiation Protocol (SIP) Refer Method, übersetzt: IETF: Verweisverfahren für das Sitzungseinleitungsprotokoll-(SIP), RFC 3515] zurück an den Exploder 1 (Nachricht 7 in 5). Die REFER-Anfrage enthält die Inhalte der Liste2, die nicht lokal dem Exploder 2 angehören, d.h. terminal3.4@exploder3 und list3@exploder3.

Der Exploder 1 empfängt die REFER-Anfrage und sammelt die Adressen, die in der Nachricht enthalten sind, in Gruppen nach ihren lokalen Netzen. In diesem Beispiel sind beide Adressen in der REFER-Anfrage (Nachricht 7) Teil des Netzes, das vom Exploder 3 gesteuert wird. Deshalb generiert der Exploder 1 eine neue INVITE-Anfrage, die an terminal3.4@exploder3 und list3@exploder3 adressiert ist und er sendet sie an den Exploder 3 (Nachricht 8 in 5). Die INVITE-Anfrage enthält wieder einen Hinweis, dass der Exploder 1 als Master-Exploder der Sitzung agiert.

Der Exploder 3 empfängt die INVITE-Anfrage (Nachricht 8), und er sendet ein Exemplar an sein lokales Endgerät 3.4 (Nachricht 9). Dann evaluiert er das andere Ziel, nämlich Liste3. Die Liste3 enthält zwei Einträge, einen lokalen (Endgerät 3.2), somit sendet der Exploder 3 ein Exemplar der INVITE-Anfrage an das Endgerät 3.2 (Nachricht 10). Der andere Eintrag in Liste3 weist auf terminal4.2@exploder4. Da der Exploder 3 nicht der Master-Exploder der Sitzung ist, sendet der Exploder 3 keine INVITE an Resourcen ausserhalb seiner eigenen Domäne. Statt dessen generiert der Exploder 3 eine REFER-Anfrage (Nachricht 11 in 5) mit terminal4.2@exploder4 als endgültiges Ziel und sendet sie zurück an den Exploder 1.

Der Exploder 1 empfängt die REFER-Anfrage (Nachricht 11 in 5) und generiert ein Exemplar der INVITE-Anfrage, die an terminal4.2@exploder4 (Nachricht 12) adressiert ist. Wenn der Exploder 4 die INVITE-Anfrage empfängt, schlüsselt er auf bzw. explodiert er nur an seine lokalen Ressourcen, in diesem Fall Endgerät 4.2 (Nachricht 13).

Obwohl in diesem Beispiel die ursprüngliche SIP-INVITE-Nachricht nur eine einzige Zieladresse enthält (i.e. list1@exploder1), kann die Nachricht vielfältige Zieladressen enthalten. Diese Option wird z.B. in so genannten Push-to-Talk Over Cellular (POC) Diensten verwendet.

In einer Variation des oben beschriebenen Ablaufs können SIP-Nachrichten, die für viele Benutzer bestimmt sind, in einer Nachricht vom Typ SIP EXPLODE transportiert werden sein. Die Zieladressen sind in der EXPLODE-Nachricht enthalten. Eine S-CSCF-Verknüpfung bzw. ein S-CSCF-Knoten wird automatisch Nachrichten vom Typ EXPLODE an den angehängten Exploder weiterleiten.

Die hier vorgestellte Lösung ist angemessen, denn der eingerichtete Signalgebungspfad weist eine Stern-Konfiguration auf, wobei der Master-Exploder im Zentrum des Sterns und die Slave-Exploder um die Peripherie herum, anstatt in einer Kette angeordnet sind. Jede nachfolgende Signalgebung zwischen zwei beliebigen Endgeräten wird höchstens zwei Exploder durchlaufen müssen, unabhängig von der gesamten Anzahl der Exploder in der Sitzung. Die Echtzeit-Eigenschaften einer Sitzung hängen nicht kritisch von der Anzahl der Exploder in der Sitzung ab.

5 veranschaulicht wie der gleiche SIP-Signalgebungsablauf auch das oben identifizierte Schleifenproblem löst. Wenn man den Exploder 3 in Betracht zieht, wenn er eine INVITE-Anfrage (Nachricht 8) empfängt, die unter anderem an list3@exploder3 adressiert ist, wird er nicht an Ressourcen explodieren, die sich ausserhalb seiner eigenen Steuerung befinden. Deshalb wird er eine REFER-Anfrage zurück an den Exploder 1 (Nachricht 11) senden, wobei die REFER-Anfrage angibt, dass list1@exploder1 kontaktiert werden muss.

Der Exploder 1 ist sich dessen bewusst, dass er als der Master-Exploder für die Sitzung agiert. Er hält eine Liste sämtlicher momentan involvierten Ressourcen bereit, direkt (Endgeräte und Listen) oder indirekt (Ressourcen in Listen). Deshalb ist sich der Exploder 1 dessen bewusst, dass list1@exploder1 schon erweitert wurde und dass jeder Eintrag schon kontaktiert und zur Sitzung hinzugefügt wurde. Deshalb ist es nicht nötig, list1@exploder erneut zu erweitern. Der Ablauf des Einrichtens der Sitzung wird als vollständig angesehen, und es erfolgen während dieser Phase an dem Exploder 1 keine weiteren Aktionen.