[go: up one dir, main page]

WO2004102921A1 - Verfahren zum aufbau einer kommunikationsverbindung und kommunikationssystem - Google Patents

Verfahren zum aufbau einer kommunikationsverbindung und kommunikationssystem Download PDF

Info

Publication number
WO2004102921A1
WO2004102921A1 PCT/EP2004/050784 EP2004050784W WO2004102921A1 WO 2004102921 A1 WO2004102921 A1 WO 2004102921A1 EP 2004050784 W EP2004050784 W EP 2004050784W WO 2004102921 A1 WO2004102921 A1 WO 2004102921A1
Authority
WO
WIPO (PCT)
Prior art keywords
sip
communication terminal
network elements
authorized
communication
Prior art date
Application number
PCT/EP2004/050784
Other languages
English (en)
French (fr)
Inventor
Mark Beckmann
Achim Luft
Holger Schmidt
Original Assignee
Siemens Aktiengesellschaft
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 Aktiengesellschaft filed Critical Siemens Aktiengesellschaft
Priority to US10/557,391 priority Critical patent/US7769020B2/en
Publication of WO2004102921A1 publication Critical patent/WO2004102921A1/de

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/1016—IP multimedia subsystem [IMS]
    • 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/1045—Proxies, e.g. for 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/1066—Session management
    • H04L65/1069—Session establishment or de-establishment
    • 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
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/04—Protocols specially adapted for terminals or networks with limited capabilities; specially adapted for terminal portability
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/14—Session management
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/40—Network security protocols
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W76/00—Connection management
    • H04W76/10—Connection setup
    • H04W76/12—Setup of transport tunnels
    • 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
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/30—Definitions, standards or architectural aspects of layered protocol stacks
    • H04L69/32—Architecture of open systems interconnection [OSI] 7-layer type protocol stacks, e.g. the interfaces between the data link level and the physical level
    • H04L69/322—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions
    • H04L69/329—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions in the application layer [OSI layer 7]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W76/00—Connection management
    • H04W76/10—Connection setup
    • H04W76/11—Allocation or use of connection identifiers

Definitions

  • the invention relates to a method for establishing a communication connection between a first communication terminal and a second communication terminal, in which the communication connection is realized by means of interconnected network elements, and a corresponding communication system, in particular a UM S.
  • SIP session initiation protocol
  • a SIP session is usually between two communication terminals, also called user entity UE, with the interposition of several interconnected network elements, for example some proxies.
  • SIP was used by 3GPP as the signaling protocol for the IP
  • a SIP session can also be made by
  • proxies such as the P-CSCF, S-CSCF, MGCF or AS, within the IP Multimedia Core Network Subsystem are dismantled or terminated [1], [2], [3].
  • Session dismantling by the P-CSCF can e.g. the interruption of the radio connection of the UE to the UTRAN (out of coverage).
  • the S-CSCF ends among other things the SIP session between the UEs based on an exhausted prepaid account of one of the end devices or for administrative reasons [1].
  • UAC user agent clients
  • UAS user agent servers
  • FIG. 1 shows the known SIP signaling messages in the IMS during a breakdown of the SIP session initiated by the P-CSCF in the event that the radio connection between the UE or UA and the UTRAN was interrupted (out of coverage) (cf.
  • the BYE message is used by the P-CSCF to identify the session and the
  • the UE or the UA by means of the 200 OK message, confirms the P-CSCF that the SIP session has been terminated and then builds the PDP context, i.e. the data connection to the UTRAN / CN on which the media session data is transmitted. Further details can be found in [1] Chap. 5.10.3.1.1 (see also [2] Chapter 8).
  • a network element e.g. the P-CSCF
  • the SIP session According to the state of the art, the UA has no control over who clears the session or which proxy is authorized to do so.
  • the UA functions as a pure “command recipient.
  • the IETF criticized this deviating functionality of the standard SIP (3GPP version) adapted by 3GPP. According to the current state of the art, it is therefore not possible to integrate the SIP protocol into the 3GPP standard, at least not with the consent of the IETF.
  • selected network elements are therefore authorized to initiate a clearing down of the communication connection.
  • Communication terminals can in particular be all communication devices that can be the start or destination of a SIP session.
  • An example of a communication terminal is a cell phone, in particular a UMTS cell phone.
  • a UA, a UAS or a UAC is also understood as a communication terminal.
  • a communication link in particular comprises packet-switched communication links.
  • An invitation message that is transmitted via network elements can preferably be changed by each network element and then forwarded to the next network element.
  • invitation messages Changed invitation messages, reply messages or update messages are also referred to as invitation messages.
  • the invention is therefore based on the idea that not every network element, for example not every proxy, can terminate the connection, for example a session, or cause the termination. In this way, for example, an authorization check in a communication control of the session breakdown in compliance with IETF
  • Communication terminal for example by the UA. It is thereby achieved that network elements, for example proxies, can trigger a termination of the connection (session), but a final disconnection is subject to the control of a communication terminal.
  • network elements for example proxies
  • the invention includes in particular a method for negotiating the network elements - also referred to below as proxies - which are authorized to end a SIP session between UAs.
  • the permissions to terminate a SIP session can preferably be assigned by the UAs. This meets the IETF's requirement that the UAs have control over the established session. However, this property can be restricted by appropriate configuration and adaptation of the process in order to meet the 3GPP specific requirements. These requirements differ from those of the IETF in that the UMTS mobile network operators have the greatest possible control over those in their network, i.e. want to have SIP sessions in their IMS / CN. This requirement for network control of the SIP session runs counter to the IETF principle of a UA controlled SIP session.
  • a further development of the invention provides that when the communication connection is set up, an invitation message is transmitted from the first communication terminal to the second communication terminal via network elements which are connected to one another, in particular on the signaling path, and that an identifier of the network elements is used to authorize a release wish for the communication connection to be entered in the invitation message. So there will be information in an invitation is entered, which signal to the communication terminals which network element is to be authorized to terminate a connection or to initiate the termination of a connection.
  • the method is therefore preferably distinguished in particular by the fact that the proxies that are on the signaling path between the UAs indicate to the UAs during the session establishment whether they want to be authorized to clear the SIP session. For this purpose, they insert an identifier (information element) in a corresponding message header (header field) of an invitation message (message or INVITE message), which identifies them (SIP URI or SIPS URI) and indicates that the specified proxy wants to be authorized to do so to end the SIP session.
  • the recipient of the INVITE message i.e. the UAS can then check the entries in the relevant header field.
  • the UAS can then provide an answer, e.g. send a "183 Session in Progress" message to the UAC.
  • This message can generally be a copy of the corresponding header field of the INVITE
  • the UAS can delete the entries of individual proxies that it does not accept as session-breaking proxies.
  • the UAS can make this decision using predefined criteria, a list comparison and / or a configuration by the user, for example.
  • the identifiers of the authorized network elements can also be stored in a subscriber identification module (SIM) within the communication terminal.
  • SIM subscriber identification module
  • the UAC can check the list of proxies that want to receive authorization to terminate the SIP session and that have been accepted by the UAS , If at least one proxy listed is not accepted by the UAC, the UAC can send a correspondingly reduced list of proxies to the UAS in a further message. Again, at least all proxies in the list that has not yet been revised by the UAC can be run through.
  • the UPDATE method [6] which is an extension of [4], can be used to transfer this list.
  • messages may be exchanged several times between the UAs until agreement has been reached between the UAs. If no agreement can be reached, the session setup can be canceled. With such a procedure, the decision as to which proxy is authorized to terminate the session ultimately rests with the UAs.
  • Figure 1 Flow chart of a network P-CSCF-initiated
  • FIG. 2 flow diagram of a network P-CSCF-initiated breakdown of a SIP session (first exemplary embodiment);
  • Figure 3 Flow chart of a network P-CSCF-initiated breakdown of a SIP session (second embodiment).
  • FIG. 2 shows the SIP signaling messages in the IMS for a session setup and dismantling.
  • FIG. 2 thus contains the negotiation by the UAs of the proxies authorized to break down the session. It is assumed that the UAs are not subject to any restrictions when selecting the IMS proxies. One such restriction could be that the UAs have to accept certain proxies and not delete them from the NI-BYE permit header.
  • Corresponding proxies can be configured, for example, by the mobile radio network, specified by the mobile radio system or the mobile radio system operator or by the user. It should also be noted here that only the SIP signaling messages which are important for explaining the invention are shown in FIG.
  • the session setup begins with the INVITE message (invitation message) denoted by N1:
  • INVITE sip Holger@siemens.com SIP / 2.0
  • VN's P-CSCF1 wants to be authorized to end the SIP session so that it inserts the NI-BYE permit header and specifies its URI there.
  • the P-CSCF1 also inserts a record route header and also enters its URI there. All proxies in the Re cord route headers are part of the SIP signaling path within the opened dialog between
  • the message N2 ((changed) invitation message) can thus be specified as follows:
  • INVITE sip Holger@siemens.com SIP / 2.0
  • proxies are entered in the NI-BYE-Permit header and thus want to be authorized to terminate the SIP session.
  • the messages labeled N3, N4 and N5 do not differ significantly, so that only message N5 (changed invitation message) is specified here.
  • This message contains the URIs of the proxies running so far in the NI-BYE permit and record route header: INVITE sip: Holger@siemens.com SIP / 2.0
  • the UE # 2 or the UAS now checks the URIs in the NI-BYE permit header. It is now assumed that the UAS does not accept S-CSCFl as a possible proxy that ends the session. The UAS therefore deletes the URI of the S-CSCFl from the NI-BYE permit header and sends the message N6, which can be interpreted as a response message or as a modified invitation message in particular, to the UAC using the via header: SIP / 2.0 183 session progress
  • the 183 session progress message which can also be understood as a modified invitation message in particular, runs on the signaling path to the UAC via all proxies listed in FIG. 2. These messages do not differ significantly from message N6, so that they are not reproduced here.
  • Each proxy checks the entries in the NI-BYE permit header. If its URI is still there, the corresponding proxy knows that it has been accepted by the UAS. If its URI is no longer included, as is the case with S-CSCF1 in this example, then the corresponding proxy is aware that it is not active by the UAS was accepted and therefore must not end the session between the UAs.
  • the list of proxies accepted by the UAS is received by the UAC with the message N10 (changed invitation message or response message).
  • the UAC checks the NI-BYE permit header.
  • the UAC in addition to the S-CSCF1, does not accept the P-CSCF2 as a proxy that ends the session.
  • the UAC therefore sends an updated list of proxies, by means of messages Nil-N15, also referred to as a modified invitation message, which no longer contains the P-CSCF2, via " the proxies specified in the record route to the UAS:
  • the UAS After receiving the message N15, the UAS checks the new proposal of the UAC in the NI-BYE permit header. It is assumed that the UAS accepts this proposal and confirms it with message N16:
  • the session establishment is completed (signaling messages are not completely contained in FIG. 2) and Holger (UE # 2) and Mark (UE # 1) exchange multimedia data with the format on which they agreed to exchange SDP messages ben.
  • Figure 2 also shows the breakdown of the SIP session by the authorized P-CSCF1.
  • FIG. 3 shows a typical signaling curve with the aid of which the expansion of the record route header is explained.
  • the same assumptions apply as in the first exemplary embodiment. It should be noted that this exemplary embodiment differs from the first exemplary embodiment only in the missing NI-BYE permit header and the extended record route header.
  • the message Nl for establishing the session does not change when the record route header is used, ie it is identical to the message Nl in the first exemplary embodiment. It is again assumed that the P-CSCFl of the VN wants to be authorized to end the SIP session. This proxy must therefore insert a record route header in the INVITE message anyway, so that it will continue to be part of the SIP signaling path in future inquiries (cf. [4] and first exemplary embodiment). To implement the method, the record route header is expanded with one information element per entry, ie per URI. This field contains the value "NI-BYE-YES" if the corresponding proxy wants to be authorized to terminate the session. If it does not want this, then the information element is preferably not inserted.
  • INVITE sip Holger@siemens.com SIP / 2.0
  • the UE # 2 or the UAS checks the URIs in the record route header. It is now assumed that the UAS does not accept the S-CSCFl as a possible session proxy. Therefore, the UAS deletes the information element "NI-BYE-YES" of the S-CSCFl from the record route header and sends the message N6 to the UAC using the via header. Alternatively, the UAS could logically set the information element to "not accepted” put, ie Send "NI-BYE-NO" back.
  • the first method mentioned here has the advantage over this method that less signaling data has to be transmitted.
  • the 183 session runs on the signaling path to the UAC
  • the UAC in turn checks the record route Hea- It is also assumed in this exemplary embodiment that the UAC, in addition to the S-CSCFl, does not accept the P-CSCF2 as a proxy that ends the session. The UAC therefore sends an updated list of the proxies, using Nil-N15, which no longer contains the P-CSCF2, via the proxies specified in the record route to the UAS:
  • This message runs through all proxies specified in the route header, so that the P-CSCF2 recognizes from the record route header that it is no longer authorized to end the session between the UAs.
  • the S-CSCF2 and the P-CSCF1 also recognize in this way, since the information element NI-BYE-YES is still behind their URI that they are still authorized to end the session.
  • the UAS After receiving message N15, the UAS checks the new UAC proposal contained in the record route header. It is assumed that the UAS accepts this proposal and confirms it with message N16:
  • FIG. 3 shows the attempt to end the session by N21-23 from the S-CSCF1.
  • Message N23 can be specified as follows:
  • the UAC (UE # 2) recognizes the source of this message.
  • the UAs save the record route header and the proxies authorized to clear the SIP session in the transaction state (note: the proxies of the IMS are all so-called state-full proxies [4]).
  • the UA therefore have knowledge of which proxy is authorized to terminate the SIP session, even if no record route header is contained in the message.
  • the UAC does not accept the BYE message from the P-CSCFl and sends an error message, i.e. a 4xx
  • the P-CSCF1 then ends the SIP session
  • UE # 1 and UE # 2 by sending a BYE message to both UA. This is very similar to message N23, so it is no longer specified here.
  • the UAs recognize from the Via headers the source of this BYE request, and the correlation with the information stored in the transaction state thus shows that the P-CSCF1 is authorized to terminate the session.
  • 3GPP TS 24.228 IP Multimedia Call Control Protocol based on SIP and SDP; Stage 3

Landscapes

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

Abstract

Die Erfindung betrifft ein Verfahren zum Aufbau einer Kommunikationsverbindung zwischen einem ersten Kommunikationsendgerät und einem zweiten Kommunikationsendgerät, bei dem die Kommunikationsverbindung mittels miteinander verbundenen Netzwerkelementen realisiert wird, und bei dem ausgewählte Netzwerkelemente autorisiert sind, einen Abbau der Kommunikationsverbindung auszulösen.

Description

Beschreibung
Verfahren zum Aufbau einer Kommunikationsverbindung und Kommunikationssystem
Die Erfindung betrifft ein Verfahren zum Aufbau einer Kommunikationsverbindung zwischen einem ersten Kommunikationsendgerät und einem zweiten Kommunikationsendgerät, bei dem die Kommunikationsverbindung mittels miteinander verbundenen Netzwerkelementen realisiert wird, und ein entsprechendes Kommunikationssystem, insbesondere ein UM S.
Die rasante Verbreitung der Mobilkommunikation führte in den letzten Jahren zur Entwicklung einer Vielzahl verbesserter Funk-Übertragungsverfahren. Um die Vorteile des Internets in die Welt der Mobilkommunikation zu integrieren, wurde beispielsweise ein sogenanntes Session Initiation Protokoll (SIP) vorgeschlagen, das ein sogenanntes „Application-Layer Control Protocol" , d.h. ein Signalisierungsprotokoll zum Auf- bau, zur Modifikation und zum Abbau von Multimedia Sessions ist. Diese Multimedia Sessions können z.B. Multimedia Konferenzen, Internet-Telefonverbindungen (Voice over IP) und ähnliche Applikationen enthalten. Mittels SIP können Teilnehmer zu bereits existierenden Sessions eingeladen bzw. hinzuge- fügt, und die Zusammensetzung der Multimedia Session verändert werden. SIP verfügt u.a. über Fähigkeiten der Adresszuordnung bzw. Adressabbildung, der Lokalisierung des angerufenen Teilnehmers und der Umleitung von Verbindungen. Eine SIP Session wird dabei in der Regel zwischen zwei Kommunikations- endgeräten, auch user entity UE genannt, unter Zwischenschaltung mehrerer miteinander verbundener Netzwerkelelemente, beispielsweise Proxies, realisiert. SIP wurde von 3GPP als Signalisierungsprotokoll für das IP
Multimedia Core Network Subsystem (IMS) ausgewählt. Gemäß der aktuellen 3GPP Spezifikationen kann eine SIP Session auch von
Netzwerkelementen (Proxies), wie dem P-CSCF, S-CSCF, MGCF o- der AS, innerhalb des IP Multimedia Core Network Subsystem abgebaut bzw. beendet werden [1], [2], [3]. Ursache dieses
Session-Abbaus durch den P-CSCF kann z.B. die Unterbrechung der Funkverbindung des UEs zum UTRAN sein (out of coverage) .
Der S-CSCF beendet u.a. die SIP Session zwischen den UEs aug- rund eines erschöpften Pre-Paid Kontos eines der Endgeräte oder aus administrativen Günden [1] .
Problematisch ist dabei jedoch, dass das in der Internet Engineering Task Force (IETF) spezifizierte und von 3GPP im IMS verwendete und zu diesem Zweck adaptierte SIP Protokoll ein reines End-to-End Protokoll ist. Die Kontrolle über die Session liegt somit definitionsgemäß in den logischen Einheiten zwischen denen sie aufgebaut wird. Diese logischen Einheiten werden als User Agents (UA) bezeichnet, wobei diese, je nach- dem ob sie eine SIP Anfrage (Request) senden oder mit einer
SIP Antwort (Response) auf eine entsprechende Anfrage antworten, in User Agent Clients (UAC) und User Agent Server (UAS) unterschieden werden [4] . In einem UE sind beide logischen Einheiten, UAC und UAS, enthalten. Gemäß des Standard SIP Protokolls (IETF-Version) können daher nur die UAs eine SIP Session beenden. Dies ist für die Integration des SIP Protokolls in Mobilfunksysteme hinderlich, da diese Integration - wie oben erläutert erfordert, dass nicht nur Aus, also nicht nur Kommunikationsendgeräte, sondern auch Proxies, also Netz- Werkelemente, einen Verbindungsabbau auslösen können.
Figur 1 zeigt die bekannten SIP Signalisierungsnachrichten im IMS bei einem vom P-CSCF initiierten Abbau der SIP Session für den Fall, dass die Funkverbindung zwischen dem UE bzw. UA und dem UTRAN unterbrochen wurde (out of coverage) (vergl.
[1] Abb. 5.26a) . Wie dieser Figur zu entnehmen ist, wird die
Session vom P-CSCF mittels der mit "Auflegen" (Hangup) be- zeichneten Nachricht abgebaut. „Auflegen" steht dabei für die
Übertragung der so genannten BYE Anfrage. Die BYE Nachricht dient dem P-CSCF dazu die Session zu identifizieren und dem
UE/UA anzuzeigen, dass diese Session abgebaut werden soll.
Infolgedessen bestätigt das UE bzw. der UA, mittels der 200 OK Nachricht, dem P-CSCF den Abbau der SIP Session und baut anschließend den PDP Context, d.h. die Datenverbindung zum UTRAN/CN, auf der die Daten der Media Session übertragen werden, ab. Weitere Einzelheiten können [1] Kap. 5.10.3.1.1 entnommen werden (vergl. auch [2] Kap. 8) .
Nach dem Stand der Technik baut also ein Netzwerkelement, z.B. der P-CSCF, die SIP Session ab. Der UA hat gemäß dem Stand der Technik keine Kontrolle darüber, wer die Session abbaut bzw. welcher Proxy dazu berechtigt ist. Der UA fun- giert als reiner „Befehlsempfänger . Diese abweichende Funktionalität des von 3GPP adaptierten Standard SIP (3GPP- Version) wurde von der IETF bemängelt. Nach dem momentanen Stand der Technik ist demnach eine Integration des SIP Protokolls in den 3GPP Standard nicht möglich, zumindest nicht mit Zustimmung der IETF.
Es ist daher eine Aufgabe der vorliegenden Erfindung, ein Verfahren zum Aufbau einer Kommunikationsverbindung zwischen einem ersten Kommunikationsendgerät und einem zweiten Kommu- nikationsendgerät anzugeben, das unter der Kontrolle eines Endgerätes die Auslösung eines Verbindungsabbaus durch ein Netzwerkelelement, durch das die Verbindung realisiert wird, ermöglicht . Diese Aufgabe wird durch die Merkmale der unabhängigen Ansprüche gelöst . Vorteilhafte und zweckmäßige Weiterbildungen ergeben sich aus den abhängigen Ansprüchen. Der unabhängige Vorrichtungsanspruch kann dabei entsprechend den abhängigen Verfahrensansprüchen weitergebildet sein.
Gemäß der Erfindung sind also ausgewählte Netzwerkelemente autorisiert, einen Abbau der Kommunikationsverbindung auszu- lösen.
Bei Kommunikationsendgeräten kann es sich insbesondere um alle Kommunikationsgeräte handeln, die der Start oder Zielpunkt einer SIP Session sein können. Ein Beispiel für ein Kommuni- kationsendgerät ist ein Mobiltelefon, insbesondere ein UMTS- Mobiltelefon. Im Rahmen der Erfindung wird aber auch ein UA, ein UAS oder ein UAC als Kommunikationsendgerät aufgefasst.
Eine Kommunikationsverbindung umfasst dabei insbesondere pa- ketvermittelte Kommunikationsverbindungen. Eine Einladungsnachricht, die über Netzwerkelemente übertragen wird, kann vorzugsweise von jedem Netzwerkelement verändert werden und dann an das nächste Netzwerkelement weiter geleitet werden.
Als Einladungsnachricht werden dabei auch geänderte Einladungsnachrichten, Antwortnachrichten oder Aktualisierungnachrichten bezeichnet .
Die Erfindung basiert demnach auf dem Gedanken, dass nicht jedes Netzwerkelement, beispielsweise nicht jeder Proxy, die Verbindung, beispielsweise eine Session abbauen kann bzw. den Abbau veranlassen kann. Auf diese Weise kann beispielsweise durch eine Autorisationsüberprüfung in einem Kommunikations endgerät die Kontrolle des Session Abbaus IETF konform im
Kommunikationsendgerät, beispielsweise durch den UA, erfolgen. Dadurch wird erreicht, dass Netzwerkelemente, beispielsweise Proxies, zwar eine Beendigung der Verbindung (Session) auslösen können, aber ein endgültiger Verbindungsabbau der Kontrolle eines Kommunikationsendgerätes unterliegt.
Die Erfindung umfasst insbesondere ein Verfahren zur Aushandlung der Netzwerkelemente - im folgenden auch als Proxies be- zeichnet -, die berechtigt sind eine SIP-Session zwischen UAs zu beenden. Die Berechtigungen zum Abbau einer SIP Session können dabei vorzugsweise von den UAs vergeben werden. Somit wird der Forderung der IETF Rechnung getragen, dass die UAs Kontrolle über die aufgebaute Session haben. Diese Eigen- schaff kann aber durch eine entsprechende Konfiguration und Adaptation des Verfahrens eingeschränkt werden, um den 3GPP spezifischen Anforderungen gerecht zu werden. Diese Anforderungen unterscheiden sich von denen der IETF in der Hinsicht, dass die UMTS-Mobilfunknetzbetreiber größtmögliche Kontrolle über die in ihrem Netzwerk, d.h. in ihrem IMS/CN, betriebenen SIP-Sessions haben möchten. Diese Forderung nach einer netz- werkseitigen Kontrolle der SIP-Session steht dem Grundsatz der IETF nach einer UA kontrollierten SIP-Session entgegen.
Eine Weiterbildung der Erfindung sieht vor, dass beim Aufbau der Kommunikationsverbindung eine Einladungsnachricht von dem ersten Kommunikationsendgerät über miteinander verbundene, insbesondere auf dem Signalisierungspfad liegende, Netzwerkelemente zu dem zweiten Kommunikationsendgerät übertragen wird, und dass eine Kennung der Netzwerkelemente, die eine Autorisation zur Auslösung eines Abbaus der Kommunikations- verbindung wünschen, in die Einladungsnachricht eingetragen werden. Es werden also Informationen in eine Einladungsnach rieht eingetragen, die den Kommunikationsendgeräten signalisieren, welches Netzwerkelement zum Abbau einer Verbindung bzw. zur Initiierung des Abbaus einer Verbindung ermächtigt werden möchten.
Vorzugsweise zeichnet sich das Verfahren also insbesondere dadurch aus, dass die Proxies, die sich auf dem Signalisie- rungspfad zwischen den UAs befinden, während des Session Aufbaus den UAs anzeigen, ob sie die Berechtigung erhalten möch- ten, die SIP Session abzubauen. Hierzu fügen sie insbesondere in einem entsprechenden Nachrichtenkopf (Header Feld) einer Einladungsnachricht (Nachricht bzw. INVITE-Nachricht) eine Kennung (Informationselement) ein, die sie identifiziert (SIP URI oder SIPS URI) und angibt, dass der spezifizierte Proxy dazu berechtigt sein möchte, die SIP Session zu beenden. Der Empfänger der INVITE Nachricht, d.h. der UAS, kann dann die Einträge im relevanten Header Feld überprüfen. Anschließend kann der UAS eine Antwort, z.B. eine „183 Session in Pro- gress" Nachricht, an den UAC senden. Diese Nachricht kann i.a. eine Kopie des entsprechenden Header Feldes der INVITE
Nachricht enthalten. Allerdings kann der UAS die Einträge von einzelnen Proxies löschen, die von ihm nicht als Session abbauende Proxies akzeptiert werden. Diese Entscheidung kann der UAS z.B. mit Hilfe von vorgegebenen Kriterien, einem Lis- tenvergleich und/oder durch eine Konfiguration durch den Nutzer treffen. Die Kennungen der autorisierten Netzwerkelemente können dabei auch in einem Teilnehmeridentifizierungsmodul (SIM) innerhalb des Kommunikationsendgerätes abgespeichert sein. Nach dem Empfang dieser Antwort, die mindestens über alle in der noch nicht vom UAS revidierten Liste aufgeführten Proxies laufen kann, kann der UAC seinerseits die Liste der Proxies, die eine Berechtigung zum Abbau der SIP Session erhalten möchten und die vom UAS akzeptiert wurden, überprüfen. Wird vom UAC mindestens ein aufgelisteter Proxy nicht akzeptiert, so kann der UAC eine entsprechend reduzierte Liste von Proxies in einer weiteren Nachricht an den UAS senden. Dabei können wieder mindestens alle in der noch nicht vom UAC revi- dierten Liste aufgeführten Proxies durchlaufen werden. Zur Übertragung dieser Liste kann z.B. die UPDATE Methode [6], die eine Erweiterung von [4] darstellt, verwendet werden. Im Rahmen der Aushandlung der Proxies können u.U. mehrfach Nachrichten zwischen den UAs ausgetauscht werden bis eine Eini- gung zwischen den UAs erzielt wurde. Ist keine Einigung zu erreichen, so kann der Session Aufbau abgebrochen werden. Durch ein derartiges Verfahren liegt die Entscheidung, welcher Proxy dazu berechtigt ist, die Session abzubauen, letzten Endes bei den UAs .
Die Erfindung wird im Folgenden anhand bevorzugter Ausfüh- rungsbeispiele näher beschrieben, zu deren Erläuterung nachstehend aufgelistete Figuren dienen:
Figur 1: Ablaufdiagramm eines Netzwerk-P-CSCF- initiierten
Abbaus einer SIP Session nachdem die Funkverbindung zwischen dem UE und UTRAN unterbrochen wurde (vergl. [1] Abb. 5:26a);
Figur 2 : Ablaufdiagramm eines Netzwerk-P-CSCF- initiierten Abbaus einer SIP Session (erstes Ausführungsbeispiel) ;
Figur 3: Ablaufdiagramm eines Netzwerk-P-CSCF- initiierten Abbaus einer SIP Session (zweites Ausführungsbeispiel) .
Im folgenden Ausführungsbeispiel wird ein neuer SIP Header zur Realisierung eines Verfahrens der eingangs beschriebenen Art eingeführt. Dieser Header wird hier als „NI-BYE-Permit" bezeichnet. Figur 2 zeigt die SIP Signalisierungsnachrichten im IMS für einen Session Auf- und Abbau. Figur 2 enthält somit die Aushandlung der zum Session Abbau berechtigten Proxies durch die UAs. Es wird angenommen, dass die UAs bei der Auswahl der IMS Proxies keinen Restriktionen unterliegen. Ei- ne solche Restriktion könnte z.B. darin bestehen, dass die UAs bestimmte Proxies akzeptieren müssen und diese nicht aus den NI-BYE-Permit Header löschen dürfen. Entsprechende Proxies können z.B. vom Mobilfunknetz konfiguriert werden, durch das Mobilfunksystem bzw. den Mobilfunksystem-Betreiber oder durch den Nutzer vorgegeben werden. Anzumerken ist hier ebenfalls, dass in Figur 2 nur die zur Erläuterung der Erfindung wichtigen SIP Signalisierungsnachrichten dargestellt sind.
Es folgt eine Beschreibung der SIP Nachrichten in Figur 2 : Der Session Aufbau beginnt mit der mit Nl bezeichneten INVITE Nachricht (Einladungsnachricht) :
INVITE sip: Holger@siemens.com SIP/2.0
Via: SIP/2.0/UDP UEl . web. com;branch=z9hG4bKnashds8 Max-Forwards: 70
To : Holger <sip:Holger@siemens . com>
From: Mark <sip:Mark@web. com>;tag=1928301774
Call-ID: a84b4c7βe66710
CSeq: 314159 INVITE Contact: <sip:Mark@UEl .web. com>
Content-Type: application/sdp
Content-Length: 142
Es wird angenommen, dass der P-CSCF1 des VN die Berechtigung haben möchte, die SIP Session zu beenden, so dass er den NI- BYE-Permit Header einfügt und seine URI dort angibt. Ebenfalls fügt der P-CSCF1 einen Record-Route Header ein und trägt dort ebenfalls seine URI ein. Alle Proxies die im Re cord-Route Header aufgeführt werden sind Teil des SIP Signa- lisierungspfades innerhalb des eröffneten Dialoges zwischen
UE#1 und UE#2 [4] . Dies ist eine notwendige Voraussetzung für die spätere Beendigung der SIP-Session durch den P-CSCF1. Die Nachricht N2 ( (geänderte) Einladungsnachricht) kann damit wie folgt angegeben werden:
INVITE sip: Holger@siemens.com SIP/2.0
Via: SIP/2.0/UDP pcscf1. visitedl .net;branch=z9hG4bKaaaaaa
Via: SIP/2.0/UDP UEl . web. com;branch=z9hG4bKnashds8
Max-Forwards : 69
NI-BYE-Permit: <sip: pcscf1.visitedl .net>
Record-Route: <sip: pcscf1.visitedl .net; lr> To: Holger <sip:Holger@siemens . com>
From: Mark <sip:Mark@web. com>; tag=1928301774
Call-ID: a84b4c76e66710
CSeq: 314159 INVITE
Contact: <sip :Mark@UEl .web. com> Content-Type: application/sdp
Content-Length: 142
(Mark 's SDP nicht gezeigt)
Es wird in diesem Ausführungsbeispiel weiterhin angenommen, dass sich alle Proxies in den NI-BYE-Permit Header eintragen und somit die Berechtigung erhalten möchten die SIP Session abzubauen. Die mit N3, N4 und N5 bezeichneten Nachrichten (geänderte Einladungsnachrichten) unterscheiden sich nicht wesentlich, so dass hier nur die Nachricht N5 (geänderte Einladungsnachricht) angegeben wird. Diese Nachricht enthält im NI-BYE-Permit und Record-Route Header die URIs der bisher durchlaufenden Proxies: INVITE sip: Holger@siemens.com SIP/2.0
Via: SIP/2.0/UDP pcscf2.visited2.net; branch=z9hG4bKdddddd Via: SIP/2.0/UDP scscf2.home2.net; branch=z9hG4bKcccccc
Via: SIP/2.0/UDP scscf1.homel .net;branch=z9hG4bKbbbbbb
Via: SIP/2.0/UDP pcscf1.visitedl .net;branch=z9hG4bKaaaaaa
Via: SIP/2.0/UDP UEl . web. com;branch=z9hG4bKnashds8 Max-Forwards : 66
NI-BYE-Permit : <sip :pcscf2.visited2. net>,
<sip : scscf2.home2.net>, <sip: scscfl .homel .net>, <sip: pcscf1.visitedl .net>
Record-Route: <sip:pcscf2.visited2.net, lr>, <sip : scscf2.home2.net, lr>, <sip: scscfl .homel .net; lr>,
<sip: pcscfl .visitedl .net; lr>
To : Holger <sip:Holger@siemens . com>
From: Mark <sip:Mark@web. com>; tag=1928301774
Call-ID: a84b4c76e66710 CSeq: 314159 INVITE
Contact: <sip :Mark@UEl .web. com>
Content-Type: application/sdp
Content-Length: 142
(Mark's SDP nicht gezeigt)
Das UE#2 bzw. der UAS überprüft nun die URIs im NI-BYE-Permit Header. Es wird nun angenommen, dass der UAS S-CSCFl nicht als möglichen Session beendenden Proxy akzeptiert. Der UAS löscht deshalb die URI des S-CSCFl aus den NI-BYE-Permit Header und sendet die Nachricht N6, die als Antwortnachricht o- der auch als insbesondere geänderte Einladungsnachricht auf- gefasst werden kann, mit Hilfe des Via Headers an den UAC: SIP/2.0 183 Session Progress
Via: SIP/2.0/UDP pcscf2.visited2.net; branch=z9hG4bKdddddd Via: SIP/2.0/UDP scscf2.home2.net; branch=z9hG4bKcccccc
Via: SIP/2.0/UDP scscf1.homel .net;branch=z9hG4bKbbbbbb
Via: SIP/2.0/UDP pcscf1.visitedl .net;branch=z9hG4bKaaaaaa
Via: SIP/2.0/UDP UEl . web. com;branch=z9hG4bKnashds8 NI-BYE-Permit: <sip:pcscf2.visited2.net>,
<sip: scscf2.home2.net>, <sip: pcscf1.visitedl .net>
Record-Route: <sip:pcscf2. visited2.net, lr>,
<sip : scscf2.home2.net, lr>, <sip: scscfl .homel .net;lr>,
<sip: pcscf1.visitedl .net; lr> To : Holger <sip:Holger@siemens . com>; ag=21111972
From: Mark <sip:Mark@web. com>; tag=1928301774
Call-ID: a84b4c76e66710
CSeq: 314159 INVITE
Contact : <sip : Holger@UE2. sie ens . com> Content-Type: application/sdp
Content-Length: 142
Auf den Signalisierungspfad zum UAC läuft die 183 Session Progress Nachricht, die auch als insbesondere geänderte Ein- ladungsnachricht aufgefasst werden kann, über alle in Figur 2 aufgeführten Proxies. Diese Nachrichten unterscheiden sich nicht wesentlich von der Nachricht N6, so dass diese hier nicht wiedergegeben werden. Jeder Proxy überprüft die Einträge im NI-BYE-Permit Header. Ist dort seine URI weiterhin ent- halten, so weiß der entsprechende Proxy, dass er vom UAS akzeptiert wurde. Ist seine URI nicht mehr enthalten, wie dies im diesem Beispiel beim S-CSCFl der Fall ist, dann ist dem entsprechenden Proxy damit bekannt, dass er vom UAS nicht ak zeptiert wurde und daher die Session zwischen den UAs nicht beenden darf. Die Liste der vom UAS akzeptierten Proxies wird vom UAC mit der Nachricht N10 (geänderte Einladungsnachricht bzw. Antwortnachricht) empfangen. Der UAC überprüft seiner- seits den NI-BYE-Permit Header. Es wird in diesem Ausführungsbeispiel weiterhin angenommen, dass der UAC zusätzlich zu dem S-CSCFl den P-CSCF2 nicht als Session beendenden Proxy akzeptiert. Der UAC sendet deshalb eine aktualisierte Liste der Proxies, mittels auch als insbesondere geänderte Einla- dungsnachricht bezeichnete Nachrichten Nil - N15, die den P- CSCF2 nicht mehr enthält, über "die im Record-Route angegebenen Proxies an den UAS:
UPDATE Holger@UE2.siemens.com SIP/2.0 Via: SIP/2.0/UDP UEl . web. com;branch==z9hG4bKlmaa99
Max-Forwards : 70
NI-BYE-Permit: <sip: scscf2.home2.net>, <sip: pcscf1.visitedl . net>
Route: <sip: pcscfl .visitedl .net; lr>, <sip : scscf1.homel .net; lr>, <sip: scscf2.home2.net, lr>,
<sip :pcscf2.visited2.net, lr>
To: Holger <sip:Holger@siemens . com>; tag=21111972
From: Mark <sip:Mark@web. com>; tag=1928301774
Call-ID: a84b4c7βe66710 CSeq: 314160 UPDATE
Contact: <sip:Mark@UEl .web. com>
Content-Type: application/sdp
Content-Length: 142
Diese Nachricht durchläuft alle im Route Header angegebenen
Proxies, so dass der P-CSCF2 an Hand des NI-BYE-Permit Header erkennt, dass er nicht mehr berechtigt ist, die Session zwischen den UAs zu beenden. Der S-CSCF2 und der P-CSCF1 erken nen auf diese Weise ebenfalls, dass ihre URI weiterhin im NI- BYE-Permit Header enthalten ist. Nach dem Empfang der Nachricht N15 prüft der UAS den neuen Vorschlag des UAC im NI- BYE-Permit Header. Es wird angenommen, dass der UAS diesen Vorschlag akzeptiert und ihn mittels der Nachricht N16 bestätigt:
SIP/2.0 200 OK
Via: SIP/2.0/UDP pcscf2.visited2.net; branch=z9hG4bKddddd2
Via: SIP/2.0/UDP scscf2.home2.net; branch=z9hG4bKccccc2
Via: SIP/2.0/UDP scscf1.homel .net;branch=z9hG4bKbbbbb2
Via: SIP/2.0/UDP pcscf1.visitedl .net;branch=z9hG4bKaaaaa2 Via: SIP/2.0/UDP UEl .web. com;branch=z9hG4bKlmaa99
NI-BYE-Permit: <sip : scscf2.home2. et>, <sip: pcscf1.visitedl .net>
To: Holger <sip:Holger@siemens . com>; tag=21111972
From: Mark <sip:Mark@web. com>; tag=1928301774 Call-ID: a84b4c76e66710
CSeq: 314160 UPDATE
Contact : <sip :Holger@UE2. siemens . com>
Content-Type: application/sdp
Content-Length: 142
(Holger τs SDP nicht gezeigt)
Nach dem hier beschriebenen Verfahren zur Aushandlung der zum SIP Session Abbau berechtigten Proxies wird der Session Auf- bau abgeschlossen (Signalisierungsnachrichten sind nicht vollständig in Figur 2 enthalten) und Holger (UE#2) und Mark (UE#1) tauschen Multimediadaten mit dem Format aus, auf das sie sich mit dem Austausch der SDP Nachrichten geeinigt ha ben. Figur 2 zeigt ferner den Abbau der SIP Session durch den dazu berechtigten P-CSCF1.
Im folgenden Ausführungsbeispiel wird kein neuer Header zur Realisierung des erfindungsgemäßen Verfahrens eingeführt. In diesem besonders vorteilhaften Ausführungsbeispiel wird der Record-Route Header erweitert, um das Verfahren zu realisieren. Figur 3 zeigt einen typischen Signalisierungsverlauf mit dessen Hilfe die Erweiterung des Record-Route Headers erläu- tert wird. Es gelten im Weiteren dieselben Annahmen, wie im ersten Ausführungsbeispiel. Anzumerken ist, dass sich dieses Ausführungsbeispiel vom ersten Ausführungsbeispiel nur im fehlenden NI-BYE-Permit Header und den erweiterten Record- Route Header unterscheidet.
Die Nachricht Nl zum Aufbau der Session ändert sich bei der Verwendung des Record-Route Headers nicht, d.h. sie ist identisch mit der Nachricht Nl im ersten Ausführungsbeispiel. Es wird wieder angenommen, dass der P-CSCFl des VN die Berechti- gung haben möchte, die SIP Session zu beenden. Damit muss dieser Proxy ohnehin einen Record-Route Header in die INVITE Nachricht einfügen, damit er bei zukünftigen Anfragen weiterhin Teil des SIP Signalisierungspfades ist (vergl. [4] und erstes Ausführungsbeispiel) . Zur Realisierung des Verfahrens wird der Record-Route Header mit einem Informationselement pro Eintrag, d.h. pro URI, erweitert. Dieses Feld enthält den Wert „NI-BYE-YES" , sofern der entsprechende Proxy die Berechtigung erhalten möchte, die Session abzubauen. Möchte er dies nicht, dann wird das Informationselement vorzugsweise nicht eingefügt. Auch die ständige Übertragung dieses Elementes ist möglich. In diesem Fall müsste dann ein „NI-BYE-NO" gesendet werden. Die Nachricht N2 kann damit wie folgt angegeben werden: INVITE sip:Holger@siemens.com SIP/2.0 Via: SIP/2.0/UDP pcscf1.visitedl .net;branch=z9hG4bKaaaaaa Via: SIP/2.0/UDP UEl . web.com;branch=z9hG4bKnashds8 Max-Forwards : 69
Record-Route: <sip: pcscfl .visitedl .net; lr>; NI-BYE-YES To : Holger <sip:Holger@siemens . com> From: Mark <sip:Mark@web. com>; tag=1928301774 Call-ID: a84b4c76e66710 CSeq: 314159 INVITE Contact: <sip:Mark@UEl .web. com> Content-Type: application/sdp Content-Length: 142
(Mark's SDP nicht gezeigt)
Es wird wieder angenommen, dass alle Proxies berechtigt sein möchten, die SIP Session abzubauen. Die mit N3, N4 und N5 be- zeichneten Nachrichten unterscheiden sich nicht wesentlich, so dass hier nur die Nachricht N5 angegeben wird:
INVITE sip: Holger@siemens.com SIP/2.0
Via: SIP/2.0/UDP pcscf2.visited2.net; branch=z9hG4bKdddddd
Via: SIP/2.0/UDP scscf2.home2.net; branch=z9hG4bKcccccc
Via: SIP/2.0/UDP scscf1.homel .net;branch=z9hG4bKbbbbbb
Via: SIP/2.0/UDP pcscfl .visitedl .net;branch=z9hG4bKaaaaaa Via: SIP/2.0/UDP UEl .web. com;branch=z9hG4bKnashds8
Max-Forwards: 66
Record-Route: <sip:pcscf2. visited2.net, lr>; NI-BYE-YES,
<sip:scscf2.home2.net, lr>; NI-BYE-YES, <sip:scscfl .homel. net;lr>; NI-BYE-YES, <sip: pcscfl .visitedl .net; lr>; NI-BYE-YES
To: Holger <sip:Holger@siemens .com>
From: Mark <sip:Mark@web. com>; tag=1928301774
Call-ID: a84b4c76e66710
CSeq: 314159 INVITE
Contact: <sip:Mark@UEl .web. com>
Content-Type: application/sdp
Content-Length: 142
(Mark's SDP nicht gezeigt)
Das UE#2 bzw. der UAS überprüft erfindungsgemäß die URIs im Record-Route Header. Es wird nun angenommen, dass der UAS den S-CSCFl nicht als möglichen Session beendenden Proxy akzeptiert. Daher löscht der UAS das Informationselement „NI-BYE- YES" des S-CSCFl aus den Record-Route Header und sendet die Nachricht N6 mit Hilfe des Via Headers an den UAC. Alternativ könnte der UAS das Informationselement auch logisch auf „Nicht akzeptiert" setzen, d.h. „NI-BYE-NO" zurücksenden. Die erste hier genannte Methode hat gegenüber dieser Methode den Vorteil, dass weniger Signalisierungsdaten übertragen werden müssen.
SIP/2.0 183 Session Progress
Via: SIP/2.0/UDP pcscf2.visited2.net; branch=z9hG4bKdddddd
Via: SIP/2.0/UDP scscf2.home2.net; branch=z9hG4bKcccccc
Via: SIP/2.0/UDP scscfl .homel .net;branch=z9hG4bKbbbbbb Via: SIP/2.0/UDP pcscfl .visitedl .net;branch=z9hG4bKaaaaaa
Via: SIP/2.0/UDP UEl . web. com;branch=z9hG4bKnashds8 Record-Route: <sip:pcscf2.visited2.net, lr>; NI-BYE-YES,
<sip:scscf2.home2.net, lr>; NI-BYE-YES,
<sip: scscfl .homel .net; lr>, <sip: pcscfl.visitedl.net; lr>; NI-BYE-YES To : Holger <sip:Holger@siemens . com>; tag=21111972
From: Mark <sip:Mark@web. com>; tag=1928301774
Call-ID: a84b4c76e66710
CSeq: 314159 INVITE
Contact : <sip :Holger@UE2. siemens . com> Content-Type: application/sdp
Content-Length: 142
(Holger 's SDP nicht gezeigt)
Auf den Signalisierungspfad zum UAC läuft die 183 Session
Progress Nachricht, auch insbesondere geänderte Einladungsnachricht genannt, über alle in Figur 3 aufgeführten Proxies. Diese Nachrichten unterscheiden sich nicht wesentlich von der Nachricht N6, so dass diese hier ebenfalls nicht wiedergege- ben werden. Jeder Proxy überprüft die Einträge im Record Route Header. Ist dort das Informationselement „NI-BYE-YES" weiterhin enthalten, so weiß der entsprechende Proxy das er vom UAS akzeptiert wurde. Ist dieses Informationselement hinter seiner URI nicht mehr enthalten, wie dies im diesem Beispiel beim S-CSCFl der Fall ist, dann ist dem Proxy damit bekannt, dass er vom UAS nicht akzeptiert wurde und daher die Session zwischen den UAs nicht beenden darf. Die Liste der vom UAS akzeptierten Proxies wird vom UAC mit der Nachricht N10 empfangen. Der UAC überprüft seinerseits den Record-Route Hea- der. Es wird in diesem Ausführungsbeispiel ebenfalls angenommen, dass der UAC zusätzlich zu dem S-CSCFl den P-CSCF2 nicht als Session beendenden Proxy akzeptiert. Der UAC sendet deshalb eine aktualisierte Liste der Proxies, mittels Nil - N15, die den P-CSCF2 nicht mehr enthält, über die im Record-Route angegebenen Proxies an den UAS:
UPDATE Holger@UE2.siemens.com SIP/2.0 Via: SIP/2.0/UDP UEl .web. com;branch=z9hG4bKlmaa99
Max-Forwards: 70
Record-Route: <sip:pcscf2.visited2.net, lr>,
<sip:scscf2.home2.net, lr>; NI-BYE-YES,
<sip : scscfl .homel .net; lr>, <sip: pcscfl.visitedl. net;lr>; NI-BYE-YES
To: Holger <sip:Holger@siemens . com>; tag=21111972
From: Mark <sip:Mark@web. com>; tag=1928301774
Call-ID: a84b4c76eβ6710
CSeq: 314160 UPDATE Contact: <sip :Mark@UEl .web. com>
Content-Type: application/sdp
Content-Length: 142
(Marks ' s SDP nicht gezeigt)
Diese Nachricht durchläuft alle im Route Header angegebenen Proxies, so dass der P-CSCF2 an Hand des Record-Route Header erkennt, dass er nicht mehr berechtigt ist, die Session zwischen den UAs zu beenden. Der S-CSCF2 und der P-CSCF1 erken- nen auf diese Weise ebenfalls, da das Informationselement NI- BYE-YES noch hinter ihrer URI steht, dass sie weiterhin berechtigt sind, die Session zu beenden. Nach dem Empfang der Nachricht N15 prüft der UAS den neuen, im Record-Route Header enthaltenen, Vorschlag des UAC. Es wird angenommen, dass der UAS diesen Vorschlag akzeptiert und ihn mittels der Nachricht N16 bestätigt:
SIP/2.0 200 OK Via: SIP/2.0/UDP pcscf2.visited2.net; branch=z9hG4bKddddd2
Via: SIP/2.0/UDP scscf2.home2.net; branch=z9hG4bKccccc2
Via: SIP/2.0/UDP scscf1.homel .net;branch=z9hG4bKbbbbb2 Via: SIP/2.0/UDP pcscfl .visitedl .net;branch=z9hG4bKaaaaa2
Via: SIP/2.0/UDP UEl . eb. com;branch=z9hG4bKlmaa99
Record-Route: <sip:pcscf2. visited2.net, lr>,
<sip:scscf2.home2.net,lr>; NI-BYE-YES, <sip : scscfl .homel .net; lr>, <sip: pcscfl.visitedl.net;lr>; NI-BYE-YES To : Holger <sip:Holger@siemens . com>; tag=21111972 From: Mark <sip:Mark@web. com>; tag=1928301774 Call-ID: a84b4c76e66710 CSeq: 314160 UPDATE
Contact : <sip : Holger@UE2. siemens . com> Content-Type: application/sdp Content-Length: 142
(Holger 's SDP nicht gezeigt)
Nach dem hier beschriebenen Verfahren zur Aushandlung der zum SIP Session Abbau berechtigten Proxies wird der Session Aufbau abgeschlossen (Signalisierungsnachrichten sind nicht vollständig in Figur 3 enthalten) und Holger (UE#2) und Mark (UE#1) tauschen Multimediadaten mit dem Format aus, auf das sie sich mit dem Austausch der SDP Nachrichten geeinigt haben. Figur 3 zeigt ferner den Versuch, N21- 23, vom S-CSCFl die Session zu beenden. Die Nachricht N23 lässt sich dabei wie folgt angeben:
BYE sip: Holger@UE2.siemens.com SIP/2.0 Via: SIP/2.0/UDP pcscf2.visited2.net; branch=z9hG4bKddddd3
Via: SIP/2.0/UDP scscf2.home2.net; branch=z9hG4bKccccc3
Via: SIP/2.0/UDP scscfl .homel .net;branch=z9hG4bKbbbbb3 Via: SIP/2.0/UDP pcscfl .visitedl .net;branch=z9hG4bKaaaaa3
Max-Forwards: 70
Route: <sip: scscf2.home2.net, lr>,
<sip :pcscf2.visited2.net, lr> To : Holger <sip:Holger@siemens . com>; tag=21111972
From: Mark <sip:Mark@web. com>; tag=1928301774
Call-ID: a84b4c76e66710
CSeq: 12 BYE
Content-Length: 0
An Hand des untersten d.h. des zuerst eingefügten Via Headers erkennt der UAC (UE#2) die Quelle dieser Nachricht. Der Record-Route Header und die zum SIP Session Abbau berechtigten Proxies werden von den UAs im Transaction State gespeichert (Anmerkung: Die Proxies des IMS sind alle sogenannte State- full Proxies [4] ) . Die UA haben somit Kenntnis darüber, welcher Proxie berechtigt ist, die SIP Session abzubauen, auch wenn kein Record-Route Header in der Nachricht enthalten ist. Infolgedessen akzeptiert der UAC die BYE Nachricht vom P- CSCFl nicht und sendet eine Fehlermeldung, d.h. eine 4xx
(401) Nachricht, in N24 - N 26, an den P-CSCF1 zurück. Dasselbe gilt für die Nachrichten N35 - N38 zwischen P-CSCF1 und UE#1.
Anschließend beendet der P-CSCF1 die SIP Session zwischen
UE#1 und UE#2, indem er an beide UA eine BYE Nachricht sendet. Diese ist der Nachricht N23 sehr ähnlich, so dass sie hier nicht mehr angegeben wird. Die UAs erkennen an Hand des Via Headers die Quelle dieser BYE Anfrage, und die Korrelation mit den im Transaction State gespeicherten Informationen ergibt somit, dass der P-CSCF1 zum Session Abbau berechtigt ist. Infolgedessen senden UE#1, mit N40 und UE#2, mit N31 - N34, jeweils ein 200 OK an den P-CSCF1. Damit ist die SIP Session beendet und die UEs bauen die verwendeten (Funk- ) Ressourcen ab.
Neben den oben erläuterten Ausführungsvarianten der Erfindung liegt eine Vielzahl weiterer AusführungsVarianten im Rahmen der Erfindung, welche hier nicht weiter beschrieben werden, aber anhand der erläuterten Ausführungsbeispiele einfach in die Praxis umgesetzt werden können.
Im Rahmen dieser Anmeldung wurde auf folgende Dokumente verwiesen:
[1] 3GPP TS 23.228 : IP Multimedia Subsystem; Stage 2
[2] 3GPP TS 24.228 : IP Multimedia Call Control Protocol ba- sed on SIP and SDP; Stage 3
[3] 3GPP TS 24.229 : Signalling Flows for the IP Multimedia
Call Control Protocol based on SIP and SDP; Stage 3 [4] RFC3261 : SIP: Session Initiation Protocol [5] WO 2002067533 AI : Closing a SIP active Session, Nokia [6] RFC3311 : The Session Initiation Protocol (SIP) UPDATE Method
Im Rahmen dieser Anmeldung wurden folgende Abkürzungen verwendet :
3GPP Third Generation Partnership Proj- ect AS Application Server CN Core Network
DRNC Drift RNC
GGSN Gateway GPRS Support Node
GMSC Gateway MSC
GSM Global System for Mobile Communications
HLR Home Location Register
HN Home Network
IETF Internet Engineering Task Force
IMS IP Mulitmedia CN Subsystem
MGCF Media Gateway Control Function
MSC Mobile Switching Center
P-CSCF Proxy CSCF
RAB Radio Access Bearer
RNC Radio Network Controller
S-CSCF Serving CSCF
SDP Session Description Protocol
SGSN Serving GPRS Support Node
SIP Session Initiation Protocol
SIPS URI Secure SIP URI
UA User Agent
UAC User Agent Client
UAS User Agent Server
UE User Equipment
UMTS Universal Mobile Telecommunication System
URI Uniform Resource Identifier
UTRAN Universal Terrestrial Radio Access Network
VLR Visitor Location Register
VN Visited Network

Claims

Patentansprüche
1. Verfahren zum Aufbau einer Kommunikationsverbindung zwischen einem ersten Kommunikationsendgerät und einem zweiten Kommunikationsendgerät, bei dem die KommunikationsVerbindung mittels miteinander verbundenen Netzwerkelementen realisiert wird, und bei dem ausgewählte Netzwerkelemente autorisiert sind, einen Abbau der Kommunikationsverbindung auszulösen.
2. Verfahren nach Anspruch 1, bei dem beim Aufbau der Kommunikationsverbindung eine Einladungsnachricht von dem ersten Kommunikationsendgerät über miteinander verbundene Netzwerkelemente zu dem zweiten Kommu- nikationsendgerät übertragen wird, und bei dem eine Kennung der Netzwerkelemente, die eine Autorisa- tion zur Auslösung eines Abbaus der Kommunikationsverbindung wünschen, in die Einladungsnachricht eingetragen werden.
3. Verfahren nach Anspruch 2, bei dem in dem zweiten Kommunikationsendgerät zweite Kennungen der Netzwerkelemente abgespeichert sind, die autorisiert sind, einen Abbau der Kommunikationsverbindung auszulösen, und bei dem die in die Einladungsnachricht eingetragenen Kennungen der Netzwerkelemente, die nicht autorisiert sind, aus der Einladungsnachricht entfernt werden.
4. Verfahren nach Anspruch 3, bei dem die geänderte Einladungsnachricht von dem zweiten
Kommunikationsendgerät über die miteinander verbundenen Netzwerkelemente zu dem ersten Kommunikationsendgerät übertragen wird und, bei dem den Netzwerkelementen signalisiert wird, ob ihre Kennung aus der Einladungsnachricht entfernt wurde.
5. Verfahren nach einem der Ansprüche 3 oder 4, bei dem in dem ersten Kommunikationsendgerät erste Kennungen der Netzwerkelemente abgespeichert sind, die autorisiert sind, einen Abbau der Kommunikationsverbindung auszulösen, und bei dem die in die Einladungsnachricht eingetragenen Kennun- gen der Netzwerkelemente, die nicht autorisiert sind, aus der Einladungsnachricht entfernt werden.
6. Verfahren nach Anspruch 5, bei dem die geänderte Einladungsnachricht von dem ersten Kom- munikationsendgerät über die miteinander verbundenen Netzwerkelemente zu dem zweiten Kommunikationsendgerät übertragen wird und, bei dem den Netzwerkelementen signalisiert wird, ob ihre Kennung aus der Einladungsnachricht entfernt wurde.
7. Verfahren nach einem der Ansprüche 5 oder 6, bei dem in dem zweiten Kommunikationsendgerät überprüft wird, ob in der Einladungsnachricht Kennungen eingetragen sind, die von den in dem Kommunikationsendgerät gespeicherten zweiten Kennungen verschieden sind, und bei dem eine Bestätigungsnachricht an das erste Kommunikationsendgerät gesendet wird, wenn in der Einladungsnachricht keine Kennungen eingetragen sind, die von den in dem Kommunikationsendgerät gespeicherten zweiten Kennungen verschieden sind.
8. Verfahren nach einem der vorhergehenden Ansprüche, bei dem die Kennungen in einen eigens für diesen Zweck vorgesehenen Nachrichtenkopf der Einladungsnachricht eingetragen werden .
9. Verfahren nach einem der Ansprüche 1 bis 7, bei dem die Kennungen in einen schon für andere Zwecke vorgesehenen Nachrichtenkopf der Einladungsnachricht eingetragen werden .
10. Verfahren nach einem der vorhergehenden Ansprüche, bei dem in dem ersten Kommunikationsendgerät erste Kennungen der Netzwerkelemente abgespeichert sind, die autorisiert sind, einen Abbau der KommunikationsVerbindung auszulösen, und bei dem die Einladungsnachricht um die Kennungen der Netzwerkelemente ergänzt wird, die autorisiert sind.
11. Verfahren nach einem der vorhergehenden Ansprüche, bei dem in dem zweiten Kommunikationsendgerät zweite Kennun- gen der Netzwerkelemente abgespeichert sind, die autorisiert sind, einen Abbau der Kommunikationsverbindung auszulösen, und bei dem die Einladungsnachricht um die Kennungen der Netzwerkelemente ergänzt wird, die autorisiert sind.
12. Verfahren zum Abbau einer gemäß einem Verfahren nach einem der vorhergehenden Ansprüche aufgebauten Kommunikationsverbindung, bei dem durch ein Netzwerkelement ein Abbau der Kommunikati- onsverbindung ausgelöst wird, bei dem in dem ersten bzw. zweiten Kommunikationsendgerät basierend auf in dem ersten bzw. zweiten Kommunikationsendgerät abgespeicherten ersten bzw. zweiten Kennungen überprüft wird, ob das den Abbau der Kommunikationsverbindung auslösende
Netzwerkelement autorisiert ist, den Abbau der Kommunikationsverbindung auszulösen, und bei dem die Kommunikationsverbindung nicht abgebaut wird, wenn das den Abbau der Kommunikations erbindung auslösende Netzwerkelement nicht autorisiert ist, den Abbau der Kommunikationsverbindung auszulösen.
13. KommunikationsSystem mit einem ersten Kommunikationsendgerät und mit einem zweiten Kommunikationsendgerät, mit miteinander verbundenen Netzwerkelementen zum Aufbau einer Kommunikationsverbindung zwischen dem ersten Kommunikationsendgerät und dem zweiten Kommunikationsendgerät, bei dem ausgewählte Netzwerkelemente autorisiert sind, einen Abbau der Kommunikationsverbindung auszulösen.
PCT/EP2004/050784 2003-05-19 2004-05-13 Verfahren zum aufbau einer kommunikationsverbindung und kommunikationssystem WO2004102921A1 (de)

Priority Applications (1)

Application Number Priority Date Filing Date Title
US10/557,391 US7769020B2 (en) 2003-05-19 2004-05-13 Method for the establishment of a communication link, and communication system

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
DE10322539A DE10322539A1 (de) 2003-05-19 2003-05-19 Verfahren zum Aufbau einer Kommunikationsverbindung und Kommunikationssystem
DE10322539.0 2003-05-19

Publications (1)

Publication Number Publication Date
WO2004102921A1 true WO2004102921A1 (de) 2004-11-25

Family

ID=33440974

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/EP2004/050784 WO2004102921A1 (de) 2003-05-19 2004-05-13 Verfahren zum aufbau einer kommunikationsverbindung und kommunikationssystem

Country Status (3)

Country Link
US (1) US7769020B2 (de)
DE (1) DE10322539A1 (de)
WO (1) WO2004102921A1 (de)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP2354229A2 (de) 2005-10-25 2011-08-10 Sylentis S.A. Modulierung der Expression der 11beta-hydroxysteroid dehydrogenase 1 für die Behandlung von Augenkrankheiten

Families Citing this family (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7623530B2 (en) * 2003-11-20 2009-11-24 Nokia Corporation Indication of service flow termination by network control to policy decision function
KR101213285B1 (ko) * 2006-01-04 2012-12-17 삼성전자주식회사 이동통신 시스템에서 아이들모드 단말기의 세션 설정 프로토콜 데이터를 전송하는 방법 및 장치
US7693519B2 (en) * 2006-07-14 2010-04-06 M-Stack Limited Method and apparatus for reducing link interference by a link between a user equipment component and an access network component
WO2017024442A1 (zh) * 2015-08-07 2017-02-16 华为技术有限公司 一种数据传输和接入网络方法及相关设备、系统
US11489948B2 (en) * 2019-12-30 2022-11-01 Cloudflare, Inc. Method and system for reliable application layer data transmission through unreliable transport layer connections in a network

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2000079756A2 (en) * 1999-06-18 2000-12-28 Telefonaktiebolaget Lm Ericsson (Publ) System and method for providing value-added services (vas) in an integrated telecommunications network using session initiation protocol (sip)
WO2002067533A1 (en) * 2001-02-19 2002-08-29 Nokia Corporation Closing a sip active session

Family Cites Families (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5666348A (en) * 1995-09-18 1997-09-09 Telefonaktiebolaget L M Ericsson (Publ.) Packet switched radio channel admission control in a cellular telecommunications system
US6421674B1 (en) * 2000-02-15 2002-07-16 Nortel Networks Limited Methods and systems for implementing a real-time, distributed, hierarchical database using a proxiable protocol
US7546376B2 (en) * 2000-11-06 2009-06-09 Telefonaktiebolaget Lm Ericsson (Publ) Media binding to coordinate quality of service requirements for media flows in a multimedia session with IP bearer resources
US7110393B1 (en) * 2001-02-28 2006-09-19 3Com Corporation System and method for providing user mobility handling in a network telephony system
WO2002091678A1 (en) * 2001-05-10 2002-11-14 Nokia Corporation Method, system and network element device for controlling sessions between terminals
US7227865B2 (en) * 2001-08-16 2007-06-05 Interdigital Technology Corporation Utilizing session initiation protocol for identifying user equipment resource reservation setup protocol capabilities
US7574735B2 (en) * 2002-02-13 2009-08-11 Nokia Corporation Method and network element for providing secure access to a packet data network
US8036104B2 (en) * 2002-07-15 2011-10-11 Qualcomm Incorporated Methods and apparatus for improving resiliency of communication networks
US6977996B1 (en) * 2002-09-24 2005-12-20 Verizon Laboratories Inc. Fee collection system and method for call completion
US7366782B2 (en) * 2003-04-14 2008-04-29 At&T Corp. Systems and methods for termination of session initiation protocol

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2000079756A2 (en) * 1999-06-18 2000-12-28 Telefonaktiebolaget Lm Ericsson (Publ) System and method for providing value-added services (vas) in an integrated telecommunications network using session initiation protocol (sip)
WO2002067533A1 (en) * 2001-02-19 2002-08-29 Nokia Corporation Closing a sip active session

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
MOH M ET AL: "Mobile IP telephony: mobility support of SIP", PROCEEDINGS OF THE INTERNATIONAL CONFERENCE ON COMPUTER COMMUNICATIONS AND NETWORKS, XX, XX, 11 October 1999 (1999-10-11), pages 554 - 559, XP002143545 *

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP2354229A2 (de) 2005-10-25 2011-08-10 Sylentis S.A. Modulierung der Expression der 11beta-hydroxysteroid dehydrogenase 1 für die Behandlung von Augenkrankheiten

Also Published As

Publication number Publication date
DE10322539A1 (de) 2004-12-09
US7769020B2 (en) 2010-08-03
US20070025358A1 (en) 2007-02-01

Similar Documents

Publication Publication Date Title
EP1536661B1 (de) Verfahren zum Registrieren eines Kommunikationsgeräts, zugehöriges Kommunikationsgerät sowie Registrierungseinheit
DE602004008741T2 (de) Nachrichten-basierte verteilung von last kontrollinformationen
DE60129821T2 (de) Gemeinsame gebührenerhebung kennung für kommunikationsnetze
DE60303004T2 (de) Kommunikationsknoten-architektur
DE60222874T2 (de) Trassierungsverfahren und -system
DE60202527T2 (de) Verfahren und system zur behandlung von mehrfachanmeldungen
DE60127815T2 (de) Verfahren zur rufkontrolle um verzögerungen beim starten von multimedia- oder sprachrufen in einem paketvermittelten funkkommunikationsnetz zu minimieren
EP1994714B1 (de) Verfahren zur zuordnung von zumindest einer nutzdatenverbindung zu zumindest einer multiplexverbindung
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
WO2007025905A1 (de) Kommunikationssystem, vermittlungsknoten-rechner und verfahren zur bestimmung eines kontrollknotens
WO2004102921A1 (de) Verfahren zum aufbau einer kommunikationsverbindung und kommunikationssystem
DE602004006171T2 (de) Sitzungseinleitungsprotokollsignalisierung (sip)
DE102005052262B4 (de) Verfahren zur Auswahl einer S-CSCF-Einheit innerhalb eines IMS basierten Dienstekommunikationssystems
DE102004030290A1 (de) Aufbau einer Verbindung für den Austausch von Daten eines IP-basierten Dienstes
WO2007087917A1 (de) Verfahren und vorrichtung zur registrierung in einem ims mit einer gruu
EP1771993B1 (de) Verfahren zur überwachung eines nachrichtenverkehrs, sowie eine erste und zweite netzwerkeinheit zu dessen durchführung
DE102004032923B4 (de) Verfahren zum Registrieren eines Kommunikationsendgeräts, Kommunikationssystem, Verfahren zum Steuern eines Kommunikationsendgeräts und Kommunikationsendgerät
DE102008045790B4 (de) Verfahren und Kommunikationsnetz zum mehrfachen Umleiten einer Kommunikationsverbindung
WO2008022613A2 (de) Verfahren zum erzeugen einer kommunikationssitzung - steuernachricht unter verwendung von sip
EP1309146A1 (de) Verfahren zur Kommunikation zweier Netzeinrichtungen auf Basis einer Ende-zu-Ende-Verbindung und Netzeinrichtung dafür
DE10234920A1 (de) Verfahren und eine Vorrichtung in einem Kommunikationsnetz, zum Abruf von Eigenschaften mindestens einer Netzwerkeinheit von anderen Netzwerkeinheiten und zum Informieren dieser anderen Netzwerkeinheiten darüber, dass sich bestimmte Eigenschaften einer Netzwerkeinheit geändert haben
DE10116786A1 (de) Verfolgen eines Teilnehmers und/oder einer Session in einem Netz
WO2006042800A1 (de) Aufbau einer dienste-verbindung zwischen einem endgerät und einem ersteren netzelement mit unterschiedlichen ip-protokoll-versionen
WO2008025801A1 (de) Verfahren, system und komponente zur verarbeitung einer verbindung

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A1

Designated state(s): AE AG AL AM AT AU AZ BA BB BG BR BW BY BZ CA CH CN CO CR CU CZ DE DK DM DZ EC EE EG ES FI GB GD GE GH GM HR HU ID IL IN IS JP KE KG KP KR KZ LC LK LR LS LT LU LV MA MD MG MK MN MW MX MZ NA NI NO NZ OM PG PH PL PT RO RU SC SD SE SG SK SL SY TJ TM TN TR TT TZ UA UG US UZ VC VN YU ZA ZM ZW

AL Designated countries for regional patents

Kind code of ref document: A1

Designated state(s): BW GH GM KE LS MW MZ NA SD SL SZ TZ UG ZM ZW AM AZ BY KG KZ MD RU TJ TM AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HU IE IT LU MC NL PL PT RO SE SI SK TR BF BJ CF CG CI CM GA GN GQ GW ML MR NE SN TD TG

121 Ep: the epo has been informed by wipo that ep was designated in this application
122 Ep: pct application non-entry in european phase
WWE Wipo information: entry into national phase

Ref document number: 2007025358

Country of ref document: US

Ref document number: 10557391

Country of ref document: US

WWP Wipo information: published in national office

Ref document number: 10557391

Country of ref document: US