DE102005050586B3 - Verfahren zum Aufbau einer Videotelefonverbindung und/oder Multimediatelefonverbindung in einem Datennetz - Google Patents

Verfahren zum Aufbau einer Videotelefonverbindung und/oder Multimediatelefonverbindung in einem Datennetz Download PDF

Info

Publication number
DE102005050586B3
DE102005050586B3 DE102005050586A DE102005050586A DE102005050586B3 DE 102005050586 B3 DE102005050586 B3 DE 102005050586B3 DE 102005050586 A DE102005050586 A DE 102005050586A DE 102005050586 A DE102005050586 A DE 102005050586A DE 102005050586 B3 DE102005050586 B3 DE 102005050586B3
Authority
DE
Germany
Prior art keywords
network
ims
mik
sip
message
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.)
Expired - Fee Related
Application number
DE102005050586A
Other languages
English (en)
Inventor
Thomas Dr. Belling
Franz Kalleitner
Norbert Seitter
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Siemens AG
Original Assignee
Siemens AG
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Siemens AG filed Critical Siemens AG
Priority to DE102005050586A priority Critical patent/DE102005050586B3/de
Priority to US12/083,878 priority patent/US10075479B2/en
Priority to CNA2006800392105A priority patent/CN101292497A/zh
Priority to PCT/EP2006/066185 priority patent/WO2007045527A1/de
Priority to EP06793368A priority patent/EP1938551A1/de
Priority to JP2008535996A priority patent/JP5237816B2/ja
Priority to KR1020087012161A priority patent/KR101422223B1/ko
Application granted granted Critical
Publication of DE102005050586B3 publication Critical patent/DE102005050586B3/de
Expired - Fee Related legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/10—Architectures or entities
    • H04L65/102—Gateways
    • H04L65/1043—Gateway controllers, e.g. media gateway control protocol [MGCP] controllers
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/66—Arrangements for connecting between networks having differing types of switching systems, e.g. gateways
    • 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/1083—In-session procedures
    • H04L65/1095—Inter-network session transfer or sharing
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N7/00—Television systems
    • H04N7/14—Systems for two-way working
    • H04N7/141—Systems for two-way working between two video terminals, e.g. videophone
    • H04N7/148—Interfacing a video terminal to a particular transmission medium, e.g. ISDN
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N7/00—Television systems
    • H04N7/14—Systems for two-way working
    • H04N7/15—Conference systems
    • H04N7/152—Multipoint control units therefor
    • 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/1066—Session management
    • H04L65/1101—Session protocols
    • H04L65/1104—Session initiation protocol [SIP]

Abstract

Die Erfindung betrifft ein Verfahren zum Aufbau einer Videotelefonverbindung und/oder Multimediatelefonverbindung in einem Datennetz, umfassend ein Telefonnetz (CS) und ein auf dem Internet-Protokoll basierendes IP-Netz (IMS), bei dem: DOLLAR A a) ein Rufaufbau zwischen einem ersten Teilnehmer (MS1), der sich im oder benachbart zum Telefonnetz (CS) befindet, und einem zweiten Teilnehmer (MS2), der sich im oder benachbart zum IP-Netz (IMS) befindet, über das Telefonnetz (CS) und das IP-Netz (IMS) mithilfe eines ersten Signalisierungsprotokolls (BICC) im Telefonnetz (CS) und eines zweiten Signalisierungsprotokolls (SIP) im IP-Netz durchgeführt wird; DOLLAR A b) beim Rufaufbau Signalisierungsnachrichten des ersten Signalisierungsprotokolls (BICC) in Signalisierungsnachrichten des zweiten Signalisierungsprotokolls (SIP) und/oder umgekehrt umgewandelt werden; DOLLAR A c) in Schritt b) ein oder mehrere Codierungen festgelegt werden, welche bei der Übertragung der während der Videotelefonverbindung ausgetauschten Nutzdaten im Telefonnetz (CS) verwendbar und/oder voraussichtlich verwendbar sind; DOLLAR A d) die in Schritt c) festgelegten Codierungen mit einer oder mehreren Signalisierungsnachrichten des zweiten Signalisierungsprotokolls (SIP) in das IP-Netz (IMS) gesendet werden; DOLLAR A e) nach und/oder während der Durchführung des Rufaufbaus eine Datenverbindung zur Übertragung der während der Videotelefonverbindung ausgetauschten Nutzdaten aufgebaut wird; DOLLAR A f) innerhalb der Datenverbindung auf Seiten des ...

Description

  • Die Erfindung betrifft ein Verfahren zum Aufbau einer Videotelefonverbindung in einem Datennetz umfassend ein Telefonnetz und ein auf dem Internetprotokoll basierendes IP-Netz. Der Ausdruck Videotelefonverbindung ist hier und im folgenden allgemein zu verstehen und umfasst neben reiner Videotelefonie auch Multimediatelefonie.
  • WO 01/05109A1 beschreibt den Aufbau einer Video- oder Multimedia- Verbindung zwischen einem H323- und einem SIP- Netz über ein Transit-PSTN/ISDN-Netz.
  • Zur Übertragung von Multimedia-Daten ist es aus dem Stand der Technik bekannt, ein Telefonnetz, beispielsweise ein Mobilfunknetz, insbesondere ein GSM- oder UMTS-Mobilfunknetz, mit einem IP-basierten Netz zu verbinden, um über ein derartig kombiniertes Datennetz Sprach- und Videotelefonie effektiv durchzuführen. Hierbei muss sichergestellt werden, dass die Dienste des Telefonnetzes mit den Diensten des IP-Netzes zusammenwirken und insbesondere eine Umwandlung der verwendeten Signalisierungen und des Transportformats der Nutzdaten gewährleistet ist.
  • Auf dem Gebiet der 3GPP-Netze (3GPP = 3rd Generation Partnership Project) wurde in den 3GPP Standard TS 29.163 ein Zusammenwirken zwischen einem sog. CS-Telefonnetz (CS = Circuit Switched), insbesondere einer 3GPP-CS-Domain oder einem PSTN-Netz (PSTN = Public Switched Telephone Network), und einem IP-basierten IMS-Netz (IMS = IP Multimedia Subsystem) spezifiziert. Die Spezifikation betrifft jedoch nur reine Sprachtelefonie, und es ist kein Verfahren bekannt, wie effektiv eine Videotelefonverbindung zwischen einem CS-Netz und einem IMS-Netz (IMS = IP Multimedia Subsystem) aufgebaut werden kann.
    •
  • Aufgabe der Erfindung ist es deshalb, ein Verfahren zu schaffen, welches den Aufbau einer Videotelefonverbindung zwischen einem Teilnehmer auf der Seite eines Telefonnetzes und einem Teilnehmer auf der Seite eines IP-Netzes ermöglicht.
  • Diese Aufgabe wird durch die unabhängigen Patentansprüche gelöst. Weiterbildungen der Erfindung sind in den abhängigen Ansprüchen definiert.
  • In dem erfindungsgemäßen Verfahren erfolgt in einem Schritt a) ein Rufaufbau zwischen einem ersten Teilnehmer, der sich im oder benachbart zum Telefonnetz befindet, und einem zweiten Teilnehmer, der sich im oder benachbart zum IP-Netz befindet, über das Telefonnetz und das IP-Netz mit Hilfe eines ersten Signalisierungsprotokolls im Telefonnetz und eines zweiten Signalisierungsprotokolls im IP-Netz. Unter Teilnehmer ist hierbei insbesondere ein Endgerät zu verstehen, insbesondere ein Mobilfunkendgerät oder ein Festnetzendgerät. Um eine Signalisierung zwischen dem ersten und dem zweiten Signalisierungsprotokoll zu gewährleisten, werden beim Rufaufbau Signalisierungsnachrichten des ersten Signalisierungsprotokolls in Signalisierungsnachrichten des zweiten Signalisierungsprotokolls und/oder umgekehrt umgewandelt (Schritt b)). In einem Schritt c) werden bei dieser Umwandlung eine oder mehrere Codierungen festgelegt, welche bei der Übertragung der während der Videotelefonverbindung ausgetauschten Nutzdaten im Telefonnetz verwendbar und/oder voraussichtlich verwendbar sind. Diese Festlegung der Codierungen wird vorgenommen, da bei der Signalisierung mit dem ersten Signalisierungsprotokoll im Telefonnetz meist keine Informationen über die verwendbaren Codierungen für die Nutzdaten übermittelt werden. Diese Informationen werden in der Telefonverbindung erst zu einem späteren Zeitpunkt, nämlich beim Aufbau der eigentlichen Datenverbindung zur Übertragung der Nutzdaten, übermittelt. Andererseits benötigt ein im IP-Netz verwendetes Signalisierungsprotokoll die Informationen bezüglich verwendbarer Codierungen. Deshalb werden in einem Schritt d) die Codierungen, die in Schritt c) festgelegt wurden, mit einer oder mehreren Signalisierungsnachrichten des zweiten Signali sierungsprotokolls in das IP-Netz gesendet. Anschließend wird nach und/oder während der Durchführung des Rufaufbaus eine Datenverbindung zur Übertragung der während der Videotelefonverbindung ausgetauschten Nutzdaten aufgebaut. Innerhalb der Datenverbindung, insbesondere während deren Aufbau gemäß Schritt e), wird dann auf Seiten des Telefonnetzes mithilfe eines dritten Signalisierungsprotokolls, welches insbesondere H.245 ist, die für die Nutzdaten verwendete Codierung bestimmt.
  • Der vorliegenden Erfindung liegt die Erkenntnis zugrunde, dass zur Signalisierung im IP-Netz bereits verwendbare bzw. voraussichtlich verwendbare Codierungen festgelegt sein müssen. Da die Codierungen auf Seiten des Telefonnetzes jedoch bei der Signalisierung noch nicht bekannt sind, wird in dem erfindungsgemäßen Verfahren vorab abgeschätzt bzw. bestimmt, welche Codierungen bei der Übertragung der Nutzlast im Telefonnetz verwendbar bzw. voraussichtlich verwendbar sind. Diese Information wird dann von dem zweiten Signalisierungsprotokoll verwendet. Somit kann mit dem erfindungsgemäßen Verfahren ein schneller Verbindungsaufbau gewährleistet werden, da nicht auf den eigentlichen Aufbau der Datenverbindung, in der die tatsächlich im Telefonnetz verwendbaren Codierungen mitgeteilt werden, gewartet werden muss.
  • Das erfindungsgemäße Verfahren wird vorzugsweise in dem bereits oben erwähnten 3GPP-Datennetz eingesetzt. Als Telefonnetz wird insbesondere ein CS-Netz und/oder ein PSTN-Netz verwendet, welche bereits oben erwähnt wurden. Als erstes Signalisierungsprotokoll wird in dem erfindungsgemäßen Verfahren vorzugsweise das aus dem Stand der Technik bekannte BICC-Protokoll (BICC = Bearer Independent Call Control) verwendet. Alternativ oder zusätzlich kann auch das aus dem Stand der Technik bekannte ISUP-Protokoll (ISUP = ISDN User Part) eingesetzt werden. Als zweites IP-Netz wird vorzugsweise das bereits oben erwähnte IMS-Netz verwendet. Ferner kommt als zweites Signalisierungsprotokoll insbesondere das hin länglich aus dem Stand der Technik bekannte SIP/SDP-Protokoll (SIP = Session Initiation Protocol; SDP = Session Description Protocol) in Betracht. In einer bevorzugten Ausführungsform wird bei dem SIP-Protokoll die bekannte Preconditions-Erweiterung eingesetzt, um nach Schritt f) zu signalisieren, dass der Aufbau einer Transportverbindung (auch als Bearer-Verbindung bezeichnet) abgeschlossen ist.
  • In einer bevorzugten Ausführungsform der Erfindung werden die Schritte b) bis d) des erfindungsgemäßen Verfahrens in einem oder mehreren Schnittstellenknoten zwischen dem Telefonnetz und dem IP-Netz durchgeführt, wobei die Schnittstellenknoten vorzugsweise einen MGCF-Knoten (MGCF = Media Gateway Control Function) und einen IM-MGW-Knoten (IM-MGW = IMS Media Gateway) umfassen. Diese Art von Schnittstellenknoten bzw. Schnittstellenrechnern sind hinlänglich aus dem Stand der Technik bekannt und werden an dieser Stelle nicht näher beschrieben.
  • Beim Aufbau der Datenverbindung im Schritt e) wird in einer besonders bevorzugten Ausführungsform die hinlänglich aus dem Stand der Technik bekannte H.324-Protokollfamilie verwendet. Bei der Verwendung eines Mobilfunknetzes als Telefonnetz wird hierbei eine Abwandlung dieses Protokolls, nämlich das H.324M-Protokoll, eingesetzt.
  • Um eine effektive Abschätzung der im Telefonnetz verwendbaren Codierungen im Schritt c) sicherzustellen, werden in einer bevorzugten Ausführungsform in diesem Schritt die Codierungen in Abhängigkeit von dem verwendeten Telefonnetz festgelegt. Hierbei wird sich die Erkenntnis zugrunde gemacht, dass je nach verwendetem Telefonnetz bestimmte Codierungen bevorzugt werden.
  • In einer weiteren Ausführungsform werden die Codierungen im Schritt c) des erfindungsgemäßen Verfahrens in Abhängigkeit von der Rufnummer des ersten Teilnehmers, der in bzw. benach bart auf der Seite des Telefonnetzes liegt, festgelegt. Es wird sich hierbei die Erkenntnis zunutze gemacht, dass mit Hilfe der Rufnummer des ersten Teilnehmers ermittelt werden kann, in welchem Telefonnetz sich der Teilnehmer befindet. Hieraus kann wieder darauf geschlossen werden, welche Codierungen bevorzugt verwendet werden.
  • In einer weiteren Ausgestaltung werden im Schritt c) diejenigen Codierverfahren festgelegt, die in Abhängigkeit von dem verwendeten Telefonnetz und dem verwendeten IP-Netz am wahrscheinlichsten in beiden Netzen verwendet werden. Es wird hierdurch gewährleistet, dass bereits vorab die richtige Auswahl von kompatiblen Codierungen festgelegt wird. Eine derartige Auswahl der Codierungen kann beispielsweise durch Bewerten von Statistiken bzw. durch administrative Einstellungen erreicht und optimiert werden. Insbesondere ist es auch möglich, dass nur eine Sprach- und Videocodierung ausgewählt wird.
  • In einer weiteren Ausgestaltung der Erfindung können die Signalisierungsnachrichten des ersten Signalisierungsprotokolls derart ausgestaltet sein, dass sie Informationen über im Telefonnetz verwendbare Sprachcodierungen enthalten. Diese Sprachcodierungen werden vorzugsweise ebenfalls bei der Festlegung der Codierungen im Schritt c) berücksichtigt. Hierdurch wird ein reibungsloser Aufbau auch für den Fall gewährleistet, dass auf der Seite des IP-Netzes nur reine Sprachtelefonie ausgewählt wird.
  • In einer besonders bevorzugten Ausführungsform der Erfindung werden beim Aufbau der Datenverbindung im Schritt f) des erfindungsgemäßen Verfahrens eine oder mehrere erste Spezifikations-Nachrichten im Telefonnetz übertragen, wobei eine erste Spezifikations-Nachricht die im ersten Teilnehmer verwendbaren Codierungen spezifiziert. Diese ersten Spezifikations-Nachrichten sind insbesondere im Stand der Technik aus dem Protokoll H.245 zur Verhandlung der Codierungen als "Terminal Capability Set" Nachrichten TCS bekannt. Die in einer ersten Spezifikations-Nachrichten spezifizierten Codierungen werden insbesondere mit dem im Schritt c) festgelegten Codierungen verglichen. Wenn der Vergleich ergibt, dass keine oder nur eine teilweise Übereinstimmung zwischen den in der ersten Spezifikations-Nachricht spezifizierten Codierungen und den im Schritt c) festgelegten Codierungen besteht, wird in einer bevorzugten Ausführungsform eine Signalisierungsnachricht des zweiten Signalisierungsprotokolls in das IP-Netz gesendet, wobei diese Signalisierungsnachricht zumindest teilweise die in der ersten Spezifikations-Nachrichten spezifizierten Codierungen enthält. Hierdurch wird gewährleistet, dass eine Datenverbindung auch hergestellt werden kann, wenn die ursprünglich abgeschätzten Codierungen nicht mit den tatsächlich verwendbaren Codierungen übereinstimmen.
  • In einer weiteren bevorzugten Ausführungsform des erfindungsgemäßen Verfahrens werden Signalisierungsnachrichten des zweiten Signalisierungsprotokolls im IP-Netz übertragen, wobei diese Signalisierungsnachrichten die im zweiten Teilnehmer verwendbaren Codierungen spezifizieren und ferner die in diesen Signalisierungsnachrichten enthaltenen Codierungen mit einer zweiten Spezifikations-Nachricht beim Aufbau der Datenverbindung in Schritt e) in das Telefonnetz gesendet werden. Auf diese Weise werden die von Seiten des IP-Netzes empfangenen Angaben über die Codierungen bei der Verhandlung der Codierungen im Telefonnetz, welche insbesondere mit dem H.245-Protokoll durchgeführt wird, berücksichtigt.
  • In einer weiteren Ausführungsform wird eine Signalisierungsnachricht des zweiten Signalisierungsprotokolls, welche die im zweiten Teilnehmer verwendbaren Codierungen spezifiziert, mit einer ersten Spezifikations-Nachricht verglichen und der Aufbau der Videotelefonverbindung wird abgebrochen oder ein Umschalten auf Sprachtelefonie, vorzugsweise mit Hilfe der SCUDIF-"Service Change"-Prozedur gemäß dem 3GPP-Standard 3GPP TS 23.172, wird veranlasst, wenn nicht zumindest eine Über einstimmung von für eine Videotelefonverbindung erforderlichen Codierungen in der Signalisierungsnachricht und der ersten Spezifikations-Nachricht vorliegt.
  • Insbesondere betreffen die in der Erfindung verwendeten Codierungen Sprach- und Videocodierungen, welche beide bei der Videotelefonie verwendet werden. Ggf. umfasst die Erfindung jedoch auch weitere Datencodierungen.
  • In einer weiteren Ausführungsform des erfindungsgemäßen Verfahrens, insbesondere im Falle, wenn ein verwendetes SIP-Protokoll nicht die Preconditions-Erweiterung unterstützt, wird der zweite Teilnehmer angewiesen, keine Nutzdaten zu übertragen, bis ein vorbestimmter Verfahrensabschnitt des Aufbaus der Datenverbindung, insbesondere der Aufbau der Transportverbindung im Telefonnetz, abgeschlossen ist. Hierdurch wird das sog. "Clipping" vermieden, d.h. der Verlust von Sprache und Video, die durch den Angerufenen gesendet werden, bevor eine durchgängige Transportverbindung vorhanden ist.
  • Neben dem soeben beschriebenen erfindungsgemäßen Verfahren betrifft die Erfindung ferner ein Datennetz mit einem Telefonnetz und einem auf dem Internetprotokoll basierenden IP-Netz, wobei das Datennetz derart ausgestaltet ist, dass das erfindungsgemäße Verfahren durchführbar ist. Hierzu weist das Datennetz vorzugsweise einen oder mehrere Schnittstellenknoten zwischen dem Telefonnetz und dem IP-Netz auf, wobei die Schnittstellenknoten zur Durchführung der Schritte b) bis d) des erfindungsgemäßen Verfahrens dienen. Vorzugsweise umfassen die Schnittstellenknoten die hinlänglich aus dem Stand der Technik bekannten MGCF- und IM-MGW-Knoten, die bereits bei der Beschreibung des erfindungsgemäßen Verfahrens erwähnt wurden.
    •
  • Ausführungsbeispiele der Erfindung werden nachfolgend anhand der beigefügten Zeichnungen detailliert beschrieben.
  • Es zeigen:
  • 1 eine schematische Darstellung einer Ausführungsform eines Datennetzes, in dem das erfindungsgemäße Verfahren eingesetzt werden kann;
  • 2–16 Signalisierungsdiagramme, welche den Signalisierungsverlauf der Nachrichten in den in der Erfindung verwendeten Protokollen für verschiedene Szenarien verdeutlichen.
  • Bevor detailliert Ausführungsformen des erfindungsgemäßen Verfahrens beschrieben werden, wird zunächst zum besseren Verständnis der Erfindung auf die bereits vorhandenen Entwicklungen im Stand der Technik eingegangen. Insbesondere wird hierbei auf die Entwicklungen der Datennetze eingegangen, für welche das erfindungsgemäße Verfahren bevorzugt verwendet wird. Die im Folgenden sowie auch im Vorangegangenen definierten Protokolle und deren Abkürzungen sind hinlänglich aus dem Stand der Technik bekannt und werden deshalb nicht näher erläutert.
  • Aus dem 3GPP-Mobilfunk-Projekt ist das sog. "Circuit Switched Domain"-Netz CS und das sog. "IP-Multimedia Subsystem (IMS)"-Netz für Sprach- und Videotelefonie bekannt. Es muss hierbei ein so genanntes „Interworking" der betreffenden Dienste dieser Netze gewährleistet sein, d. h. ein Verbinden der Dienste mittels einer geeigneten Umwandlung der verwendeten Signalisierung und des verwendeten Transportformats der Daten, zwischen IMS und der CS Domain ist erforderlich. Das IMS wird neben den 3GPP-Zugangsnetzen „Global System for Mobile Communications" (GSM) und „Universal Mobile Telecommunications System" (UMTS) auch für andere Zugangsnetze verwendet, beispielsweise „Wireless Local Area Network" (WLAN) und „Digital Subscriber Line" (DSL). Gerade in diesen Szenarien ist zuerst zu erwarten, dass Sprach- und Videotelefonie über das IMS erfolgen. Videotelefonie kann auch in einem öffentlichen Tele fonnetz, d.h. einem so genannten „Public Switched Telephone Network (PSTN)", genutzt werden, wobei hier in der Regel für Transport und Signalisierung dieselben Protokolle wie in der 3GPP-CS-Domain genutzt werden. Auch von einem PSTN-Netz ist ein Interworking hin zum IMS erforderlich.
  • Bisher ist ein Interworking zwischen IMS und CS-Domain oder PSTN nur für Sprachtelefonie beschrieben. Die vorliegende Erfindung betrifft das entsprechende Interworking für Videotelefonie. Ein Bedarf dafür ist abzusehen, da sowohl in der 3GPP-CS-Domain wie auch in IMS Videotelefonie an Bedeutung gewinnt, und zwar insbesondere für Zugangsnetze wie WLAN oder DSL bzw. für neu entstehende Netz-Zutrittsmöglichkeiten (z.B. Worldwide Interoperability for Microwave Access (WiMAX)).
  • Das Interworking zwischen einem IMS-Netz und einem CS-Netzwerk, also einem PSTN oder einer 3GPP-CS-Domain, ist ab 3GPP Release 6 nur für reine Sprachtelefonie in 3GPP TS 29.163 spezifiziert.
  • Gemäß TS 29.163 erfolgt das Interworking der so genannten „Call-Control" Signalisierung in der so genannten „Media Gateway Control Function" (MGCF). Das Interworking der Nutzverbindung, also das Weiterreichen und Umpacken sowie nötigenfalls das Transkodieren der Nutzdaten, erfolgt in der so genannten „Internet Multimedia-Media Gateway" (IM-MGW). Die MGCF kontrolliert die IM-MGW mittels des von der ITU-T standardisierten H.248 Protokolls, wie in 3GPP TS 29.332 weiter beschrieben wird. Im Folgenden werden MGCF und IM-MGW zusammen als „Multimedia-Interworking-Knoten" (MIK) bezeichnet.
  • Im CS-Netz wird Bearer Independent Call Control (BICC) oder ISDN User Part (ISUP) zur Call-Control Signalisierung verwendet. Im Falle, wenn die Call-Control Signalisierung getrennt von den Transportverbindungen geführt werden, wird diese Methode auch als "out-of-band" Signalisierung bezeichnet. In weiterer Folge besteht auch die Möglichkeit innerhalb der Transportverbindung Signalisierungs-Meldungen auszutauschen, welche als "in-band" Signalisierungen bezeichnet werden. Im Falle von ISUP wird Time Division Multiplex (TDM) als Transport im CS-Netzwerk genutzt, und im Falle von BICC Pakettransport mittels Internet Protocol (IP) oder Asynchron Transfer Modus (ATM). Die Aushandlung, ob reine Sprachtelefonie oder Videotelefonie verwendet wird, kann für ISUP während des Call-Control Signalisierung zum Aufbau des Gesprächs mittels der so genannten ISUP "UDI Fallback" Prozedur erfolgen. Für BICC kann diese Aushandlung mittels dem in 3GPP TS 23.172 standardisierten „Service Change and UDI Fallback" (SCUDIF) erfolgen, der auch während des Gesprächs einen Wechsel zwischen Sprachtelefonie und Videotelefonie ermöglicht. Sowohl „UDI Fallback" wie SCUDIF nutzen out-of-band Signalisierung. Daneben ist es für ISUP und BICC möglich, die genannten Prozeduren nicht zu verwenden, und einen Rufaufbau (auch als Call-Control bezeichnet) nur für Videotelefonie zu versuchen, und im Falle, dass Videotelefonie nicht unterstützt wird, den Rufaufbau abzubrechen. Im Gegensatz zur optionalen Verhandlung zwischen Sprache und Video erfolgt die Verhandlung der für Videotelefonie verwendeten Sprach- und Video-Codecs "in-band", nachdem bereits vorher Videotelefonie ausgewählt und eine entsprechende Transportverbindung (engl. „Bearer") aufgebaut wurde.
  • Für Videotelefonie wird in dem CS-Netwerk eine so genannte BS30 Datenverbindung mit 64 kbyte/s Bandbreite verwendet. Innerhalb dieser Datenverbindung wird die von der ITU-T standardisierte Protokollsuite H.324 verwendet, wobei in der 3GPP-CS-Domain die für den Mobilfunk angepasste Variante H.324M ausgewählt wird. Nach dem Rufaufbau wird hierbei die Konfiguration der Multimedia-Verbindung in-band über das von der ITU-T standardisierte H.245 Protokoll ausgehandelt, besonders der verwendete Video-Codec und Sprach-Codec und die Details der jeweiligen Codec-Konfiguration. Sprache und Video werden mittels des H.223 Protokolls in dieselbe Transportverbindung gemultiplext. Für die 3GPP-CS-Domain beschreibt TS 26.110 die Verwendung der Protokollsuite H.245 weiter, wobei insbesondere die so genannte H.324M Konfiguration ausgewählt wird.
  • Die wichtigsten Abläufe beim Aufbau einer 3G-324M Verbindung (engl. "session") sind die folgenden:
    • 1. Nach dem Start der ISUP oder BICC Rufaufbausignalisierung erfolgt die Reservierung der notwendigen Ressourcen, welche für den gewünschten "Bearer" benötigt werden, und in weiterer Folge der Aufbau der Transportverbindung.
    • 2. Start der "in-band" Verhandlung. Zunächst Verhandlung, welcher H.223 "Multiplexer Level" für diese Transportverbindung zu verwenden ist.
    • 3. Erkennung des leitenden Endgerätes, welches die Multistream-Verbindung eröffnet mittels H.245 Verhandlung, falls erforderlich. Diese Funktion ist nur dann notwendig, falls es zu einem Konflikt im Zusammenhang beim Öffnen eines bidirektionalen logischen Kanals (= logical channel) kommt. Diese Funktion wird als "Master or Slave determination" (MSD) bezeichnet.
    • 4. Mittels so genannter „Terminal Capability Set" H.245-Nachrichten TCS werden die Fähigkeiten des die Nachricht sendenden Endgeräts übertragen. Solche Meldungen werden unabhängig von beiden Endgeräten gesendet. Diese beschriebenen Fähigkeiten beinhalten folgende Informationen: Audio- und Video-Codec und deren spezifischen Eigenschaften bzw. dessen Ausprägungen; funktionaler Umfang des Multiplexers, im Detail welcher Adaptions-Layer unterstützt wird (z.B "simple" (= einfach) oder "nested" (= verschachtelt) multiplexing) und dessen Mobilfunk spezifische Erweiterungen.
    • 5. Aufbau von "logischen" Kanälen je Mediastrom mittels H.245-Signalisierung. Ab diesem Zeitpunkt, entweder mit MSD oder ohne, ist das Endgerät bzw. die IM-MGW dazu bereit, "logical channels" zu öffnen, um den Austausch von Sprach-, und/oder Video-Nutzdaten zu ermöglichen. Bei dem Erstellen eines bidirektionalen "logical channel" wird die Kanalnummer (= channel number) und die endgültigen zu verwendeten Fähigkeiten der Medien (engl. "media capabilities") festgelegt.
    • 6. Definition der Multiplexeigenschaften mittels H.245.
    • 7. Start der Übermittlung von Video, Audio/Sprache oder Daten.
  • Im IMS erfolgt die Aushandlung für Videotelefonie "out-of-band" mit Hilfe des so genannten „Session Description Protocol" (SDP), IETF RFC 2327, das mittels des so genannten „Session Initiation Protocol" (SIP), IETF RFC 3261, transportiert wird. Hierbei ist die Aushandlung, ob Sprachtelefonie oder Videotelefonie verwendet wird, mit der Aushandlung der Verwendeten Codecs verbunden, und erfolgt vor oder während des Aufbaus der Bearer. Es wird der so genannte SDP „offer-answer" Mechanismus gemäß RFC 3264 verwendet. Hierbei schickt der Anbieter in der SDP „offer" Nachricht eine Liste von unterstützten Codecs. Nach Erhalt dieser Nachricht schickt der Antwortende eine SDP „Answer" Nachricht, die diejenigen Codecs aus der Liste enthält, die auch er unterstützt und benutzen will. Der Antwortende darf keine Codecs angeben, die nicht in der Liste der SDP „offer" enthalten waren. Im Gegensatz zur CS-Domain werden für Sprache und Video zwei getrennte Transportverbindungen (engl. „Bearer") genutzt, die jeweils das so genannte „Real Time Transport Protocol" (RTP), IETF RFC 3550, verwenden. Für das 3GPP-IMS, welches über ein General Packet Radio Service (GPRS) Zugangsnetz verwendet, beschreibt 3GPP TS 26.235 die für Videotelefonie zu verwendenden Codecs.
  • Im Folgenden werden die auf Seiten der CS-Domain und auf Seiten des IMS für Videotelefonie verwendeten Protokolle und Codecs nochmals zusammengefasst: CS-Netz (insbesondere 3GPP CS-Domain):
    Call Control: BICC oder ISUP. Aushandlung zwischen reiner Sprachtelefonie und Videotelefonie kann für ISUP mittels "UDI Fallback" und für BICC mittels "SCUDIF" erfolgen.
    Multimedia Protocol suite H.324M (H.324 Annex C):
    Codec-Verhandlung: H.245 in-band Verhandlung über den aufgebauten CS-Bearer mit 64 kbit/s
    Video-Codec: Unterstützung von H.263 vorgeschrieben H.261 optional MP4V-ES (simple video profile level 0) optional
    Sprach-Codec: Unterstützung von NB-AMR vorgeschrieben WB-AMR optional G.723.1 empfohlen
    Transport: Multiplexen von Sprache und Video in einen Bearer gemäß H.223 Annex A + B
    IMS (Codecs für GPRS-Zugangsnetz):
    Call Control: SIP Beinhaltet sowohl Aushandlung zwischen reiner Sprachtelefonie und Videotelefonie, wie auch Codec-Verhandlung.
    Codec-Verhandlung: Vor Aufbau des Bearers Out-of-band mittels SDP, das in SIP transportiert wird.
    Video-Codec: Unterstützung von H.263 vorgeschrieben, H.264 optional, MP4V-ES (simple video profile level 0) optional,
    Sprach-Codec: Unterstützung von NB-AMR und WB-AMR vorgeschrieben.
    Transport: Zwei getrennte RTP Bearer für Sprache und Video unter Verwendung von unterschiedlichen so genannten RTP "Payload" Formaten: Sprache: Nb-AMR + WB-AMR: IETF RFC 3267 Video: H.263: IETF RFC 2429 H.264 (AVC): IETF RFC 3984 MPEG-4: IETF RFC 3016 Synchronisation von parallel RTP Medienströmen erfolgt mittels so genannter RTP "timestamps", die durch das " Real Time Control Protocol" (RTCP, siehe IETF RFC 3550) ausgehandelt werden.
  • Neben den oder an Stelle der hier angegeben Codecs können aber auch andere Codecs von den Endgeräten unterstützt werden, insbesondere wenn die CS-Endgeräte sich im PSTN befinden oder die IMS-Endgeräte GPRS nicht als Zugangsnetz nutzen.
  • Es ist wünschenswert, auf der CS-Seite und im IMS den gleichen Videocodec und wenn möglich auch den gleichen Sprachcodec zu verwenden, um ein Transkodieren zu vermeiden. Ein Transkodieren insbesondere des Videocodecs, aber in geringerem Umfang auch des Sprachcodecs, würde erhebliche Rechenleistung und Ressourcen in der IM-MGW erfordern. Zudem würde die Übertragung verzögert und die Qualität des Bildes bzw. der Sprache verschlechtert. Wenn die erforderliche Bandbreite für die Codecs auf Seiten der CS-Domain und dem IMS unterschiedlich sind, würde auf einer Seite zusätzliche Bandbreite verwendet, ohne dass dadurch die Bild- oder Sprachqualität verbessern würde.
  • 1 zeigt eine typische Netzwerkkofiguration, wie sie in der nachfolgend beschriebenen Ausführungsform der Erfindung verwendet werden kann.
  • Es ist die Netzwerkkonfiguration dargestellt, die nötig ist, damit ein mit der 3GPP CS-Domäne verbundenes Terminal in der Form eines mobilen Endgeräts MS1 mit einem mit dem IMS verbundenen Terminal in der Form eines mobilen Endgeräts MS2 kommunizieren kann. Die CS-Domäne ist mit Hilfe einer „Media Gateway Control Function" (MGCF) und einer IMS Media Gateway (IM-MGW) mit dem IMS verbunden. Die MGCF kontrolliert die IMS Media Gateway über die so genannte „Mn" Schnittstelle. Auf Seiten der CS-Domäne befinden sich im Kernnetz so genannte „Mobile Switching Center"(MSC)-Server, die über BICC Signalisierung miteinander und mit der MGCF kommunizieren. Sie kontrollieren jeweils CS-MGWs. Die CS-MGWs sind untereinander und mit der IM-MGW über die so genannte „Nb" Schnittstelle verbunden. Für Videotelefonie wird der so genannte „BS30" Datentransportdienst (engl. „Bearer Service") verwendet. MS1 ist mittels eines so genannten Radiozugangsnetzes, beispielsweise eines UTRAN, mit einem MSC-Server einer CS-MGW verbunden. Auf Seiten des IMS kommuniziert die MGCF mit Hilfe des SIP Call Control Protokolls mit so genannten „call session control functions" (CSCF), die die Signalisierung über den Gateway GPRS support node" (GGSN) und ein Radiozugangsnetzes, beispielsweise eines sog. UTRAN, zum mobilen Endgerät MS2 weiterreichen. Daten werden von der IMS Media Gateway über die Mb Schnittstelle zum GGSN transportiert, der diese Daten ebenfalls über das Radiozugangsnetz UTRAN zum MS2 weiterreicht.
  • In 1 bezeichnet somit die Linie L1, die sich über die beiden MSC-Server zur MGCF erstreckt, die BICC-Signalisierung. Die Linie L2, die sich von der MGCF über die CSCF zum GGSN und von dort zum UTRAN auf der IMS-Seite erstreckt, bezeichnet die SIP-Signalisierung. Ferner bezeichnet die Linie L3, welche sich von der Schnittstelle UTRAN auf der CS-Seite über die beiden CS-MGWs und IM-MGW erstreckt, den kombinierten Sprach-/Videostrom. Die Linie L4, welche sich – analog zur Linie L3 – vom UTRAN auf der CS-Seite über die beiden CS-MGWs hin zum IM-MGW erstreckt, bezeichnet die Übertragung gemäß dem H.245 Protokoll. Die Linie L5, die sich vom IM-MGW über den GGSN zum UTRAN auf der IMS-Seite erstreckt, betrifft den Transport des Videostroms im IMS-Netz und die Linie L6, die sich ebenfalls von IM-MGW über den GGSN zum UTRAN auf der IMS-Seite erstreckt, betrifft den im IMS-Netz transportierten Sprachstrom.
  • Ein Verfahren, das das Interworking von Videotelefonie unter Vermeidung von Transkodieren zwischen einem CS-Netz, also einem PSTN oder einer 3GPP CS-Domain, sowie einem IP-Netz, das SIP und SDP zur Aushandlung der Codecs verwenden, also beispielsweise dem IMS, ist Gegenstand der Erfindung.
  • Im Falle eines Rufaufbaus von Seiten des CS-Netzes in Richtung des IMS, der im Weiteren als „IMS terminierender" (IMS-T) Rufaufbau bezeichnet wird, empfängt die MGCF zunächst ISUP oder BICC Signalisierung, aus der sie erkennen oder vermuten kann, dass Videotelefonie gewünscht ist, aber nicht, welche Sprach- und Video-Codecs verwendet werden.
  • Im Falle eines Rufaufbaus von Seiten des IMS in Richtung des CS-Netzes, der im Weiteren als „IMS originierender" (IMS-O) Rufaufbau bezeichnet wird, empfängt die MGCF zunächst SIP-Signalisierung, aus der sie erkennen oder vermuten kann, dass Videotelefonie gewünscht ist, sowie welche Codecs auf Seiten des IMS unterstützt werden.
  • Um einen schnellen Aufbau der Verbindung zu erreichen, und im Folgenden die Signalisierung zwischen IMS und CS-Netz in geeigneter Weise umsetzen zu können, ist es im Falle des IMS-O Rufaufbaus – wie auch im Falle des IMS-T Rufaufbaus – erforderlich, dass die MGCF für die Signalisierung in Richtung des IMS Angaben über die auf der CS-Seite unterstützen Codecs macht, bevor sie diese Information aus der H.324/M Verbindung erhält. Diese Information wird auf der CS-Seite häufig erst zur Verfügung stehen, nachdem die Out-of-Band Call-Control Signalisierung zum Rufaufbau bereits abgeschlossen ist, zum Beispiel wenn zu diesem Zeitpunkt die Transportverbindung durchgeschaltet wird. In vielen Netzen werden in Richtung des Rufaufbaus gesendete Daten in der Transportverbindung, so genannte „forward early media", bis zu diesem Zeitpunkt geblockt.
  • Der Kern der Erfindung besteht darin, dass der Multimedia-Interworking-Knoten (MIK) in der SIP-Codec-Verhandlung beim Rufaufbau zunächst nur eine Abschätzung der auf der CS-Seite unterstützen Codecs abgibt. In einer vorteilhaften Ausführungsform berücksichtigt der MIK bei der Auswahl der Codecs das CS-Netz, an dem dieser angeschlossen ist. Wenn es sich beim CS-Netz um eine 3GPP CS-Domäne handelt, verwendet die MGCF vorzugsweise die in 3GPP TS 26.110 angegeben Codecs. In einem Festnetz können andere Codecs vorherrschen. In einer anderen vorteilhaften Ausführungsform berücksichtigt der MIK bei der Auswahl der Codecs das Netz, in dem sich der CS-seitige Gesprächsteilnehmer befindet. So verwendet der MIK im IMS-O Fall die Telefonnummer des Angerufenen, um zu ermitteln, in welchem Netz sich der Angerufene befindet, um für dieses Netz wahrscheinliche Codecs auszuwählen. Im IMS-T Fall verwendet der MIK die Telefonnummer des Anrufers, um zu ermitteln, in welchem Netz sich der Anrufer befindet, um für dieses Netz wahrscheinliche Codecs auszuwählen. Die Selektion der Codecs kann durch Bewerten von Statistiken bzw. durch administrative Einstellungen durch den Betreiber des MIK optimiert werden.
  • In einer einfacheren Ausführungsform wählt der MIK jeweils nur einen Sprachcodec und Videocodec aus, der mit großer Wahrscheinlichkeit auch vom Terminal im IMS unterstützt wird, beispielsweise den H.263 und den AMR Codec. Diese Ausführungsform kann ausreichend sein, weil gemäß 3GPP TS 26.235 und TS 26.110 die selben Sprach- und Videocodecs in der CS Domäne und dem IMS unterstützt werden müssen. Die Ausführungsform ist vorteilhaft, um die darauf folgenden Signalisierungsabläufe zu vereinfachen.
  • Falls im IMS-T Falle SCUDIF verwendet wird, ist es vorteilhaft, wenn der MIK neben den oben beschriebenen ausgewählten Codecs auch die Sprachcodecs aufnimmt, welche bei der Verwendung von SCUDIF in der anfänglich beim Rufaufbau übermittelten IAM-Nachricht (IAM = Initial Address Message) in einer Codecliste hinterlegt sind. Hierdurch wird ein reibungsloser Rufaufbau auch für den Fall gewährleistet, dass auf Seiten des IMS Sprachtelefonie ausgewählt wird.
  • Der MIK empfängt im Folgenden in der H.245 Inband-Verhandlung eine so genannte „Terminal Capability Set" Nachricht. Darin befinden sich Angaben zu den Fähigkeiten des Terminals auf Seiten des CS-Netzes, unter anderem zu den unterstützten Videocodecs und Sprachcodecs unter genauen Angaben, welche Optionen der einzelnen Codecs unterstützt werden. Erfindungsgemäß vergleicht der MIK die darin enthaltenen Codecs mit den zuvor abgeschätzten und in das IMS signalisierten Codecs. Sollten die Codecs voneinander abweichen, kann es vorteilhaft oder erforderlich sein, dass der MIK zu diesem Zeitpunkt erneut eine SDP „offer" in das IMS schickt, wobei er die in der „Terminal Capability Set" Nachricht angegeben Codecs weiterreicht. Die SDP „offer" kann beispielsweise mittels einer SIP „re-INVITE" oder „UPDATE" Nachricht transportiert werden. Eine erneute SDP offer ist im Besonderen dann erforderlich, wenn die zuvor abgeschätzten Codecs nicht mit jeweils mindestens einem Sprachcodec und Videocodec mit den in der „Terminal Capability Set" Nachricht empfangenen Codecs übereinstimmen.
  • Im IMS-O Fall hat der MIK bereits in der SIP „INVITE" Nachricht Informationen über die IMS-seitig unterstützten Codecs erhalten. Falls diese Codecs nicht in mindestens jeweils einem Sprachcodec und Videocodec mit den in der „Terminal Capability Set" Nachricht empfangenen Codecs übereinstimmen, ist es vorteilhaft, wenn der MIK die H.223 Verbindung abbaut und den Rufaufbau als Sprachtelephonie fortsetzt, beispielsweise indem er SCUDIF nutzt oder indem er CS-seitig den Rufaufbau zunächst komplett beendet und dann für Sprachtelefonie neu beginnt. Es kann auch der Fall auftreten, dass der MIK in der von ihm zuvor gesendeten SDP „answer" IMS-seitig unterstützte Codec ausgeschlossen hat, die er nun doch auf Grund der in der „Terminal Capability Set" Nachricht empfangenen Codecs auswählen möchte.
  • Im IMS-T Fall sendet der MIK dagegen die abgeschätzten Codecs in einer SDP „offer" und besitzt aus der erhaltenen SDP „answer" nur die Information, welche der zunächst von ihm abgeschätzten Codecs auf der Seite des IMS unterstützt werden. Es ist also sinnvoll, mittels einer neuen „SDP offer" abzufragen, ob in der ersten SDP „offer" nicht enthaltene Codecs im IMS unterstützt werden.
  • Ein weiterer entscheidender Punkt der Erfindung ist, dass der MIK die von der IMS-Seite empfangenen Angaben über Codec in der H.245 Inband-Verhandlung mittels einer „Terminal Capability Set" Nachricht weiterreicht. Vorzugsweise wartet der MIK mit dem Senden dieser Nachricht, bis er von der IMS-Seite die SDP-Nachricht mit Angaben zu den Codecs empfangen hat. Es ist besonders vorteilhaft, wenn der MIK auch für eine gewisse Zeit auf den Empfang einer „Terminal Capability Set" Nachricht wartet, bevor er diese Nachricht selbst schickt, da der MIK, wie oben beschrieben, auf Grund der in der empfangenen „Terminal Capability Set" Nachricht enthaltenen Codecinformation beschließen kann, auf der IMS-Seite eine SDP „offer" zu schicken, und die in der folgenden SDP „answer" enthaltenen Informationen in der von ihm geschickten Terminal Capability Set" Nachricht berücksichtigt.
  • Sollte der MIK jedoch für eine gewisse Zeit von der Gegenseite keine „Terminal Capability Set" Nachricht empfangen, beispielsweise weil sich hinter dem CS-Netz wieder ein anderer MIK an einem Übergang zu einem IMS-Netzwerk befindet, kann es erforderlich sein, dass der MIK vor Erhalt einer „Terminal Capability Set" Nachricht selbst eine „Terminal Capability Set" Nachricht schickt. Darin gibt der MIK erfindungsgemäß diejenigen Codecs an, die in der letzten, auf der IMS Seite gesendeten bzw. empfangenen SDP-Nachricht enthalten waren.
  • Sollte der MIK nach Senden einer „Terminal Capability Set" Nachricht auf Seiten des IMS erneut eine SDP-Nachricht empfangen, das in der ersten „Terminal Capability Set" Nachricht erlaubte Codecs ausschließt, so sendet der MIK erfindungsgemäß eine neue „Terminal Capability Set" Nachricht, in der die entsprechenden Codecs entfernt sind.
  • Nachdem auf Seiten des CS-Netzes H.245 „Terminal Capability Set" Nachrichten ausgetauscht wurden, werden mittels der H.245 Signalisierung getrennte logische Kanäle des H.223 Protokolls zum Transport von Sprache und Video ausgewählt. Dadurch wird auch jeweils genau einer der unterstützten Sprachcodecs und Videocodecs ausgewählt. Sollten zu diesem Zeitpunkt auf Seiten des IMS noch mehrere Sprachcodecs oder Videocodecs ausgewählt sein, sendet der MIK erfindungsgemäß erneut eine „SDP offer" auf Seiten des IMS, in der er genau die mittels H.245 ausgewählten Codecs angibt, um zu verhindern, dass von Seiten des IMS-Terminals ein Codec verwendet wird, den der MIK nicht weiterreichen kann. Die SDP „offer" kann beispielsweise mittels einer SIP „re-INVITE" oder „UPDATE" Nachricht transportiert werden.
  • Im IMS-T Falle ist es wünschenswert, „Clipping" zu vermeiden, dass heißt einen Verlust von Sprache oder Video, die durch den Angerufenen gesendet wird, bevor eine durchgängige Transportverbindung vorhanden ist. Falls auf Seiten des IMS die „SIP Preconditions" Erweiterung gemäß IETF RFC 3312 unterstützt wird, nutzt der MIK die SIP „Preconditions" Erweiterung, um anzuzeigen, dass lokale so genannte „QoS preconditions" vorhanden sind, d.h. ein Aufbau der Transportverbindung erforderlich ist, bevor der Rufaufbau abgeschlossen werden kann. Sobald durch das Öffnen der logischen H.223 Kanäle für Sprache und Video der CS-seitige Aufbau der Transportverbindung abgeschlossen ist, nutzt der MIK erfindungsgemäß die SIP „Preconditions" Erweiterung, um anzuzeigen, dass lokale so genannten „QoS preconditions" erfüllt sind. Allerdings kann es vorkommen, dass CS-seitig „forward early media" erst nach Abschluss des Rufaufbaus in der Call-Control-Signalisierung durchgereicht werden, und erst zu diesem Zeitpunkt die H.223 und H.245 Verhandlung innerhalb der Transportverbindung möglich wird. Um ein Blockieren des Rufaufbaus zu vermeiden, signalisiert der MIK auch dann auf Seiten des IMS, dass lokale so genannten „QoS preconditions" erfüllt sind, wenn nach Aufbau der Transportverbindung eine gewisse Zeit lang keine H.223 Signalisierung empfangen wird.
  • Falls auf Seiten des IMS die SIP „precondition" Erweiterung nicht unterstützt wird, oder aber auf Seiten des CS-Netzes „forward early media" nicht unterstützt werden, ist es vorteilhaft, wenn der MIK das IMS-seitige Terminal anweist, solange keine Medienströme zu senden, bis die H.223 und H.245 Verhandlung innerhalb der CS-seitigen Transportverbindung abgeschlossen ist. Das IMS-Terminal kann diese Information seinem Benutzer anzeigen, und dadurch ebenfalls „Clipping" vermeiden. Dazu nutzt der MIK erfindungsgemäß die in RFC 3264 beschriebene so genannte „hold" Prozedur, also beispielsweise das SDP „inactive" Attribut. Sobald durch das Öffnen der logischen H.223 Kanäle für Sprache und Video der CS-seitige Aufbau der Transportverbindung abgeschlossen ist, nutzt der MIK dann erfindungsgemäß die „Resume" Prozedur gemäß RFC 3284, um dem IMS-seitigen Terminal das Senden von Medienströmen zu gestatten.
  • Im IMS-T Falle ist es möglich, dass in der Call-Control Signalisierung die Videotelefonie nicht eindeutig erkennbar ist, da nur ein transparenter BS30-Bearer signalisiert wird (z.B. nur Parameter „TMR" mit Wert „UDI" in der „IAM" Nachricht). In diesem Fall bietet der MIK vorzugsweise neben einem Sprach- und einem Video-Codec auf der IMS-Seite auch andere in Frage kommende Daten-Codecs, beispielsweise den so genannten „Clearmode" Codec, IETF RFC 4040, oder einen FAX Codec, beispielsweise im Format von RFC 3362, an. Durch den „Clearmode" Codec wird es möglich, einen BS30-Datendienst transparent durch das IMS weiterzureichen. Die Verwendung des „Clearmode" Codec ist daher auch vorteilhaft, um das Interworking in dem Fall zu erleichtern, dass der Verbindungsaufbau vom IMS zu einem anderen MIK weitergeleitet wird. In einer Ausführungsform konfiguriert der MIK die CS-seitige Transportverbindung zunächst nur für den BS30-Service, und schaltet die Datenverbindung noch nicht durch. Sobald der MIK von der IMS-Seite Signalisierung bezüglich der ausgewählten Codecs erhält, kann der MIK erkennen, ob es sich um Videotelefonie handelt, und startet in diesem Fall die H.223 Inband-Verhandlung. In einer anderen Ausführungsform startet der MIK bereits bei Erhalt der IAM-Nachricht die Inband-Aushandlung mittels H.223 und H.245. Falls der MIK von der IMS-Seite Signalisierung bezüglich der ausgewählten Codecs erhält, und daraus erkennt, dass keine Videotelefonie ausgewählt wurde, beendet der MIK den Versuch der H.223 und H.245 Aushandlung.
  • Nachfolgend wird detailliert der Rufaufbau für verschiedene Szenarien gemäß dem erfindungsgemäßen Verfahren erläutert.
  • 2 zeigt mit Hilfe des Signalisierungsverlaufs das Prinzip des Interworkings zwischen der H.245 Signalisierung und auf der CS-Seite und der SIP/SDP Call Control Signalisierung auf Seiten des IMS durch einen Multimedia Interworking Knoten (MIK), der beispielsweise aus MGCF und IM-MGW bestehen kann, im Falle eines Rufaufbaus von Seiten des CS-Netzes in Richtung des IMS, der im Weiteren als „IMS terminierender" (IMS-T) Rufaufbau bezeichnet wird. Es sind lediglich für die Erfindung direkt relevante Nachrichten dargestellt.
  • Die Signalisierungs-Schritte sind im Einzelnen wie folgt:
    • 1. Der MIK erhält eine so genannte BICC oder ISUP „IAM" Nachricht von der CS-Seite. Der MIK erkennt auf Grund der darin enthaltenen Parameter, dass Videotelephonie gewünscht ist oder gewünscht sein könnte. Die IAM-Nachricht enthält keine Angaben über die für Videotelefonie zu verwendenden Sprach- und Video-Codecs.
    • 2. Der MIK wandelt die IAM Nachricht in eine SIP „INVITE" Nachricht um. Erfindungsgemäß macht der MIK in der darin enthaltenen SDP „offer" Angaben über die Sprach- (im Beispiel AMR) und Video-Codecs (im Beispiel H.263 und MP4V-ES), die wahrscheinlich auf der CS-Seite für die H.324 Videotelephonie unterstützt werden. Bei der Auswahl der Codecs kann der MIK auch berücksichtigen, welche Codecs der Betreiber des IMS-Netzes wünscht, um beispielsweise nicht zu große Bandbreite für die Übertragung an der Luftschnittstelle zu benötigen. Um den Signalisierungsverlauf und die Implementierung einfach zu halten, ist es vorteilhaft, wenn der MIK nur jeweils einen Sprach- und Video-Codec auswählt, der mit großer Wahrscheinlichkeit auch vom Terminal im IMS unterstützt wird, beispielsweise den H.263 und den AMR Codec. Dadurch können Schritte 7, 8, 11 und 12 vermieden werden, falls die gewählten Codecs tatsächlich auf der CS-Seite und im IMS unterstützt werden. Falls der MIK dagegen nicht mit hinreichender Wahrscheinlichkeit weiß, dass jeweils ein bestimmter Sprachcodec und Videocodec auf der CS-Seite und IMS unterstützt wird, ist es sinnvoll, alle in Frage kommenden Codecs aufzunehmen, um zumindest die Nachrichten 7 und 8 mit gewisser Wahrscheinlichkeit zu vermeiden. Es ist vorteilhaft wenn der MIK zusätzlich auch den „clearmode" Codec, RFC 4040, einfügt, um das Interworking in dem Fall zu erleichtern, dass der Verbindungsaufbau vom IMS zu einem anderen MIK weitergeleitet wird. Durch den Clearmode Codec wird es möglich, einen BS30-Datendienst transparent durch das IMS weiterzureichen.
    • 3. Die Transport Verbindung wird auf Seiten des CS-Netzes aufgebaut. Dann findet durch die Transportverbindung die Inband-Verhandlung des H.223 Multiplexer Levels statt und ein logischer H.223 Kanal zum Austausch von H.245 Nachrichten wird geöffnet.
    • 4. Der MIK erwartet in der Transportverbindung eine H.245 „Terminal Capability Set" Nachricht 5. Nur falls er in einer gewissen Zeit diese Nachricht nicht empfängt, beispielsweise weil sich ein weiter MIK auf der CS-Seite befindet, sendet der MIK erfindungsgemäß eine H.245 „Terminal Capability Set" Nachricht, in der er die in Nachricht 2 gesendeten, bzw. falls Nachricht 6 schon eingetroffen ist, in dieser empfangenen Sprachcodecs und Videocodecs angibt.
    • 5. Der MIK enthält in der Transportverbindung eine H.245 „Terminal Capability Set" Nachricht. Darin befinden sich Angaben zu den Fähigkeiten des Terminals auf Seiten des CS-Netzes, unter anderem zu den unterstützten Videocodecs (im Beispiel H.263 und H.261) und Sprachcodecs (im Beispiel G.711 und AMR) unter der genauen Angaben, welche Optionen der einzelnen Codecs unterstützt werden, und welche Codecs parallel unterstützt werden können.
    • 6. Der MIK erhält auf Seiten des IMS eine SIP-Nachricht, die die SDP answer enthält. In der SDP answer sind diejenigen Codecs aus der in Nachricht 2 angebotenen Liste enthalten, die vom Terminal auf Seiten des IMS unterstützt und gewünscht werden, im Beispiel AMR als Sprachcodec und H.263 und MP4V-ES als Videocodecs, aber nicht der Clearmode Codec. Der MIK vergleicht erfindungsgemäß die in Nachrichten 5 und 6 empfangenen Codecs. Falls die Codecs übereinstimmen, oder ihre Schnittmenge (im Beispiel H.263 und AMR) zumindest jeweils mindestens einen für den Betreiber akzeptablen Sprach- und Video-Codec enthält, fährt der MIK direkt mit Schritt 9 fort.
    • 7. Falls in Nachricht 5 im Vergleich zu Nachricht 2 zusätzliche Codecs enthalten waren (Im Beispiel der H.261 Videocodec und der G.711 Sprachcodec), kann der MIK entscheiden, dass es wünschenswert ist, zu überprüfen, ob diese zusätzlichen Codecs auf Seiten des IMS unterstützt werden, beispielsweise weil sie eine höhere Qualität bieten oder vom Betreiber des MIK vorgezogen werden, oder weil die zuvor ermittelte Schnittmenge keinen Sprach- und/oder Video-Codec enthält. Im Beispiel entscheidet der MIK, zu überprüfen, ob der H.261 Videocodec auf Seiten des IMS unterstützt wird. Um eine Überprüfung durchzuführen, sendet der MIK erfindungsgemäß eine geeigneten SIP-Nachricht, beispielsweise einer re-INVITE oder einer UPDATE Nachricht, mit einer SDP offer, die die Codecs der Schnittmenge und zusätzlich die zu überprüfenden Codecs enthält.
    • 8. Falls der MIK Nachricht 7 gesendet hat, empfängt er erneut eine SDP „answer" innerhalb einer SIP Nachricht. In der SDP „answer" sind diejenigen Codecs aus der in Nachricht 6 angebotenen Liste enthalten, die das vom Terminal auf Seiten des IMS unterstützt und gewünscht werden, im Beispiel AMR als Sprachcodec und H.263 und H.261 als Videocodecs.
    • 9. Falls Nachricht 4 nicht gesendet wurde oder die darin enthaltenen Codecs sich von den in Nachricht 8, bzw. falls Schritte 7 und 8 übersprungen wurden, in Nachricht 6 empfangenen Codecs unterscheiden, reicht der MIK erfindungsgemäß die in Nachricht 8, bzw. falls Schritte 7 und 8 übersprungen wurden, in Nachricht 6 empfangenen Sprach- und Video-Codecs sowie die Details der Codec-Konfiguration mittels einer H.245 „Terminal Capability Set" Nachricht weiter. Falls die Schnittmenge der in Nachricht 4 bzw. 9 weitergereichten Codecs und der in Nachricht 5 empfangenen Codecs jeweils nur einen Sprachcodec und Videocodec enthält, ist es vorteilhaft, Schritt 11 parallel zu Schritt 10 durchzuführen.
    • 10. Die so genannte H.245 "Master-Slave-Determination", also die Ermittlung des "Master" bzw. "Slave"-Terminals, wird durchgeführt. Die „Master-Slave-Determination" Nachrichten können auch bereits zusammen mit den „Terminal Capability Set" Nachrichten 5 und 4 bzw. 9 gesendet worden sein. Die "Master-Slave-Determination" ist nur zum Auflösen eines Ressourcenkonflikts relevant und wird daher in dieser Erfindung nicht weiter betrachtet. Mittels H.245 werden dann so genannte logische Kanäle des H.223 Protokolls zum Übertragen der Sprache und Video geöffnet. Dabei wird jeweils ein Sprachcodec und ein Videocodec aus der Schnittmenge der in Nachrichten 5 und 4 bzw. 9 übertragenen Codecs ausgewählt.
    • 11. Falls in Nachricht 6 bzw. 8 noch mehr als ein Sprach oder mehr als ein Videocodec enthalten war, sendet der MIK erfindungsgemäß eine geeignete SIP Nachricht, beispielsweise einer re-INVITE oder einer UPDATE Nachricht, mit einer SDP „offer", in der der MIK den in Schritt 10 ausgewählten Sprach- und Video-Codec angibt.
    • 12. Falls der MIK Nachricht 11 gesendet hat, empfängt er eine SIP-Nachricht, die die zugehörige SDP „answer" enthält.
  • 3 stellt mit Hilfe des Signalisierungsverlaufs das Prinzip des Interworkings zwischen der H.245 Signalisierung und auf der CS-Seite und der SIP/SDP Call Control Signalisierung auf Seiten des IMS durch einen Multimedia Interworking Knoten (MIK), der beispielsweise aus MGCF und IM-MGW bestehen kann, im Falle eines Rufaufbaus von Seiten des IMS in Richtung des CS-Netzes dar, der im Weiteren als „IMS orginierender" (IMS-O) Rufaufbau bezeichnet wird. Es sind lediglich für die Erfindung direkt relevante Nachrichten dargestellt.
  • Die Signalisierungs-Schritte sind im Einzelnen wie folgt:
    • 1. Der MIK erhält eine SIP „INVITE" Nachricht mit einer SDP „offer", die Angaben über die Sprachcodecs (im Beispiel AMR) und Videocodecs (im Beispiel H.263 und MP4V-ES) enthält, die das Terminal auf der IMS-Seite unterstützt und zur Verwendung für diesen Anruf wünscht. Der MIK erkennt an der Kombination aus Videocodecs und Sprachcodecs, dass Videotelefonie gewünscht wird.
    • 2. Der MIK sendet eine so genannte BICC oder ISUP „IAM" Nachricht zur CS-Seite, und gibt darin an, dass Videotelephonie gewünscht wird. Die IAM-Nachricht enthält jedoch keine Angaben über die für Videotelefonie zu verwendenden Sprach- und Video-Codecs.
    • 3. Der MIK sendet auf Seiten des IMS eine SIP-Nachricht, die die SDP answer enthält. Dies ist in vielen Fällen auf Grund von spezifischen Regeln zum Transport von SDP „offer" und „answer" in SIP in RFC 3261 bereits vor dem Aufbau der Transportverbindung auf der CS-Seite in Schritt 4 erforderlich, um den Verbindungsaufbau nicht zu verzögern, und ein sinnvolles Interworking späterer SIP und ISUP/BICC Nachrichten während des Verbindungsaufbaus zu ermöglichen. In der SDP answer fügt der MIK erfindungsgemäß diejenigen Codecs aus der in Nach richt 1 angebotenen Liste ein, die wahrscheinlich auf der CS-Seite für die H.324/M Videotelephonie unterstützt werden (im Beispiel den H.263 Videocodec und den AMR Sprachcodec). Bei der Auswahl der Codecs kann der MIK auch berücksichtigen, welche Codecs der Betreiber des IMS-Netzes wünscht, um beispielsweise nicht zu große Bandbreite für die Übertragung an der Luftschnittstelle zu benötigen. Um den Signalisierungsverlauf und Implementierung einfach zu halten, ist es vorteilhaft, wenn der MIK nur jeweils einen Sprach- und Video-Codec auswählt, beispielsweise den H.263 und den AMR Codec. Dadurch können Schritte 7 und 8 vermieden werden, falls die gewählten Codecs tatsächlich auf der CS-Seite unterstützt werden. Falls der MIK vor Senden von Nachricht 3 schon Nachricht 6 erhalten hat, wählt der MIK aus der Schnittmenge der Codecs in Nachricht 1 und 6 jeweils eine Sprachcodec und Videocodec aus, und fügt diese in Nachricht 3 ein.
    • 4. Die Transport-Verbindung wird auf Seiten des CS-Netzes aufgebaut. Dann findet durch die Transportverbindung die Inband-Verhandlung des H.223 Multiplexer Levels statt und ein logischer H.223 Kanal zum Austausch von H.245 Nachrichten wird geöffnet.
    • 5. Der MIK erwartet in der Transportverbindung eine H.245 „Terminal Capability Set" Nachricht 6. Nur falls er in einer gewissen Zeit diese Nachricht nicht empfängt, beispielsweise weil sich ein weiterer MIK auf der CS-Seite befindet, sendet der MIK erfindungsgemäß eine H.245 „Terminal Capability Set", in der er die in Nachricht 3 gesendeten Sprachcodecs und Videocodecs angibt.
    • 6. Der MIK enthält in der Transportverbindung eine H.245 „Terminal Capability Set" Nachricht. Darin befinden sich Angaben zu den Fähigkeiten des Terminals auf Seiten des CS-Netzes, unter anderem zu den unterstützten Videocodecs (im Beispiel MP4V-ES und H.261) und Sprachcodecs (im Beispiel G.711 und AMR). Der MIK vergleicht erfindungsgemäß die in Nachricht 5 empfangenen Codecs mit den in Nachricht 3 gesendeten Codecs. Falls in Nachricht 3 jeweils nur ein Videocodec und ein Sprachcodec ausgewählt wurden, und diese Codecs in Nachricht 6 enthalten waren, fährt der MIK direkt mit Schritt 9 fort (Im Beispiel ist der in Nachricht 3 gesendete Videocodec H.263 nicht in Nachricht 5 enthalten).
    • 7. Der MIK vergleicht erfindungsgemäß die in Nachricht 6 empfangenen Codecs mit den in Nachricht 1 gesendeten Codecs. Der MIK wählt aus der Schnittmenge der Codecs in Nachrichten 6 und 1 jeweils einen Sprach und Videocodec aus. Der MIK sendet diese Codecs erfindungsgemäß in einer SDP „offer" Nachricht innerhalb einer geeigneten SIP Nachricht, beispielsweise einer re-INVITE oder einer UPDATE Nachricht.
    • 8. Falls der MIK Nachricht 7 gesendet hat, empfängt er erneut eine SDP „answer" innerhalb einer SIP-Nachricht. In der SDP „answer" muss das IMS Terminal die Auswahl der Codecs aus Nachricht 6 bestätigen. Das IMS Terminal wird diese Codecs akzeptieren, da es sie bereits in Nachricht 1 selbst angeboten hat.
    • 9. Falls Nachricht 5 nicht gesendet wurde, reicht der MIK erfindungsgemäß die in Nachricht 7, bzw. falls Schritte 7 und 8 übersprungen wurden, in Nachricht 3 gesendeten Sprach- und Video-Codecs sowie die Details der Codec-Konfiguration mittels einer H.245 „Terminal Capability Set" Nachricht weiter. Falls Nachricht 5 und Nachricht 7 gesendet wurden und die darin enthaltenen Codecs sich unterscheiden, sendet der MIK ebenfalls eine H.245 „Terminal Capability Set" Nachricht und gibt darin die in Nachricht 7 enthaltenen Codecs an.
    • 10. Die so genannte H.245 "Master-Slave-Determination", also die Ermittlung des "Master" bzw. "Slave"-Terminals, wird durchgeführt. Die „Master-Slave-Determination" Nachrichten können auch bereits zusammen mit den „Terminal Capability Set" Nachrichten 6 und 5 bzw. 9 gesendet worden sein. Die "Master-Slave-Determination" ist nur zum Auflösen eines Ressourcenkonflikts relevant und wird daher in dieser Erfindung nicht weiter betrachtet. Mittels H.245 werden dann so genannte logische Kanäle des H.223 Protokolls zum Übertragen der Sprache und Video geöffnet. Dabei werden die bereits in Nach richt 5 bzw. 9 ausgewählten Sprachcodecs und Videocodecs verwendet.
  • 4 stellt mit Hilfe des Signalisierungsverlaufs das Interworking zwischen der BICC Signalisierung auf der CS-Seite und der SIP/SDP Call Control Signalisierung auf Seiten des IMS durch einen Multimedia Interworking Knoten (MIK) im Falle eines IMS terminierenden Rufaufbaus dar. Der MIK kann beispielsweise aus MGCF und IM-MGW bestehen. Im CS-Netz wird „Service Change and UDI Fallback" (SCUDIF) gemäß 3GPP TS 23.172 verwendet. Es wird angenommen, dass das CS-Netz so konfiguriert ist, dass es so genannte „forward early media" unterstützt, d.h. bereits vor der BICC „ANM" Nachricht vom Anrufer gesendete Nutzdaten weitereicht. Auf Seiten des IMS werden die SIP „Preconditions" (IETF RFC 3312), „Update" (IETF RFC 3311) und „100rel" (IETF RFC 3262) Erweiterungen verwendet. Es wird angenommen, dass das IMS Terminal Videotelephonie unterstützt und akzeptiert.
  • Die Signalisierungs-Schritte sind im Einzelnen wie folgt:
    • 1. Der MIK erhält eine so genannte „IAM" Nachricht von der CS-Seite. Gemäß SCUDIF Signalisierung ist darin eine Codecliste enthalten, die für Sprachtelephonie zu verwendende Codecs angibt sowie als Platzhalter für Videotelefonie einen so genannten „MuMe" Dummy-Codec, der lediglich anzeigt, dass Videotelefonie gemäß H.324M unterstützt wird, nicht aber welche Sprachcodecs und Videoodecs in diesem Fall unterstützt werden. Da der MuME Codec als erster Codec in der Codecliste enthalten ist, wird er auf CS-Seite bevorzugt, d.h. Videotelephonie ist gewünscht.
    • 2. Der MIK wandelt die IAM Nachricht in eine SIP „INVITE" Nachricht um. Erfindungsgemäß macht der MIK in der darin enthaltenen SDP „offer" Angaben über die Sprachcodecs (im Beispiel AMR) und Videocodecs (im Beispiel H.263 und MP4V-ES), die wahrscheinlich auf der CS-Seite für die H.324 Videotelephonie unterstützt werden, wie bereits für Schritt 2 in 2 beschrieben. Um einen reibungslosen Rufaufbau auch für den Fall, dass auf Seiten des IMS Sprachtelefonie ausgewählt wird, zu gewährleisten, sollte der MIK erfindungsgemäß als weniger bevorzugte Alternative auch die in Nachricht 1 enthaltenen Sprachcodecs angeben. Der MIK nützt die SIP „Preconditions" Erweiterung, um anzuzeigen, dass lokal ein Aufbau der Transportverbindung erforderlich ist, bevor der Rufaufbau abgeschlossen werden kann. Dieses ist vorteilhaft, um so genanntes „Clipping" zu vermeiden, dass heißt ein Verlust von Sprache oder Video, die durch den Angerufenen gesendet wird, bevor eine durchgängige Transportverbindung vorhanden ist.
    • 3. Eine SIP „Trying" Nachricht quittiert die INVITE Nachricht.
    • 4. Der MIK empfängt von Seiten des IMS eine SIP „183" Nachricht, die die SDP „answer" enthält. In der SDP answer sind diejenigen Codecs aus der in Nachricht 2 angebotenen Liste enthalten, die vom Terminal auf Seiten des IMS unterstützt und gewünscht werden. Der MIK erkennt daran, dass Videocodec(s) enthalten sind, dass Videotelephonie gewünscht ist, und verfährt wie im Detail für Nachricht 5 in 2 beschrieben.
    • 5. Der MIK sendet eine BICC „APM" Nachricht, in der als so genannte „available codec list" der MuMe Codec sowie erfindungsgemäß diejenigen Sprachcodecs enthalten sind, die sowohl in Nachricht 1 wie in Nachricht 4 enthalten waren. Als „selected codec" wird der „MuMe" Codec angegeben. Der MIK entfernt also erfindungsgemäß Sprachcodecs aus Nachricht 4, die nur für Videotelephonie mittels H.324M in Frage kommen, um die Regeln der Out-of-Band BICC Codec-Verhandlung einzuhalten.
    • 6. Gemäß SIP „100rel" Extension bestätigt der MIK den Empfang der 183 Nachricht mit einer SIP „PRACK" Nachricht.
    • 7. Die SIP „PRACK" Nachricht wird bestätigt.
    • 8. Die Transportverbindung wird auf Seiten des CS-Netzes aufgebaut.
    • 9. Falls auf Seiten des CS-Netzes die so genannte „Continuity Check" Prozedur verwendet wird, empfängt der MIK eine so genannte BICC „COT" Nachricht.
    • 10. Durch die Transportverbindung des CS-Netzes findet die Inband-Verhandlung des H.223 Multiplexer Levels sowie die in 2 beschriebene H.245 Verhandlung statt.
    • 11. und 12. Wie in 2 für Nachrichten 7 und 8 beschrieben, kann es während der H.245 Verhandlung zum Senden einer SDP „offer" und „answer" kommen. Sie wird mittels einer SIP „UPDATE" Nachricht (IETF RFC 3311) transportiert.
    • 13. Nach Abschluss der H.245 Inband-Verhandlung signalisiert der MIK erfindungsgemäß mit Hilfe der SIP „Preconditions" Erweiterung, dass der lokale Aufbau der Transportverbindung abgeschlossen ist. Die Nachricht kann mit Nachricht 11 aus 2 verknüpft werden, falls diese erforderlich ist. Eine SIP „UPDATE" Nachricht wird zum Transport des entsprechenden SDPs verwendet.
    • 14. Die SIP „UPDATE" Nachricht wird bestätigt.
    • 15. Eine SIP „Ringing" Nachricht wird empfangen.
    • 16. Die Information aus Nachricht 15. wird als „ACM" Nachricht weitergereicht.
    • 17. Der angerufene Teilnehmer nimmt den Anruf an. Der MIK empfängt eine SIP „200 OK(INVITE)" Nachricht.
    • 18. Die Information aus Nachricht 17. wird als „ANM" Nachricht weitergereicht.
    • 19. Die SIP „200 OK(INVITE)" wird bestätigt.
  • 5 stellt mit Hilfe des Signalisierungsverlaufs das Interworking zwischen der BICC Signalisierung auf der CS-Seite und der SIP/SDP Call Control Signalisierung auf Seiten des IMS durch einen Multimedia Interworking Knoten (MIK) im Falle eines IMS terminierenden Rufaufbaus dar. Der MIK kann beispielsweise aus MGCF und IM-MGW bestehen. Im CS-Netz wird „Service Change and UDI Fallback" (SCUDIF) gemäß 3GPP TS 23.172 verwendet. Auf Seiten des IMS werden die SIP „Preconditions" (IETF RFC 3312), „Update" (IETF RFC 3311) und „100rel" (IETF RFC 3262) Erweiterungen verwendet. Es wird angenommen, dass das IMS Terminal nur Sprachtelephonie unterstützt.
  • Die Signalisierungs-Schritte sind im Einzelnen wie folgt:
    • 1. bis 3. wie in 4 beschrieben.
    • 4. Der MIK empfängt von Seiten des IMS eine SIP „183" Nachricht, die die SDP „answer" enthält. In der SDP answer sind diejenigen Codecs aus der in Nachricht 2 angebotenen Liste enthalten, die vom Terminal von Seiten des IMS unterstützt und gewünscht werden. Der MIK erkennt, dass Sprachtelephonie gewünscht ist, weil nur Sprachcodecs) enthalten sind.
    • 5. Der MIK sendet eine BICC „APM" Nachricht, in der als so genannte „available codec list" erfindungsgemäß diejenigen Sprachcodecs enthalten sind, die sowohl in Nachricht 1 wie in Nachricht 4 enthalten waren. Als „selected codec" wird ein Sprachcodec angegeben. Der MIK entfernt also erfindungsgemäß Sprachcodecs aus Nachricht 4, die nur für Videotelephonie mittels H.324M in Frage kommen, um die Regeln der Out-of-Band BICC Codec-Verhandlung einzuhalten.
    • 6. bis 16. Der Rufaufbau schreitet wie in TS 29.163 beschrieben weiter fort.
  • 6 stellt mit Hilfe des Signalisierungsverlaufs das Interworking zwischen der BICC Signalisierung auf der CS-Seite und der SIP/SDP Call Control Signalisierung auf Seiten des IMS durch einen Multimedia Interworking Knoten (MIK) im Falle eines IMS terminierenden Rufaufbaus dar. Der MIK kann beispielsweise aus MGCF und IM-MGW bestehen. Im CS-Netz wird „Service Change and UDI Fallback" (SCUDIF) gemäß 3GPP TS 23.172 verwendet. Es wird angenommen, dass das CS-Netz so konfiguriert ist, dass es so genannte „forward early media" nicht unterstützt, d.h. vor der BICC „ANM" Nachricht vom Anrufer gesendete Nutzdaten nicht weitereicht. Auf Seiten des IMS werden die SIP „Preconditions" (IETF RFC 3312), „Update" (IETF RFC 3311) und „100rel" (IETF RFC 3262) Erweiterungen verwendet. Es wird angenommen, dass das IMS Terminal Videotelephonie unterstützt und akzeptiert.
  • Die Signalisierungs-Schritte sind im Einzelnen wie folgt:
    • 1. bis 9. Wie in 4 beschrieben.
    • 10. Falls der MIK durch Konfiguration bereits weiß, dass auf Seiten des CS-Netzes keine „forward early Media" unterstützt werden, überspringt er diesen Schritt. Andernfalls wartet er eine gewisse Zeit darauf, in der Transportverbindung H.223 Signalisierung zu empfangen, um H.223 Multiplexer Levels auszuhandeln. Er stellt dann erfindungsgemäß fest, dass keine „forward early Media" unterstützt werden, und fährt, wie im Weiteren beschrieben, fort.
    • 11. Um den Rufaufbau fortzusetzen, signalisiert der MIK erfindungsgemäß mit Hilfe der „Preconditions" Erweiterung, dass der lokale Aufbau der Transportverbindung abgeschlossen ist. Um „Clipping", dass heißt einen Verlust von Sprache oder Video, die durch den Angerufenen gesendet wird, bevor eine durchgängige Transportverbindung vorhanden ist, zu vermeiden, ist es erfindungsgemäß vorteilhaft, wenn der MIK die Medien im SDP wie in RFC 3264 beschrieben auf „hold" setzt, beispielsweise, indem er sie mit dem so genannten „inactive" Attribut versieht. Eine SIP „UPDATE" Nachricht wird zum Transport des entsprechenden SDPs verwendet.
    • 12. Die SIP „UPDATE" Nachricht wird bestätigt.
    • 13. Eine SIP „Ringing" Nachricht wird empfangen.
    • 14. Die Information aus Nachricht 13 wird als „ACM" Nachricht weitergereicht.
    • 15. Der angerufene Teilnehmer nimmt den Anruf an. Der MIK empfängt eine SIP „200 OK(INVITE)" Nachricht.
    • 16. Die SIP „200 OK(INVITE)"-Nachricht wird bestätigt.
    • 17. Die Information aus Nachricht 15 wird als „ANM" Nachricht weitergereicht.
    • 18. Durch die Transportverbindung des CS-Netzes findet die Inband-Verhandlung des H.223 Multiplexer Levels sowie die in 2 beschriebene H.245 Verhandlung statt.
    • 19. bis 20. Wie in 2 für Nachrichten 7 und 8 beschrieben, kann es während der H.245 Verhandlung zum Senden einer SDP „offer" und „answer" kommen. Sie wird mittels einer SIP „re-INVITE" Nachricht transportiert.
    • 21. Die SIP „200 OK(INVITE)" 20 wird bestätigt.
    • 22. Falls der MIK die Medien in Nachricht 11 auf „hold" gesetzt hat, aktiviert er sie nach Abschluss der H.245 Inband-Verhandlung wieder, wie in RFC 3264 beschrieben, beispielsweise in dem er SDP ohne das „inactive" Attribut sendet. Die Nachricht kann mit Nachricht 11 aus 2 verknüpft werden, falls dieses erforderlich ist. Eine SIP „re-INVITE" Nachricht wird zum Transport des entsprechenden SDPs verwendet.
    • 23. Die SIP „re-INVITE" Nachricht wird bestätigt.
    • 24. Die SIP „200 OK(INVITE)" 23 wird bestätigt.
  • 7 stellt mit Hilfe des Signalisierungsverlaufs das Interworking zwischen der BICC Signalisierung und auf der CS-Seite und der SIP/SDP Call Control Signalisierung auf Seiten des IMS durch einen Multimedia Interworking Knoten (MIK) im Falle eines IMS terminierenden Rufaufbaus dar. Der MIK kann beispielsweise aus MGCF und IM-MGW bestehen. Im CS-Netz wird „Service Change and UDI Fallback" (SCUDIF) gemäß 3GPP TS 23.172 verwendet. Auf Seiten des IMS werden die SIP „Preconditions" (IETF RFC 3312) und „Update" (IETF RFC 3311) Erweiterungen nicht genützt, aber die SIP „100rel" (IETF RFC 3262) Erweiterungen wird verwendet. Es wird angenommen, dass das IMS Terminal Videotelephonie unterstützt und akzeptiert.
  • Die Signalisierungs-Schritte sind im Einzelnen wie folgt:
    • 1. Wie in 4.
    • 2. Der MIK wandelt die IAM Nachricht in eine SIP „INVITE" Nachricht um. Erfindungsgemäß macht der MIK in der darin enthaltenen SDP „offer" Angaben über die Sprachcodecs (im Beispiel AMR) und Videocodecs (im Beispiel H.263 und MP4V-ES), die wahrscheinlich auf der CS-Seite für die H.324 Videotelephonie unterstützt werden, wie bereits für Schritt 2 in 2 beschrieben. Um einen reibungslosen Rufaufbau auch für den Fall, dass auf Seiten des IMS Sprachtelefonie ausgewählt wird, zu gewährleisten, sollte der MIK erfindungsgemäß als weniger bevorzugte Alternative auch die in Nachricht 1 enthaltenen Sprachcodecs angeben. Um „Clipping", dass heißt einen Verlust von Sprache oder Video, die durch den Angerufenen gesendet wird, bevor eine durchgängige Transportverbindung vorhanden ist, zu vermeiden, ist es erfindungsgemäß vorteilhaft, wenn der MIK die Medien im SDP wie in RFC 3264 beschrieben auf „hold" setzt, beispielsweise indem er sie mit dem so genannten „inactive" Attribut versieht.
    • 3. bis 10. Wie in 4.
    • 11. bis 15. Wie Nachrichten 15. bis 19. in 4.
    • 16. bis 17. Wie in 2 für Nachrichten 7 und 8 beschrieben, kann es während der H.245 Verhandlung zum Senden einer SDP „offer" und „answer" kommen. Sie wird mittels einer SIP „re-INVITE" Nachricht transportiert.
    • 18. Die SIP „200 OK(INVITE)"-Nachricht wird bestätigt.
    • 19. Falls der MIK die Medien in Nachricht 2 auf „hold" gesetzt hat, aktiviert er sie nach Abschluss der H.245 Inband-Verhandlung wieder, wie in RFC 3264 beschrieben, beispielsweise indem er SDP ohne das „inactive" Attribut sendet. Die Nachricht kann mit Nachricht 11 aus 2 verknüpft werden, falls dieses erforderlich ist. Eine SIP „re-INVITE" Nachricht wird zum Transport des entsprechenden SDPs verwendet.
    • 20. Die SIP „re-INVITE" Nachricht wird bestätigt.
    • 21. Die SIP „200 OK(INVITE)"-Nachricht wird bestätigt.
  • 8 stellt mit Hilfe des Signalisierungsverlaufs das Interworking zwischen der BICC Signalisierung auf der CS-Seite und der SIP/SDP Call Control Signalisierung auf Seiten des IMS durch einen Multimedia Interworking Knoten (MIK) im Falle eines IMS terminierenden Rufaufbaus dar. Der MIK kann beispielsweise aus MGCF und IM-MGW bestehen. Im CS-Netz wird „Service Change and UDI Fallback" (SCUDIF) gemäß 3GPP TS 23.172 verwendet. Auf Seiten des IMS werden die SIP „Preconditions" (IETF RFC 3312), „Update" (IETF RFC 3311) und „100rel" (IETF RFC 3262) Erweiterungen nicht genützt. Es wird angenommen, dass das IMS Terminal Videotelephonie unterstützt und akzeptiert.
  • Die Signalisierungs-Schritte sind im Einzelnen wie folgt:
    • 1. bis 3. Wie in 7.
    • 4. Um den Rufaufbau fortzusetzen, sendet der MIK eine BICC „APM" Nachricht. Zu diesem Zeitpunkt hat der MIK noch keine Kenntnis, ob Videotelefonie auf Seiten des IMS akzeptiert wird, und welche Codecs unterstützt werden. Der MIK nimmt an, dass Videotelefonie akzeptiert wird und wählt Sprachcodecs aus der in Nachricht 1 enthaltenen Liste aus, die wahrscheinlich auf Seiten des IMS unterstützt werden, beispielsweise den „AMR" Codec. Der MIK fügt diese Sprachcodecs und den „MuMe" Codec in die so genannte „available codec list" ein. Als „selected codec" wird der „MuMe" Codec angegeben.
    • 5. bis 9. Wie Nachrichten 8 bis 12 in 7.
    • 10. Der MIK empfängt auf Seiten des IMS eine SIP „200 OK(INVITE)" Nachricht, die die SDP „answer" enthält. In der SDP answer sind diejenigen Codecs aus der in Nachricht 2 angebotenen Liste enthalten, die vom Terminal auf Seiten des IMS unterstützt und gewünscht werden. Der MIK erkennt daran, dass Videocodec(s) enthalten sind, dass Videotelephonie gewünscht ist, und verfährt wie im Detail für Nachricht 5 in 2 beschrieben.
    • 11. bis 18. Wie Nachrichten 14 bis 21 in 7.
  • 9 stellt mit Hilfe des Signalisierungsverlaufs das Interworking zwischen der BICC Signalisierung auf der CS-Seite und der SIP/SDP Call Control Signalisierung auf Seiten des IMS durch einen Multimedia Interworking Knoten (MIK) im Falle eines IMS terminierenden Rufaufbaus dar. Der MIK kann beispielsweise aus MGCF und IM-MGW bestehen. Im CS-Netz wird „Service Change and UDI Fallback" (SCUDIF) gemäß 3GPP TS 23.172 verwendet. Auf Seiten des IMS werden die SIP „Preconditions" (IETF RFC 3312), „Update" (IETF RFC 3311) und „100rel" (IETF RFC 3262) Erweiterungen nicht genützt. Es wird angenommen, dass das IMS Terminal nur Sprachtelephonie unterstützt.
  • Die Signalisierungs-Schritte sind im Einzelnen wie folgt:
    • 1. bis 9. Wie in 9.
    • 10. Der MIK empfängt auf Seiten des IMS eine SIP „200 OK(INVITE)" Nachricht, die die SDP „answer" enthält. In der SDP answer sind diejenigen Codecs aus der in Nachricht 2 angebotenen Liste enthalten, die vom Terminal auf Seiten des IMS unterstützt und gewünscht werden. Der MIK erkennt daran, dass keine Videocodec(s), aber Sprachcodecs enthalten sind, dass Sprachtelephonie gewünscht ist.
    • 11. Der MIK bricht die H.223 und H.245 Verhandlung ab.
    • 12. bis 13. Wie Nachrichten 11 und 12 in 9.
    • 14. Falls der MIK die Medien in Nachricht 2 auf „hold" gesetzt hat, aktiviert er sie nach Abschluss der H.245 Inband-Verhandlung wieder, wie in RFC 3264 beschrieben, beispielsweise indem er SDP ohne das „inactive" Attribut sendet. Eine SIP „re-INVITE" Nachricht wird zum Transport des entsprechenden SDPs verwendet.
    • 15. Die SIP „re-INVITE" Nachricht wird bestätigt.
    • 16. Die SIP „200 OK(INVITE)" 15 wird bestätigt.
    • 17. bis 18. Der MIK nützt die so genannte BICC „Codec Modification" Prozedur, um auf Seiten des CS-Netzes auf Sprachtelefonie umzuschalten.
  • 10 stellt mit Hilfe des Signalisierungsverlaufs das Interworking zwischen der ISUP Signalisierung auf der CS-Seite und der SIP/SDP Call Control Signalisierung auf Seiten des IMS durch einen Multimedia Interworking Knoten (MIK) im Falle eines IMS terminierenden Rufaufbaus dar. Der MIK kann beispielsweise aus MGCF und IM-MGW bestehen. Es wird angenommen, dass das CS-Netz so konfiguriert ist, dass es so genannte „forward early media" unterstützt, d.h. bereits vor der BICC „ANM" Nachricht vom Anrufer gesendete Nutzdaten weitereicht. Auf Seiten des IMS werden die SIP „Preconditions" (IETF RFC 3312), „Update" (IETF RFC 3311) und „100rel" (IETF RFC 3262) Erweiterungen verwendet. Es wird angenommen, dass das IMS Terminal Videotelephonie unterstützt und akzeptiert.
  • Die Signalisierungs-Schritte sind im Einzelnen wie folgt:
    • 1. Der MIK erhält eine so genannte ISUP „IAM" Nachricht von der CS-Seite und erkennt oder vermutet auf Grund der signalisierten Parameter, beispielsweise auf Grund des Wertes „UDI" im Parameter TMR sowie geeignete Werte im Parameter „USI", dass Videotelefonie erwünscht.
    • 2. Der MIK wandelt die IAM Nachricht in eine SIP „INVITE" Nachricht um. Erfindungsgemäß macht der MIK in der darin enthaltenen SDP „offer" Angaben über die Sprach- (im Beispiel AMR) und Videocodecs (im Beispiel H.263 und MP4V-ES), die wahrscheinlich auf der CS-Seite für die H.324 Videotelephonie unterstützt werden, wie bereits für Schritt 2 in 2 beschrieben. Der MIK nützt die SIP „Preconditions" Erweiterung, um anzuzeigen, dass lokal ein Aufbau der Transportverbindung erforderlich ist, bevor der Rufaufbau abgeschlossen werden kann. Dieses ist vorteilhaft, um so genanntes „Clipping" zu vermeiden, dass heißt ein Verlust von Sprache oder Video, die durch den Angerufenen gesendet wird, bevor eine durchgängige Transportverbindung vorhanden ist. Für den Fall, dass der MIK nicht sicher entscheiden kann, ob Videotelefonie oder ein anderer Datendienst gewünscht ist, kann der MIK zusätzlich für andere Datendienste geeignete Codecs einfügen, beispielsweise einen FAX codec „t38" gemäß RFC 3362. Falls das angerufene Terminal nur einen bestimmten Datendienst unterstützt, wird es den entsprechenden Datendienst auswählen. Der Anrufer hat möglicherweise ebenfalls gewusst, dass das Terminal nur diesen bestimmten Datendienst unterstützt, und sendet entsprechend diesen Datendienst.
    • 3. bis 4. Wie in 4.
    • 6. bis 7. Wie Nachrichten 7. bis 8. in 4.
    • 7. bis 17. Wie Nachrichten 9. bis 19. in 4.
  • 11 stellt mit Hilfe des Signalisierungsverlaufs das Interworking zwischen der SIP Signalisierung auf der CS-Seite und der SIP/SDP Call Control Signalisierung auf Seiten des IMS durch einen Multimedia Interworking Knoten (MIK) im Falle eines IMS terminierenden Rufaufbaus dar. Der MIK kann beispielsweise aus MGCF und IM-MGW bestehen. Auf Seiten des IMS werden die SIP „Preconditions" (IETF RFC 3312), „Update" (IETF RFC 3311) und „100rel" (IETF RFC 3262) Erweiterungen nicht genützt. Es wird angenommen, dass das IMS Terminal Videotelephonie unterstützt und akzeptiert.
  • Die Signalisierungs-Schritte sind im Einzelnen wie folgt:
    • 1. bis 3. Wie in 10.
    • 4. bis 16. Wie Nachrichten 6. bis 18. in 8
  • 12 stellt mit Hilfe des Signalisierungsverlaufs das Interworking zwischen der BICC Signalisierung auf der CS-Seite und der SIP/SDP Call Control Signalisierung auf Seiten des IMS durch einen Multimedia Interworking Knoten (MIK) im Falle eines IMS originierenden Rufaufbaus dar. Der MIK kann beispielsweise aus MGCF und IM-MGW bestehen. Im CS-Netz wird „Service Change and UDI Fallback" (SCUDIF) gemäß 3GPP TS 23.172 verwendet. Auf Seiten des IMS werden die SIP „Preconditions" (IETF RFC 3312), „Update" (IETF RFC 3311) und „100rel" (IETF RFC 3262) Erweiterungen verwendet. Es wird angenommen, dass das CS Terminal Videotelephonie unterstützt und akzeptiert.
  • Die Signalisierungs-Schritte sind im Einzelnen wie folgt:
    • 1. Der MIK erhält eine so genannte SIP „INVITE" Nachricht, die eine SDP „offer" enthält. In der SDP offer sind Codecs enthalten, die vom Terminal auf Seiten des IMS unterstützt und die für den Ruf gewünscht werden. Der MIK erkennt daran, dass Videocodec(s) enthalten sind, dass Videotelephonie gewünscht ist, und verfährt wie im Detail für Nachricht 1 in 3 beschrieben.
    • 2. Der MIK sendet eine so genannte „IAM" Nachricht zur CS-Seite. Gemäß SCUDIF Signalisierung ist darin eine Codecliste enthalten, die für Sprachtelephonie zu verwendende Codecs angibt sowie als Platzhalter für Videotelefonie einen so genannten „MuMe" Dummy-Codec, der lediglich anzeigt, dass Videotelefonie gemäß H.324M unterstützt wird, nicht aber welche Sprachcodecs und Videocodecs in diesem Fall unterstützt wer den. Als Sprachcodecs wählt der MIK vorzugsweise die in Nachricht 1 enthaltenen Codecs. Der MIK fügt den MuME Codec als ersten Codec in die Codecliste ein, um auszudrücken, dass Videotelephonie gewünscht ist.
    • 3. Eine SIP „Trying" Nachricht quittiert die INVITE Nachricht.
    • 4. Der MIK empfängt eine BICC „APM" Nachricht, in der als so genannter „selected codec" der „MuMe" Codec angegeben ist. Daraus erkennt der MIK, dass auch das CS Terminal Videotelefonie unterstützt. In der „available codec list" der MuMe Codec sind Sprachcodecs enthalten, die das CS Terminal für Sprachtelefonie unterstützt.
    • 5. Die Transportverbindung wird auf Seiten des CS-Netzes aufgebaut.
    • 6. Der MIK sendet auf Seiten des IMS eine SIP „183" Nachricht, die die SDP „answer" enthält, wie für Nachricht 3 in 3 im Detail beschrieben.
    • 7. Gemäß SIP „100rel" Extension empfängt der MIK eine SIP „PRACK" Nachricht als Bestätigung der 183 Nachricht mit.
    • 8. Die SIP „PRACK" Nachricht wird bestätigt.
    • 9. Der MIC empfängt eine SIP „UPDATE" Nachricht, die mit Hilfe der SIP „Preconditions" Erweiterung anzeigt, dass auf Seiten des IMS Terminals der lokale Aufbau der Transportverbindung abgeschlossen ist.
    • 10. Falls auf Seiten des CS-Netzes die so genannte „Continuity Check" Prozedur verwendet wird, sendet der MIK eine so genannte BICC „COT" Nachricht.
    • 11. Die SIP „UPDATE" Nachricht wird bestätigt.
    • 12. Durch die Transportverbindung des CS-Netzes findet die Inband-Verhandlung des H.223 Multiplexer Levels sowie die in 3 beschriebene H.245 Verhandlung statt.
    • 13. und 14. Wie in 3 für Nachrichten 7 und 8 beschrieben, kann es während der H.245 Verhandlung zum Senden einer SDP „offer" und „answer" kommen. Sie wird mittels einer SIP „UPDATE" Nachricht (IETF RFC 3311) transportiert. Sollte zu diesem Zeitpunkt Nachricht 20 bereits gesendet worden sein, wird statt der „UPDATE" Nachricht eine SIP „re-INVITE" Nachricht verwendet.
    • 15. Eine „ACM" Nachricht wird empfangen.
    • 16. Die Information aus Nachricht 15 wird als SIP „Ringing" Nachricht weitergereicht.
    • 17. Der angerufene Teilnehmer nimmt den Anruf an. Der MIK empfängt eine „ANM" Nachricht Nachricht.
    • 18. Die Information aus Nachricht 17 wird als SIP „200 OK(INVITE)" weitergereicht.
    • 19. Die SIP „200 OK(INVITE)" wird bestätigt.
  • 13 stellt mit Hilfe des Signalisierungsverlaufs das Interworking zwischen der BICC Signalisierung auf der CS-Seite und der SIP/SDP Call Control Signalisierung auf Seiten des IMS durch einen Multimedia Interworking Knoten (MIK) im Falle eines IMS originierenden Rufaufbaus dar. Der MIK kann beispielsweise aus MGCF und IM-MGW bestehen. Im CS-Netz wird „Service Change and UDI Fallback" (SCUDIF) gemäß 3GPP TS 23.172 verwendet. Auf Seiten des IMS werden die SIP „Preconditions" (IETF RFC 3312), „Update" (IETF RFC 3311) und „100rel" (IETF RFC 3262) Erweiterungen verwendet. Es wird angenommen, dass das CS Terminal nur Sprachtelephonie unterstützt und akzeptiert.
  • Die Signalisierungs-Schritte sind im Einzelnen wie folgt:
    • 1. bis 3. Wie 12.
    • 4. Der MIK empfängt eine BICC „APM" Nachricht, in der als „available codec list" nur Sprachcodecs enthalten sind. Daraus erkennt der MIK, dass das CS Terminal nur Sprachtelefonie unterstützt.
    • 5. Die Transportverbindung wird auf Seiten des CS-Netzes aufgebaut.
    • 6. Der MIK sendet auf Seiten des IMS eine SIP „183" Nachricht, die die SDP „answer" für Nachricht 1 enthält. Darin gibt der MIK nur Sprachcodecs an.
    • 7. bis 16. Der Rufaufbau für Sprachtelefonie schreitet wie in TS 29.163 beschrieben voran.
  • 14 stellt mit Hilfe des Signalisierungsverlaufs das Interworking zwischen der BICC Signalisierung auf der CS-Seite und der SIP/SDP Call Control Signalisierung auf Seiten des IMS durch einen Multimedia Interworking Knoten (MIK) im Falle eines IMS originierenden Rufaufbaus dar. Der MIK kann beispielsweise aus MGCF und IM-MGW bestehen. Im CS-Netz wird „Service Change and UDI Fallback" (SCUDIF) gemäß 3GPP TS 23.172 verwendet. Auf Seiten des IMS werden die SIP „Preconditions" (IETF RFC 3312), „Update" (IETF RFC 3311) und „100rel" (IETF RFC 3262) Erweiterungen nicht verwendet. Es wird angenommen, dass das CS Terminal Videotelephonie unterstützt und akzeptiert.
  • Die Signalisierungs-Schritte sind im Einzelnen wie folgt:
    • 1. bis 5. Wie 12
    • 6. Falls auf Seiten des CS-Netzes die so genannte „Continuity Check" Prozedur verwendet wird, sendet der MIK eine so genannte BICC „COT" Nachricht.
    • 7. Durch die Transportverbindung des CS-Netzes findet die Inband-Verhandlung des H.223 Multiplexer Levels sowie die in 3 beschriebene H.245 Verhandlung statt.
    • 8. Eine „ACM" Nachricht wird empfangen.
    • 9. Die Information wird als SIP „Ringing" Nachricht weitergereicht.
    • 10. Der angerufene Teilnehmer nimmt den Anruf an. Der MIK empfängt eine „ANM" Nachricht.
    • 11. Der MIK sendet auf Seiten des IMS eine SIP „200 OK(INVITE)" Nachricht, die die SDP „answer" enthält, wie für Nachricht 3 in 3 im Detail beschrieben.
    • 12. Die SIP „200 OK(INVITE)" wird bestätigt.
    • 13. und 14. Wie in 3 für Nachrichten 7 und 8 beschrieben, kann es während der H.245 Verhandlung zum Senden einer SDP „offer" und „answer" kommen. Sie wird mittels einer SIP „re.INVITE" Nachricht transportiert.
    • 15. Die SIP „200 OK(INVITE)" wird bestätigt.
  • 15 stellt mit Hilfe des Signalisierungsverlaufs das Interworking zwischen der ISUP Signalisierung auf der CS-Seite und der SIP/SDP Call Control Signalisierung auf Seiten des IMS durch einen Multimedia Interworking Knoten (MIK) im Falle eines IMS originierenden Rufaufbaus dar. Der MIK kann beispielsweise aus MGCF und IM-MGW bestehen. Auf Seiten des IMS werden die SIP „Preconditions" (IETF RFC 3312), „Update" (IETF RFC 3311) und „100rel" (IETF RFC 3262) Erweiterungen verwendet. Es wird angenommen, dass das CS Terminal Videotelephonie unterstützt und akzeptiert.
  • Die Signalisierungs-Schritte sind im Einzelnen wie folgt:
    • 1. Wie 12.
    • 2. Der MIK sendet eine so genannte „IAM" Nachricht zur CS-Seite. Der MIK drückt darin aus, dass Videotelephonie gewünscht wird, zum Beispiel durch Wahl von Wert „UDI" für Parameter TMR und geeigneter Werte im Parameter „USI".
    • 3. Wie 12.
    • 4. bis 17. Wie Nachrichten 6 bis 19 in 12.
  • 16 stellt mit Hilfe des Signalisierungsverlaufs das Interworking zwischen der ISUP Signalisierung auf der CS-Seite und der SIP/SDP Call Control Signalisierung auf Seiten des IMS durch einen Multimedia Interworking Knoten (MIK) im Falle eines IMS originierenden Rufaufbaus dar. Der MIK kann beispielsweise aus MGCF und IM-MGW bestehen. Auf Seiten des IMS werden die SIP „Preconditions" (IETF RFC 3312), „Update" (IETF RFC 3311) und „100rel" (IETF RFC 3262) Erweiterungen nicht verwendet. Es wird angenommen, dass das CS Terminal Videotelephonie unterstützt und akzeptiert.
  • Die Signalisierungs-Schritte sind im Einzelnen wie folgt:
    • 1. Wie 14.
    • 2. Der MIK sendet eine so genannte „IAM" Nachricht zur CS-Seite. Der MIK drückt darin aus, dass Videotelephonie gewünscht wird, zum Beispiel durch Wahl von Wert „UDI" für Parameter TMR und geeigneter Werte im Parameter „USI".
    • 3. Wie 14.
    • 4. bis 13. Wie Nachrichten 6 bis 15 in 14.
    • CS
    Circuit Switched Netz
    IMS
    IP Multimedia Gateway
    L1, L2, L3, L4
    Datenverbindungen
    MIK
    Multimedia-Interworking-Knoten
    IMS
    IP Multimedia Subsystem
    IM-MGW
    IMS Media Gateway
    MIK
    Multimedia-Interworking-Knoten
    MGW
    Media Gateway
    MSC
    Mobile Switching Center
    MGCF
    Media Gateway Control Function
    GGSN
    Gateway GPRS Support Node
    CSCF
    Call Session Control Function
    Nb, Mc, Mn, Nc, Gm
    Schnittstellen
    MS1, MS2
    Endgeräte
    UTRAN
    Radiozugangsnetz

Claims (25)

  1. Verfahren zum Aufbau einer Videotelefonverbindung und/oder Multimediatelefonverbindung in einem Datennetz umfassend ein Telefonnetz (CS) und ein auf dem Internet Protokoll basierendes IP-Netz (IMS), bei dem: a) ein Rufaufbau zwischen einem ersten Teilnehmer (MS1), der sich im oder benachbart zum Telefonnetz (CS) befindet, und einem zweiten Teilnehmer (MS2), der sich im oder benachbart zum IP-Netz (IMS) befindet, über das Telefonnetz (CS) und das IP-Netz (IMS) mithilfe eines ersten Signalisierungsprotokolls (BICC) im Telefonnetz (CS) und eines zweiten Signalisierungsprotokolls (SIP) im IP-Netz durchgeführt wird; b) beim Rufaufbau Signalisierungsnachrichten des ersten Signalisierungsprotokolls (BICC) in Signalisierungsnachrichten des zweiten Signalisierungsprotokolls (SIP) und/oder umgekehrt umgewandelt werden; c) bei der Umwandlung in Schritt b) ein oder mehrere Codierungen festgelegt werden, welche bei der Übertragung der während der Videotelefonverbindung ausgetauschten Nutzdaten im Telefonnetz (CS) verwendbar und/oder voraussichtlich verwendbar sind; d) die in Schritt c) festgelegten Codierungen mit einer oder mehreren Signalisierungsnachrichten des zweiten Signalisierungsprotokolls (SIP) in das IP-Netz (IMS) gesendet werden; e) nach und/oder während der Durchführung des Rufaufbaus eine Datenverbindung zur Übertragung der während der Videotelefonverbindung ausgetauschten Nutzdaten aufgebaut wird; f) innerhalb der Datenverbindung auf Seiten des Telefonnetzes (CS) mithilfe eines dritten Signalisierungsprotokolls (H.245) die für die Nutzdaten verwendete Codierung bestimmt wird.
  2. Verfahren nach Anspruch 1, wobei das Datennetz ein 3GPP-Netz (3GPP = 3rd Generation Partnership Project) ist.
  3. Verfahren nach Anspruch 1 oder 2, wobei das Telefonnetz ein CS-Netz (CS = Circuit Switched) und/oder ein PSTN-Netz (PSTN = Public Swiched Telephone Network) ist.
  4. Verfahren nach einem der vorhergehenden Ansprüche, bei dem das erste Signalisierungsprotokoll BICC (BICC = Bearer Independent Call Control) und/oder ISUP (ISUP = ISDN User Part) ist.
  5. Verfahren nach einem der vorhergehenden Ansprüche, bei dem das IP-Netz (IMS) ein IMS-Netz (IMS = IP Multimedia Subsystem) ist.
  6. Verfahren nach einem der vorhergehenden Ansprüche, bei dem das zweite Signalisierungsprotokoll SIP/SDP ist (SIP = Session Initiation Protocol; SDP = Session Description Protocol) ist.
  7. Verfahren nach Anspruch 6, wobei das SIP/SDP-Protokoll die Preconditions-Erweiterung beinhaltet und die Erweiterung verwendet wird, um nach Schritt f) zu signalisieren, dass der Aufbau einer Transportverbindung im Telefonnetz (CS) abgeschlossen ist.
  8. Verfahren nach einem der vorhergehenden Ansprüche, bei dem die Schritte b) bis d) in einem oder mehreren Schnittstellenknoten zwischen dem Telefonnetz (CS) und dem IP-Netz (ISM) durchgeführt werden.
  9. Verfahren nach Anspruch 8, bei dem die Schnittstellenknoten einen MGCF-Knoten (MGCF = Media Gateway Control Function) und einen IM-MGW-Knoten (IM-MGW = IMS Media Gateway) umfassen.
  10. Verfahren nach einem der vorhergehenden Ansprüche, bei dem der Aufbau der Datenverbindung in Schritt e) mithilfe der H.324-Protokollfamilie, insbesondere der H.324M-Protokollfamilie, erfolgt.
  11. Verfahren nach einem der vorhergehenden Ansprüche, wobei das oder die Codierungen in Schritt c) in Abhängigkeit von dem verwendeten Telefonnetz (CS) festgelegt werden.
  12. Verfahren nach einem der vorhergehenden Ansprüche, wobei das oder die Codierungen in Schritt c) in Abhängigkeit von der Rufnummer des ersten Teilnehmers (MS1) festgelegt werden.
  13. Verfahren nach einem der vorhergehenden Ansprüche, bei dem in Schritt c) diejenigen Codierverfahren festgelegt werden, die in Abhängigkeit von dem verwendeten Telefonnetz (CS) und dem verwendeten IP-Netz (ISM) am wahrscheinlichsten in beiden Netzen verwendet werden.
  14. Verfahren nach einem der vorhergehenden Ansprüche, wobei in den Signalisierungsnachrichten des ersten Signalisierungsprotokolls Informationen über im Telefonnetz (CS) verwendbare Sprachcodierungen enthalten sind, wobei in Schritt c) unter anderem diese Sprachcodierungen festgelegt werden.
  15. Verfahren nach einem der vorhergehenden Ansprüche, wobei beim Aufbau der Datenverbindung im Schritt f) eine oder mehrere erste Spezifikations-Nachrichten (TCS) im Telefonnetz (CS) übertragen werden, welche jeweils die im ersten Teilnehmer (MS1) verwendbaren Codierungen spezifizieren.
  16. Verfahren nach Anspruch 15, bei dem die in einer ersten Spezifikations-Nachricht (TCS) spezifizierten Codierungen mit den in Schritt c) festgelegten Codierungen verglichen werden.
  17. Verfahren nach Anspruch 16, bei dem, wenn der Vergleich der in der ersten Spezifikations-Nachricht (TCS) spezifizier ten Codierungen mit den in Schritt c) festgelegten Codierungen ergibt, dass die Codierungen nicht oder nur teilweise übereinstimmen, eine Signalisierungsnachricht des zweiten Signalisierungsprotokolls (SIP) in das IP-Netz gesendet wird, welche zumindest teilweise die in der ersten Spezifikations-Nachricht (TCS) spezifizierten Codierungen enthält.
  18. Verfahren nach einem der vorhergehenden Ansprüche, wobei Signalisierungsnachrichten des zweiten Signalisierungsprotokolls (SIP) im IP-Netz (IMS) übertragen werden, welche die im zweiten Teilnehmer (MS2) verwendbaren Codierungen spezifizieren, wobei die in diesen Signalisierungsnachrichten enthaltenen Codierungen mit einer zweiten Spezifikations-Nachricht beim Aufbau der Datenverbindung in Schritt e) in das Telefonnetz (CS) gesendet werden.
  19. Verfahren nach Anspruch 18 in Kombination mit Anspruch 15, wobei eine Signalisierungsnachricht des zweiten Signalisierungsprotokolls (SIP), welche die im zweiten Teilnehmer (MS2) verwendbaren Codierungen spezifiziert, mit einer ersten Spezifikations-Nachricht verglichen wird und der Aufbau der Videotelefonverbindung abgebrochen wird oder ein Umschalten auf Sprachtelefonie, vorzugsweise mit Hilfe der SCUDIF-"Service Change"-Prozedur gemäß dem 3GPP-Standard 3GPP TS 23.172, veranlasst wird, wenn nicht zumindest eine Übereinstimmung von für eine Videotelefonverbindung erforderlichen Codierungen in der Signalisierungsnachricht und der ersten Spezifikations-Nachricht vorliegt.
  20. Verfahren nach einem der vorhergehenden Ansprüche, bei dem die in Schritt c) festgelegten Codierungen Sprach- und Videocodierungen umfassen.
  21. Verfahren nach Anspruch 20, bei dem die in Schritt c) festgelegten Codierungen neben den Sprach- und Videocodierungen weitere Datencodierungen umfassen.
  22. Verfahren nach einem der vorhergehenden Ansprüche, bei dem der zweite Teilnehmer (MS2) angewiesen wird, keine Nutzdaten zu übertragen, bis ein vorbestimmter Verfahrensabschnitt des Aufbau der Datenverbindung, insbesondere der Aufbau der Transportverbindung im Telefonnetz (CS), abgeschlossen ist.
  23. Datennetz, umfassend ein Telefonnetz (CS) und ein auf dem Internet Protokoll basierendes IP-Netz (IMS), wobei das Datennetz derart ausgestaltet ist, dass ein Verfahren nach einem der vorhergehenden Ansprüche durchführbar ist.
  24. Datennetz nach Anspruch 23, wobei das Datennetz einen oder mehrere Schnittstellenknoten zwischen dem Telefonnetz (CS) und dem IP-Netz (IMS) zur Durchführung der Schritte b) bis d) des Verfahrens nach Anspruch 1 enthält.
  25. Datennetz nach Anspruch 24, wobei die Schnittstellenknoten einen MGCF-Knoten (MGCF = Media Gateway Control Function) und einen IM-MGW-Knoten (IM-MGW = IMS Media Gateway) umfassen.
DE102005050586A 2005-10-21 2005-10-21 Verfahren zum Aufbau einer Videotelefonverbindung und/oder Multimediatelefonverbindung in einem Datennetz Expired - Fee Related DE102005050586B3 (de)

Priority Applications (7)

Application Number Priority Date Filing Date Title
DE102005050586A DE102005050586B3 (de) 2005-10-21 2005-10-21 Verfahren zum Aufbau einer Videotelefonverbindung und/oder Multimediatelefonverbindung in einem Datennetz
US12/083,878 US10075479B2 (en) 2005-10-21 2006-09-08 Method for establishing a video telephone connection and/or a multimedia telephone connection in a data network
CNA2006800392105A CN101292497A (zh) 2005-10-21 2006-09-08 在数据网络中建立视频电话连接和/或多媒体电话连接的方法
PCT/EP2006/066185 WO2007045527A1 (de) 2005-10-21 2006-09-08 Verfahren zum aufbau einer videotelefonverbindung und/oder multimediatelefonverbindung in einem datennetz
EP06793368A EP1938551A1 (de) 2005-10-21 2006-09-08 Verfahren zum aufbau einer videotelefonverbindung und/oder multimediatelefonverbindung in einem datennetz
JP2008535996A JP5237816B2 (ja) 2005-10-21 2006-09-08 データネットワークにおいてビデオ電話コネクションおよび／またはマルチメディア電話コネクションを確立する方法
KR1020087012161A KR101422223B1 (ko) 2005-10-21 2006-09-08 데이터 네트워크에서 비디오 전화 접속 및/또는 멀티미디어전화 접속을 설정하는 방법

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
DE102005050586A DE102005050586B3 (de) 2005-10-21 2005-10-21 Verfahren zum Aufbau einer Videotelefonverbindung und/oder Multimediatelefonverbindung in einem Datennetz

Publications (1)

Publication Number Publication Date
DE102005050586B3 true DE102005050586B3 (de) 2006-11-02

Family

ID=37085301

Family Applications (1)

Application Number Title Priority Date Filing Date
DE102005050586A Expired - Fee Related DE102005050586B3 (de) 2005-10-21 2005-10-21 Verfahren zum Aufbau einer Videotelefonverbindung und/oder Multimediatelefonverbindung in einem Datennetz

Country Status (7)

Country Link
US (1) US10075479B2 (de)
EP (1) EP1938551A1 (de)
JP (1) JP5237816B2 (de)
KR (1) KR101422223B1 (de)
CN (1) CN101292497A (de)
DE (1) DE102005050586B3 (de)
WO (1) WO2007045527A1 (de)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20100118778A1 (en) * 2007-04-02 2010-05-13 Karl-Peter Ranke Improvements in Mobile Technology

Families Citing this family (30)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7953867B1 (en) 2006-11-08 2011-05-31 Cisco Technology, Inc. Session description protocol (SDP) capability negotiation
CN101601269B (zh) * 2006-12-08 2015-11-25 艾利森电话股份有限公司 用户媒体与通告媒体之间切换的方法，系统及通告服务器
KR100977812B1 (ko) * 2007-02-21 2010-08-25 (주) 콜게이트 단문메시지를 이용한 3세대 통신 서비스 제공 방법 및시스템
US8843992B2 (en) * 2007-05-22 2014-09-23 Telefonaktiebolaget L M Ericsson (Publ) Method, apparatuses and computer program for dynamically configuring a proxy call session control function of the IP multimedia subsystem from a policy control rules server
CN101316435B (zh) * 2007-05-31 2012-08-08 华为技术有限公司 呼叫控制的方法和ims的电路交换控制装置及终端设备
US7788383B2 (en) * 2007-10-30 2010-08-31 Cisco Technology, Inc. Communicating a selection of a potential configuration
CN101453706B (zh) * 2007-12-04 2011-03-30 华为技术有限公司 一种多媒体呼叫建立方法、系统和装置
CN101471860B (zh) * 2007-12-27 2011-04-13 华为技术有限公司 一种软交换设备选择呼叫仲裁节点的方法、系统和设备
KR101571723B1 (ko) * 2008-09-02 2015-11-25 엘지전자 주식회사 단말기 및 그 제어 방법
CN101355608B (zh) * 2008-09-11 2011-05-25 中兴通讯股份有限公司 一种实现彩铃ip化的系统及方法
CN101997848B (zh) * 2009-08-14 2015-05-20 中兴通讯股份有限公司 应用服务器呼叫控制中呼叫继续的方法和装置
CN102045298B (zh) * 2009-10-17 2013-12-04 中兴通讯股份有限公司 一种ims媒体编解码器协商的方法和系统
CN101848481B (zh) * 2010-05-12 2012-08-22 杭州东信北邮信息技术有限公司 一种无接入网条件下的bicc业务测试系统和方法
TW201215214A (en) * 2010-07-06 2012-04-01 Interdigital Patent Holdings IP multimedia subsystem (IMS)-based pre-negotiation of video codec for video single radio video call continuity
PL2640052T3 (pl) 2010-11-10 2019-12-31 Panasonic Intellectual Property Corporation Of America Terminal i sposób wyboru trybu kodowania
JP2012105212A (ja) * 2010-11-12 2012-05-31 Ntt Docomo Inc コアネットワークおよび通信システム
JP2012105210A (ja) * 2010-11-12 2012-05-31 Ntt Docomo Inc コアネットワークおよび通信システム
JP2012105211A (ja) * 2010-11-12 2012-05-31 Ntt Docomo Inc コアネットワークおよび通信システム
CN102065095A (zh) * 2010-12-31 2011-05-18 华为技术有限公司 一种建立主被叫间呼叫连接的方法及装置
EP3139696B1 (de) 2011-06-09 2020-05-20 Panasonic Intellectual Property Corporation of America Kommunikationsendgerät und kommunikationsverfahren
GB2494745B (en) * 2011-07-08 2015-11-11 Avaya Inc Negotiate multi-stream continuous presence
DK2822262T3 (da) * 2011-08-17 2019-05-20 Ericsson Telefon Ab L M Mekanisme til dynamisk signalering af koderegenskaber
CN102984493B (zh) * 2012-11-21 2016-03-02 华为终端有限公司 视频数据传输的方法、装置及通信设备
CN103856461A (zh) * 2012-12-04 2014-06-11 联芯科技有限公司 Ims业务实时媒体流的协商式调节方法
EP3145165B1 (de) * 2014-05-13 2019-10-16 Panasonic Intellectual Property Corporation of America Netzwerkknoten und signalisierungsverfahren
US10148703B2 (en) 2014-10-09 2018-12-04 T-Mobile Usa, Inc. Service capabilities in heterogeneous network
US11799922B2 (en) * 2016-12-21 2023-10-24 T-Mobile Usa, Inc. Network core facilitating terminal interoperation
US10771509B2 (en) 2017-03-31 2020-09-08 T-Mobile Usa, Inc. Terminal interoperation using called-terminal functional characteristics
FR3073115A1 (fr) * 2017-10-27 2019-05-03 Orange Procede et entite de gestion d'une session multimedia entre un terminal appelant et au moins un terminal appele, terminal et programme d'ordinateur correspondants.
CN110830748A (zh) * 2019-12-19 2020-02-21 广东以诺通讯有限公司 一种视频通话方法及系统

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2001005109A1 (en) * 1999-07-12 2001-01-18 Telefonaktiebolaget Lm Ericsson Method and system for exchanging information between multimedia network nodes

Family Cites Families (24)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2000307720A (ja) 1999-04-21 2000-11-02 Canon Inc ネットワーク接続装置における音声符号化方法
CN101917745B (zh) * 1999-05-17 2013-05-01 艾利森电话股份有限公司 用于电信网络中的能力协商的系统、设备和方法
JP3764609B2 (ja) 1999-09-08 2006-04-12 株式会社エヌ・ティ・ティ・ドコモ 制御装置、交換機、制御方法および符号化変換方法
CA2419536C (en) 2000-08-14 2009-12-29 Nokia Corporation Communication system and method providing a mode selection procedure
US20020078151A1 (en) * 2000-12-15 2002-06-20 Wickam Bryce C. System for communicating messages of various formats between diverse communication devices
WO2002052811A1 (en) * 2000-12-22 2002-07-04 Nokia Corporation Method and system for modifying a connection parameter
TW583023B (en) * 2000-12-22 2004-04-11 Nippon Kayaku Kk Alkane oxidizing catalyst, method for producing the same and method for producing unsaturated oxygen-containing compound
PT1346557E (pt) * 2000-12-22 2009-07-20 Nokia Corp Método e sistema para estabelecer uma ligação multimédia através da negociação das capacidades num canal de controlo fora da banda
JP4362261B2 (ja) 2002-01-17 2009-11-11 日本電気通信システム株式会社 音声符号制御方法
KR20030089264A (ko) * 2002-05-17 2003-11-21 (주)씨앤에스 테크놀로지 인터넷망과 공중전화망 겸용 영상전화기
US20030236892A1 (en) * 2002-05-31 2003-12-25 Stephane Coulombe System for adaptation of SIP messages based on recipient's terminal capabilities and preferences
US7685315B2 (en) * 2002-10-28 2010-03-23 Nokia Corporation System and method for conveying terminal capability and user preferences-dependent content characteristics for content adaptation
US7353021B2 (en) * 2002-11-14 2008-04-01 Lucent Technologies Inc. Network controller replacement of indication of one or more specific network connections usable by first network component in signaling message for second network component with wild card network connection information
US7443879B2 (en) * 2002-11-14 2008-10-28 Lucent Technologies Inc. Communication between user agents through employment of codec format unsupported by one of the user agents
US7139279B2 (en) 2002-12-12 2006-11-21 Dilithium Networks Pty Ltd. Methods and system for fast session establishment between equipment using H.324 and related telecommunications protocols
GB2417174B (en) * 2003-02-24 2007-01-31 Mitsubishi Electric Corp Communication service unit and connection sequence executing method
US7586857B2 (en) * 2003-04-01 2009-09-08 Alcatel-Lucent Usa Inc. Fast network SIP/SDP procedures for conference operations upon request from end user with optimization of network resources
DE10323403A1 (de) * 2003-05-23 2004-12-09 Siemens Ag Verfahren zur Signalisierung von Anrufumleitungsparametern in einem SIP-Netz
EP1509018A1 (de) 2003-08-18 2005-02-23 Siemens Aktiengesellschaft Verfahren, Software-Produkt und Vorrichtungen zur Signalisierung der Modifikation von Bearerverbindungen mittels SIP Protokoll
US7885208B2 (en) * 2003-09-11 2011-02-08 Nokia Corporation IP-based services for circuit-switched networks
US6924831B2 (en) * 2003-09-12 2005-08-02 Aevoe Incorporated Video telephone integrating public-switch telephone network and asymmetric digital subscriber line
JP2005159581A (ja) 2003-11-21 2005-06-16 Anyuser Global Kk Ｉｐ電話用異種プロトコール（ｓｉｐ／ｈ．３２３）インターワーキング方法
US20060002373A1 (en) * 2004-06-30 2006-01-05 Michael Denny Terminals, methods, systems, and computer program products for providing video communications over a broadband connection based on a call via a PSTN
JP4044082B2 (ja) 2004-09-14 2008-02-06 株式会社東芝 選択装置、変換装置、選択方法、変換方法、コンピュータプログラム

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2001005109A1 (en) * 1999-07-12 2001-01-18 Telefonaktiebolaget Lm Ericsson Method and system for exchanging information between multimedia network nodes

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20100118778A1 (en) * 2007-04-02 2010-05-13 Karl-Peter Ranke Improvements in Mobile Technology
US8457116B2 (en) * 2007-04-02 2013-06-04 Telefonaktiebolaget Lm Ericsson (Publ) Mobile technology

Also Published As

Publication number Publication date
CN101292497A (zh) 2008-10-22
KR20080069617A (ko) 2008-07-28
JP2009512379A (ja) 2009-03-19
WO2007045527A1 (de) 2007-04-26
EP1938551A1 (de) 2008-07-02
JP5237816B2 (ja) 2013-07-17
KR101422223B1 (ko) 2014-07-22
US20090290573A1 (en) 2009-11-26
US10075479B2 (en) 2018-09-11

Similar Documents

Publication Publication Date Title
DE102005050586B3 (de) Verfahren zum Aufbau einer Videotelefonverbindung und/oder Multimediatelefonverbindung in einem Datennetz
DE102005050588B4 (de) Signalisierung bezüglich des Aufbaus von H.324 Videotelefonie zwischen einer Mediagateway und einem Controller
EP1938625B1 (de) Verfahren zum weiterleiten von signalisierungsdaten in einer netzübergangseinheit und in einer steuereinheit
DE60037350T2 (de) Vefahren zur Zusammenarbeit unterschiedlicher IP Telefon-Protokolle
EP2073480B1 (de) Verfahren zur Zuordnung von zumindest einer Nutzdatenverbindung zu zumindest einer Multiplexverbindung
DE102005036298B3 (de) Verfahren und Kommunikationssystem zur Auswahl eines Übertragungsmodus' für eine Übermittlung von Nutzdaten
DE102005031167A1 (de) Verfahren, Server-Einrichtung und Umsetzeinrichtung zum Aufbauen einer Nutzdatenverbindung
WO2005039140A1 (de) Behandlung von early media ii
DE60212988T2 (de) Verfahren, Einrichtung und Computerprogramm zur Auswahl einer Medienübergangskontrollfunktion basierend auf der Überwachung von Resourcen von Medienübergangsfunktionen
WO2006134034A1 (de) Verfahren zur steuerung des leistungsmerkmals 'sip call-transfer'
EP1705889B1 (de) Verfahren zum schnellen Aufbauen einer Nutzdatenverbindung zwischen Kommunikationsendeinrichtungen
WO2005039139A1 (de) Behandlung von early media-daten i
EP1493285B1 (de) Call hold / terminal portability in h.323/isup-bicc-sip netzen
DE102004040480B4 (de) Verfahren und Vorrichtung zum Nutzdatenabgriff multimedialer Verbindungen in einem Paketnetz
EP1430701B1 (de) Verfahren zum steuern von leistungsmerkmalen in paketorientierten kommunikationssystemen
EP1845676A1 (de) Verfahren zur Videotelefonie zwischen einem ersten Endgerät in einem leitungsvermittelten Datennetz und einem zweiten Endgerät in einem paketvermittelten Datennetz
DE102005045121B4 (de) Vorrichtung zur Unterstützung des Leistungsmerkmals "Fall-back" in SIP-Netzen
EP1286508A1 (de) Verfahren zur Übergabe eines Anrufs zwichen einem Telekommunikationsnetzwerk und einem Datennetzwerk
EP1513312A1 (de) Multimediale Videotelephonie
WO2007141190A1 (de) Verfahren zur unterstützung von handoff calls for ims/cs handover in existierenden hybrid ims/cs networks
WO2004047470A1 (de) Übermittlung von sprachdaten in einem mobilfunknetz bestehend aus einem funkzugangsnetz und einem vermittlungsnetz

Legal Events

Date Code Title Description
8100 Publication of patent without earlier publication of application
8364 No opposition during term of opposition
R119 Application deemed withdrawn, or ip right lapsed, due to non-payment of renewal fee