DE10232175A1 - Verfahren zum Sicherstellen der Reihenfolge von Nachrichten im SIP-/SIP-T Protokoll - Google Patents

Verfahren zum Sicherstellen der Reihenfolge von Nachrichten im SIP-/SIP-T Protokoll Download PDF

Info

Publication number
DE10232175A1
DE10232175A1 DE10232175A DE10232175A DE10232175A1 DE 10232175 A1 DE10232175 A1 DE 10232175A1 DE 10232175 A DE10232175 A DE 10232175A DE 10232175 A DE10232175 A DE 10232175A DE 10232175 A1 DE10232175 A1 DE 10232175A1
Authority
DE
Germany
Prior art keywords
messages
sip
protocol
seq
mgc
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Withdrawn
Application number
DE10232175A
Other languages
English (en)
Inventor
Klaus Hoffmann
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Siemens AG
Original Assignee
Siemens AG
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Siemens AG filed Critical Siemens AG
Priority to DE10232175A priority Critical patent/DE10232175A1/de
Priority to AU2003250746A priority patent/AU2003250746A1/en
Priority to EP03787589A priority patent/EP1522181A1/de
Priority to PCT/DE2003/001942 priority patent/WO2004017594A1/de
Priority to US10/512,479 priority patent/US20050237997A1/en
Priority to CNA038015870A priority patent/CN1593052A/zh
Publication of DE10232175A1 publication Critical patent/DE10232175A1/de
Withdrawn legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/10—Architectures or entities
    • H04L65/102—Gateways
    • H04L65/1023—Media gateways
    • H04L65/103—Media gateways in the network
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/10—Architectures or entities
    • H04L65/102—Gateways
    • H04L65/1023—Media gateways
    • H04L65/1026—Media gateways at the edge
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/10—Architectures or entities
    • H04L65/102—Gateways
    • H04L65/1033—Signalling gateways
    • H04L65/1036—Signalling gateways at the edge
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/10—Architectures or entities
    • H04L65/102—Gateways
    • H04L65/1033—Signalling gateways
    • H04L65/104—Signalling gateways in the network
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/10—Architectures or entities
    • H04L65/102—Gateways
    • H04L65/1043—Gateway controllers, e.g. media gateway control protocol [MGCP] controllers
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/1066—Session management
    • H04L65/1101—Session protocols
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/1066—Session management
    • H04L65/1101—Session protocols
    • H04L65/1104—Session initiation protocol [SIP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04M—TELEPHONIC COMMUNICATION
    • H04M7/00—Arrangements for interconnection between switching centres
    • H04M7/12—Arrangements for interconnection between switching centres for working between exchanges having different types of switching equipment, e.g. power-driven and step by step or decimal and non-decimal
    • H04M7/1205—Arrangements for interconnection between switching centres for working between exchanges having different types of switching equipment, e.g. power-driven and step by step or decimal and non-decimal where the types of switching equipement comprises PSTN/ISDN equipment and switching equipment of networks other than PSTN/ISDN, e.g. Internet Protocol networks
    • H04M7/1245—Arrangements for interconnection between switching centres for working between exchanges having different types of switching equipment, e.g. power-driven and step by step or decimal and non-decimal where the types of switching equipement comprises PSTN/ISDN equipment and switching equipment of networks other than PSTN/ISDN, e.g. Internet Protocol networks where a network other than PSTN/ISDN interconnects two PSTN/ISDN networks
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04M—TELEPHONIC COMMUNICATION
    • H04M7/00—Arrangements for interconnection between switching centres
    • H04M7/12—Arrangements for interconnection between switching centres for working between exchanges having different types of switching equipment, e.g. power-driven and step by step or decimal and non-decimal
    • H04M7/1205—Arrangements for interconnection between switching centres for working between exchanges having different types of switching equipment, e.g. power-driven and step by step or decimal and non-decimal where the types of switching equipement comprises PSTN/ISDN equipment and switching equipment of networks other than PSTN/ISDN, e.g. Internet Protocol networks
    • H04M7/126—Interworking of session control protocols
    • H04M7/127—Interworking of session control protocols where the session control protocols comprise SIP and SS7

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Multimedia (AREA)
  • Business, Economics & Management (AREA)
  • General Business, Economics & Management (AREA)
  • Telephonic Communication Services (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

Beim Stand der Technik wird als Protokoll zwischen Media Gateway Controllern (MGC) ein BICC oder SIP-T-Protokoll verwendet. Bei letzterem ist die Übertragung von ISUP-Nachrichten mit Hilfe der INFO-Methode explizit vorgesehen; problematisch ist allerdings, dass ein Teil der ISUP-Nachrichten wie z. B. USR- oder APM-Nachrichten während des Übertragungsvorganges eine ganz bestimmte Reihenfolge einhalten muss, die es bei der empfangsseitigen Bearbeitung zwingend zu beachten gilt. Das Einhalten der Reihenfolge ist aber nicht immer gegeben, da diese SIP-T/SIP-Nachrichten unterschiedliche Wege nehmen können und es somit während des Übertragungsvorganges zu Überholungen oder sogar zu Verlusten kommen kann. Die Erfindung löst dieses Problem, indem diesen SIP-T/SIP-Nachrichten eine fortlaufende Sequenznummer mitgegeben wird, anhand der die SIP/SIP-T-Partnerseite eine gegebenenfalls während der Übertragung verfälschte Reihenfolge wiederherstellen kann.

Description

  • Die Erfindung betrifft ein Verfahren gemäß dem Oberbegriff von Patentanspruch 1.
  • 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 das ISUP-Protokoll) angeschlossen. Die Nutzinformationen selbst werden über von Media Gateways (MG) in die jeweils benutzte Transporttechnologie umgewandelt.
  • Die Steuerung der Media Gateways werden von jeweils zugeordneten Media Gateway Controllern (MGC) durchgeführt. 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.
  • Da das BICC Protokoll eine Weiterentwicklung eines ISUP Protokolls darstellt, werden die hierzu relevanten Anteile in einem gesonderten Teil zusammengefasst, der als Q.1902.x BICC CS2 Protokoll (bearer independent call control capability set 2, mit einem eigenen Service indicator beim MTP (message transfer part)) bezeichnet wird. Die rein spezifischen für die Kommunikation zwischen Media Gateway Controllern relevanten Anteile sind in einem weiteren Teil niedergelegt, der als Q.765.5 BAT (bearer application transport) bezeichnet wird. Dieses ITU-T Standard Protokoll beschreibt auch für IP bearer RTP als Bearer Technologie. Als Konsequenz wird für die Übertragung durch das ATM bzw. IP Netz eine Trennung zwischen Signalisierungsinformation und Nutzinformation vollzogen, wodurch dem Endkunden seine gewohnten Dienste im Telekommunikationsnetz bereitgestellt sind.
  • Ein dem BICC Protokoll adäquates Protokoll ist bei dem IETF Standardisierungsgremium mit dem RFC 3204 Protokoll (= SIP-T Protokoll) entstanden. Dieses stellt einen Zusatz zum SIP Protokoll (RFC 2543) dar. Mit Hilfe des SIP-T Protokolls können ISUP-Nachrichten – im Gegensatz zum SIP Protokoll – übertragen werden. Die Übertragung der ISUP-Nachrichten erfolgt im allgemeinen durch Tunneln, d. h. durch transparentes Durchreichen. Vorzugsweise werden die von einem PSTN-Teilnehmer abgegebenen ISUP-Nachrichten zusammen mit einer Trägernachricht geführt (INFO Methode, RFC 2976) und dem empfangenden PSTN-Teilnehmer zugeführt.
  • Als ISUP-Nachrichten seien beispielhaft USR- (User-to-User) oder APM-Nachrichten angesprochen. Erstere beschreiben Zusatzinformationen, die während eines laufenden Gesprächs über einen Signalisierungskanal (PSTN-Welt) übertragen werden können. Beispielhaft sei hier der Austausch eines Passwortes oder einer PIN-Nummer (Personal Identification Number) angesprochen. Die Übertragung dieser Zusatzinformationen muss auch über das SIP-T Protokoll möglich sein, da zwischen einem rufenden und einem gerufenen PSTN-Teilnehmer gegebenenfalls ein Internetnetz angeordnet sein kann.
  • Wie bereits angesprochen, werden ISUP-Nachrichten nach der INFO Methode zusammen mit einer Trägernachricht (CONTENT TYPE: ISUP) über das SIP-T Protokoll geführt. Die INFO Methode ist aber lediglich eine Ausprägung des Transports von ISUP Nachrichten über das SIP-/SIP-T Protokoll. Problematisch hierin ist jedoch, dass die ISUP-Nachrichten, insbesondere für die nach der INFO Methode übertragenen, empfangsseitig eine ganz bestimmte Reihenfolge in der Verarbeitung erforderlich ist. Dies ist bei den angesprochenen APM-/USR-Nachrichten der Fall. Dieses Problem resultiert daraus, dass diese Nachrichten vom rufenden PSTN-Teilnehmer bei der Anwendung von SIP/SIP-T z.B. über ein UDP-Protokoll (das als Träger des SIP-/SIP-T Protokolls verwendet werden kann) gesendet werden, und es anschließend während des Übertragungsvorganges im Internetnetz zu Überholungen oder Verlusten kommen kann, da unterschiedliche Wege für die Nutznachrichten vorgesehen werden können. Gerade bei Anwendung eines UDP-Protokolls kann es hier zu Problemen führen, da hier das Einhalten einer Reihenfolge – im Gegensatz zum TCP/IP Protokoll – nicht gewährleistet ist. Eine adäquate Lösung zu dieser Problematik liefert der IETF Standard für die INFO Methode (RFC 2976) und nicht, vielmehr wird dieses Problem hier als weniger wichtig herausgestellt („ISUP to SIP mapping" (draft IETF-sipping-isup-02, chapter 12.1)).
    •
  • Eine Aufgabe der Erfindung liegt darin, den Transport von ISUP-Nachrichten über die MGC-MGC Kommunikation derart weiterzubilden, dass eine sicherere Transportmöglichkeit der ISUP-Nachrichten sichergestellt ist.
  • Die Erfindung wird ausgehend von den im Oberbegriff von Patentanspruch 1 angegebenen Merkmalen durch die im kennzeichnenden Teil beanspruchten Merkmale gelöst.
  • Der Vorteil der Erfindung ist darin zu sehen, daß die empfangsseitige Verarbeitung der gemäß der INFO-Methode übertragenen ISUP-Nachrichten in der richtigen Reihenfolge sichergestellt ist. Als ISUP-Nachrichten kommen hierbei USR- oder APM-Nachrichten in Betracht, wobei dies keinerlei Einschränkung ist, da weltweit viele nationale Ausprägungen des ISUP's existieren. Erfindungsgemäß wird vorgesehen, die gemäß der INFO-Methode zu übertragenden ISUP-Nachrichten zu Beginn der Übertragung mit einer Sequenznummer zu beaufschlagen. Zusätzlich zu dieser Lösungen für den USR- und APM-Transportmechanismus bietet die Einführung dieses Verfahrens auch noch die Sicherstellung des DSS1/ISUP Features UUS2 und UUS3 (ITU-T Q.737), bei welchem es dem Teilnehmer erlaubt ist, mehrere "User to User Nachrichten" zu senden. Mit der Erweiterung für die INFO wird dann auch für diesen ISDN Service die richtige Reihenfolge sichergestellt, und kann auch bei SIP-T (MGC-MGC Kommunikation) dem Kunden angeboten werden.
    •
  • Die Erfindung wird im folgenden anhand eines figürlich dargestellten Ausführungsbeispiels näher erläutert.
  • Es zeigen:
  • 1 die grundsätzlichen Verhältnisse zwischen 2 PSTN-Teilnehmern, zwischen denen ein Internetnetz angeordnet ist,
  • 2 eine erste Darstellung von ausgetauschten Protokollelementen
  • 3 eine zweite Darstellung von ausgetauschten Protokollelementen
  • 4 eine dritte Darstellung von ausgetauschten Protokollelementen
  • 5 eine vierte Darstellung von ausgetauschten Protokollelementen
  • 6 eine tabellarische Darstellung, in welchen Feldern die Sequenznummer Rseq und RRCK geführt werden kann, wobei die fettmarkierten Teile die Erweiterungen anzeigen.
  • In 1 ist eine Netzkonfiguration aufgezeigt, auf der das erfindungsgemäße Verfahren zum Ablauf gelangt. Hierbei sind beispielhaft 2 PSTN-Netze offenbart, in denen jeweils eine Mehrzahl von PSTN-Teilnehmern in bekannter Weise angeordnet sind. Diese sind an Ortsvermittlungsstellen LE herangeführt, die ihrerseits mit Transit-Vermittlungsstellen TX verbunden sind.
  • In den Transit-Vermittlungsstellen TX wird nun die Trennung zwischen Signalisierungsinformationen und Nutzinformationen durchgeführt. Die Signalisierungsinformationen werden von der Transit-Vermittlungsstelle TX unmittelbar über ein ISUP-Protokoll einem jeweils zugeordneten Media Gateway Controller MGC (MGC A oder MGC B) zugeführt. Die Nutzinformationen werden zu einem (eingangsseitig angeordneten) Media Gateway MG (MG A oder MG B) übertragen, das als Schnittstelle zwischen TDM-Netz und einem ATM- bzw. IP-Übertragungsnetz fungiert. und werden über das betreffende Übertragungsnetz paketorientiert übertragen. Das Media Gateway MG A wird von dem Media Gateway Controller MGC A ebenso gesteuert, wie das Media Gateway MG B vom Media Gateway Controller MGC 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 Media Gateway Controllers MGC B in einen TDM Datenstrom umgewandelt und dem in Frage kommenden PSTN-Teilnehmer zugeführt werden.
  • Die zwischen dem Media Gateway Controller MGC und dem jeweils zugeordneten Media Gateway übertragenen Daten werden von ei nem standardisierten Protokoll unterstützt. Dieses kann beispielsweise das MGCP oder das H.248 Protokoll sein. Zwischen den beiden Media Gateway Controllern MGC A, MGC B soll nun als weiteres standardisiertes Protokoll anstelle eines BICC Protokolls das SIP- oder SIP-T Protokoll vorgesehen werden. Vorzugsweise wird in vorliegendem Ausführungsbeispiel das SIP-T Protokoll verwendet. Zwischen beiden Media Gateway Controllern können noch weitere Einrichtungen wie Proxies geschaltet sein.
  • Im folgenden wird nun davon ausgegangen, dass ein PSTN-Teilnehmer der A-Seite einem gerufenen PSTN-Teilnehmer der B-Seite ISUP-Nachrichten sendet. In 2 ist die erfindungsgemäße Vorgehensweise aufgeführt. Zunächst signalisiert der PSTN-Teilnehmer der A-Seite einem PSTN-Teilnehmer der B-Seite einen Verbindungswunsch. Später sollen dann spezielle ISUP-Nachrichten wie beispielsweise USR-Nachrichten während der Verbindung über den Signalisierungskanal ausgetauscht werden. Beide PSTN-Teilnehmer sind in der PSTN-Welt angeordnet, wo ein derartiger Austausch über den Signalisierungskanal des ISUP-Protokoll möglich ist. Die Verbindung zwischen beiden Teilnehmern wird nun aber hier über ein Internetnetz IP mit Hilfe des SIP-T Protokolls geführt, wo dieser Signalisierungskanal (also ISUP) nicht zur Verfügung steht:
  • Gemäß 2 wird zunächst eine Nachricht IAM (Initial Adress Message) also eine Rufanforderung dem (gerufenen) PSTN-Teilnehmer (B-Seite) gesendet. In dieser Rufanforderung ist festgelegt, mit welchem Teilnehmer der rufende Teilnehmer zu kommunizieren wünscht, d.h. die Teilnehmernummer wird darin abgelegt. Im A-seitigen Media Gateway Controller MGC A wird diese Nachricht in eine SIP-T Protokoll-Nachricht INVITE umgesetzt und über das Internetnetz IP übertragen. Im B-seitigen Media Gateway Controller MGC B wird diese Nachricht wieder in eine ISUP-Nachricht IAM gewandelt und dem gerufenen PSTN-Teilnehmer zugeführt. Als Folge übergibt der gerufene PSTN-Teilnehmer eine ISUP-Nachricht ACM (Adress Complete Mes sage) in Richtung rufenden PSTN-Teilnehmer. Im Media Gateway Controller MGC B wird diese in eine SIP-T Protokoll-Nachricht PROVISIONAL RESPONSE 180-Nachricht umgesetzt und zusammen mit einer Sequenznummer Rseq25 über das Internetnetz IP in Richtung rufenden PSTN-Teilnehmer übertragen. Die Sequenznummer Rseq weist hier den (beliebigen) Wert 25 auf.
  • Der rufende PSTN-Teilnehmer empfängt nun diese Nachricht, nachdem sie in dem ihm zugeordneten Media Gateway Controller MGC A wieder in die ursprüngliche ISUP-Nachricht umgesetzt wurde. Zeitgleich hierzu wird in dem Media Gateway Controller MGC A die empfangene SIP-T Nachricht nach der PRACK-Methode (PROVISIONAL RESPONSE ACKNOLEDGE) quittiert. Hierzu wird die empfangene PROVISIONAL RESPONSE 180-Nachricht quasi teilweise gespiegelt und in einem Feld RACK mit der Sequenznummer Rseq25 und dem Protokollelement INVITE dem gerufenen Media Gateway Controller MGC B zugeführt.
  • Im folgenden wird davon ausgegangen, dass beispielhaft der rufende PSTN-Teilnehmer (A-Seite) USR-Nachrichten (oder APM-Nachrichten) dem gerufenen PSTN-Teilnehmer (B-Seite) übergeben will (2). Hierzu wird die USR-Nachricht z.B. über dem Media Gateway Controller MGC A zugeführt, wo sie im SIP-T Protokoll in ein speziellen Feld, dem Feld (CONTENT TYPE: ISUP) eingefügt und während des Übertragungsvorganges geführt wird.
  • Weiterhin wird erfindungsgemäß dieser Nachricht eine Sequenznummer Rseq zugewiesen, die mitübertragen wird, in vorliegendem Ausführungsbeispiel die (neu ausgehandelte) Sequenznummer Rseq10. Die INFO-Nachricht wird bei Eintreffen im Media Gateway Controller MGC B als 200 FINAL RESPONSE-Nachricht dem Media Gateway Controller MGC A quittiert, wobei in dem Feld RACK die Sequenznummer Rseq10 aus der INFO-Nachricht abgelegt ist.
  • Im folgenden können nun weitere USR-Nachrichten zwischen rufendem und gerufenen PSTN-Teilnehmer ausgetauscht werden. Beispielhaft sei angenommen, dass das gesamte Nachrichtenpaket insgesamt 10 Nachrichten umfasst. Jeder dieser Nachrichten wird sendeseitig eine fortlaufende Sequenznummer beginnend mit der Sequenznummer Rseq10 bis Rseq11 zugewiesen, so dass der B-seitige Media Gateway Controller MGC B die korrekte Reihenfolge der Nachrichten herstellen und dem zugeordneten PSTN-Teilnehmer zuführen kann. Nachrichten, die aufgrund von Nachrichtenüberholungen in der falschen Reihenfolge eintreffen, werden gelöscht. Da diese Nachrichten dann nicht quittiert werden, wird vom gerufenen Teilnehmer die Nachricht erneut gesendet und wenn sie in der richtigen Reihenfolge eingetroffen ist, vom rufenden Teilnehmer bearbeitet und quittiert.
  • Im Anschluss daran kann dann vom gerufenen PSTN-Teilnehmer ein Leistungsmerkmal initiiert werden. Dies soll beispielhaft das Leistungsmerkmal Anrufumleitung sein. Eine dieses Leistungsmerkmal repräsentierende Nachricht CPG wird vom gerufenen PSTN-Teilnehmer dem rufenden PSTN-Teilnehmer übergeben. Im SIP-T Protokoll wird diese Nachricht in eine PROVISIONAL RESPONSE 183 Nachricht zusammen mit der Sequenznummer Rseq26 umgesetzt, die zwischen beiden Media Gateway Controllern MGC A, MGC B nach der PRACK Methode quittiert wird (mit BACK 26). Der Nachrichtenaustausch wird durch eine vom gerufenen Teilnehmer abgegebene Nachricht FINAL RESPONSE 200 (ANM, Answer Massage (Teilnehmer hat abgehoben)) dem rufenden Teilnehmer beendet. Auch im Falle, dass der weitere B-seitige PSTN-Teilnehmer, auf den die Abrufumleitung gelegt wurde, seinerseits eine Anrufumleitung auf einen dritten Teilnehmer durchführt, und dieser wiederum etc., funktioniert das Verfahren. Hierbei werden jeweils die Sequenznummer Rseq26 solange hochgezählt, bis der letzte Teilnehmer keine weitere Anrufumleitung mehr initiiert.
  • Grundsätzlich werden somit ISUP-Nachrichten bevor der gerufenen PSTN-Teilnehmer abgehoben hat, diesem zugestellt und können von ihm in der korrekten Reihenfolge empfangen werden. Der Vorteil dieser Vorgehensweise liegt somit darin, dass im SIP-T-Protokoll die Reihenfolge der nach der INFO Methode übertragenen ISUP-Nachrichten berücksichtigt ist, wodurch ein Auslösen der Verbindung am PSTN Endpunkt verhindert wird.
  • In 3 sind nun beispielhaft die Verhältnisse aufgezeigt, wenn der B-seitige PSTN-Teilnehmer zuerst abhebt und dann USR-Nachrichten austauscht. Hierbei soll vor dem Abheben noch eine Anrufumlenkung von einem zuerst angewählten Teilnehmer initiiert worden sein. Die in 2 aufgezeigten grundsätzlichen Verhältnisse ändern sich damit in der Reihenfolge. Wesentlich hierbei ist, dass der MGC B nach dem Senden der FINAL RESPONSE 200 (ANM) Nachricht solange warten muss, bis diese über ACK quittiert ist. Erst danach kann der MGC-B bei Senden einer USR-Nachricht sicher sein, dass diese Nachricht die FINAL RESPONSE 200 (ANM) Nachricht nicht überholt.
  • Das Einführen eines Wartezyklus ist grundsätzlich als alternatives Verfahren zu betrachten. Die Seite, die die INFO Nachricht sendet, wartet solange, bis die „200 OK" Meldung auf diese INFO Nachricht empfangen wurde (denn die 200 OK bestätigt den Empfang der INFO), bevor die nächste INFO Nachricht gesendet wird. In diesem Fall ist das Einführen einer Sequenznummer nicht erforderlich, aber dynamisch ungünstiger.
  • In 4 ist ein Beispiel aufgezeigt, in dem der MGC-B entweder wartet (wie am Beispiel von 3 beschrieben) oder zusätzlich (dynamisch günstigere) Maßnahmen ergreift, um Überholungen zu vermeiden. Hier darf die APM-Nachricht (beispielhaft sind hier statt USR-APM-Nachrichten angesprochen) auf der A-Seite nicht vor der ACM-Nachricht übertragen werden. Eine Möglichkeit ist das Einführen eines Wartezyklus (d. h. auf der B-Seite wird immer gewartet, bis die Quittung gekommen ist). Alternativ kann die B-Seite die Sequenznummer Rseq mit 26 weitergezählt werden um die Reihenfolge sicherzustellen. Der damit verbundene Vorteil liegt in der dynamisch erheblich günstigeren Übertragung.
  • Gleiches gilt für die in 5 aufgezeigten Verhältnisse. Hier soll kein zusätzlicher Wartezyklus eingeführt werden. Demgemäss werden die Sequenznummern bei Übertragung der APM-Nachrichten nicht neu ausgehandelt sondern auch bei der 200 OK (ANM) für die INVITE hochgezählt. Erfindungsgemäß wird dann in der ACK der Empfang quittiert und die Rack gespiegelt, womit die korrekte Reihenfolge sichergestellt ist.
  • Abweichend vom bisherigen Standard durch die Provisional response und die dazugehörige PRACK (bei dem der Sender eine beliebige Startnummer sendet) wird festgelegt, dass die erste Startnummer immer die „1" ist. Damit erkennt der Empfänger, dass dies die erste Nachricht einer Sequenz ist, die es zu quittieren gilt. Falls er aber wegen Überholung (oder Verlust) aber eine 2 empfängt, soll/kann/muss er diese Nachricht ignorieren. Der im SIP Standard schon bekannte Wiederholmechanismus sorgt für eine Wiederholung, und die 1. Nachricht wird dann irgendwann mal vor der 2. Nachricht ankommen. Dies könnte als Verbesserung auch schon für den Mechanismus der Provisional Responses eine Verbesserung aufgenommen werden. Auf jeden Fall könnte dies für die INFO von A nach B, bzw. für die INFO von B nach A, wenn man sich nicht an die zuvor benutzten Nummer der Provisional Response „anhängt", verwendet werden.
  • In 6 ist abschließend aufgezeigt, in welchen Feldern die Sequenznummern Rseq übertragen werden. o bedeutet Optional und m bedeutet mandatory.

Claims (6)

  1. Verfahren zum Übertragen von Nachrichten zwischen wenigstens 2 Teilnehmern, zwischen denen ein Internetnetz (IP) angeordnet ist, dessen Schnittstelle zu den Teilnehmern durch wenigstens einen Media Gateway Controller (MGC A, MGC B) gebildet wird, der über das SIP oder SIP-T Protokoll Nachrichten überträgt, die zum Teil mit Trägernachrichten (INFO) geführt sein können, dadurch gekennzeichnet, dass in dem die Nachrichten sendenden wenigstens einen Media Gateway Controller (MGC A) vor dem Sendevorgang die im SIPoder SIP-T Protokoll geführten Nachrichten mit einer fortlaufenden Sequenznummer (Rseq10, Rseq11; Rseq25, Rseq26) beaufschlagt werden, die wahlweise fest vereinbart, nach Maßgabe einer früher bereits verwendeten fortlaufenden Sequenznummer fortgeführt oder immer auf einen Startwert gesetzt wird, und dass mit Hilfe dieser Sequenznummer (Rseq10, Rseqll; Rseq25, Rseq26) von dem die Nachrichten empfangende wenigstens einen Media Gateway Controller (MGC B) die Reihenfolge der übertragenen Nachrichten wiederhergestellt wird.
  2. Verfahren nach Anspruch 1, dadurch gekennzeichnet, dass die Teilnehmer PSTN-Teilnehmer und/oder Mobilfunk Tln sind.
  3. Verfahren nach Anspruch 1, 2, dadurch gekennzeichnet, dass die Nachrichten als ISUP-Nachrichten und/oder BICC-Nachrichten ausgebildet sind.
  4. Verfahren nach Anspruch 1, 2, dadurch gekennzeichnet, dass die ISUP-Nachrichten als USR-Nachrichten und/oder APM-Nachrichten ausgebildet sind.
  5. Verfahren nach einem der vorstehenden Ansprüche, dadurch gekennzeichnet, dass die Trägernachrichten als SIP- oder SIP-T Nachricht ausgebildet ist und nach der INFO Methode übertragen wird.
  6. Verfahren nach einem der vorstehenden Ansprüche, dadurch gekennzeichnet, dass der Startwert mit „1" beginnt und sowohl für Provisional Response Nachrichten als auch INFO Nachrichten gilt.
DE10232175A 2002-07-16 2002-07-16 Verfahren zum Sicherstellen der Reihenfolge von Nachrichten im SIP-/SIP-T Protokoll Withdrawn DE10232175A1 (de)

Priority Applications (6)

Application Number Priority Date Filing Date Title
DE10232175A DE10232175A1 (de) 2002-07-16 2002-07-16 Verfahren zum Sicherstellen der Reihenfolge von Nachrichten im SIP-/SIP-T Protokoll
AU2003250746A AU2003250746A1 (en) 2002-07-16 2003-06-11 Method for ensuring the sequence of messages in sip/ sip-t protocol
EP03787589A EP1522181A1 (de) 2002-07-16 2003-06-11 Verfahren zum sicherstellen der reihenfolge von nachrichten im sip-/ sip-t protokoll
PCT/DE2003/001942 WO2004017594A1 (de) 2002-07-16 2003-06-11 Verfahren zum sicherstellen der reihenfolge von nachrichten im sip-/ sip-t protokoll
US10/512,479 US20050237997A1 (en) 2002-07-16 2003-06-11 Method for preserving the sequence of messages in sip/sip-t protocol
CNA038015870A CN1593052A (zh) 2002-07-16 2003-06-11 用于确保sip－/sip－t协议中消息的顺序的方法

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
DE10232175A DE10232175A1 (de) 2002-07-16 2002-07-16 Verfahren zum Sicherstellen der Reihenfolge von Nachrichten im SIP-/SIP-T Protokoll

Publications (1)

Publication Number Publication Date
DE10232175A1 true DE10232175A1 (de) 2004-01-29

Family

ID=29796388

Family Applications (1)

Application Number Title Priority Date Filing Date
DE10232175A Withdrawn DE10232175A1 (de) 2002-07-16 2002-07-16 Verfahren zum Sicherstellen der Reihenfolge von Nachrichten im SIP-/SIP-T Protokoll

Country Status (6)

Country Link
US (1) US20050237997A1 (de)
EP (1) EP1522181A1 (de)
CN (1) CN1593052A (de)
AU (1) AU2003250746A1 (de)
DE (1) DE10232175A1 (de)
WO (1) WO2004017594A1 (de)

Families Citing this family (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2006116920A1 (fr) * 2005-04-30 2006-11-09 Huawei Technologies Co., Ltd. Système et procédé de communication assurant une interconnexion à travers les domaines ip par le biais d’une passerelle de supports marginale
US7668183B2 (en) * 2006-02-02 2010-02-23 Alcatel-Lucent Usa Inc. Flexible SIP profile for mixed networks
US10511521B2 (en) * 2016-08-03 2019-12-17 Anchorfree Inc. System and method for virtual multipath data transport

Family Cites Families (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
AUPQ220199A0 (en) * 1999-08-13 1999-09-02 Telefonaktiebolaget Lm Ericsson (Publ) Transport of priority based control protocol messages over a switched communications network
GB2369262A (en) * 2000-09-05 2002-05-22 Ericsson Telefon Ab L M Call looping prevention
US7126938B2 (en) * 2002-02-05 2006-10-24 Lucent Technologies Inc. Internet protocol enabled multimedia mail system with reduced bandwidth requirements
US7257109B2 (en) * 2002-05-08 2007-08-14 Sylvain Dany D Dynamic call control

Also Published As

Publication number Publication date
AU2003250746A1 (en) 2004-03-03
CN1593052A (zh) 2005-03-09
US20050237997A1 (en) 2005-10-27
EP1522181A1 (de) 2005-04-13
WO2004017594A1 (de) 2004-02-26

Similar Documents

Publication Publication Date Title
DE69905807T2 (de) Optimale Lenkung von Anrufen über das öffentliche Telefonnetz und über Internet
DE60105127T2 (de) Sitzungseintichtungsprotokoll basierend auf fortschrittlichen intelligenten netz/intelligenten netznachrichtenübertragung
EP1449386B1 (de) Verfahren zum austauschen von nach unterschiedlichen codierungsgesetzen erzeugten nutzinformationen zwischen wenigstens 2 teilnehmerendeinrichtungen
DE60103170T2 (de) Verhinderung von gesprächsumweglenkung
EP1480431A1 (de) Verfahren zur Signalisierung von Anrufumleitungsparametern in einem SIP-Netz
EP2351332B1 (de) Verfahren und einrichtung zur bidirektionalen adressumsetzung in sip-gesteuerten datenströmen zwischen ipv4- und ipv6- datenendgeräten
EP1505842B1 (de) Verfahren zum Umsteuern einer Bearerverbindung (Bearer Redirect) für SIP/ SIP-T Teilnehmer
EP1897321A1 (de) Verfahren zur steuerung des leistungsmerkmals "sip call-transfer"
DE69938252T2 (de) Sicherheit in telekommunikationsnetzübergangseinrichtungen
EP1307026A1 (de) Effiziente Änderung von Adressinformationen mit Hilfe von NAT und NAPT Routern bei getrennter Übertragung von Nutzdaten und Signalisierungsinformationen
EP1269766B1 (de) Bereitstellen von ergänzenden diensten in einem paketvermittelnden kommunikationsnetz
EP1410567A1 (de) Verfahren zur prüfung einer nutzkanalverbindung in einem telekommunikationssystem
EP1841161B1 (de) Verfahren zur gesicherten Nutzdatenübertragung
EP1360845A1 (de) Verfahren zur festlegung der codierung bei nach unterschiedlichen codierungsgesetzen erzeugten nutzinformationen zwischen wenigstens 2 teilnehmerendeinrichtungen
DE10232175A1 (de) Verfahren zum Sicherstellen der Reihenfolge von Nachrichten im SIP-/SIP-T Protokoll
DE102005057244B4 (de) Verfahren zur Kommunikation zwischen Endgeräten in SIP-Netzen
EP1294166A1 (de) Signalisierungsverfahren für die Übertragung von Nutzdaten über leitungs- und packetvermittelte Datenübertragungsnetze
EP1305958A1 (de) Verfahren zum vermitteln für die übertragung von nutzdatenpaketen sowie zugehörige signalisierungseinheit
EP1292075B1 (de) Verfahren zur Leitweglenkung von Datenpaketen
EP1661363B1 (de) Verfahren zur unterstuetzung des name delivery leistungsmerkmales fuer gemischte tdm netze/sip centrex kommunikations- architekturen
DE102004002680A1 (de) Adaptereinheit und Verfahren
DE102005045121B4 (de) Vorrichtung zur Unterstützung des Leistungsmerkmals "Fall-back" in SIP-Netzen
EP1614277B1 (de) Verfahren zum vorsehen eines teilnehmerinteraktions-dienstes ("user interactive dialogue (uid) vor verbindungsannahme") vor verbindungsannahme durch den gerufenen teilnehmer
DE102005031410A1 (de) Verfahren zum Aufbau einer multimedialen Verbindung bei kaskadierter Verbindungsweiterleitung
DE102004047025B3 (de) Verfahren zum Aufbau einer Multimedia-Verbindung

Legal Events

Date Code Title Description
OP8 Request for examination as to paragraph 44 patent law
8130 Withdrawal