Beschreibung
Verfahren zum Aufbau einer Videotelefonverbindung und/oder Multimediatelefonverbindung in einem Datennetz
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 Videotelefo- nie auch Multimediatelefonie .
Zur Übertragung von Multimedia-Daten ist es aus dem Stand der Technik bekannt, ein Telefonnetz, beispielsweise ein Mobil- funknetz, insbesondere ein GSM- oder UMTS-Mobilfunknetz, mit einem IP-basierten Netz zu verbinden, um über ein derartig kombiniertes Datennetz Sprach- und Videotelefonie effektiv durchzufuhren. Hierbei muss sichergestellt werden, dass die Dienste des Telefonnetzes mit den Diensten des IP-Netzes zu- sammenwirken und insbesondere eine Umwandlung der verwendeten Signalisierungen und des Transportformats der Nutzdaten gewahrleistet ist.
Auf dem Gebiet der 3GPP-Netze (3GPP = 3rd Generation Part- nership 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) spezi- fiziert. Die Spezifikation betrifft jedoch nur reine Sprach- telefonie, 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 ge- lost. Weiterbildungen der Erfindung sind in den abhangigen Ansprüchen definiert.
In dem erfindungsgemaß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 Teilneh- mer ist hierbei insbesondere ein Endgerat zu verstehen, insbesondere ein Mobilfunkendgerat oder ein Festnetzendgerat . Um eine Signalisierung zwischen dem ersten und dem zweiten Sig- nalisierungsprotokoll zu gewahrleisten, werden beim Rufaufbau Signalisierungsnachrichten des ersten Signalisierungsproto- kolls 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 wahrend der Videotelefonverbindung ausgetauschten Nutzda- ten im Telefonnetz verwendbar und/oder voraussichtlich verwendbar sind. Diese Festlegung der Codierungen wird vorgenommen, da bei der Signalisierung mit dem ersten Signalisie- rungsprotokoll im Telefonnetz meist keine Informationen über die verwendbaren Codierungen für die Nutzdaten übermittelt werden. Diese Informationen werden in der Telefonverbindung erst zu einem spateren Zeitpunkt, nämlich beim Aufbau der eigentlichen Datenverbindung zur Übertragung der Nutzdaten, u- bermittelt. Andererseits benotigt ein im IP-Netz verwendetes Signalisierungsprotokoll die Informationen bezuglich verwend- barer Codierungen. Deshalb werden in einem Schritt d) die Codierungen, die in Schritt c) festgelegt wurden, mit einer o- der mehreren Signalisierungsnachrichten des zweiten Signali-
sierungsprotokolls in das IP-Netz gesendet. Anschließend wird nach und/oder wahrend der Durchfuhrung des Rufaufbaus eine Datenverbindung zur Übertragung der wahrend der Videotelefonverbindung ausgetauschten Nutzdaten aufgebaut. Innerhalb der Datenverbindung, insbesondere wahrend 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 erfindungsgemaß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 Signalisierungspro- tokoll verwendet. Somit kann mit dem erfindungsgemaßen Verfahren ein schneller Verbindungsaufbau gewahrleistet werden, da nicht auf den eigentlichen Aufbau der Datenverbindung, in der die tatsachlich im Telefonnetz verwendbaren Codierungen mitgeteilt werden, gewartet werden muss.
Das erfindungsgemaß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 erfindungsgemaßen Verfahren vorzugsweise das aus dem Stand der Technik bekannte BICC-Protokoll (BICC = Bearer Independent CaIl Control) verwendet. Alternativ oder zusatzlich 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 Gate- way) 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 Bewer- ten 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 Sig- nalisierungsnachrichten des ersten Signalisierungsprotokolls derart ausgestaltet sein, dass sie Informationen über im Telefonnetz verwendbare Sprachcodierungen enthalten. Diese Sprachcodierungen werden vorzugsweise ebenfalls bei der Fest- legung 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 Sprachte- lefonie 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 verwendba- ren 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 Ausfuhrungsform eine Signalisierungsnachricht des zweiten Signalisierungsprotokolls in das IP-Netz gesendet, wobei diese Signalisierungsnachricht zumindest teilweise die in der ersten Spezifikations-Nachrichten spezifizierten Codierungen enthalt. Hierdurch wird gewahrleistet, dass eine Datenverbindung auch hergestellt werden kann, wenn die ursprunglich abgeschätzten Codierungen nicht mit den tatsach- lieh verwendbaren Codierungen übereinstimmen.
In einer weiteren bevorzugten Ausfuhrungsform des erfindungs- gemaßen Verfahrens werden Signalisierungsnachrichten des zweiten Signalisierungsprotokolls im IP-Netz übertragen, wo- bei 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 Ausfuhrungsform 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 Auf- baus 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 umfas- sen 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 :
Fig. 1 eine schematische Darstellung einer Ausführungsform eines Datennetzes, in dem das erfin- dungsgemäße Verfahren eingesetzt werden kann;
Fig.2 - Fig.16 Signalisierungsdiagramme, welche den Signali- sierungsverlauf der Nachrichten in den in der Erfindung verwendeten Protokollen für verschie- dene 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 Ent- Wicklungen 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, zwi- sehen 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 Videote- lefonie. 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ötigen- falls 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 zusam- men als „Multimedia-Interworking-Knoten" (MIK) bezeichnet.
Im CS-Netz wird Bearer Independent CaIl 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 Paket- transport mittels Internet Protocol (IP) oder Asynchron
Transfer Modus (ATM) . Die Aushandlung, ob reine Sprachtelefo- nie 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 erfol- gen. 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 Signali- sierung. 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 op- tionalen 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 Ablaufe beim Aufbau einer 3G-324M Verbindung (engl, "session") sind die folgenden:
1. Nach dem Start der ISUP oder BICC Rufaufbausignalisie- rung erfolgt die Reservierung der notwendigen Ressourcen, welche für den gewünschten "Bearer" benotigt wer- den, 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 Endgerates, welches die MuI- tistream-Verbindung eröffnet mittels H.245 Verhandlung, falls erforderlich. Diese Funktion ist nur dann notwendig, falls es zu einem Konflikt im Zusammenhang beim Offnen 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 Endgerats übertragen. Solche Meldungen werden unabhängig von beiden Endgeraten 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 unterstutzt 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 Endgerat bzw. die IM-MGW dazu bereit, "logical Channels" zu offnen, 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 Proto- col" (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 Ver- wendeten Codecs verbunden, und erfolgt vor oder wahrend 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 unterstutzten Codecs. Nach Erhalt dieser Nachricht schickt der Antwortende eine SDP „Answer" Nachricht, die diejenigen Codecs aus der Liste enthalt, die auch er unterstutzt 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 getrenn- te 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) :
CaIl 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) : CaIl 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 Medienstromen 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 a- ber auch andere Codecs von den Endgeraten unterstutzt werden, insbesondere wenn die CS-Endgerate sich im PSTN befinden oder die IMS-Endgerate 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, wurde erhebliche Rechen- leistung und Ressourcen in der IM-MGW erfordern. Zudem wurde 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, wurde auf einer Seite zusatzliche Bandbreite verwendet, ohne dass dadurch die Bild- oder Sprachqualitat verbessern wurde.
Figur 1 zeigt eine typische Netzwerkkofiguration, wie sie in der nachfolgend beschriebenen Ausfuhrungsform der Erfindung verwendet werden kann.
Es ist die Netzwerkkonfiguration dargestellt, die notig ist, damit ein mit der 3GPP CS-Domane verbundenes Terminal in der Form eines mobilen Endgerats MSl mit einem mit dem IMS ver- bundenen Terminal in der Form eines mobilen Endgerats MS2 kommunizieren kann. Die CS-Domane 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-Domane befinden sich im Kernnetz so genannte „Mobile Switching Center" (MSC) -Server, die über BICC Signali- sierung 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" Da- tentransportdienst (engl. „Bearer Service") verwendet. MSl 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 CaIl 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 Endgerat 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 weiter- reicht.
In Fig. 1 bezeichnet somit die Linie Ll, die sich über die beiden MSC-Server zur MGCF erstreckt, die BlCC-Signalisie- rung. 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 ge- nannte „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üh- rungsform 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 ad- ministrative 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üh- rungsform ist vorteilhaft, um die darauf folgenden Signali- sierungsablä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 Op- tionen 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 er- neut 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 mochte.
Im IMS-T Fall sendet der MIK dagegen die abgeschätzten Codecs in einer SDP „offer" und besitzt aus der erhaltenen SDP „ans- wer" nur die Information, welche der zunächst von ihm abgeschätzten Codecs auf der Seite des IMS unterstutzt werden. Es ist also sinnvoll, mittels einer neuen „SDP offer" abzufragen, ob in der ersten SDP „offer" nicht enthaltene Codecs im IMS unterstutzt 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 Capabi- lity 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" Nach- rieht 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, bei- spielsweise 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 erfindungsgemaß 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 erfindungsge- maß 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 unterstutzten Sprachcodecs und Videocodecs ausgewählt. Sollten zu diesem Zeitpunkt auf Seiten des IMS noch mehrere Sprachcodecs oder Vide- ocodecs ausgewählt sein, sendet der MIK erfindungsgemaß 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 durchgangige Transportverbindung vorhanden ist. Falls auf Seiten des IMS die „SIP Preconditions" Erweiterung gemäß IETF RFC 3312 unterstutzt wird, nutzt der MIK die SIP „Preconditions" Erweiterung, um anzuzeigen, dass lokale so genannte „QoS preconditi- ons" vorhanden sind, d.h. ein Aufbau der Transportverbindung erforderlich ist, bevor der Rufaufbau abgeschlossen werden kann. Sobald durch das Offnen der logischen H.223 Kanäle für Sprache und Video der CS-seitige Aufbau der Transportverbindung abgeschlossen ist, nutzt der MIK erfindungsgemaß 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 unterstutzt wird, oder aber auf Seiten des CS-Netzes „forward early media" nicht unterstutzt werden, ist es vorteilhaft, wenn der MIK das IMS-seitige Terminal anweist, solange keine Medienstrome 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 erfindungsgemaß die in RFC 3264 beschriebene so genannte „hold" Prozedur, also beispielsweise das SDP „inactive" Attribut. Sobald durch das Offnen der logischen H.223 Kanäle für Sprache und Video der CS-seitige Aufbau der Transportverbindung abgeschlossen ist, nutzt der MIK dann erfindungsgemaß die „Resume" Prozedur gemäß RFC 3284, um dem IMS-seitigen Terminal das Senden von Medienstro- 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 Inter- working 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 Videote- lefonie 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.
Figur 2 zeigt mit Hilfe des Signalisierungsverlaufs das Prinzip des Interworkings zwischen der H.245 Signalisierung und auf der CS-Seite und der SIP/SDP CaIl 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. Erfindungsgemaß 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 unterstutzt 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 benotigen. 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 unterstutzt 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 tatsachlich auf der CS-Seite und im IMS unterstutzt werden. Falls der MIK dagegen nicht mit hinreichender Wahrscheinlichkeit weiß, dass jeweils ein bestimmter Sprachcodec und Videocodec auf der CS-Seite und IMS unterstutzt 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 zusatzlich auch den „clearmo- de" Codec, RFC 4040, einfugt, 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 In- band-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 empfangt, beispielsweise weil sich ein weiter MIK auf der CS-Seite befindet, sendet
der MIK erfindungsgemaß 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 enthalt 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 unterstutzten 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 unterstutzt werden, und welche Codecs parallel unterstutzt werden können.
6. Der MIK erhalt auf Seiten des IMS eine SIP-Nachricht, die die SDP answer enthalt. In der SDP answer sind diejenigen Co- decs aus der in Nachricht 2 angebotenen Liste enthalten, die vom Terminal auf Seiten des IMS unterstutzt 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 erfindungsgemaß die in Nachrichten 5 und 6 empfange- nen 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 enthalt, fahrt der MIK direkt mit Schritt 9 fort.
7. Falls in Nachricht 5 im Vergleich zu Nachricht 2 zusatzli- che 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 zusatzlichen Codecs auf Seiten des IMS unterstutzt 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 enthalt. Im Beispiel entscheidet der MIK, zu überprüfen, ob der H.261 Videocodec auf Seiten des IMS unterstutzt wird. Um eine Überprüfung durchzufuhren, sendet der MIK erfindungsgemaß eine geeigneten SIP-Nachricht, beispielsweise einer re-INVITE oder einer UPDATE Nachricht, mit einer SDP offer, die die Codecs
der Schnittmenge und zusatzlich die zu überprüfenden Codecs enthalt .
8. Falls der MIK Nachricht 7 gesendet hat, empfangt 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 unterstutzt 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 ent- haltenen Codecs sich von den in Nachricht 8, bzw. falls
Schritte 7 und 8 übersprungen wurden, in Nachricht 6 empfangenen Codecs unterscheiden, reicht der MIK erfindungsgemaß 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 enthalt, ist es vorteilhaft, Schritt 11 parallel zu Schritt 10 durchzufuhren.
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 Auflosen 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 erfin- dungsgemaß 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.
Figur 3 stellt mit Hilfe des Signalisierungsverlaufs das Prinzip des Interworkings zwischen der H.245 Signalisierung und auf der CS-Seite und der SIP/SDP CaIl 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 orginieren- der" (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" Nach- rieht 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-
rieht 1 angebotenen Liste ein, die wahrscheinlich auf der CS- Seite für die H.324/M Videotelephonie unterstutzt 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 benotigen.
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 tatsachlich auf der CS- Seite unterstutzt 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 fugt diese in Nachricht 3 ein.
4. Die Transport-Verbindung wird auf Seiten des CS-Netzes aufgebaut. Dann findet durch die Transportverbindung die In- band-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 empfangt, beispielsweise weil sich ein weiterer MIK auf der CS-Seite befindet, sendet der MIK erfindungsgemaß eine H.245 „Terminal Capability Set", in der er die in Nachricht 3 gesendeten Sprachcodecs und Videocodecs angibt. 6. Der MIK enthalt 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 unterstutzten Videocodecs (im Beispiel MP4V-ES und H.261) und Sprachcodecs (im Beispiel G.711 und AMR) . Der MIK vergleicht erfindungsgemaß 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, fahrt 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 erfindungsgemaß 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 erfindungsgemaß 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, empfangt 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 er- findungsgemaß 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 Auflosen eines Ressourcenkonflikts relevant und wird daher in dieser Erfindung nicht weiter betrachtet. Mittels H.245 werden dann so genann- te logische Kanäle des H.223 Protokolls zum Übertragen der
Sprache und Video geöffnet. Dabei werden die bereits in Nach-
rieht 5 bzw. 9 ausgewählten Sprachcodecs und Videocodecs verwendet .
Figur 4 stellt mit Hilfe des Signalisierungsverlaufs das In- terworking zwischen der BICC Signalisierung auf der CS-Seite und der SIP/SDP CaIl 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 „lOOrel" (IETF RFC 3262) Erweiterungen verwendet. Es wird angenommen, dass das IMS Terminal Videote- lephonie 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. Videote- lephonie 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 Videotele- phonie unterstützt werden, wie bereits für Schritt 2 in Figur 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 „Precon- ditions" 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 Figur 2 be- schrieben.
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 „se- lected 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 „lOOrel" 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 Figur 2 beschriebene H.245 Verhandlung statt.
11. und 12. Wie in Figur 2 für Nachrichten 7 und 8 beschrie- ben, 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" Er- Weiterung, dass der lokale Aufbau der Transportverbindung abgeschlossen ist. Die Nachricht kann mit Nachricht 11 aus Figur 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.
Figur 5 stellt mit Hilfe des Signalisierungsverlaufs das In- terworking zwischen der BICC Signalisierung auf der CS-Seite und der SIP/SDP CaIl Control Signalisierung auf Seiten des IMS durch einen Multimedia Interworking Knoten (MIK) im Falle eines IMS terminierenden Rufaufbaus dar. Der MIK kann bei- spielsweise 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 „lOOrel" (IETF RFC 3262) Erweiterungen verwendet. Es wird an- genommen, dass das IMS Terminal nur Sprachtelephonie unterstützt .
Die Signalisierungs-Schritte sind im Einzelnen wie folgt: 1. bis 3. wie in Figur 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 Sprachcodec (s) 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.
Figur 6 stellt mit Hilfe des Signalisierungsverlaufs das In- terworking zwischen der BICC Signalisierung auf der CS-Seite und der SIP/SDP CaIl Control Signalisierung auf Seiten des IMS durch einen Multimedia Interworking Knoten (MIK) im Falle eines IMS terminierenden Rufaufbaus dar. Der MIK kann bei- spielsweise 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 An- rufer gesendete Nutzdaten nicht weitereicht. Auf Seiten des IMS werden die SIP „Preconditions" (IETF RFC 3312), „Update" (IETF RFC 3311) und „lOOrel" (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 Figur 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 er- findungsgemäß 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
Figur 2 beschriebene H.245 Verhandlung statt.
19. bis 20. Wie in Figur 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 Figur 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.
Figur 7 stellt mit Hilfe des Signalisierungsverlaufs das In- terworking zwischen der BICC Signalisierung und auf der CS- Seite und der SIP/SDP CaIl 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 „Precon- ditions" (IETF RFC 3312) und „Update" (IETF RFC 3311) Erwei- terungen nicht genützt, aber die SIP „lOOrel" (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 Figur 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 Figur 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 Figur 4.
11. bis 15. Wie Nachrichten 15. bis 19. in Figur 4. 16. bis 17. Wie in Figur 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 Figur 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.
Figur 8 stellt mit Hilfe des Signalisierungsverlaufs das In- terworking zwischen der BICC Signalisierung auf der CS-Seite und der SIP/SDP CaIl 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 „Precon- ditions" (IETF RFC 3312), „Update" (IETF RFC 3311) und „lOOrel" (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 Figur 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 „Mu- Me" 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 Figur 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 an- gebotenen 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 Figur 2 beschrieben. 11. bis 18. Wie Nachrichten 14 bis 21 in Figur 7.
Figur 9 stellt mit Hilfe des Signalisierungsverlaufs das In- terworking zwischen der BICC Signalisierung auf der CS-Seite und der SIP/SDP CaIl 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 „Precon- ditions" (IETF RFC 3312), „Update" (IETF RFC 3311) und
„lOOrel" (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 Figur 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 Figur 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 entsprechen- den 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 Modifi- cation" Prozedur, um auf Seiten des CS-Netzes auf Sprachtele- fonie umzuschalten.
Figur 10 stellt mit Hilfe des Signalisierungsverlaufs das In- terworking zwischen der ISUP Signalisierung auf der CS-Seite und der SIP/SDP CaIl 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 „lOOrel" (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 Figur 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 Figur 4.
6. bis 7. Wie Nachrichten 7. bis 8. in Figur 4. 7. bis 17. Wie Nachrichten 9. bis 19. in Figur 4.
Figur 11 stellt mit Hilfe des Signalisierungsverlaufs das In- terworking zwischen der SIP Signalisierung auf der CS-Seite und der SIP/SDP CaIl 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 „lOOrel" (IETF RFC 3262) Erweiterungen nicht genützt. Es wird angenommen, dass das IMS Terminal Vi- deotelephonie unterstützt und akzeptiert.
Die Signalisierungs-Schritte sind im Einzelnen wie folgt:
1. bis 3. Wie in Figur 10.
4. bis 16. Wie Nachrichten 6. bis 18. in Figur 8
Figur 12 stellt mit Hilfe des Signalisierungsverlaufs das In- terworking zwischen der BICC Signalisierung auf der CS-Seite und der SIP/SDP CaIl Control Signalisierung auf Seiten des IMS durch einen Multimedia Interworking Knoten (MIK) im Falle eines IMS originierenden Rufaufbaus dar. Der MIK kann bei- spielsweise 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 „Precon- ditions" (IETF RFC 3312), „Update" (IETF RFC 3311) und „lOOrel" (IETF RFC 3262) Erweiterungen verwendet. Es wird an- genommen, 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 Figur 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 ge- nannten „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 Videotele- fonie 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 Figur 3 im Detail beschrieben.
7. Gemäß SIP „lOOrel" 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 „Continui- ty 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
Figur 3 beschriebene H.245 Verhandlung statt.
13. und 14. Wie in Figur 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.
Figur 13 stellt mit Hilfe des Signalisierungsverlaufs das In- terworking zwischen der BICC Signalisierung auf der CS-Seite und der SIP/SDP CaIl 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 „Precon- ditions" (IETF RFC 3312), „Update" (IETF RFC 3311) und
„lOOrel" (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 Figur 12.
4. Der MIK empfängt eine BICC „APM" Nachricht, in der als „a- vailable codec list" nur Sprachcodecs enthalten sind. Daraus erkennt der MIK, dass das CS Terminal nur Sprachtelefonie un- terstü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.
Figur 14 stellt mit Hilfe des Signalisierungsverlaufs das In- terworking zwischen der BICC Signalisierung auf der CS-Seite und der SIP/SDP CaIl 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 „Precon- ditions" (IETF RFC 3312), „Update" (IETF RFC 3311) und
„lOOrel" (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:
I. bis 5. Wie Figur 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 Figur 3 beschriebene H.245 Verhandlung statt.
8. Eine „ACM" Nachricht wird empfangen.
9. Die Information wird als SIP „Ringing" Nachricht weiterge- reicht.
10. Der angerufene Teilnehmer nimmt den Anruf an. Der MIK empfängt eine „ANM" Nachricht.
II. 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 Figur 3 im Detail beschrieben.
12. Die SIP „200 OK(INVITE)" wird bestätigt.
13. und 14. Wie in Figur 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.
Figur 15 stellt mit Hilfe des Signalisierungsverlaufs das In- terworking zwischen der ISUP Signalisierung auf der CS-Seite und der SIP/SDP CaIl 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 „lOOrel" (IETF RFC 3262) Erweiterungen verwendet. Es wird angenommen, dass das CS Terminal Videote- lephonie unterstützt und akzeptiert.
Die Signalisierungs-Schritte sind im Einzelnen wie folgt:
1. Wie Figur 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 Figur 12.
4. bis 17. Wie Nachrichten 6 bis 19 in Figur 12.
Figur 16 stellt mit Hilfe des Signalisierungsverlaufs das Interworking zwischen der ISUP Signalisierung auf der CS-Seite und der SIP/SDP CaIl 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 „lOOrel" (IETF RFC 3262) Erweiterungen nicht verwendet. Es wird angenommen, dass das CS Terminal Vi- deotelephonie unterstützt und akzeptiert.
Die Signalisierungs-Schritte sind im Einzelnen wie folgt:
1. Wie Figur 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 Figur 14.
4. bis 13. Wie Nachrichten 6 bis 15 in Figur 14.