WO2008017657A1 - Erkennen des korrekten sip established dialogues im falle des verlustes von nachrichten - Google Patents

Erkennen des korrekten sip established dialogues im falle des verlustes von nachrichten Download PDF

Info

Publication number
WO2008017657A1
WO2008017657A1 PCT/EP2007/058133 EP2007058133W WO2008017657A1 WO 2008017657 A1 WO2008017657 A1 WO 2008017657A1 EP 2007058133 W EP2007058133 W EP 2007058133W WO 2008017657 A1 WO2008017657 A1 WO 2008017657A1
Authority
WO
WIPO (PCT)
Prior art keywords
message
sip
dialogue
established
cscf
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.)
Ceased
Application number
PCT/EP2007/058133
Other languages
English (en)
French (fr)
Inventor
Thomas Belling
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.)
Nokia Solutions and Networks GmbH and Co KG
Original Assignee
Nokia Siemens Networks GmbH and Co KG
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 Nokia Siemens Networks GmbH and Co KG filed Critical Nokia Siemens Networks GmbH and Co KG
Publication of WO2008017657A1 publication Critical patent/WO2008017657A1/de
Anticipated expiration legal-status Critical
Ceased 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/80—Responding to QoS
    • 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/1083—In-session procedures
    • H04L65/1094—Inter-user-equipment sessions transfer or sharing
    • 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
    • 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/1016—IP multimedia subsystem [IMS]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04M—TELEPHONIC COMMUNICATION
    • H04M2207/00—Type of exchange or network, i.e. telephonic medium, in which the telephonic communication takes place
    • H04M2207/18—Type of exchange or network, i.e. telephonic medium, in which the telephonic communication takes place wireless networks

Definitions

  • the invention relates to methods and apparatus for establishing a connection in a cellular mobile radio network.
  • the so-called "Proxy Call Session Control Function” (P-CSCF) is used AF.
  • P-CSCF Provides further SIP signaling to control services between an IMS and a terminal, and extends from the embedded SDP derived infor ⁇ mation regarding the service, in particular on the type of media streams to the PCRF on.
  • SIP Session Initiation Protocol
  • SIP uses the so-called "Session Description Protocol” (SDP), IETF RFC 4556 and in an older version RFC 2327, in a manner described in IETF RFC 3264 for describing the switched communication connection
  • SDP Session Description Protocol
  • IETF RFC 4556 and in an older version RFC 2327, in a manner described in IETF RFC 3264 for describing the switched communication connection
  • the KK uses the information on services received from the AF, to configure or authorize access network connection (s) and / or charging for these services.
  • SIP "forking" procedure special procedures for the information of the CC are standardized for the P-CSCF
  • One task of these procedures is that the P-CSCF informs the CC about those media streams that belong to the SIP dialog hear ge ⁇ , the selected the terminal at the end of the construction of a service.
  • ge ⁇ the present of standardized ⁇ th procedures can lead to errors when cutting portions between P-CSCF and terminal, for example in the transmission over the air
  • the aim of the present invention is to enable the AF to recognize even the SIP dialog selected by the terminal when SIP messages are lost and to inform the CC accordingly.
  • proxies When establishing a call from the SIP terminal of a caller A to a called user B, SIP signaling can be passed on by switching nodes, so-called "proxies.”
  • the proxies are allowed an incoming message that matches the request of the user A. after a connection to B indicates (a so-called "INVITE Request") to several other proxies or SIP terminals to pass on simultaneously or sequentially, for example, to search the user B. Since following proxies can also branch the message when forwarding, this can lead to a tree-like branching of the message.
  • This branching handover of messages is referred to as "forking" in SIP
  • a so-called "lxx Provisional Response” message which may serve, for example, the to negotiate media used for communication links (eg voice, video) and their coding, or to indicate that a user B is being alerted (for example, by ringing his SIP phone). It can be in In the case of Forking, multiple terminals send such Provisional Responses, for example, when multiple SIP phones ring simultaneously.
  • a so-called "2xx Final Response” for example, if user has lifted the SIP telephone B.
  • the P-CSCF will accordingly inform the KK on those media streams that belong to the first established SIP dialog that reaches the terminal A at the end of the construction of a diene ⁇ tes.
  • the P-CSCF informs the KK on receipt of the first "2xx Final Response", that now only the media streams belonging to the corresponding first established dialog should be used.
  • the KK configures and / or authorizes the access network connections accordingly
  • the "2xx Final Response” message is lost in the transmission of P-CSCF to the terminal A.
  • the terminal selects that second page.
  • the access network connections for have been configured, the data streams of the first dialogue and / or authorized, the data streams of the two ⁇ th established dialogue selected by the terminal A can not be transported, and the service proposes characterized fail.
  • Object of the present invention is to optimize the connection setup while avoiding the problems mentioned.
  • a core of the invention is the following algorithm: If the P-CSCF after receiving an initial "2xx Final Response” message, for example a SIP "200 OK" message, in response to a SIP "INVITE" message and before receiving an "ACK” message as confirmation of this first "2xx Final Response "message at least one more" 2xx Final Response "message in response to this SIP” INVITE "message he ⁇ holds, checks the P-CSCF upon receipt of each SIP" BYE "Nach ⁇ richt with respect to one of the" 2xx "Messages generated Established Dialogues", whether exactly another of the "2xx Final Response” messages corresponding established dialogue was not terminated by a "BYE” message, and informed in this case the KK that now exclusively the to the exactly one unfinished established dialogue belonging media streams should be used.
  • the P-CSCF informs the KK as already standardized on receipt of the first "2xx Final Response" message that now only the media streams belonging to the corresponding first established dialog should be used, and only informs the KK in the sequence if exactly one unfinished established dialogue is not identical to the established dialogue corresponding to the first received "2xx Final Response" message, that now only the media streams belonging to the one unfinished established dialogue should be used.
  • a correct configuration of the KK is already achieved earlier.
  • the P-CSSF preferably added in obtaining any ,, 2xx Final Response "message to the corresponding SIP dialog in one of the" INVITE "message assigned list unless the dialogue is it not included, and deletes when he halt ⁇ each SIP" Bye "message to the corresponding SIP dialog from this stored list and then checks whether the Lis ⁇ te contains exactly one SIP dialog.
  • the present invention ensures that even if in the case of SIP Forking SIP message is lost in the transmission of P-CSCF to the terminal A, the P-CSCF correctly informs the KK of the data streams corresponding to the established dialogue selected by the terminal A. This will si ⁇ ensure that the back access network connections for the As ⁇ tenströme this dialogue configured and / or authorized, and the connection of the data streams thus is not under ⁇ broken.
  • the inventive algorithm delivers the correct result in both loss of 2xx message as with the almost equally probable ⁇ bereavement subsequent Ack message and for any number of established dialogues.
  • Fig. 1 a typical configuration of the network components
  • Fig. 2 a signaling diagram for the error case "SIP 200 OK message lost”
  • 3 shows a signaling diagram for the error case "SIP ACK message lost”.
  • Fig. 1 shows a typical configuration of the network components.
  • a mobile terminal UE A There are a mobile terminal UE A, a "Gateway GPRS Support
  • CCF Policy and Charging Rules Function
  • P-CSCF Proxy Call Session Control Function
  • Subsystem IMS shown.
  • UE A uses two PDP contexts A and B as access network connections to the GGSN through the mobile access network GPRS.
  • PDP Context A SIP signaling regarding a service, such as VoIP, is carried between UE and P-CSCF.
  • P-CSCF passes this signaling to or from the IMS.
  • PDP Context B is used as the access network connection for the service.
  • the KK configures and / or authorizes PDP Context B for the data streams of the service.
  • a SIP proxy is shown, which is connected to two SIP terminals UE Bl and UE B2.
  • Fig. 2 shows a signaling diagram for error case "SIP
  • a signaling curve is shown between the network elements shown in FIG. 1. It is assumed that the SIP proxy, that branched one sent by UE A SIP INVITE message "forked" and ter complicat to UE UE Bl and B2 wei ⁇ . Different for understanding not important SIP messages are not shown.
  • the signaling process is as follows:
  • UE A sends a SIP "INVITE" message to start a new service.
  • P-CSCF passes on the "INVITE" message This message and other SIP messages contain, among other things, information regarding the data streams belonging to the service.
  • SIP proxy decides to "forge” the SIP "INVITE" message to look for the called party and hands it over
  • SIP proxy passes the "INVITE" message to UE B2.
  • UE Bl accepts the service by sending a SIP "2xx Final Response” message, here a "200 OK (INVITE)" lookup.
  • the message contains a "Dialogue 1" label for a first dialog.
  • SIP proxy passes on the "200 OK" message.
  • P-CSCF saves the dialog 1 in a list. P-CSCF passes the "200 OK" message, assuming that this message is lost during transmission.
  • P-CSCF already informs the KK at this time about the data streams corresponding to the dialog 1.
  • the KK is already correctly informed at this time.
  • the error case shown in FIG. 2 that message 7 is lost, it may happen that the data streams are temporarily interrupted.
  • UE B2 accepts the service by sending a SIP "2xx Final Response” message, here a "200 OK (INVITE)" After ⁇ report.
  • the message contains a "Dialogue 2" label for a second dialog.
  • P-CSCF stores dialog 2 in a list. P-CSCF passes the 200 OK on.
  • a UE selects Dialog 2 according to the 3GPP standard as beizubehal ⁇ Tenden established dialogue.
  • UE A acknowledges the receipt of the SIP 200 OK message 11 according to the SIP standard by sending a SIP ACK message.
  • P-CSCF passes the SIP ACK message
  • SIP Proxy passes on the SIP ACK message
  • P-CSCF notes that Dialog 1 is already in the list of dialogs and does not have to be re-saved. P-CSCF passes the 200 OK on
  • UE A acknowledges receipt of SIP 200 OK message 17 according to SIP standard by sending a SIP ACK message.
  • P-CSCF passes the SIP "ACK" message
  • SIP proxy extends the SIP "ACK" message on 21.
  • SIP proxy extends the SIP "ACK” message on 21.
  • ⁇ genes established dialogue "Dialogue 1" by sending a "BYE” message.
  • the P-CSCF upon receipt of the "BYE" message, the P-CSCF removes the Dialog "Dialogue 1" specified in this message from the list of established dialogs, and then checks whether there is still exactly one dialog in this list. Since "2 Dialogue” is in the list only still present, infor ⁇ mized P-CSCF according to the invention the KK on the "Dialogue 2" corresponding media streams. 23. P-CSCF passes the SIP BYE message
  • SIP Proxy passes the SIP BYE message
  • Fig. 3 shows a signaling diagram for the case of error "SIP ACK message lost". It is a signaling sequence between the shown in Fig. 1. ⁇ identified network elements. It is assumed that the SIP proxy a transmitted from UE A SIP INVITE After ⁇ directing "Forked", that is branched and leading to UE Bl and UE B2. termony. Different for the understanding not important SIP messages are not represented.
  • the signaling process is as follows:
  • P-CSCF saves the dialog 1 in a list. P-CSCF passes on the "200 OK" message.
  • a UE selects "Dialogue 1" according to the 3GPP standard as beizube ⁇ holding As shown Fig.. 2 ..
  • a UE acknowledges the receipt of the SIP "200 OK" message 7 according to standard SIP by sending a SIP " ACK message. It is assumed that this message is lost during transmission 10. to 12.
  • SIP SIP "200 OK message
  • UE A acknowledges the receipt of the SIP "200 OK” message 12 in accordance with the SIP standard by sending a SIP "ACK" message.
  • P-CSCF passes the SIP "ACK" message
  • SIP proxy passes the SIP "ACK" message further 16.
  • SIP proxy passes the SIP "ACK" message further 16.
  • ⁇ genes established dialogue "Dialogue 2" by sending a "BYE” message.
  • the P-CSCF upon receipt of the "BYE" message, the P-CSCF removes the Dialog "Dialogue 2" specified in this message from the list of established dialogues, and then checks whether there is still exactly one dialog in this list. In the list because only dialogue 1 is present, informed P-CSCF according to the invention the KK on the dialogue 1 correspond ⁇ the media streams. In the variant that P-CSCF has already sent this information in step 8, no new information is now necessary because the unchanged "Dialogue 1" are selected entspre ⁇ sponding media streams. P-CSCF can now alshö ⁇ reindeer, a List of established dialogues but also not to errors, if this list is continued.
  • P-CSCF passes the SIP "BYE" message
  • SIP Proxy continues to pass the SIP "BYE" message 20 to 25. Like 15. to 20. in FIG. 2.

Landscapes

  • Engineering & Computer Science (AREA)
  • Multimedia (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Business, Economics & Management (AREA)
  • General Business, Economics & Management (AREA)
  • Telephonic Communication Services (AREA)
  • Mobile Radio Communication Systems (AREA)

Abstract

Die Erfindung betrifft Vorrichtungen und Verfahren zum Aufbau einer Verbindung in einem zellularen Mobilfunknetz, dadurch gekennzeichnet, dass wenn eine Steuerungseinrichtung (P-CSCF) nach Erhalt einer ersten,,2xx Final Responses" Nachricht als Antwort auf eine,,SIP INVITE" Nachricht und vor Erhalt einer,,ACK" Nachricht als Bestätigung dieser ersten,,2xx Final Responses" Nachricht mindestens eine weitere,,2xx Final Response" Nachricht als Antwort auf diese,,SIP INVITE" Nachricht erhält, die Steuerungseinrichtung (P-CSCF) beim Erhalt jeder SIP,,BYE" Nachricht bezüglich eines der durch die,,2xx Final Response" Nachricht erzeugten Etablierten Dialogs (,,Establis- hed Dialogue") überprüft, ob noch genau ein anderer den,,2xx Final Responses" zugeordneter Etablierter Dialog (,,Establis- hed Dialogue") durch eine,,BYE" Nachricht beendet wurde, und in diesem Fall einen Kontrollknoten (KK), zum Beispiel eine Policy Decision Function", eine,,Charging Rules Function", oder eine,,Policy and Charging Rules Function", informiert, dass jetzt ausschließlich die zu dem genau einen nicht been- deten Etablierten Dialog (,,Established Dialogue") gehörenden Medienströme verwendet werden sollen.

Description

„Erkennen des korrekten SIP Established Dialogues im Falle des Verlustes von Nachrichten"
Die Erfindung betrifft Verfahren und Vorrichtungen zum Aufbau einer Verbindung in einem zellularen Mobilfunknetz.
Gemäß 3GPP TS 29.209, bzw. 29.211, bzw. 29.214 versorgt im Rahmen der Prozeduren zur so genannten „Service Based Local Policy" (SBLP), bzw. zum so genannten „Flow Based Charging" (FBC) bzw. zum so genannten „Policy and Charging Control" (PCC) eine so genannte "Applikationsfunktion" (AF) einen Kontrollknoten (KK) ("Policy Decision Function" (PDF), bzw. „Charging Rules Function" (CRF), bzw. „Policy and Charging
Rules Function" (PCRF) ) mit Informationen über gerade ausgeführte Dienste. Beispielsweise dient im „Internet Multimedia Subsystem" (IMS), das in 3GPP TS 23.228 standardisiert ist, die so genannte „Proxy CaIl Session Control Function" (P- CSCF) als AF. Die P-CSCF reicht SIP-Signalisierung zur Kontrolle von Diensten zwischen einem IMS und einem Endgerät weiter, und reicht aus dem eingebettet SDP abgeleitete Infor¬ mation bezüglich des Dienstes, im Besonderen über die Art der Medienströme, an die PCRF weiter. Das so genannte „Session Initiation Protocol" (SIP) ist von der IETF in RFC 3261 und in einer älteren Version in RFC 2543 standardisiert. SIP nützt zur Beschreibung der vermittelten Kommunikationsverbindung das so genannte „Session Description Protocol" (SDP) , IETF RFC 4556 und in einer älteren Version RFC 2327 , in einer in IETF RFC 3264 beschriebenen Weise. Der KK nützt die vom AF erhaltene Information über Dienste, um Zugangsnetzverbindung (en) und/oder Vergebührung für diese Dienste zu konfigurieren bzw. zu autorisieren. Für die weiter unten genauer beschriebene so genannte SIP „Forking" Prozedur sind für die P-CSCF spezielle Prozeduren hinsichtlich der Information des KK standardisiert. Eine Aufgabe dieser Prozeduren ist es, dass die P-CSCF den KK über diejenigen Medienströme informiert, die zu dem SIP Dialog ge¬ hören, den das Endgerät am Ende des Aufbaus eines Dienstes ausgewählt. Allerdings können die gegenwärtig standardisier¬ ten Prozeduren dann zu Fehlern führen, wenn zwischen P-CSCF und Endgerät, zum Beispiel bei der Übertragung über die Luft- schnittsteile, SIP Nachrichten verloren gehen.
Ziel der vorliegenden Erfindung ist es, der AF zu ermöglichen, auch dann den vom Endgerät ausgewählten SIP Dialog zu erkennen, wenn SIP Nachrichten verloren gehen, und den KK entsprechend zu informieren.
Beim Rufaufbau von dem SIP Endgerät eines Anrufers A zu einem angerufenen Nutzer B kann die SIP- Signalisierung von Vermittlungsknoten, so genannten „Proxies", weitergereicht werden. Dabei ist es den Proxies erlaubt, eine eingehende Nach- rieht, die den Wunsch des Nutzers A nach einer Verbindung zu B anzeigt (ein so genannter „INVITE Request") an mehrere andere Proxies oder SIP Endgeräte gleichzeitig oder sequentiell weiterzureichen, zum Beispiel um den Nutzer B zu suchen. Da auch darauf folgende Proxies die Nachricht beim Weiterreichen verzweigen können, kann es zu einer baumartigen Verzweigung der Nachricht kommen. Dieses verzweigte Weiterreichen von Nachrichten wird in SIP als „Forking" bezeichnet. Wenn die INVITE Nachricht ein Endgerät des Nutzers B erreicht, kann dieses Endgerät mit einer so genannten „lxx Provisional Res- ponse" Nachricht antworten, die zum Beispiel dazu dienen kann, die zur Kommunikationsverbindungen verwendeten Medien (z.B. Sprache, Video) und ihre Codierung auszuhandeln, oder aber dazu anzuzeigen, das ein Nutzer B alarmiert wird (zum Beispiel durch das Klingeln seines SIP-Telefons) . Es kann im Fall von Forking vorkommen, dass mehrere Endgeräte solche Provisional Responses schicken, beispielsweise wenn mehrere SIP-Telefone gleichzeitig klingeln. Zum Abschluss des Auf¬ baus der Kommunikationsbeziehung zwischen A und einem Endge- rät von B antwortet dieses Endgerät mit einer so genannten „2xx Final Response", beispielsweise wenn Nutzer B das SIP- Telefon abgehoben hat. Mehrere Endgeräte von B können solche „Final Responses" (=endgültige Antworten) schicken, bei¬ spielsweise wenn mehrere klingelnde SIP-Telefone abgehoben werden. Entsprechend kann es vorkommen, dass das Endgerät ei¬ ne Teilnehmers A „Provional Responses" und / oder „Final Res¬ ponses" von mehreren Endgeräten eines Teilnehmers B erhält. Jedes Endgerät von B versieht alle Nachrichten, die es als Antworten an A sendet, mit der gleichen eindeutigen Identifi- zierung. Erreichen das Endgerät von A SIP Antwortnachrichten mit einer neuen Identifizierung, erfährt das Endgerät von A dadurch, dass es mit einem neuen Endpunkt kommuniziert. In SIP spricht man in diesem Fall davon, dass zwischen dem Endgerät von A und dem antwortenden Endgerät von B ein so ge- nannter „Dialog" besteht. Bevor A für einen Dialog eine „fi¬ nal Response" erhalten hat, spricht man von einem „frühen Dialog" (engl. „Early Dialogue") , danach von einem „etablierten Dialog" (engl. „Established Dialogue"). Sobald ein Endgerät B durch Senden einer „2xx Final Response" einen etablierten Dialog erzeugt, beenden in vielen Fällen diejenigen Proxies, die durch Forking weitere frühe Dialoge verursacht haben, diese frühen Dialoge durch Signalisierung mit den anderen Endgeräten B. Wenn jedoch mehrere Endgeräte B nahezu gleichzeitig mehrere „2xx Final Response" Nachrichten senden, können alle diese Nachrichten Endgerät A erreichen und dazu führen, dass mehrere etablierten Dialoge entstehen. Gemäß 3GPP TS 23.228, Kapitel 4.2.7.3, soll in diesem Fall ein IMS Terminal als Endgerät A allerdings nur den ersten e- tablierten Dialog weiterführen, und die anderen durch Senden von SIP ,,BYE" Nachrichten sofort beenden.
Die P-CSCF soll entsprechend den KK über diejenigen Medienströme informieren, die zu dem ersten etablierten SIP Dialog gehören, der das Endgerät A am Ende des Aufbaus eines Diens¬ tes erreicht.
Bisher ist standardisiert, dass die P-CSCF den KK beim Erhalt der ersten „2xx Final Response" informiert, dass jetzt aus- schließlich die zu dem entsprechenden ersten etablierten Dialog gehörenden Medienströme verwendet werden sollen. Der KK konfiguriert und/oder autorisiert die Zugangsnetverbindungen entsprechend. Allerdings kann es vorkommen, dass die „2xx Final Response" Nachricht bei der Übertragung von P-CSCF zu dem Endgerät A verloren geht. Wenn in der Folge eine zu einem anderen zweiten Dialog gehörende „2xx" Nachricht von dem Terminal A emp¬ fangen wird, wählt das Terminal diesen zweiten Dialog aus. Da aber auf Grund der von der P-CSCF erhaltenen Information durch den KK die Zugangsnetzverbindungen für die Datenströme des ersten Dialogs konfiguriert und/oder autorisiert wurden, werden die Datenströme des vom Endgerät A ausgewählten zwei¬ ten etablierten Dialog nicht transportiert, und der Dienst schlägt dadurch fehl.
Das beschriebene Problem wurde im letzten 3GPP CT3 Meeting erkannt, aber bisher wurde dafür noch keine Lösung gefunden.
Aufgabe der vorliegenden Erfindung ist unter Vermeidung der genannten Probleme den Verbindungsaufbau zu optimieren. Die
Aufgabe wird jeweils durch die in den unabhängigen Ansprüchen definierte Erfindung gelöst.
Ein Kern der Erfindung ist der folgende Algorithmus: Wenn die P-CSCF nach Erhalt einer ersten „2xx Final Response" Nachricht, zum Beispiel eine SIP „200 OK" Nachricht, , als Antwort auf eine SIP „INVITE" Nachricht und vor Erhalt einer „ACK" Nachricht als Bestätigung dieser ersten „2xx Final Res- ponse" Nachricht mindestens eine weitere „2xx Final Response" Nachricht als Antwort auf diese SIP „INVITE" Nachricht er¬ hält, überprüft die P-CSCF beim Erhalt jeder SIP „BYE" Nach¬ richt bezüglich eines der durch die „2xx" Nachrichten erzeugten etablierten Dialoge („Established Dialogues") , ob noch genau ein anderer der den „2xx Final Response" Nachrichten entsprechender etablierten Dialog nicht durch eine „BYE" Nachricht beendet wurde, und informiert in diesem Fall den KK, dass jetzt ausschließlich die zu dem genau einen nicht beendeten etablierten Dialog gehörenden Medienströme verwen- det werden sollen.
Vorzugsweise informiert die P-CSCF wie bisher standardisiert den KK bereits bei Erhalt der ersten „2xx Final Response" Nachricht, dass jetzt ausschließlich die zu dem entsprechen- den ersten etablierten Dialog gehörenden Medienströme verwendet werden sollen, und informiert den KK in der Folge nur dann, wenn der genau eine nicht beendete etablierten Dialog nicht mit dem der ersten empfangenen „2xx Final Response" Nachricht entsprechenden etablierten Dialog identisch ist, dass jetzt ausschließlich die zu dem genau einen nicht beendeten etablierten Dialog gehörenden Medienströme verwendet werden sollen. Damit wird in der größten Zahl der Fälle bereits früher eine korrekte Konfiguration des KK erreicht.
Wenn die P-CSCF nicht bereits beim Erhalt der ersten „2xx
Final Response" Nachricht den KK informiert hat und ohne zwi¬ schenzeitlichen Empfang mindestens einer weiteren „2xx Final Response" Nachricht die „ACK" Nachricht zur ersten „2xx Final Response" Nachricht empfängt, informiert die P-CSCF nun den KK, dass jetzt ausschließlich die zu dem entsprechenden ersten etablierten Dialog gehörenden Medienströme verwendet werden sollen.
Die P-CSSF fügt vorzugsweise beim Erhalt jeder ,,2xx Final Response" Nachricht den entsprechenden SIP Dialog in einer der „INVITE" Nachricht zugeordneten Liste ein, sofern der Dialog darin nicht bereits enthalten ist, und löscht beim Er¬ halt jeder SIP „Bye" Nachricht den entsprechenden SIP Dialog aus dieser gespeicherten Liste und überprüft dann ob die Lis¬ te noch genau einen SIP Dialog enthält.
Die vorliegende Erfindung stellt sicher, dass auch wenn im Falle von SIP Forking SIP Nachricht bei der Übertragung von P-CSCF zu dem Endgerät A verloren gehen, die P-CSCF den KK korrekt über die dem vom Endgerät A ausgewählten etablierten Dialog entsprechenden Datenströme informiert. Damit wird si¬ chergestellt, dass die Zugangsnetzverbindungen für die Da¬ tenströme dieses Dialogs konfiguriert und/oder autorisiert werden und die Verbindung der Datenströme somit nicht unter¬ brochen wird.
Der erfindungsgemäße Algorithmus liefert sowohl bei Verlust der 2xx Nachricht wie auch bei dem nahezu ebenso wahrschein¬ lichen Verlust der darauf folgenden Ack Nachricht und auch für eine beliebige Anzahl von etablierten Dialogen das richtige Ergebnis.
Weitere Merkmale und Vorteile der Erfindung ergeben sich aus den Patentansprüchen und der nachfolgenden Beschreibung eines Ausführungsbeispiels anhand der Zeichnung, Dabei zeigt:
Fig. 1: eine typische Konfiguration der Netzkomponenten, Fig. 2: ein Signalisierungsdiagramm für den Fehlerfall „SIP 200 OK Nachricht verloren" und Fig. 3: ein Signalisierungsdiagramm für den Fehlerfall „SIP ACK Nachricht verloren".
Fig. 1 zeigt eine typische Konfiguration der Netzkomponenten. Es sind ein mobiles Endgerät UE A, eine „Gateway GPRS Support
Node" GGSN, ein Kontrollknoten KK (Beispielsweise eine "PoIi- cy Decision Function" (PDF) , eine „Charging Rules Function"
(CRF) , oder eine „Policy and Charging Rules Function" (PCRF) ) und eine „Proxy CaIl Session Control Function" P-CSCF als Ap- plikationsfunktion AF innerhalb eines Internet Multimedia
Subsystem IMS dargestellt. UE A nützt zwei PDP Kontexte A und B als Zugangsnetzverbindungen zum GGSN durch das mobile Zugangsnetz GPRS. In PDP Context A wird SIP Signalisierung bezüglich eines Dienstes, wie beispielsweise VoIP, zwischen UE and P-CSCF befördert. P-CSCF reicht diese Signalisierung zum bzw. vom IMS weiter. PDP Context B wird als Zugangsnetzverbindung für den Dienst verwendet. Der KK konfiguriert und/oder autorisiert PDP Context B für die Datenströme des Dienstes. Weiterhin ist ein SIP-Proxy dargestellt, der mit zwei SIP Endgeräten UE Bl und UE B2 verbunden ist..
Fig. 2 zeigt ein Signalisierungsdiagramm für Fehlerfall „SIP
200 OK Nachricht verloren".
Es ist ein Signalisierungsverlauf zwischen den in Fig. 1 dar- gestellten Netzwerkelementen dargestellt. Es wird angenommen, dass der SIP Proxy einen von UE A gesendete SIP INVITE Nachricht „forked", also verzweigt und zu UE Bl sowie UE B2 wei¬ terleitet. Verschiedene für das Verständnis nicht wichtige SIP Nachrichten werden nicht dargestellt.
Der Signalisierungsverlauf ist im Einzelnen wie folgt:
1. UE A sendet eine SIP „INVITE" Nachricht, um einen neuen Dienst zu starten. 2. P-CSCF reicht die „INVITE" Nachricht weiter. In dieser und weiteren SIP Nachrichten sind unter Anderem Angaben bezüglich der zum Dienst gehörenden Datenströme enthalten.
3. SIP-Proxy beschließt, die SIP „INVITE" Nachricht zu „for- ken", um den angerufenen Teilnehmer zu suchen, und reicht die
„INVITE" Nachricht zu UE Bl weiter.
4. SIP-Proxy reicht die „INVITE" Nachricht zu UE B2 weiter.
5. UE Bl akzeptiert den Dienst durch Senden einer SIP „2xx Final Response" Nachricht, hier einer „200 OK(INVITE)" Nach- rieht. Die Nachricht enthält für einen ersten Dialog eine Kennzeichnung „Dialogue 1".
6. SIP-Proxy reicht die „200 OK" Nachricht weiter.
7. P-CSCF speichert den Dialog 1 in einer Liste. P-CSCF reicht die „200 OK" Nachricht weiter. Es wird angenommen, dass diese Nachricht bei der Übertragung verloren geht.
8. In einer vorteilhaften Ausführungsform informiert P-CSCF den KK bereits zu diesem Zeitpunkt über die Dialog 1 ent¬ sprechenden Datenströme. Dadurch wird in dem Normalfall, dass keine Nachrichten verloren gehen, bereits zu diesem Zeitpunkt der KK korrekt informiert. Anderseits kann es in dem in Fig. 2 dargestellten Fehlerfall, dass Nachricht 7 verloren wird, dazu kommen, dass die Datenströme zeitweilig unterbrochen werden .
9. UE B2 akzeptiert den Dienst durch Senden einer SIP „2xx Final Response" Nachricht, hier einer „200 OK(INVITE)" Nach¬ richt. Die Nachricht enthält für einen zweiten Dialog eine Kennzeichnung „Dialogue 2".
10. SIP-Proxy reicht die 200 OK weiter.
11. P-CSCF speichert den Dialog 2 in einer Liste. P-CSCF reicht die 200 OK weiter.
12. UE A wählt Dialog 2 gemäß 3GPP Standard als beizubehal¬ tenden etablierten Dialog. UE A bestätigt den Empfang der SIP 200 OK Nachricht 11 gemäß SIP Standard durch Senden einer SIP ACK Nachricht. 13. P-CSCF reicht die SIP ACK Nachricht weiter
14. SIP Proxy reicht die SIP ACK Nachricht weiter
15. Da UE Bl keine ACK Nachricht als Antwort auf die SIP 200 OK Nachricht 5 empfangen hat, wiederholt er nach Ablauf eines kurzen Zeitraums das Senden der SIP 200 OK Nachricht.
16. SIP-Proxy reicht die 200 OK weiter.
17. P-CSCF stellt fest, dass Dialog 1 bereits in der Liste der Dialoge enthalten ist und nicht erneut abgespeichert wer- den muss. P-CSCF reicht die 200 OK weiter
18. UE A bestätigt den Empfang der SIP 200 OK Nachricht 17 gemäß SIP Standard durch Senden einer SIP ACK Nachricht.
19. P-CSCF reicht die SIP „ACK" Nachricht weiter
20. SIP Proxy reicht die SIP „ACK" Nachricht weiter 21. Gemäß 3GPP Standard beendet UE A den als zweiten empfan¬ genen etablierten Dialog „Dialogue 1" durch Senden einer „BYE" Nachricht.
22. Erfindungsgemäß entfernt die P-CSCF bei Erhalt der „BYE" Nachricht den in dieser Nachricht angegebenen Dialog „Dialo- gue 1" aus der Liste der etablierten Dialoge, und überprüft dann, ob noch genau ein Dialog in dieser Liste vorhanden ist. Da in der Liste nur noch „Dialogue 2" vorhanden ist, infor¬ miert P-CSCF erfindungsgemäß den KK über die „Dialogue 2" entsprechenden Medienströme. 23. P-CSCF reicht die SIP BYE Nachricht weiter
24. SIP Proxy reicht die SIP BYE Nachricht weiter
Fig. 3 zeigt ein Signalisierungsdiagramm für den Fehlerfall „SIP ACK Nachricht verloren". Es ist ein Signalisierungsverlauf zwischen den in Fig. 1 dar¬ gestellten Netzwerkelementen dargestellt. Es wird angenommen, dass der SIP Proxy einen von UE A gesendete SIP INVITE Nach¬ richt „forked", also verzweigt und zu UE Bl sowie UE B2 wei- terleitet. Verschiedene für das Verständnis nicht wichtige SIP Nachrichten werden nicht dargestellt.
Der Signalisierungsverlauf ist im Einzelnen wie folgt:
1. bis 6. Wie Fig. 2.
7. P-CSCF speichert den Dialog 1 in einer Liste. P-CSCF reicht die „200 OK" Nachricht weiter.
8. Wie Fig. 2. 9. UE A wählt „Dialogue 1" gemäß 3GPP Standard als beizube¬ haltenden Wie Fig. 2.. UE A bestätigt den Empfang der SIP „200 OK" Nachricht 7 gemäß SIP Standard durch Senden einer SIP „ACK" Nachricht. Es wird angenommen, dass diese Nachricht bei der Übertragung verloren geht. 10. bis 12. Wie 9. bis 11. in Fig. 2.
13. UE A bestätigt den Empfang der SIP „200 OK" Nachricht 12 gemäß SIP Standard durch Senden einer SIP „ACK" Nachricht.
14. P-CSCF reicht die SIP „ACK" Nachricht weiter
15. SIP Proxy reicht die SIP „ACK" Nachricht weiter 16. Gemäß 3GPP Standard beendet UE A den als zweiten empfan¬ genen etablierten Dialog „Dialogue 2" durch Senden einer „BYE" Nachricht.
17. Erfindungsgemäß entfernt die P-CSCF bei Erhalt der „BYE" Nachricht den in dieser Nachricht angegebenen Dialog „Dialo- gue 2" aus der Liste der etablierten Dialoge, und überprüft dann, ob noch genau ein Dialog in dieser Liste vorhanden ist. Da in der Liste nur noch Dialog 1 vorhanden ist, informiert P-CSCF erfindungsgemäß den KK über die Dialog 1 entsprechen¬ den Medienströme. In der Variante, dass P-CSCF diese Informa- tion bereits in Schritt 8 gesendet hat, ist nun keine erneute Information nötig, da unverändert die „Dialogue 1" entspre¬ chenden Medienströme ausgewählt sind. P-CSCF kann nun aufhö¬ ren, eine Liste der etablierten Dialoge zu führen. Es kann allerdings auch nicht zu Fehlern kommen, wenn diese Liste weiter geführt wird.
18. P-CSCF reicht die SIP „BYE" Nachricht weiter
19. SIP Proxy reicht die SIP „BYE" Nachricht weiter 20 bis 25. Wie 15. bis 20. in Fig. 2.

Claims

Patentansprüche
1. Verfahren zum Aufbau einer Verbindung in einem zellularen Mobilfunknetz, dadurch gekennzeichnet, dass wenn eine Steuerungseinrichtung (P-CSCF) nach Erhalt einer ersten „2xx Final Responses" Nachricht als Antwort auf eine „SIP INVITE" Nachricht und vor Erhalt einer „ACK" Nachricht als Bes¬ tätigung dieser ersten „2xx Final Responses" Nachricht mindestens eine weitere „2xx Final Response" Nachricht als Antwort auf diese „SIP INVITE" Nachricht erhält, die Steuerungseinrichtung (P-CSCF) beim Erhalt jeder SIP „BYE" Nachricht bezüglich eines durch die „2xx Final Response" Nachrichten erzeugten Etablierten Dialogs („Established Dialogue") überprüft, ob noch genau ein anderer den „2xx Final Responses" Nachrichten zugeordne¬ ter Etablierter Dialog („Established Dialogue") nicht durch eine „BYE" Nachricht beendet wurde, und in diesem Fall einen Kontrollknoten (KK, zum Beispiel eine Policy Decision Function", eine „Charging Rules Function", oder eine „Policy and Charging Rules Function") informiert, dass jetzt ausschließlich die zu dem genau einen nicht beendeten Etablierten Dialog („Established Dialogue") gehörenden Medienströme verwendet werden sollen.
2. Verfahren nach Anspruch 1, dadurch gekennzeichnet, dass die Steuerungseinrichtung (P-CSCF) den Kontrollknoten
(KK) bereits bei Erhalt der ersten „2xx Final Response" Nachricht darüber informiert, dass jetzt ausschließlich die zu dem entsprechenden ersten etablierten Dialog
(„Established Dialogue") gehörenden Medienströme verwen¬ det werden sollen, und den Kontrollknoten (KK) in der Folge nur dann informiert, wenn der genau eine nicht be¬ endete etablierte Dialog („Established Dialogue") nicht mit dem der ersten empfangenen „2xx Final Response" Nachricht entsprechenden Etablierten Dialog („Establis- hed Dialogue") identisch ist, dass jetzt ausschließlich die zu dem genau einen nicht beendeten Etablierten Dia- log („Established Dialogue") gehörenden Medienströme verwendet werden sollen.
3. Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass wenn die Steuerungseinrichtung (P-CSCF) nicht bereits beim Erhalt der ersten „2xx Final Response" Nachricht den Kontrollknoten (KK) informiert hat und ohne zwischenzeitlichen Empfang mindestens einer weiteren „2xx Final Response" Nachricht die „ACK" Nachricht zur ersten „2xx Final Response" Nachricht empfängt, die P-CSCF nun den Kontrollknoten (KK) informiert, dass jetzt aus¬ schließlich die zu dem entsprechenden ersten etablierten Dialog („Established Dialogue") gehörenden Medienströme verwendet werden sollen.
4. Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass die Steuerungseinrichtung (P-CSCF) beim Erhalt jeder „2xx Responses" Nachricht den entsprechenden SIP Dialog in eine der „INVITE" Nachricht zugeordneten Liste einfügt, sofern der Dialog darin nicht bereits enthalten ist, und beim Erhalt jeder SIP „Bye" Nachricht den ent¬ sprechenden SIP Dialog aus dieser gespeicherten Liste löscht und dann überprüft ob die Liste noch genau einen SIP Dialog enthält.
5. Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass der Kontrollknoten (KK) eine Policy Decision Function", eine „Charging Rules Function", oder eine „Policy and Charging Rules Function" ist.
6. Steuerungseinrichtung (P-CSCF) zum Aufbau einer Verbin- düng in einem zellularen Mobilfunknetz, mit einer Empfangseinrichtung, mit einer Sendeeinrichtung und mit einer Überprüfungseinrichtung, dadurch gekennzeichnet, dass die Steuerungseinrichtung so aufgebaut ist, dass wenn die Steuerungseinrichtung nach Erhalt einer ersten „2xx Final Responses" Nachricht in der Empfang¬ seinrichtung als Antwort auf eine „SIP INVITE" Nachricht und vor Erhalt einer „ACK" Nachricht als Bestätigung dieser ersten „2xx Final Responses" Nachricht mindestens eine weitere „2xx Final Response" Nachricht als Antwort auf diese „SIP INVITE" Nachricht erhält, die Steuerungseinrichtung beim Erhalt jeder SIP „BYE" Nachricht bezüglich eines der durch die „2xx Final Res- ponse" Nachricht erzeugten Etablierten Dialogs
(„Established Dialogue") mit der Überprüfungseinrichtung überprüft, ob noch genau ein anderer den „2xx Final Res¬ ponses" entsprechender Etablierter Dialog („Established Dialogue") durch eine „BYE" Nachricht beendet wurde, und in diesem mit der Sendeeinrichtung Fall den Kontrollknoten (KK) informiert, dass jetzt ausschließlich die zu dem genau einen nicht beendeten etablierten Dialog („Established Dialogue") gehörenden Medienströme verwen¬ det werden sollen.
PCT/EP2007/058133 2006-08-11 2007-08-06 Erkennen des korrekten sip established dialogues im falle des verlustes von nachrichten Ceased WO2008017657A1 (de)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
EP06016879A EP1887773A1 (de) 2006-08-11 2006-08-11 Erkennen des korrekten SIP Established Dialogues im Falle des Verlustes von Nachrichten
EP06016879.6 2006-08-11

Publications (1)

Publication Number Publication Date
WO2008017657A1 true WO2008017657A1 (de) 2008-02-14

Family

ID=37604538

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/EP2007/058133 Ceased WO2008017657A1 (de) 2006-08-11 2007-08-06 Erkennen des korrekten sip established dialogues im falle des verlustes von nachrichten

Country Status (2)

Country Link
EP (1) EP1887773A1 (de)
WO (1) WO2008017657A1 (de)

Non-Patent Citations (3)

* Cited by examiner, † Cited by third party
Title
"Digital cellular telecommunications system (Phase 2+); Universal Mobile Telecommunications System (UMTS); IP Multimedia System (IMS); Stage (3GPP TS 23.228 version 7.2.0 Release 7)", ETSI TS 123 228 V7.2.0, December 2005 (2005-12-01), XP014032467 *
"Universal Mobile Telecommunications System (UMTS); Policy Control over Gq interface (3GPP TS 29.209 version 6.4.0 Release 6)", ETSI TS 129 209 V6.4.0, September 2005 (2005-09-01), XP014032719 *
ROSENBERG J ET AL: "SIP: Session Initiation Protocol", IETF RFC 3261, June 2002 (2002-06-01), pages 1 - 269, XP002323877 *

Also Published As

Publication number Publication date
EP1887773A1 (de) 2008-02-13

Similar Documents

Publication Publication Date Title
DE602004009669T2 (de) Routing-optimierung bei der sip-verbindungsherstellung
JP4549414B2 (ja) 通信方法及び通信システム
US7529354B2 (en) Method of managing a connection release, corresponding system and device
DE102004026785B4 (de) Kommunikationssystem, Kommunikationsendgerät, Konferenzsteuereinheit, Verfahren zum Steuern eines Kommunikationssystems, Verfahren zum Steuern eines Kommunikationsendgeräts und Verfahren zum Steuern einer Konferenzsteuereinheit
WO2007128693A1 (de) Verfahren zum ermöglichen einer steuerung der dienstqualität und/oder der dienstvergebührung bei telekommunikationsdiensten
DE10361704A1 (de) Vorrichtung und Verfahren zum Aufbauen einer Verbindung in einem aus mobilen Knoten gebildeten Funknetzwerk
WO2008017662A1 (de) Festlegung des veranlassers für eine konfiguration oder einen aufbau einer zugangsnetzverbindung
DE60212988T2 (de) Verfahren, Einrichtung und Computerprogramm zur Auswahl einer Medienübergangskontrollfunktion basierend auf der Überwachung von Resourcen von Medienübergangsfunktionen
EP1673918B1 (de) Behandlung von Early Media-Daten I
EP1673919A1 (de) Behandlung von early media ii
EP1662820A1 (de) Übermittlung Dienst-relevanter Zugangsinformationen bei Authentisierung eines Endgeräts an einer Zugangseinrichtung eines Telekommunikationsnetzes
DE102006014921A1 (de) Verfahren für Lawful Interception bei Anrufweiterschaltung in einem paketorientierten Telekommunikationsnetz
DE602004007552T2 (de) Verfahren und einrichtung für push-to-talk-dienst
DE102011053994B3 (de) Verfahren zur Festnetzerreichbarkeit und dafür geeignetes Mobilfunkendgerät
WO2008017657A1 (de) Erkennen des korrekten sip established dialogues im falle des verlustes von nachrichten
DE102004030290A1 (de) Aufbau einer Verbindung für den Austausch von Daten eines IP-basierten Dienstes
WO2004102921A1 (de) Verfahren zum aufbau einer kommunikationsverbindung und kommunikationssystem
EP1887738A1 (de) Festlegung des Veranlassers für eine Konfiguration oder einen Aufbau einer Zugangsnetzverbindung
WO2008022613A2 (de) Verfahren zum erzeugen einer kommunikationssitzung - steuernachricht unter verwendung von sip
DE102008045790B4 (de) Verfahren und Kommunikationsnetz zum mehrfachen Umleiten einer Kommunikationsverbindung
EP1535477A1 (de) Verfahren zum weiterleiten von signalisierungsnachrichten und zugeh rige komponenten
EP1641303A1 (de) Nutzung von Presence-Informationen (Statusinformationen) zur Erweiterung einer bestehenden Kommunikationsverbindung
EP1936923A1 (de) Verfahren und Vorrichtungen zur Vermittlung von leitungsvermittelnden zu paketvermittelnden Domänen
EP2025141A1 (de) Verfahren zum weiterleiten einer nachricht sowie rechnereinheit und kommunikationssystem
WO2003096711A1 (de) Verfahren zum erfassen von anrufen und zugehörige einheiten

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 07788247

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

NENP Non-entry into the national phase

Ref country code: RU

122 Ep: pct application non-entry in european phase

Ref document number: 07788247

Country of ref document: EP

Kind code of ref document: A1