„Signalisierung bezüglich des Aufbaus von H.324 Videotelefo- nie zwischen einer Mediagateway und einem Controller"
Die Erfindung betrifft Verfahren und Vorrichtungen zum Ruf- aufbau einer Telekommunikationsverbindung.
Neben der so genannten „Circuit Switched (CS) Domain" eines auf dem 3rd Generation Partnership Project (3GPP) basierendem Mobilfunknetzes, kann auch das so genannte "IP Multimedia Subsystem" (IMS) für Sprach- und Videotelefonie genützt werden, und ein so genanntes „Interworking" der betreffenden Dienste, 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 „Global System for Mobile Communications" (GSM) und „Universal Mobile Telecommunications System" (UMTS) Zugangsnetzen auch für andere Zugangsnetze verwendet, beispielsweise „Wireless Local Area Network" (WLAN) und „Digital Subscriber Line" (DSL) . Ge- rade in diesen Szenarien ist zuerst zu erwarten, dass Sprach- und Videotelefonie über das IMS erfolgen. Videotelefonie kann auch in einem öffentlichen Telefonnetz, d.h. einem so genannten „Public Switched Telephone Network (PSTN)", genützt werden, wobei hier in der Regel für Transport und Signalisierung dieselben inband Videotelefonie spezifischen Protokolle wie in der 3GPP CS Domain genützt werden. Auch vom PSTN ist ein Interworking zum IMS erforderlich.
Bisher ist lediglich ein Interworking zwischen IMS und CS Do- main oder PSTN nur für Sprachtelefonie im Standard beschrieben. Die vorliegende Erfindung betrifft das entsprechende Interworking von Videotelefonie . Ein Bedarf dafür ist abzusehen, da sowohl in der 3GPP CS Domain wie auch in IMS, hier
besonders für Zugangsnetze wie WLAN oder DSL, bzw. neu entstehende Netz-Zutrittsmöglichkeiten (z.B. Worldwide Interope- rability for Microwave Access (WiMAX) , Videotelefonie an Bedeutung gewinnt.
Das Interworking zwischen IMS 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 ge- nannten „Internet Multimedia - Media Gateway" (IM-MGW) . Die MGCF kontrolliert die IM-MGW mittels des von der ITU-T standardisierten H.248 Protokolls über die so genannte „Mn" Schnittstelle, wie in 3GPP TS 29.332 weiter beschrieben wird.
Im CS Netz wird Bearer Independent CaIl Control (BICC) oder
ISDN User Part (ISUP) zur Call-Control Signalisierung verwendet. In jenem Fall, wenn die Call-Control Signalisierung getrennt von den Transportverbindungen geführt werden, wird diese Methode auch als "out-of-band" Signalisierung bezeich- net. 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 genützt, und im Falle von BICC Pa- kettransport 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 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 Wech- sei zwischen Sprachtelefonie und Videotelefonie ermöglicht. Sowohl „UDI Fallback" wie SCUDIF nützen out-of-band Signalisierung. Daneben ist es für ISUP wie BICC möglich, die genannten Prozeduren nicht zu verwenden, und einen Call-Aufbau nur für Videotelefonie zu versuchen, und im Falle, dass Vide- otelefonie nicht unterstützt wird, den Call-Aufbau 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 Vi- deotelefonie 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 Aufbau der Datenverbindung wird hierbei die Konfiguration der Multimedia-Verbindung inband ü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 Rufaufbausignalisie- rung, erfolgt die Reservierung der notwendigen Ressourcen welche für den gewünschten "Bearer" benotigt werden und in weiterer Folge der Aufbau der Transportverbin- düng.
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 notwendig. 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 werden die Fähigkeiten des die Nachricht sendenden Endgerats übertragen. Solche Meldungen werden unabhängig von beiden Endgeraten gesendet. Diese be- schriebenen 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 mobil 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 be- reit, "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 "media capabilities" festgelegt.
6. Definition der Multiplexeigenschaften mittels H.245.
7. Start der Übermittlung von Video, Audio/Sprache oder Da- ten
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 „Ses- sion 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 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 be- nutzen 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 über das General Packet Radio Service (GPRS) Zugangsnetz beschreibt 3GPP TS 26.235 die für Videotelefonie zu verwendenden Codecs.
Im Folgenden werden die auf Seiten der CS Domain und auf Sei- ten 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 inband 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 glei- chen 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 Rechenleistung 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-Domaine und dem IMS unterschiedlich sind, wurde auf einer Seite zusatzliche Bandbreite verwendet, ohne dass dadurch die Bild- oder Sprachqualitat verbessern wurde.
Dazu ist es erforderlich, dass die MGCF und die IM-MGW geeignete Informationen austauschen bezuglich der Aushandlung der
Sprach- und Videocodecs mittels H.245 und SIP/SDP und bezüglich des Aufbaus der Transportverbindung mittels H.223.
Ein Verfahren, zum Austausch geeignete Informationen bezüg- lieh der Aushandlung der Sprach- und Videocodecs mittels
H.245 und des Aufbaus der Transportverbindung mittels H.223 zwischen MGCF und IM-MGW ist Gegenstand der vorliegenden Erfindung. Dadurch wird ein Transkodieren für Videotelefonie weitgehend vermieden. Die MGCF und die IM-MGW verbinden ein CS Netz, also einem PSTN oder einer 3GPP CS Domain, sowie ein IP Netz, das SIP und SDP zur Aushandlung der Codecs verwenden, also beispielsweise dem IMS.
Eine Aufgabe der Erfindung ist es möglichst effizient einen Aufbau einer geeigneten Telekommunikationsverbindung über ein leitungsvermitteltes Netz und ein IMS Netz zu unterstützen und eine Videotelefonie-Transcodierung möglichst zu vermeiden. Die Aufgabe wird durch die unabhängigen Patentansprüche gelöst. Vorteilhafte Ausführungsformen sind in den Unteran- Sprüchen angegeben.
Erfindungsgemäß befindet sich der so genannte „H.245 Client", also die funktionale Einheit die das H.245 Protokoll termi- niert, in der IM-MGW. Der H.245 Client tauscht Informationen bezüglich der Auswahl der Codecs und des Ablaufs des Rufaufbaus mit den für den so genannten „Call Control" zuständigen funktionalen Komponenten in der MGCF aus, vorzugsweise mit der oder den funktionalen Komponente (n) , die auf der Seite des IMS für die Behandlung des SIP und des SDP zuständig sind. Dazu wird das Protokoll der ,,Mn" Schnittstelle geeignet erweitert .
Der Kern der Erfindung ist der Folgende:
Beispielsweise wenn die MGCF beim Rufaufbau aus der CaIl Control Signalisierung erkennt oder vermutet, dass auf der CS Seite Videotelefonie gemäß des H.324 gewünscht ist, weist die MGCF die IM-MGW an:
• Die H.223 Verhandlung des so genannten „Multiplex Le- vels" eigenständig durchzufuhren, und
• Die für den Aufbau von H.324 Videotelefonie notige H.245 Verhandlung durchzufuhren, und • Die MGCF zu informieren, so bald logische H.223 Kanäle mittels H.245 geöffnet werden, Und die IM-MGW fuhrt die entsprechenden Anweisungen aus.
Vorzugsweise konfiguriert die MGCF die IM-MGW entsprechend mittels so genannter H.248 „Add" oder „Modify" Nachrichten, beispielsweise wenn sie die für die Behandlung des gemultip- lexten H.223 Protokolls zustandige so genannte „Termination" einrichtet. Vorzugsweise fugt die MGCF in diese Nachrichten ein oder mehrere neu zu standardisierende so genannte H.248 „Signals" ein, die ausdrucken, dass die H.223 und/oder H.245 Verhandlung durchgeführt werden soll.
Um eine Benachrichtigung über den Aufbau von logischen H.223 Kanälen zu verlangen, nutzt die MGCF vorzugsweise ein dazu neu zu standardisierendes so genanntes H.248 „Event", das die MGCF vorzugsweise in dieselbe H.248 Nachricht einfugt. Wenn im Folgenden ein logischer H.223 Kanal mittels H.245 Signalisierung geöffnet wird, nutzt die IM-MGW erfindungsgemaß eine so genannte H.248 „Notify" Nachricht, in der sie das neu definierte „Event" angibt.
Es ist vorteilhaft, wenn die IM-MGW in der Benachrichtigung über das Offnen eines logischer H.223 Kanals den ausgewählten Codec sowie die so genannte „logical Channel Number" angibt,
vorzugsweise als Parameter des bei der Benachrichtigung verwendeten Events. Die MGCF diese Information erfindungsgemäß, um die IM MGW so zu konfiguriert, dass die den Medienstrom zwischen der Seite des CS Netzes und der Seite des IMS durch- reicht. Die MGCF gibt für beide Seiten an, welche Codecs gewählt wurden. Auf der Seite des CS Netzes ist gemäß bestehenden H.248 Standard die Angabe „logical Channel Number" erforderlich. Wenn auf beiden Seiten derselbe Codec in derselben Konfiguration gewählt wurden, braucht die IM-MGW keinen Transkoder verwenden.
Es ist vorteilhaft wenn die IM-MGW die MGCF auch benachrichtigt, wenn die H.223 Verhandlung des Multiplex Levels" beendet ist bzw. wenn diese Verhandlung fehlgeschlagen ist. Die MGCF kann am Ausbleiben der Benachrichtigung feststellen oder mit Hilfe einer Fehlermeldung feststellen, dass die CS- seitige Transportverbindung nicht oder noch nicht für Video- telefonie genützt wird und darauf in der Call-Control Signalisierung reagieren, beispielsweise durch Umkonfigurieren des Rufs auf einen anderen Dienst wie Sprachtelephonie oder Beenden der Verbindung.
Um eine Benachrichtigung über das Ergebnis der H.223 Verhandlung des Multiplex Levels" zu verlangen, nützt die MGCF vorzugsweise ein dazu neu zu standardisierendes so genanntes H.248 „Event", das die MGCF vorzugsweise ebenfalls in die H.248 Nachricht zum Starten der H.223 Verhandlung einfügt. Wenn im Folgenden die Verhandlung beendet ist, nützt die IM- MGW erfindungsgemäß eine so genannte H.248 „Notify" Nachricht, in der sie das neu definierte „Event" angibt.
Im Falle eines Rufaufbaus von Seiten des CS Netzes in Richtung des IMS kann es vorkommen, dass der Verbindungsaufbau vom IMS zu einem anderen MGCF weitergeleitet wird. In diesem
Fall ist es vorteilhaft, wenn die MGCF die IM-MGW so konfiguriert, dass sie den BS30 Datendienst transparent weiterreicht, zum Beispiel unter Verwendung des so genannten „Clearmode" Codecs, IETF RFC 4040. Die MGCF handelt mittels der mit der anderen MGCF ausgetauschten SIP/SDP Signalisierung den transparenten Transport des Datendienstes aus. In einer Ausführungsform konfiguriert die MGCF die IM MGW zunächst nur für den BS30 Service, und schaltet die Datenverbindung noch nicht durch. Sobald die MGCF von der Seite des IMS Signalisierung bezüglich der ausgewählten Codecs erhält, kann die MGCF erkennen, ob es sich um Videotelefonie handelt, und konfiguriert in diesem Fall die IM-MGW so, dass sie die Inband H.223 Aushandlung startet. Falls dagegen ein transparenter Transport ausgewählt wird, ist keine Umkonfiguration der IM-MGW erforderlich.
Die IM-MGW führt die H.245 Prozeduren zur so genannten „Master Slave Determination" vorzugsweise selbstständig durch.
In einer einfachen Ausführungsform sendet und empfängt die
IM-MGW auch die so genannten H.245 „Terminal-Capability Set" Nachrichten selbstständig. Diese beinhaltet Informationen unter anderem über unterstütze Audio und Video Codecs und deren spezifischen Eigenschaften sowie über den funktionaler Umfang des Multiplexers, (z. B welcher Adaptions-Layer unterstützt wird, die unterstütze Verschachtelungstiefe des MuI- tiplexings, also so genanntes „simple" oder „nested" MuI- tiplexing und Angaben über mobil spezifische Erweiterungen) . Die IM-MGW gibt in der gesendeten „Terminal-Capability Set" Nachricht vorkonfigurierte Werte an, die ihre eignen Fähigkeiten wiederspiegeln.
In einer einfacheren Ausfuhrungsform wird auf die Übermittelung von Codecs zwischen der MGCF und der IM-MGW verzichtet, und MGCF und IM-MGW sind so konfiguriert, dass sie die selben Sprach-und-VideoCodecs in der SIP/SDP out-of-band Verhandlung auf Seiten des IMS bzw. in der H.245 Inband Verhandlung auf Seiten des CS Networks auswählen. Diese Ausfuhrungsform 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 unterstutzt werden müssen.
In einer alternativen Ausfuhrungsform tauscht die IM-MGW jedoch Informationen bezuglich der unterstutzen Codecs mit der MGCF aus:
In einer vorteilhaften Ausfuhrungsform teil die MGCF der IM- MGW mit, welche Codecs die IM-MGW in der gesendeten „Termi- nal-Capability Set" Nachricht angeben soll, und teilt jeweils auch die Details der Codec-Konfiguration mit. Vorzugsweise wählt die MGCF hierfür Codecs aus, die sie auf Seiten des IMS aus der SIP/SDP Signalisierung erhalten hat. In einer Ausfuhrungsform berücksichtigt die MGCF bei der Auswahl auch, welche Codecs an der IM-MGW unterstutzt werden. Die MGCF besitzt entweder konfiguriertes Wissen über diese Fähigkeiten, oder sie fragt diese Fähigkeiten mittels einer so genannten H.248 „AuditCapabilities" Nachricht bei der IM-MGW ab. In einer alternativen Ausfuhrungsform entfernt die IM-MGW diejenigen der von der MGCF empfangenen Codecs, die sie selbst nicht unterstutzt, bevor sie die Codecs in einer „Terminal- Capability Set" Nachricht sendet. Die MGCF gibt die Codecs vorzugsweise in einer „Add" oder „Modify" Nachricht als Parameter des „Signals" an, das die IM-MGW anweist, die H.245 Verhandlung durchzufuhren.
Die MGCF kann die Codecs schon angeben, wenn sie die IM-MGW anweist, die H.245 Verhandlung zu beginnen, oder aber in einer getrennten H.248 Nachricht zu einem späteren Zeitpunkt, beispielsweise wenn sie entsprechende Information in ein SIP Nachricht erhält. Falls die MGCF die Codecs erst zu einem späteren Zeitpunkt angeben will, weist sie die MGCF vorzugsweise an, auf diese Nachricht zu warten. Dazu benütz die MGCF vorzugsweise einen speziellen Parameter des „Signals", das die IM-MGW anweist, die H.245 Verhandlung durchzuführen. Falls die MGCF keine Codecs gesendet hat und die MGCF nicht zum Warten aufgefordert hat, sendet die IM-MGW eine „Termi- nal-Capability Set" Nachricht mit vorkonfigurierten Werten
In einer vorteilhaften Ausführungsform teilt die IM-MGW der MGCF auch mit, welche Codecs sie in einer „Terminal-
Capability Set" Nachricht empfangen hat, und gibt dabei jeweils auch die detaillierte Konfiguration des Codecs an. Vorzugsweise teilt die IM-MGW empfangene Codecs, die sie selbst nicht unterstützt, der MGCF jedoch nicht mit. Die MGCF reicht diese Information vorzugsweise mittels SIP/SDP zum Terminal auf Seiten de IMS weiter.
Um eine Benachrichtigung über die empfangenen Codecs zu verlangen, nützt die MGCF vorzugsweise ein dazu neu zu standardisierendes so genanntes H.248 „Event", das die MGCF vorzugs- weise in dieselbe H.248 Nachricht einfügt, in der sie die IM- MGW anweist, die H.245 Verhandlung zu beginnen. Wenn die IM- MGW im Folgenden Terminal-Capability Set" Nachricht empfängt, nützt die IM-MGW erfindungsgemäß eine so genannte H.248 „No- tify" Nachricht, in der sie das neu definierte „Event" an- gibt, und die Codecs als Parameter dieses Events angibt.
In einer Ausführungsform öffnet die IM-MGW nach Austausch der H.245 „Terminal-Capability Set" Nachrichten und Abschluss der
H.245 „Master Slave Determination" selbststandig logische H.223 Kanäle, so sie nach Ausgang der Master Slave Determination dafür zustandig ist. Dabei wählt die IM-MGW aus der Schnittmenge der in den „Terminal-Capability Set" Nachrichten übermittelten Codecs geeignete Codecs, vorzugsweise jeweils einen Sprachcodec und einen Videocodec, und öffnet dann mittels so genannter H.245 „Open logical Channel" Nachrichten die Kanäle. Wie oben beschrieben informiert die IM-MGW die MGCF über das Offnen der Kanäle.
In einer alternativen Ausfuhrungsform weist die MGCF die IM- MGW an, die logischen Kanäle für bestimmte Codecs aufzubauen, vorzugsweise in dem sie die Codecs als spezielle Parameters eines geeigneten neu zu standardisierenden Signals innerhalb einer H.248 „Modify" Nachricht angibt. Falls die MGCF ein solches Signal verwenden will, weist sie die MGCF vorzugsweise an, auf diese Nachricht zu warten. Dazu benutz die MGCF vorzugsweise einen speziellen Parameter des „Signals", das die IM-MGW anweist, die H.245 Verhandlung durchzufuhren.
In einer bevorzugten Ausfuhrungsform informiert die IM-MGW die MGCF auch, wenn die Inband-Aushandlung mittels H.245 fehlgeschlagen ist, beispielsweise weil keine übereinstimmenden Fähigkeiten gefunden wurden, die eine Übertragung von Vi- deotelefonie erlaubt hatten. Falls die Inband Verhandlung nicht erfolgreich war, kann die MGCF entweder den CaIl abbauen, oder aber einen Ruckfall zu Sprache anstoßen, wobei die MGCF auf CS Seite den so genannten „Service Change and UDI Fallback" (SCUDIF), 3GPP TS 23.172, verwenden kann, und auch auf der IMS-Seite einer SIP/SDP Codec-Renegotiation mittels einer SIP re-INVITe Nachricht.
Die MGCF kann die IM-MGW entweder bereits beim ersten Konfigurieren der so genannten „Terminations" oder aber nach Benachrichtigung über eine erfolgreiche Inband-Aushandlung anweisen, die Verbindung durchzuschalten. Sobald die MGCF das IMS-MGW anweist, den Video-Call durchzuschalten, vergleicht das IMS-MGW die Einstellungen für den Video-Codec und den Sprach-Codec, um zu entscheiden, ob Transcoding für das Video-Signal und / oder das Sprach-Signal notwendig ist. Weitere Merkmale und Vorteile der Erfindung ergeben sich aus den Patentansprüchen und der nachfolgenden Beschreibung eines Ausführungsbeispieles anhand der Zeichnung. Dabei zeigt: Fig. 1 eine Netzwerkkonfiguration,
Fig. 2 ein Block Diagramm der Schlüssel-Komponenten, Fig. 3 das Prinzip des Interworking zu einer Ausführungsform und
Fig. 4 den Kontext für einen Video-Call.
Figur 1 zeigt eine typische Netzwerkkonfiguration. Es ist die Netzwerkkonfiguration dargestellt, die nötig ist, damit ein mit der 3GPP CS Domäne verbundenes mobiles Endgerät MSl mit einem mit dem IMS verbundenen mobilen Endgerät 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 IM-MGW mit- tels des von der ITU-T standardisierten H.248 Protokolls ü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 MGW sind untereinander und mit der IMS MGW über die so genannte „Nb" Schnittstelle verbunden. Für Videotele- phonie wird der so genannte „BS30" Datentransportdienst (engl. Bearer Service") verwendet. MSl ist mittels eines so
genannten Radiozugangsnetzes, beispielsweise eines UTRAN, mit einem MSC Server einer CS MGW verbinden. Aus 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 Gatewy GPRS Support node" (GGSN) und ein Radiozugangsnetzes, beispielsweise eines UTRAN, zum mobilen Endgerat MS2 weiterreichen. Daten werden von der IMS Media Gateway über die Mb Schnittstelle zum GGSN transportiert, der sie durch sie ebenfalls über das Radiozu- gangsnetz zum MS weitergereicht.
Figur 2 zeigt ein Block Diagramm der Schlüssel-Komponenten. Es sind funktionale Schlusselkomponenten in MGCF und IM-MGW dargestellt. Erfindungsgemaß befindet sich der so genannte „H.245 Client", also die funktionale Einheit die das H.245 Protokoll terminiert, in der IM-MGW und tauscht mittels des H.248 Protokolls über die „Mn" Schnittstellen Informationen bezuglich der Auswahl der Codecs und des Ablaufs des Rufaufbaus mit den für den so genannten „Call Control" zustandigen funktionalen Komponenten in der MGCF aus, vorzugsweise mit der oder den funktionalen Komponente (n) , die auf der Seite des IMS für die Behandlung des SIP und des SDP zustandig sind. Erfindungsgemaß werden von der CS Seite innerhalb des H.223 Protokolls empfangene H.245 Nachrichten vom H.223 MuI- tiplexer an den „H.245 Client" weitergereicht. Erfindungsgemaß tauscht der H.245 Client auch Informationen bezuglich des H.223 Protokolls mit dem H.223 Multiplexer/Demultiplexer aus. In der IM-MGW werden so genannte „Media streams" für Audio und Video getrennt behandelt. Abhangig von den auf IMS Seite und CS Seite ausgewählten Audio- und Videocodecs und den Details ihres Transportformats in diesen Netzen kann wahlweise ein transparentes Weiterreichen der Daten, ein so genanntes „Re-Framing", d.h eine einfache Änderung des Transportforma-
tes, oder aber ein vollständige Umwandlung der Daten zwischen verschiedenen Codecs mittels eines so genannten Transkoders erforderlich sein. Die vorliegende Erfindung zielt darauf ab, Transkodieren besonders für Videocodecs weitgehend zu vermei- den .
Figur 3 (Prinzip des Interworking) stellt mit Hilfe des Sig- nalisierungsverlaufs das Prinzip des Interworkings zwischen der H.245 Signalisierung und auf der CS Seite und der H.248 Signalisierung zwischen MGCF und IM-MGW dar.
Die Signalisierungs-Schritte sind im Einzelnen wie folgt:
1. Die MGCF beschließt, auf der CS Seite eine H.324 Verbindung für Videotelephonie einzurichten. Zunächst konfiguriert die MGCF die physikalische so genannte „Termination" auf Seite des CS Netzes. Für Pakettransport generiert die MGCF dazu eine neue Termination in einem neuen so genannten H.248 „context" mit Hilfe eines H.248 „Add" Befehls. Für TDM-Transport kann die MGCF statt dessen eine bestehende Termination, die eine festen Zeitschlitz in einer physikalischen Leitung darstellt, in einen neuen Context verschieben. Die Termination bekommt einen so genannten H.248 „stream" zugewiesen.
2. Die IM-MGW richtet die Termination entsprechend ein und gibt die Identifier der Tl für die Termination und Cl für den Context zurück.
3. Die CS-seitige Transportverbindung wird aufgebaut.
4. Die MGCF richtet gemäß bestehenden H.248.1 und H.248.20 Standard eine spezielle logische H.248 Termination zum Beschreiben des Multiplexen im selben Context Cl ein und drückt durch den so genannten „Mux" Parameter aus, dass das MuI- tiplexing in Termination Tl beschrieben wird und gemäß des H.223 Standards geschieht. Sie beschreibt den Logischen Kanal des H.223 Protokolls, der zur H.245 Signalisierung verwendet
werden soll mittels einen eigenen „streams" der so genannten „logical Channel number" (LCN) mit Wert 0 zugewiesen bekommt. Erfindungsgemäß weist die MGCF die IM-MGW an, die H.223 Verhandlung des so genannten „MultiplexingLevels" zu beginnen, vorzugsweise mittels eines neuen so genannten H.248 „sig- nals", das hier „H223Negotiation" genannt wird. Erfindungsgemäß weist die MGCF die IM-MGW an, anschließend die H.245 Verhandlung zu beginnen, vorzugsweise mittels eines neuen so genannten H.248 „Signals", das hier „H245Negotiation" genannt wird. In einer Variante der Erfindung sind „H223Negotiation" und „H245Negotiation" zu einem Signal zusammengefasst . Erfindungsgemäß weist die MGCF die IM-MGW vorzugsweise auch an, der MGCF eine Nachricht zu schicken, so bald die H.223 Verhandlung des so genannten „Mul- tiplexingLevels" abgeschlossen ist, vorzugsweise mittels eines neuen so genannten H.248 „events", das hier „H223Establishment" genannt wird. Erfindungsgemäß weist die MGCF die IM-MGW auch an, der MGCF eine Nachricht mit auf der CS Seite unterstützten Codecs zu schicken, sobald die IM-MGW eine H.245 „Terminal Capability Set" Nachricht empfängt. Vorzugsweise nützt die MGCF dazu ein neues so genanntes H.248 „event", das hier „H245Capabilities" genannt wird. Erfindungsgemäß weist die MGCF die IM-MGW auch an, der MGCF eine Nachricht mit dem ausgewählten Codec und der zugehörigen H.245 „logical Channel number" zu schicken, sobald mittels H.245 ein logischer H.223 „Channel" geöffnet wird. Vorzugsweise nützt die MGCF dazu ein neues so genanntes H.248 „e- vent", das hier „H245Channel" genannt wird.
5. Die IM-MGW richtet die neue Termination entsprechend ein und gibt den Identifier T2 zurück.
6. Die IM-MGW richtet die H.223 Verbindung ein verhandelt dabei den MultiplexingLevel, im Beispiel 2.
7. Die IM-MGW teilt erfindungsgemäß der MGCF mit, dass die Verhandlung des H.223 Multiplexing Levels abgeschlossen ist. Vorzugsweise nützt die IM-MGW zur Benachrichtigung der MGCF eine so genannte H.248 „Notify" Nachricht mit dem neuen Event „H223Establishment.
Die MGCF kann die erhaltene Information nutzen, um festzustellen, ob zum gegebenen Zeitpunkt eine Inband-H.245 Verhandlung möglich ist, was vorteilhaft ist weil beispielsweise so genannte „early Media" vor der Vollendung des Rufaufbaus durch die Call-Control Signalisierung auf der CS Seite je nach beteiligten Netzwerken durchgereicht oder geblockt werden können. Wenn über einen längeren Zeitraum keine H.223 Signalisierung empfangen wird, kann die MGCF auch den Fehlerfall feststellen, dass sie irrtümlich Videotelefonie erwartet hat.
8. Die MGCF bestätigt den Erhalt der „Notify" Nachricht.
9. Die IM-MGW erhält eine so genannte „Terminal Capability Set" H.245 Nachricht, die mit einer so genannten „Master- Slave Determination" H.245 Nachricht kombiniert sein kann. Die „Terminal Capability Set" H.245 Nachricht enthält unter
Anderem Angaben zu den vom Terminal auf der Seite des CS Netzes unterstützten Sprach und Videocodecs und den Details ihrer Konfiguration.
10. Erfindungsgemäß reicht die IM-MGW die erhaltene Informa- tion über die Codecs weiter. Vorzugsweise nützt die IM-MGW dazu eine so genannte H.248 „Notify" Nachricht mit dem neuen Event „H245Capabilities", das geeignete Parameter zur Angabe der Codecs enthält, beispielsweise als SDP oder in Form der so genannten H.248 „SDP equivalents" enkodiert. In einer vorteilhaften Variante der Erfindung löscht die IM- MGW von ihr nicht unterstütze Codecs, bevor sie die Information an die MGCF weiterreicht.
11. Die MGCF bestätigt den Erhalt der „Notify" Nachricht.
12. Die IM-MGW bestätigt die „Terminal Capability Set" H.245 Nachricht und die „Master-Slave Determination" H.245 Nachricht .
13. Die MGCF weist die IM-MGW an, in der H.245 Verhandlung bestimmte Codecs anzubieten, beispielsweise weil die MGCF entsprechende Informationen innerhalb von SIP/SDP Nachrichten auf Seiten des IMS erhalten hat. Es ist vorteilhaft, wenn die MGCF auch die vom IM-MGW unterstützten Codecs berücksichtigt. Die MGCF besitzt entweder konfiguriertes Wissen über diese Fähigkeiten, oder sie fragt diese Fähigkeiten mittels einer so genannten H.248 „AuditCapabilities" Nachricht bei der IM- MGW ab. In einer vorteilhaften Variante der Erfindung berücksichtigt die MGCF die von der IM-MGW unterstützten Codecs nicht selbst, sondern reicht alle in Frage kommenden Codecs an die IM-MGW. Die IM-MGW löscht dann selbst von ihr nicht unterstütze Codecs, bevor sie die Information in H.245 Signalisierung weiterreicht.
Vorzugsweise nützt die MGCF das neue so genannte H.248 „sig- nal" „H245Negotiation" innerhalb einer H.248 „Modify" Nach- rieht, und gibt die Codecs als geeignete Parameter des „sig- nals" an, beispielsweise als SDP oder in Form der so genannten H.248 „SDP equivalents" enkodiert.
14. Die IM-MGW sendet eine „Terminal Capability Set" H.245 Nachricht, in der Sie Angaben zu auf Seiten der IM-MGW unter- stützten Fähigkeiten zum Beispiel bezüglich von H.223 Protokolloptionen macht, die von der MGCF in Nachricht 13 empfangenen Informationen bezüglich der Codecs weiterreicht und auch den in Schritt 6 festgelegten H.223 MultiplexigLevel berücksichtigt. Im Beispiel kombiniert die IM-MGW diese Nach- rieht mit einer „Master-Slave Determination" H.245 Nachricht.
15. Die IM-MGW sendet eine Bestätigung der H.248 „Modify" Nachricht .
16. Die IM-MGW erhält eine Bestätigung der „Terminal Capabi- lity Set" H.245 Nachricht und der „Master-Slave Determination" H.245 Nachricht.
17. Die MGCF wählt Codecs für die Videotelefonie aus, wobei sie Informationen aus der SIP/SDP Signalisierung auf Seiten des IMS sowie die in Nachricht 10 enthaltenen Informationen bezüglich des CS-seitigen Terminals berücksichtigt. Vorzugsweise wählt die MGCF erfindungsgemäß Codecs aus, die sowohl auf Seiten des IMS wie des CS Netzes unterstützt werden, um ein Transkodieren zu vermeiden.
Erfindungsgemäß weist die MGCF die IM-MGW an, logische Kanäle für diese Codec (s) zu konfigurieren.
Vorzugsweise nützt die MGCF das neue so genannte H.248 „sig- nal" „H245Selection" innerhalb einer H.248 „Modify" Nach- rieht, und gibt die Codecs als geeignete Parameter des „sig- nals" an, beispielsweise als SDP oder in Form der so genannten H.248 „SDP equivalents" enkodiert.
In einer hier nicht dargestellten Variante der Erfindung verzichtet die MGCF auf die endgültige Auswahl der Codecs und überlässt diese Entscheidung der IM-MGW. Die IM-MGW würde dann erfindungsgemäß aus der Schnittmenge der in Nachrichten 9 und 13 erhaltenen Codecs sowie der von ihr selbst unterstützten Codecs auswählen.
18. Die MGCF sendet für die in Nachricht 17 erhaltenen Co- decs eine so genannte „Open Logical Channel" H.245 Nachricht, in der sie die dem ausgewählten Codec entsprechenden H.223 „logical Channel number" (LCN) verwendet, die zuvor mittels der Terminal Capability Set" H.245 Nachrichten 9 oder 14 festgelegt wurde. In einem hier nicht dargestellten Fall kann es auch vorkommen, dass die die IM-MGW aus dem CS Netz eine „Open Logical Channel" H.245 Nachricht erhält. In diesem Fall wurde im CS
Netz aus den in der „Terminal Capability Set" Nachricht 14 angebotenen Fähigkeiten ausgewählt.
19. Die IM-MGW bestätigt die „Modify" Nachricht. Sollte die IM-MGW nicht in der Lage sein, die geforderten logischen „Channels" einzurichten, beispielsweise weil sie der H.245 „Slave" ist, teilt sie das vorzugsweise in dieser Nachricht mit .
20. Die IM-MGW erhält eine so genannte „Open Logical Channel Ack" H.245 Nachricht. 21. Erfindungsgemäß informiert die IM-MGW die MGCF, sobald ein logischer „Channel mittels H.245 geöffnet wurde und gibt dabei die verwendete die H.223 „logical Channel number" sowie den entsprechenden Codec weiter. Den Codec ermittel die IM- MGW mit Hilfe der in der ensprechenden „Open Logical Channel" Nachricht signalisierten „logical Channel number" und den ihr zugeordneten Informationen in den „Terminal Capability Set" H.245 Nachrichten 9 oder 14.
Vorzugsweise nützt die IM-MGW dazu eine so genannte H.248 „Notify" Nachricht mit dem neuen Event „H245Channel", das ge- eignete Parameter zur Angabe der Codecs sowie der „logical
Channel number" enthält, beispielsweise als SDP oder in Form der so genannten H.248 „SDP equivalents" enkodiert.
22. Die MGCF bestätigt den Erhalt der „Notify" Nachricht.
23. Die MGCF weist die IM-MGW an, den logischen H.223 Kanal einzurichten, der mit Hilfe der Nachrichten 21 bis 26 bereits über H.245 Signalisierung vereinbart wurde. Dazu sendet die IM-MGW einen H.248 „Modify" Nachricht bezüglich der Multiple- xing Termination T2 in der sie einen neuen „stream 3" beschreibt, wobei sie die LCN und den Codec wie in Nachricht 21 angibt.
24. Die IM-MGW sendet eine Bestätigung der H.248 „Modify" Nachricht .
25. Die MGCF weist die IM-MGW an, auf Seiten des IMS eine Termination einzurichten, mit der stream 3 verbunden werden soll, so dass die IM-MGW die auf Seiten des IMS oder des CS Netzes empfangenen steam 3 zugeordneten Daten an der jeweils anderen Seite weiterreicht. Dazu sendet die IM-MGW einen H.248 „Add" Nachricht bezüglich Context Cl, und gibt darin an, dass „stream 3" befördert werden soll und welcher Codec dafür zu verwenden ist. Wenn in Nachricht 23 und 25 der selbe Codec angegeben ist, erkennt die IM-MGW, dass kein Transko- dieren erforderlich ist.
26. Die IM-MGW bestätigt die „Modify" Nachricht.
27. Die Schritte 17 bis 26 werden auch durchgeführt, um den „stream 4" für den Bearer zum Transport der Sprache und den entsprechendenden Sprachcodec für eine Termination T4 zu kon- figurieren.
Der H.248 Context für einen Video-Call sieht also wie Fig. 4 gezeigt aus.