-
Die
vorliegende Erfindung bezieht sich allgemein auf das Gebiet von
Kommunikationsprotokollen und -systemen und genauer ausgedrückt auf
nachrichtenbasierte Kommunikationen, bei denen Nachrichten zwischen
Endpunkten über
ein oder mehrere Zwischenelemente kommuniziert werden.
-
Viele
Kommunikationssysteme verwenden ein nachrichtenbasiertes Anforderung-Antwort-Kommunikationsprotokoll
zum Kommunizieren zwischen einem Quellelement und einem Bestimmungselement.
Oft werden Anforderungs- und Antwortnachrichten über ein Zwischenelement gesendet,
das empfangene Nachrichten an das geeignete Bestimmungselement weiterleitet.
-
Ein
Sitzungsinitiierungsprotokoll (SIP; SIP = Session Initiation Protocol)
ist ein Beispiel für
ein derartiges Kommunikationsprotokoll, das in der Kommentaranforderung
(RFC; RFC = Request for Comments) 3261 als ein Anwendungsschichtsteuer-
und Signalisierungsprotokoll zum Einrichten, Modifizieren und Abschließen von
Echtzeitrufen und -konferenzen hauptsächlich über Internetprotokoll-Netzwerke (IP-Netzwerke;
IP = Internet Protocol) definiert ist. Diese Vorgänge werden
durch ein Senden von Anforderungen und ein Empfangen von Antworten
in der Form von SIP-Nachrichten von einem SIP-Element zu einem anderen
bewirkt.
-
Unter
einigen Umständen
kann es notwendig sein, dass ein Zwischenelement Informationen an
ein Quellelement kommuniziert, es kann jedoch sein, dass zwischen
einem Zwischenelement und einem Quellelement kein direkter Zweiweg-Kommunikationspfad
existiert. In derartigen Fällen
besteht der einzige Weg für
ein Zwischenelement, um mit einem Quellelement Informationen zu
kommunizieren, darin, auf eine Antwortnachricht zu warten, die von
dem Bestimmungselement gesendet werden soll und auch über das
Zwischenele ment gesendet wird, und die Informationen, die kommuniziert
werden sollen, zu der Antwortnachricht hinzuzufügen. Wenn ein Zwischenelement
Nachrichten von mehreren Quell- und Bestimmungselementen empfängt, ist
zusätzlich
ein Mechanismus erforderlich, um zu ermöglichen, dass das Zwischenelement
bestimmt, welche Antwortnachrichten welchen Anforderungsnachrichten
zugeordnet sind. Bei einem SIP entsteht eine derartige Situation
bei einer Verwendung einer SIP-Nachrichtenkomprimierung,
bei der die Informationen, die kommuniziert werden sollen, sich
auf eine Nachrichtenkomprimierung beziehen, wie es in RFC 3486 definiert
ist. RFC 3486 beschreibt, wie SIP-Nachrichten komprimiert sein können, und
liefert einen Parameter, der zu einer SIP-Nachricht hinzugefügt werden kann, um anzuzeigen,
ob ein Element die SIP-Komprimierung unterstützt.
-
Zum
Beispiel kann eine SIP-Anforderungsnachricht, die von einem Quellelement über ein
Zwischenelement an ein Bestimmungselement gesendet wird, Informationen
enthalten, die anzeigen, dass das Quellelement eine SIP-Komprimierung
unterstützt.
Wenn das Zwischenelement ebenfalls eine Komprimierung unterstützt, dann
müssen
die Informationen gegebenenfalls an das Quellelement zurück kommuniziert
werden, um zu ermöglichen,
dass zukünftige
Kommunikationen zwischen dem Quell- und dem Zwischenelement unter
Verwendung einer Komprimierung stattfinden. Das Zwischenelement erreicht
dies durch ein Einfügen,
auf ein Empfangen einer entsprechenden Antwortnachricht hin, die durch
das Bestimmungselement an das Quellelement gesendet wird, von Informationen
in die Nachricht zum Anzeigen an das Quellelement, dass das Zwischenelement
ebenfalls eine Komprimierung unterstützt.
-
Da
ein Zwischenelement, wie z. B. ein SIP-Proxy, typischerweise Nachrichten
von mehreren Bestimmungen empfängt,
muss eine Kontextdatenbank aufrechterhalten werden, um zu ermöglichen,
dass das Zwischenelement entsprechende Anforderungs- und Antwortnachrichten
zusammenpaart, die einen Teil der gleichen Transaktion bilden. Derartige
Techniken, wie dieselben z. B. in RFC 3486 beschrieben sind, erfordern
Zwischenelemente wie z. B. Proxy-Server in dem Antwortpfad, um lokal
Dialog- oder Transaktionskontextinformationen zu speichern – mit anderen
Worten erfordern die gegenwärtig
vorgeschlagenen Techniken eine Verwendung von zustandsbetonten Elementen.
-
Zustandsbetonte
Elemente erfordern die Bereitstellung von zusätzlicher Speicherkapazität, Datenbanken,
Nachschlagroutinen, Wertlose-Daten-Sammelroutinen und dergleichen,
die wertvolle Verarbeitungsressourcen aufbrauchen und typischerweise
die Kosten und Entwicklungszeiten derartiger Geräte erhöhen. Bei einem SIP z. B. befinden sich
komprimierungsaktivierte Proxy-Server oft an dem Gateway zwischen
ortsfesten und drahtlosen Netzwerken und stellen allgemein wesentliche
Netzwerkelemente dar, die sowohl eine hohe Leistungsfähigkeit
als auch eine hohe Verfügbarkeit
erfordern.
-
Wie
Fachleute erkennen werden, ist das Erfordernis, ein Element hochverfügbar zu
machen, schwierig und kostenaufwändig,
insbesondere wenn große
Mengen an Kontextdaten aufbewahrt werden muss. Ferner führt die
Bereitstellung von Hochverfügbarkeitsmechanismen
typischerweise zu einer gewissen Reduzierung der Leistungsfähigkeit,
was insbesondere z. B. bei Telekommunikationsanwendungen unerwünscht ist,
wo die Anzahl von gleichzeitigen Rufen, die durch ein Element gehandhabt
werden kann, die oft ein erheblicher Unterscheidungsfaktor zwischen
Konkurrenzprodukten ist, direkt in einem Zusammenhang mit der Leistungsfähigkeit
des Systems steht.
-
Folglich
ist es ein Ziel der vorliegenden Erfindung, zumindest einige der
oben erwähnten
Probleme zu mildern.
-
Gemäß einem
ersten Aspekt der vorliegenden Erfindung wird ein Verfahren gemäß Anspruch
1 geschaffen zum Kommunizieren von Informationen zwischen einem
Zwischenelement und einem Quellelement in einem nachrichtenbasierten
Kommunikationssystem, bei dem eine Anforderungsnachricht von dem
Quellelement an ein Bestimmungselement gesendet wird und ansprechend
auf dieselbe eine entsprechende Antwortnachricht von dem Bestimmungselement
an das Quellelement gesendet wird, wobei die Anforderungs- und die
Antwortnachricht über
ein Zwischenelement gesendet werden, das angeordnet ist, um die
Nachrichten an das geeignete Element weiterzuleiten. Das Verfahren
umfasst an dem Zwischenelement und vor einem Weiterleiten einer
empfangenen Anforderungsnachricht ein Bestimmen des Vorhandenseins
einer Anzeige der Informationen, die kommuniziert werden sollen,
in der empfangenen Anforderungsnachricht, und, wenn vorhanden, Hinzufügen eines
temporären
Identifizierers, der dem Zwischenelement zugeordnet ist, zu der
Nachricht in einer derartigen Weise, dass der temporäre Identifizierer
in der entsprechenden Antwortnachricht enthalten ist. Vor einem
Weiterleiten einer empfangenen Antwortnachricht umfasst das Verfahren:
Bestimmen des Vorhandenseins eines temporären Identifizierers, der dem
Zwischenelement zugeordnet ist, und, wenn vorhanden, Ersetzen des
temporären Identifizierers
durch die Informationen, die an das Quellelement kommuniziert werden
sollen.
-
Vorteilhafterweise
beseitigt dies die Notwendigkeit, nachrichtenbezogene Kontextinformationen zu
speichern, und beseitigt somit die Notwendigkeit nach zugeordneten
Datenbanknachschlagroutinen, Wertlose-Daten-Sammelroutinen und dergleichen.
-
Geeigneterweise
ist der temporäre
Identifizierer in dem System unzweideutig.
-
Geeigneterweise
umfasst der Schritt des Hinzufügens
des temporären
Identifizierers ferner ein Hinzufügen von zusätzlichen Informationen zum Identifizieren
des Typs von Informationen, die an das Quellelement kommuniziert
werden sollen.
-
Das
nachrichtenbasierte Kommunikationssystem kann ein Sitzungsinitiierungsprotokoll-basiertes
System (SIP-basiertes
System) sein, wobei das Zwischenelement ein SIP-Proxy-Server ist, wobei in dem Falle
die Anforderungsnachricht eine SIP-Anforderungsnachricht sein kann,
und wobei die Antwortnachricht eine SIP-Antwortnachricht sein kann.
In diesem Falle umfasst der Schritt des Bestimmens des Vorhandenseins
in der empfangenen Anforderungsnachricht ferner ein Bestimmen des
Vorhandenseins eines SIP-Komprimierungsparameters.
-
Die
Anforderungsnachricht umfasst geeigneterweise den URI des SIP-Proxy,
und dann umfasst der Schritt des Hinzufügens des temporären Identifizierers
ferner ein Hinzufügen
des temporären
Identifizierers zu dem URI des SIP-Proxy.
-
Geeigneterweise
umfasst der Schritt des Bestimmens des Vorhandenseins des temporären Identifizierers
in einer Antwortnachricht ferner ein Bestimmen des Vorhandenseins
des temporären
Identifizierers in dem URI des SIP-Proxy in der Antwortnachricht.
-
Der
Schritt des Ersetzens des temporären Identifizierers
umfasst ferner bevorzugt ein Ersetzen des temporären Identifizierers durch einen
SIP-Komprimierungsparameter.
-
Geeigneterweise
werden zukünftige
Anforderungsnachrichten von dem Quellelement an den SIP-Proxy unter
Verwendung einer Komprimierung gesendet, wenn der SIP-Proxy dem
Quellelement vorhergehend angezeigt hat, dass der Proxy eine SIP-Komprimierung
unterstützt.
-
Gemäß einem
zweiten Aspekt der vorliegenden Erfindung wird ein SIP-Proxy gemäß Anspruch
9 geschaffen, der zum Wirksamsein gemäß einem der oben beschriebenen
Verfahrensschritte angepasst ist.
-
Gemäß einem
dritten Aspekt wird eine Vorrichtung gemäß Anspruch 10 zum Weiterleiten
von Nachrichten in einem nachrichtenbasierten Kommunikationssystem
geschaffen, bei dem eine Anforderungsnachricht von einem Quellelement
an ein Bestimmungselement gesendet wird und ansprechend auf dieselbe
eine Antwortnachricht von dem Quellelement an das Bestimmungselement
gesendet wird, wobei das System derart angeordnet ist, dass Nachrichten über die
Vorrichtung zum Weiterleiten zu dem geeigneten Bestimmungsort derselben
gesendet werden, mit einer Einrichtung zum Bestimmen, vor einer
einem Weiterleiten einer empfangenen Anforderungsnachricht, des
Vorhandenseins einer Anzeige der Informationen, die kommuniziert
werden sollen, in der empfangenen Anforderungsnachricht, wobei die
Einrichtung, wenn das Vorhandensein der Anzeige bestimmt wird, zum
Hinzufügen
eines temporären Identifizierers,
der dem Zwischenelement zugeordnet ist, zu der Nachricht angeordnet
ist, in einer derartigen Weise, dass der temporäre Identifizierer in der entsprechenden
Antwortnachricht enthalten ist; und eine Einrichtung zum Bestimmen,
vor einem Weiterleiten einer empfangenen Antwortnachricht, des Vorhandenseins
eines temporären
Identifizierers, der dem Zwischenelement zugeordnet ist, in der
empfangenen Antwortnachricht, wobei die Einrichtung angeordnet ist
zum Ersetzen des temporären
Identifizierers durch die Informationen, die an das Quellelement
kommuniziert werden sollen, wenn das Vorhandensein des temporären Identifizierers
bestimmt wird.
-
Nun
wird ein Ausführungsbeispiel
der vorliegenden Erfindung lediglich beispielhaft unter Bezugnahme
auf die zugehörigen
Diagramme beschrieben, in denen:
-
1A ein
Blockdiagramm ist, das ein SIP-Netzwerk gemäß dem Stand der Technik zeigt;
-
1B ein
Nachrichtenflussdiagramm ist, das einen typischen Nachrichtenfluss
zwischen den unter schiedlichen Netzwerkelementen des in 1A gezeigten
Netzwerks skizziert;
-
2A ein
Blockdiagramm ist, das ein SIP-Netzwerk einschließlich eines
SIP-Proxy-Servers gemäß einem
Ausführungsbeispiel
der vorliegenden Erfindung zeigt;
-
2B ein
Nachrichtenflussdiagramm ist, das einen Nachrichtenfluss zwischen
den unterschiedlichen Netzwerkelementen des in 2B gezeigten
Netzwerks skizziert; und
-
3 ein
Flussdiagramm ist, das Beispielverarbeitungsschritte skizziert,
die durch einen SIP-Proxy-Server
gemäß einem
Ausführungsbeispiel der
vorliegenden Erfindung durchgeführt
werden.
-
Die
folgende Beschreibung erfolgt unter Bezugnahme auf Sitzungsinitiierungsprotokoll-Netzwerke
(SIP-Netzwerke). Jedoch werden Fachleute verstehen, dass die hierin
beschriebenen erfindungsgemäßen Konzepte
in keiner Weise auf SIP beschränkt sind
und, mit einer geeigneten Modifikation, wie erforderlich, bei anderen
Kommunikationsprotokollen verwendet werden können, die ähnliche Charakteristika aufweisen.
-
1A zeigt
ein Blockdiagramm eines typischen SIP-Netzwerks 100 gemäß dem Stand
der Technik. Das SIP-Netzwerk weist eine Anzahl von Netzwerkelementen
auf, nämlich
einen SIP-Benutzeragent-Client (UAC; UAC = user agent client) 102,
einen SIP-Benutzeragent-Server (UAS; UAS = user agent server) 110 und
eine Anzahl von Zwischenelementen, wie z. B. SIP-Proxy-Server 104, 106 und 108.
Der UAC 102 kann durch ein Senden einer Anforderungsnachricht
wie z. B. einer EINLADEN-Nachricht an den UAS 110 z. B.
mit dem UAS 110 einen Ruf einrichten. Der UAS kann mit
einer Antwortnachricht antworten, wie z. B. einer 200-OK-Nachricht,
wie es unten weiter detailliert beschrieben ist. Wie Fachleute erkennen
werden, können
zusätzliche
Nachrichten ebenfalls gesendet werden, um die Rufeinstellung zu
vollenden.
-
Bei
einem SIP ist ein derartiger Austausch von Nachrichten als eine
Transaktion bekannt, wobei eine Transaktion alle Nachrichten von
der ersten Anforderungsnachricht, die von einem Server gesendet wird,
bis zu einer endgültigen
(nicht-1xx-)Antwortnachricht, die von dem Server zurück zu dem
Client gesendet wird, aufweist. Ein SIP-Ruf ist als alle Nachrichten
von einer Anfangs-EINLADEN-Nachricht bis zu einer BYE-Nachricht
aufweisend definiert. Ein SIP-Ruf kann mehrere Transaktionen aufweisen.
-
Die
Proxy-Server 104, 106 und 108 werden verwendet,
um Nachrichten auf eine bekannte Weise zu routen. Bei diesem Beispiel
unterstützen
der UAC 102 und der Proxy-Server 106 eine SIP-Nachrichtenkomprimierung
gemäß RFC 3486,
während
die anderen Netzwerkelemente dies nicht tun.
-
Sich
nun auf 1B beziehend ist ein Nachrichtenflussdiagramm
gezeigt, das die Anfangsnachrichten zeigt, die bei einem Einstellen
eines Rufes zwischen dem UAC 102 und dem UAS 110 enthalten sind.
Fachleute werden verstehen, dass zusätzliche Nachrichten ebenfalls
in einer Rufeinstellung enthalten sein können. Zur Klarheit sind die
in 1B gezeigten Nachrichten in einer abgekürzten Form
gezeigt und zeigen lediglich einige der verfügbaren SIP-Nachrichtenkopfblöcke.
-
Der
UAC 102 sendet eine SIP-EINLADEN-Nachricht 120 an
den UAS 110. Die EINLADEN-Nachricht 120 wird anfänglich an
einen Proxy-Server 104 gesendet, dessen Adresse in dem UAC 102 vorkonfiguriert
ist. Der Kontakt-Kopfblock der EINLADEN-Nachricht 120 enthält den Einheitsressourcenmodifizierer
(URI; URI = universal resource indicator) des UAC 102.
Wie vorhergehend erwähnt
unterstützt
der UAC 102 eine SIP-Nachrichtenkomprimierung,
somit fügt,
gemäß RFC 3486,
der UAC 102 den Parameter komp = sigkomp zu dem URI desselben
in dem Kontakt-Kopfblock hinzu. Der Wert, den komp annehmen kann,
zeigt den Typ von Komprimierungsschema an, das verwendet werden soll.
Hiernach wird angenommen, dass das Signalisierungskomprimierungsschema
(SigKomp-Schema; Sig-Komp
= Signaling Compression), das in RFC 3320 definiert ist, verwendet
wird, jedoch sind die tatsächlichen
Komprimierungsmechanismen außerhalb des
Schutzbereichs der vorliegenden Erfindung und werden nicht weiter
erörtert.
Zur Klarheit wird hiernach die abgekürzte Notierung komp anstatt
der langen Notierung komp=sigkomp verwendet. Das Vorhandensein des
komp-Parameters in dem URI des SIP-Nachrichtenkopfblockes wird verwendet,
um sowohl anzuzeigen, dass ein bestimmtes Element eine Komprimierung
unterstützt,
als auch dass dieses Element wünscht,
zukünftige
Nachrichten wenn möglich in
einem komprimierten Format zu empfangen.
-
Es
ist auch möglich,
dass der UAC 102 vorkonfiguriert ist, um Anfangsnachrichten
in einer komprimierten Form zu senden, wenn der UAC 102 weiß, dass
der Proxy 104 ebenfalls eine Komprimierung unterstützt.
-
Da
der UAC 102 zumindest bei dieser Stufe nicht weiß, ob andere
Elemente in dem SIP-Netzwerk eine SIP-Nachrichtenkomprimierung unterstützen, sendet
der UAC 102 die Nachrichten anfänglich unkomprimiert, nachdem
derselbe einen Über-Kopfblock
zu der Nachricht 120 mit dem URI des UAC 102 hinzugefügt hat.
-
Der
SIP-Proxy 104, der keine SIP-Komprimierung unterstützt und
somit zustandslos ist, empfängt
die EINLADEN-Nachricht 120 und leitet diese Nachricht,
nach einem Hinzufügen
des URI desselben zu der Liste von Über-Kopfblöcken, an den SIP-Proxy 106 weiter.
-
Der
SIP-Proxy 106, der eine SIP-Komprimierung unterstützt, empfängt die
EINLADEN-Nachricht 122. Der Proxy 106 ist konfiguriert,
um in dem Pfad von zukünftigen
Anforderungen in dem gleichen SIP-Dialog zu bleiben und erreicht
dies durch ein Hinzufügen
eines AUFZEICHNUNG-ROUTE-Kopfblockes (RECORD-ROUTE-Kopfblockes),
der den URI desselben enthält,
zu der Nachricht. Da der Proxy 106 eine Komprimierung unterstützt, speichert
derselbe Informationen in einer Transaktionskontextdatenspeicherung.
Der Typ von gespeicherten Informationen umfasst den Kontakt-URI,
eine eindeutige Rufidentifizierung und andere Informationen, die
durch den Proxy verwendet werden können, um die gegenwärtige Anforderung
auf eine Übereinstimmung
mit einer schlussendlichen Antwortnachricht zu prüfen. Zusätzliche
Informationen werden gespeichert, um anzuzeigen, ob bei einem Kommunizieren
mit unterschiedlichen SIP-Elementen eine Komprimierung verwendet
werden sollte. Somit wird von dem Proxy 202 behauptet,
dass derselbe ein zustandsbetonter Proxy ist. Schließlich fügt der Proxy 106 den
URI desselben zu der Liste von Über-Kopfblöcken hinzu
und leitet die Nachricht 124 unkomprimiert an den SIP-Proxy 108 weiter,
da der Proxy 106 anfänglich wieder
nicht weiß,
ob der Proxy 108 eine Komprimierung unterstützt.
-
Der
SIP-Proxy 108, der bei diesem Beispiel keine Komprimierung
unterstützt
und somit zustandslos ist, empfängt
die EINLADEN-Nachricht 124 und fügt, da derselbe ebenfalls wünscht, in
dem Pfad für
zukünftige
Anforderungen in dem gleichen Dialog zu bleiben, einen AUFZEICHNUNG-ROUTE-Kopfblock, der die
URI desselben enthält,
zu der Nachricht hinzu und fügt
den URI desselben zu der Spitze der Liste von Über-Kopfblöcken hinzu. Die Nachricht wird
an den UAS 110 unkomprimiert gesendet, da der Proxy 108 nicht
weiß,
ob der UAS eine SIP-Komprimierung unterstützt.
-
Der
UAS 110 empfängt
und verarbeitet die Nachricht 126 auf die übliche Weise.
Da die EINLADEN-Nachricht die erste Nachricht eines Rufes ist, konstruiert
und speichert der UAS 110 einen „Routensatz" als Teil des gegenwärtigen Rufkontextes. Ein
Routensatz ist eine Sammlung von geordne ten URIs, die eine Kette
von Servern identifiziert, durch die neue Anforderungen außerhalb
des gegenwärtigen
Dialogs gesendet werden sollten. Ein Routensatz kann durch Kopfblöcke wie
Aufzeichnung-Route gelernt werden, oder derselbe kann konfiguriert
werden. Für
den UAS 110 wird der Routensatz aus den Kopfblockinformationen
der Nachricht 126 erhalten und umfasst:
Routensatz:
P3
P2
UAC;
komp
-
Somit
werden neue Anforderungen in dem gleichen Ruf, die von dem UAS 110 zu
dem UAC 102 gesendet werden, über die Route gesendet, die
in dem Routensatz bereitgestellt ist. Jedoch gilt dies lediglich
für neue
Anforderungen und nicht für
Nachrichten, die ansprechend auf vorhergehende Anforderungen gesendet
werden.
-
Der
UAS 110 antwortet auf die empfangene EINLADEN-Nachricht
durch ein Senden einer 200-OK-Antwortnachricht 128 zurück zu dem
UAC 102. Das SIP erfordert, dass Antwortnachrichten dem
gleichen Pfad folgen, der durch entsprechende Anforderungsnachrichten
genommen wird, und dies wird durch ein Senden der Antwort 128 an
die nächste
Sprungadresse sichergestellt, die an der Spitze der Über-Liste
der Nachricht 128 angezeigt ist, in diesem Falle den Proxy 108.
Da der UAS 110 keine Komprimierung unterstützt, wird
diese Nachricht in unkomprimierter Form gesendet.
-
Der
Proxy 108 empfängt
die Nachricht 128, entfernt die URI desselben von der Liste
von Über-Kopfblöcken und
leitet die Nachricht 130 unkomprimiert an den Proxy 106 weiter.
-
Wenn
der Proxy 106, der ein zustandsbetonter Proxy ist, die
Antwortnachricht 130 empfängt, bestimmt der Proxy, ob
die empfangene Nachricht Teil der gegenwärtigen Transaktion ist. Dies
kann z. B. durch ein Überprüfen eines
Transaktionsidentifizierers für
die gegenwärtige
Nachricht auf Übereinstimmung
mit den Informationen, die in dem Transaktionskontext gespeichert
sind, erreicht werden. Wenn die Nachricht Teil der gegenwärtigen Transaktion
ist, dann analysiert der Proxy die empfangene Nachricht, um zu bestimmen,
ob dieselbe eine Route aufgezeichnet hat (record-routed). Die Bezeichnung
Route aufgezeichnet (recordrouted) wird hierin sowie in der SIP-Spezifikation
verwendet, um ein SIP-Element zu bezeichnen, das vorhergehend einen
AUFZEICHNUNG-ROUTE-Kopfblock in eine SIP-Nachricht in der gleichen
Transaktion eingefügt
hat.
-
Wenn
der Proxy 106 eine Route aufgezeichnet hat, inspiziert
der Proxy die Route, die für
diesen Dialog eingestellt ist. Die Route umfasst in diesem Fall:
den DAS 102, den Proxy 108, den Proxy 106 und
den UAC 102. Der Proxy 104 ist in der Route nicht
enthalten, da derselbe keine Route aufgezeichnet hat. Der Proxy 106 überprüft das nächste nachgeschaltete
Element in der Route (in diesem Falle den UAC 102), um
zu bestimmen, ob dasselbe eine Komprimierung unterstützt. Dies
kann durch ein Bestimmen, ob der Komprimierungsparameter in dem URI
des UAC 102 vorhanden ist, erreicht werden.
-
Da
der URI des UAC 102 in dem Kontakt-Kopfblock der Nachricht 130 den
komp-Parameter enthält,
wodurch angezeigt wird, dass der UAC SIP-Komprimierungsanforderungen
unterstützt,
fügt der
Proxy 106 einen Komprimierungsparameter desselben zu einem
zweckmäßigen Teil
der Nachricht hinzu. In diesem Fall wird dies durch ein Modifizieren des
AUF-ZEICHNUNG-ROUTE-Kopfblockes
desselben der Nachricht 132 erreicht, um den komp-Parameter
zu umfassen.
-
Wenn
der UAC die Nachricht 134 empfängt, konstruiert der UAC einen
Routensatz durch die Kopfblockinformation, die in der empfangenen
Nachricht enthalten ist, wobei der Routensatz Folgendes aufweist:
Routensatz:
P2;
komp
P3
UAS
-
Die
Tatsache, dass der Routensatzeintrag für den Proxy 106 den
Komprimierungsparameter umfasst, ermöglicht, dass der UAC weitere
Anforderungen in dem gleichen Dialog in einem komprimierten Format
sendet, wie unten zu sehen sein wird.
-
Der
UAC 102 verarbeitet die empfangene Nachricht 134 und
antwortet durch ein Senden einer ACK-Nachricht zurück an den
UAS 110. RFC 3261 spezifiziert, dass eine ACK-Nachricht
einen Teil einer neuen Transaktion bildet und dieselbe somit nicht dem
gleichen Pfad folgen muss wie die Anfangs-EINLADEN-Nachricht, und somit wird die
ACK direkt an den Proxy 106 in einem komprimierten Format
gesendet.
-
Der
Proxy 106 leitet die Nachricht in einem unkomprimierten
Format an den Proxy 108 weiter, der die Nachricht wiederum
auf die normale Weise an den UAS 110 weiterleitet.
-
Somit
ist zu sehen, dass es, um eine SIP-Nachrichtenkomprimierung nach dem Stand
der Technik zu implementieren, erforderlich ist, dass eine Transaktionskontextdatenspeicherung
in jedem Proxy aufrechterhalten wird, der eine SIP-Komprimierung
unterstützt.
Zusätzlich
muss ein Proxy durch ein Analysieren von Nachrichtenkopfblöcken auch
bestimmen, ob ein anderes Element in dem Antwortpfad eine Komprimierung
unterstützt.
Da ein SIP-Proxy-Server,
der eine Komprimierung unterstützt,
transaktionszustandsbetont sein muss, sind die Ressourcenanforderungen
in dem SIP-Proxy ferner direkt proportional zu der Anzahl von gleichzeitigen
eingerichteten Transaktionen, die durch das gleiche System gehandhabt
werden.
-
Ein
Ausführungsbeispiel
gemäß der vorliegenden
Erfindung, das ermöglicht,
dass ein SIP-Proxy-Server, der eine Kompri mierung unterstützt, zustandslos
ist, ist nun unter Bezugnahme auf 2 beschrieben.
-
2A repräsentiert
ein SIP-Netzwerk und einen Nachrichtenfluss ähnlich denjenigen, die in 1A gezeigt
sind, und gleichen Merkmalen und Nachrichten sind die gleichen numerischen
Identifizierer verliehen worden. Das SIP-Netzwerk weist einen SIP-Benutzeragent-Client
(UAC) 102, drei SIP-Proxy-Server 104, 202 bzw. 108 und
einen SIP-Benutzeragent-Server
(UAS) 110 auf. Der Proxy-Server 202 ist unten
detaillierter beschrieben.
-
2B zeigt
ein Nachrichtenflussdiagramm, das den Nachrichtenfluss einer SIP-Transaktion
skizziert, die verschiedenartige Elemente eines SIP-Netzwerks einschließlich eines
SIP-Proxy 202 gemäß einem
Ausführungsbeispiel
der vorliegenden Erfindung umfasst.
-
Die
Transaktion startet mit dem UAC 102, der eine EINLADEN-Nachricht 120 an
einen UAS 110 über
ein SIP-Netzwerk sendet, das die Proxy-Server 104, 202 und 108 aufweist.
-
Die
Nachricht 120 wird anfänglich
an einen Proxy-Server 104 gesendet, dessen Adresse in dem UAC 102 vorkonfiguriert
ist. Der Kontakt-Kopfblock der EINLADEN-Nachricht 120 enthält den URI
des UAC 102. Bei diesem Beispiel unterstützt der
UAC 102 eine SIP-Nachrichtenkomprimierung, also fügt der UAC 102 den
Parameter komp zu dem URI desselben in dem Kontakt-Kopfblock hinzu.
-
Der
UAC 102 stellte den Über-Kopfblock
der Nachricht 120 an den URI des UAC 102 ein.
Da der UAC bei dieser Stufe nicht weiß, ob der Proxy 104 eine
Komprimierung unterstützt,
wird die Nachricht 120 unkomprimiert gesendet.
-
Der
SIP-Proxy 104, der keine SIP-Komprimierung unterstützt und
somit zustandslos ist, empfängt
die EINLADEN-Nachricht 120 und leitet, nachdem derselbe
den URI desselben zu der Liste von Über-Kopfblöcken hinzugefügt hat,
diese Nachricht an den SIP-Proxy 202 weiter.
-
Der
SIP-Proxy 202, der eine SIP-Komprimierung unterstützt, empfängt die
EINLADEN-Nachricht 122. Der Proxy 202 ist konfiguriert,
um in dem Pfad von zukünftigen
Anforderungen in dem gleichen SIP-Dialog zu bleiben und fügt so einen
AUFZEICHNUNG-ROUTE-Kopfblock, der den URI desselben enthält, zu der
Nachricht hinzu. Im Gegensatz zu dem Proxy 106 wie oben
beschrieben jedoch ist der Proxy 202 zustandslos – mit anderen
Worten erhält derselbe
keinen Transaktionskontext aufrecht und erfordert somit keine Kontextspeicherungsmittel.
Die Operation des Proxy 202 ist unten unter Bezugnahme
auf 3 beschrieben.
-
Wenn
durch den Proxy 202 eine Nachricht empfangen wird (Schritt 302),
bestimmt der Proxy (Schritt 304), ob die Nachrichte eine
Anforderungs- oder eine Antwortnachricht ist. Wenn, wie in diesem Fall,
die empfangene Nachricht eine Anforderungsnachricht ist, findet
der Proxy den Aufzeichnung-Route-Kopfblock (den der Proxy 202 gerade
zu der Nachricht hinzugefügt
hat) (Schritt 312), der den URI desselben enthält, in der
Nachricht und fügt (Schritt 314)
einen neuen Komprimierungsparameter zu derselben hinzu. Dieser neue
Komprimierungsparameter umfasst einen Identifizierer, um den Proxy 202 unzweideutig
zu identifizieren, und einen Komprimierungsflag, der anzeigt, ob
zukünftige
Anforderungen komprimiert werden sollten oder nicht. Der unzweideutige
Identifizierer kann in einer Anzahl von unterschiedlichen Weisen
hergeleitet werden, die für Fachleute
offensichtlich sind.
-
Der
Wert des Flags wird durch den Proxy 202 auf die folgende
Weise bestimmt. Der Proxy 202 analysiert die empfangene
Nachricht, um zu bestimmen, ob das nächste vorgeschaltete Element
eine SIP-Komprimierung unterstützt.
Das nächste
vorgeschaltete Element (d. h. zu dem UAC hin) kann durch ein erstes
Bestimmen des Vorhandenseins des obersten Auf zeichnung-Route-Kopfblockes
(falls irgendeiner vorhanden ist) in der Nachricht bestimmt werden,
da, falls irgendein Element eine Route aufgezeichnet hat, jegliche
neue Anforderungsnachrichten automatisch durch das Element gehen
werden, das eine Route aufgezeichnet hat. Wenn kein Aufzeichnung-Route-Kopfblock
vorhanden ist, impliziert dies, dass das nächste vorgeschaltete Element
dasjenige ist, das durch den Kontakt-Kopfblock der empfangenen Nachricht
definiert ist. Sobald der URI des nächsten vorgeschalteten Elements
festgestellt worden ist, analysiert der Proxy 202 den URI
desselben, um das Vorhandensein des komp-Parameters zu bestimmen.
Wenn der komp-Parameter vorhanden ist, zeigt dies an, dass zukünftige Anforderungsnachrichten,
die zwischen dem nächsten
vorgeschalteten Element und dem Proxy 202 gesendet werden,
in einer komprimierten Form gesendet werden können. Entsprechend stellt der
Proxy 202 den Wert des Flags ein, um anzuzeigen, dass eine
Komprimierung verwendet werden sollte, andernfalls wird der Flag
eingestellt, um anzuzeigen, dass keine Komprimierung verwendet werden
sollte. An diesem Punkt jedoch enthält der Aufzeichnung-Route-Parameter
für den Proxy 202 nicht
den komp-Parameter.
-
Schließlich fügt der Proxy 202 den
URI desselben zu der Liste von Über-Kopfblöcken hinzu
und leitet die Nachricht 210 unkomprimiert an den SIP-Proxy 108 weiter,
da der Proxy 106 anfänglich wieder
nicht weiß,
ob der Proxy 108 eine Komprimierung unterstützt.
-
Es
ist zu beachten, dass der unzweideutige Identifizierer und der Flag
lediglich in die Nachricht eingefügt werden, wenn der Proxy konfiguriert
ist, um in dem Pfad zu bleiben, z. B. durch ein Konfiguriertwerden,
um einen Aufzeichnung-Route-Kopfblock hinzuzufügen.
-
Der
SIP-Proxy 108, der keine Komprimierung unterstützt, empfängt die
EINLADEN-Nachricht 210 und fügt, da derselbe ebenfalls wünscht, in
dem Pfad für
zukünftige
Anforderungen in dem gleichen Dialog zu bleiben, einen AUFZEICHNUNG-ROUTE-Kopfblock,
der den URI desselben enthält,
zu der Nachricht hinzu, fügt
die Nachrichtendetails zu einer Transaktionskontextdatenspeicherung
hinzu und fügt den
URI desselben zu der Spitze der Liste von Über-Kopfblöcken hinzu. Die Nachricht wird
an den UAS 110 unkomprimiert gesendet, da der Proxy 108 nicht
weiß,
ob der UAS eine SIP-Komprimierung
unterstützt.
-
Der
UAS 110 empfängt
und verarbeitet die Nachricht 212. Da die EINLADEN-Nachricht
die erste Nachricht eines Rufes ist, speichert der UAS 110 einen
Routensatz als Teil des gegenwärtigen
Rufkontextes. Für
den UAS 110 wird der Routensatz aus den Kopfblockinformationen
der Nachricht 126 erhalten und weist Folgendes auf:
Routensatz:
P3
P2:
ID + FLAG
UAC; komp
-
Somit
werden neue Anforderungen in dem gleichen Ruf, die von dem UAS 110 an
den UAC 102 gesendet werden, über die Route gesendet, die
in dem Routensatz bereitgestellt ist.
-
Der
UAS 110 sendet dann eine 200-OK-Antwortnachricht 128 zurück an den
UAC 102. Wie vorhergehend erwähnt, erfordert das SIP, dass
Antwortnachrichten dem gleichen Pfad folgen, der durch entsprechende
Anforderungsnachrichten genommen wird, und dies wird durch ein Senden
der Antwort 214 an die nächste Sprungadresse erreicht,
die an der Spitze der Über-Liste der Nachricht 214 ist,
in diesem Fall den Proxy 108. Da die nächste Sprungadresse den komp-Parameter
nicht enthält,
wird die Nachricht unkomprimiert gesendet.
-
Der
Proxy 108 empfängt
die Nachricht 214, entfernt den URI desselben aus der Liste
von Über-Kopfblöcken und
leitet die Nachricht 216 unkomprimiert an den Proxy 202 weiter.
-
Wenn
der Proxy 202 die Nachricht 216 empfängt (Schritt 302),
und sich erneut auf 3 beziehend, bestimmt der Proxy
(Schritt 304), ob die empfangene Nachricht 216 Teil
einer Anforderung oder einer Antwort ist. In diesem Fall ist die
empfangene Nachricht eine Antwortnachricht – mit anderen Worten ist die
empfangene Nachricht Teil einer Transaktion, die die anfängliche
Anforderung-EINLADEN-Nachricht
umfasst. Der Proxy 202 überprüft somit
die Nachricht, um den relevanten Kopfblock des nächsten nachgeschalteten Elements
in der Route (d. h. des UAC) zu finden, und durchsucht die empfangene
Nachricht nach dem Vorhandensein des unzweideutigen Identifizierers
desselben, der oben erwähnt
ist. Eine derartige Suchroutine kann aufgrund der einfachen Natur
der erforderlichen Suche bezüglich
Geschwindigkeit und Effizienz optimiert werden.
-
Wenn
der Identifizierer des Proxy 202 in der Nachricht gefunden
wird, wird der Wert des Flags erhalten. In diesem Fall zeigt der
Flag, wie es oben beschrieben ist, an, dass zukünftige Anforderungsnachrichten
komprimiert werden sollten und das nächste nachgeschaltete Element
eine Komprimierung unterstützt.
Der Proxy 202 modifiziert somit den Aufzeichnung-Route-Eintrag
desselben in der Nachricht 216, um den vorhergehend hinzugefügten unzweideutigen
Identifizierer und Flag zu entfernen und ersetzt denselben durch
den komp-Parameter. Die modifizierte Nachricht 218 wird
dann an den Proxy 104 weitergeleitet.
-
Fachleutenn
wird bewusst sein, dass bei einem SIP die Notierung „vorgeschaltet" und „nachgeschaltet" immer unter Bezugnahme
auf die Richtung des Nachrichtenflusses der gegenwärtigen Anforderung
oder Antwort erfolgt.
-
Wenn
der UAC die Nachricht 134 empfängt, konstruiert der UAC einen
Routensatz durch die Kopfblockinformation, die in der empfangenen
Nachricht enthalten ist, wobei der Routensatz Folgendes aufweist:
Routensatz:
P2;
komp
P3
UAS
-
Der
UAC 102 verarbeitet die empfangene Nachricht 134 und
antwortet durch ein Senden einer ACK-Nachricht zurück an den
UAS 110. Da der Proxy 202 keine Route aufgezeichnet
hat und der Aufzeichnung-Route-Kopfblock anzeigt, dass der Proxy 202 eine
SIP-Komprimierung unterstützt,
wird die Nachricht 136 direkt an den Proxy 106 in
einem komprimierten Format gesendet. Die ACK-Nachricht 136 wird
an den UAS 110 über
den Proxy 108 in einem unkomprimierten Format weitergeleitet,
wie es in den Nachrichten 138 bzw. 140 gezeigt
ist.
-
Zusammenfassend
liefert eine SIP-Komprimierung einen Mechanismus, durch den ein
Quellelement (wie z. B. ein UAC) anfordern kann, dass ein Zwischenelement
(wie z. B. ein Proxy) dem Quellelement anzeigt, ob das Quellelement
bei einem Senden von zukünftigen
Anforderungsnachrichten an das Zwischenelement eine Komprimierung
verwenden kann. Da das SIP lediglich einen Einweg-Kommunikationspfad
bereitstellt, d. h. entweder eine Anforderung oder eine Antwort,
kann eine derartige Anzeige lediglich in einer Antwortnachricht
gegeben werden. Gemäß dem vorliegenden
Ausführungsbeispiel
erfordert ein derartiger Mechanismus vorteilhafterweise keine Verwendung
eines zustandsbetonten Zwischenelements.
-
Die
Wirkung des obigen Prozesses ist, dass die 200-OK-Nachricht 134,
die durch den UAC 102 empfangen wird, die identische zu
derjenigen ist, die nach dem Stand der Technik empfangen wird, außer dass
im Gegensatz zu dem Stand der Technik, der die Verwendung von zustandbetonten
Proxy-Servern erforderte,
das vorliegende Ausführungsbeispiel
lediglich die Verwendung von zustandslosen Proxy-Servern erfordert.
Somit können
SIP-Proxy-Server gemäß dem oben
beschriebenen Ausführungsbeispiel
in SIP-Netzwerken einge setzt werden, die eine Unterstützung einer
SIP-Nachrichtenkomprimierung
erfordern, wobei ermöglicht
wird, dass aus den bereits erwähnten
Vorteilen einer Verwendung von zustandslosen im Gegensatz zu zustandsbetonten Proxy-Servern ein voller
Vorteil gezogen wird.
-
Fachleute
werden erkennen, dass die gleichen Techniken auch auf andere SIP-Elemente,
wie z. B. aufeinanderfolgende Benutzeragenten (B2BUA; B2BUA = back-to-back
user agents) angewendet werden können.