-
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 DSS1-Protokoll) oder über
als Media Gateway Controller (MGC) ausgebildete Vermittlungsstellen
(z. B. über
ein ISUP-Protokoll) angeschlossen. Die Nutzinformationen selbst
werden über
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 Call
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 (Session 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 Standardisierungsgremium
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 Anmelde-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, Rosenberg, J. et
al.) vom Standardisierungsgremium 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.
Redirect-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 „Request-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 eine 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 Resourcen-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öglichkeiten)
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 dem kennzeichnenden Teil 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 eine 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 gezwungenen Forking bis zu den Endgeräten des zweiten Teilnehmers ausgeführt wird,
werden erfindungsgemäß alle Endgeräte eine
Anruf-Anfrage vom ersten Teilnehmer erhalten und 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 Mappingfunktionalitä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 Aktualisierung-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-Meldung
(INVITE) das letzte gültige
SDP eines Endgeräts
des zweiten Teilnehmers gesendet werden, oder anschließend eine
neue Anmelde-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-programmierte 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:
-
1:
ein Kommunikationssystem mit SIP-Teilnehmern;
-
2:
skizzierte Schritte des erfindungsgemäßen Verfahrens.
-
Die 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
B1, 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 Signalisierungspfad) und
Nutzinformationen durchgeführt.
Die Signalisierungsinformationen 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 Kommunikation
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 2 wird
nun gemäss 1 das
Verfahren zur Kommunikation zwischen einem Endgerät eines
ersten Teilnehmers A und gemäss
einem Internetprotokoll signalisierbaren Endgeräten B1, 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 B1 des
zweiten Teilnehmers B eingeleitet, indem eine Einlade-Meldung INVITE
aus dem Endgerät
des ersten Teilnehmers A an das erste Endgerät B1, 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
B1, 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 B1,
B2, B3 des zweiten Teilnehmers B ausgeführt, derart dass potentielle
Antworten mit Kommunikationsinformationen (= SIP-basierte Signalisierungsdaten
200 OK, 18x, SDP1, 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 (=
gabelungsförmig angerufenen)
Endgeräten
B1, 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 B1, B2, B3 zumindest an
der Zusatzanwendung AS durch Signalisierung informiert bzw. wird
es ermöglicht,
dass im Falle von SIP-Telefonen alle Endgeräte B1, 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 Kommunikationspfad
dynamisch hinzufügbare
Einheit sein.
-
Im
Folgenden wird ausführlicher
das Verfahren gemäss 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 B1 (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 Anmelde-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
B1 übermittelt
werden. Da die Anmelde-Meldung INVITE über die Zusatzanwendung AS
geführt
ist/wird, wird ein Forking FORK aus der Zusatzanwendung eingeleitet,
so dass jeweils eine Anmelde-Meldung INVITE jeweils an ein mögliches Endgerät B1, B2,
B3 mit SDP vom ersten Teilnehmer A gesendet wird.
-
Es
kann sein, dass das erste Endgerät
B1 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 SDP1
(Session Description Protocol aus B1) über die Zusatzanwendung AS
an den ersten Teilnehmer A (siehe Schritt 2). Gleichzeitig setzt
das erste Endgerät
B1 ein eigenes TO-tag auf (= „early
dialogue" mit B1)
18x. Es kann jedoch auch sein, dass das erste Endgerät B1 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 B1 aufbauen kann.
-
Im
Schritt 3 wird nun eine neu entstehende (da geforkte) Anmelde-Meldung
INVITE aus der Zusatzanwendung AS an das zweite Endgerät B2 übermittelt,
wobei das Senden dieser zweiten Anmelde-Meldung INVITE parallel
oder sequentiell erfolgen kann.
-
In
der Zwischenzeit (z. B. als der Dialog von A mit B1 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 B1, 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 unterstü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 Zuatzanwendung 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 offer/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 B1 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 sagen
zu.
-
Nun
kann die Zusatzanwendung AS gegebenenfalls die Aktualisierung-Meldung
UPDATE (die zuvor noch nicht gesendet werden konnte senden (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
B1, 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 B1 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 telefonieren.
Weiterhin können
die anderen Endgeräte
B1, 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. B1) 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 RFC3261, RFC3311, RFC3262, RFC3264
IETF über
ihre Session Description Protocols RFC2327 (SDP).
-
Das
Internetprotokoll zwischen den SIP-Endgeräte ist vorzugsweise 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 Interworkingpunkt 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.