Erweiterung der Autokonfigurationsmethode für Rich Communications Suite enhanced (RCS-e) durch die COCUS AG

Transkript

1 Erweiterung der Autokonfigurationsmethode für Rich Communications Suite enhanced (RCS-e) durch die COCUS AG Autoren: Sascha Hellermann (Geschäftsführer COCUS NEXT GmbH) Simon Probst (Solution Designer COCUS NEXT GmbH)

2 1. Einführung Die GSM Association (GSMA) ist eine Industrievereinigung der GSM-Mobilfunkanbieter und vertritt mehr als 800 Mobilfunkanbieter weltweit. Als Gegenentwurf zu Over-The-Top (OTT) Instant Messengern (IM) wie WhatsApp und um dem schwindenden Einfluss des Short Message Service (SMS) entgegenzuwirken entwarf die GSMA die Rich Communication Suite enhanced (RCS-e). RCS-e soll es Nutzern ermöglichen ohne Konfiguration auch über Netzanbietergrenzen mit anderen Nutzern Kurznachrichten, Bilder und Dateien auszutauschen oder (Video-)Anrufe zu tätigen. Die RCS-e basiert dabei auf zahlreichen Internetstandards und benutzt zur Signalisierung das Session Initiation Protocol (SIP), welches bereits zur Signalisierung im IP Multimedia Subsystem (IMS) verwendet wird. Das IMS spezifiziert welche Dienste intern in einem Mobilfunknetzwerk vorhanden sein müssen und wie diese miteinander interagieren. Durch die Verwendung von SIP lässt sich RCS-e somit in ein bereits bestehendes IMS integrieren. 2. Automatische Clientkonfiguration von RCS-e Die Spezifikation von RCS-e sieht, unter anderem, eine HTTP(S) basierte Konfiguration von Endgeräten vor. Sobald sich ein Endgerät mit dem mobilen Datennetzwerk des Mobilfunkanbieters verbindet, sendet es eine Anfrage an eine definierte URL, um Konfigurationsparameter für den RCS-e Dienst abzurufen (siehe Abbildung 1). Diese URI lautet: Wobei die Werte <MNC> und <MCC> durch den Mobile Network Code (MNC) sowie den Mobile Country Code (MCC) des Mobilfunkanbieters ersetzt werden, bei dem der Nutzer Kunde ist. Das Endgerät sendet initial ein HTTP GET an die oben genannte URI und erhält in der Antwort einen HTTP Cookie, welcher für folgende Anfragen an die gesicherte URI verwendet wird. Im On-Net Fall, d.h. das Endgerät ist im mobilen Datennetzwerk eingebucht, erfolgt implizit eine Authentifizierung durch z.b. sog. Header Enrichment über die MSISDN. Falls das Endgerät nicht im mobilen Datennetz eingebucht ist, werden in der Spezifikation weitere Methoden zur Authentifizierung beschrieben. Nach dem initialen HTTP Request, erfolgt eine zweite GET Anfrage über HTTPS an die o.g. URI. Dabei sendet das Endgerät mehrere Parameter mit, die eine genauere Identifikation des Endgeräts und der dort gespeicherten Kommunikation erlauben. Der kann nun eine neue oder initiale Konfiguration an das Endgerät schicken oder diesem mitteilen, dass seine gespeicherte Konfiguration noch gültig ist. Nachdem das Endgerät eine Antwort vom erhalten hat, wird es eine Verbindung zum RCS-e Applikationsserver aufbauen und kann ab da alle unterstützten Funktionen nutzen. Server im Netz von Mobilfunkanbieter <cookie> XML Konfiguration Abbildung 1 Endgerätekonfiguration nach RCS-e Spezifikation

3 Die Spezifikation sieht vor, dass der unter der Kontrolle des Netzanbieters steht, d.h. der Server vom Netzanbieter betrieben und verwaltet wird. Ebenso müssen die SSL/TLS Zertifikate für die Konfigurationsdomain vom Netzanbieter gestellt werden. Der Betrieb einer extern gehosteten RCS-e Lösung ist in der Spezifikation nicht vorgesehen, da RCS-e als Teil des IMS durch die GSMA betrachtet wird.

4 3. Alternative Netzkonfiguration für externe Hier werden die durch COCUS entwickelten alternativen Lösungsansätze beschrieben, die als Grundlage zur Patenanmeldung dienen sollen: Um den RCS-e Dienst extern, d.h. nicht im Netzwerk des Mobilfunkanbieters, zu betreiben ist es notwendig, dass eine entsprechende Konfiguration auf das Endgerät übertragen wird. Dazu könnte der im Netzwerk des Mobilfunkanbieters verbleiben während die Einträge in der Client- Konfiguration auf die externen Systeme verweisen. Wünscht der Mobilfunkanbieter aber eine reine Over-The- Top (OTT) Lösung, bei der keine oder nur wenige Systeme in seinem Netz verbleiben, sind andere Ansätze nötig: Lösung 1: Die in Kapitel 2 genannte URI verweist auf den externen. Dabei muss das entsprechende SSL Zertifikat auf dem externen Server installiert werden, um zu gewährleisten, dass eine gesicherte HTTPs Verbindung aufgebaut werden kann. Der externe Server implementiert dann die in der RCS-e Spezifikation beschriebene Funktionalität (siehe Abbildung 2). <cookie> XML Konfiguration Abbildung 2 Konfiguration von externem Server Falls ein Netzbetreiber die SSL-Zertifikate nicht an einen externen Dienstleister herausgeben möchte oder die DNS Einträge für die o.g. URI ändern kann oder möchte, werden zwei weitere Alternativen vorgeschlagen:

5 Lösung 2: Der verbleibt im Netz des Mobilfunkanbieters und hat die nötigen SSL-Zertifikate installiert. Jede Anfrage wird aber mit einem HTTP Statuscode 301 Moved Permanently oder 308 Permanent Redirect beantwortet, welche den Client dazu veranlassen, seine Anfrage an einen anderen Host zu stellen. Dieser neue Host wird im Location Header der Antwort übertragen und verweist auf den des Dienstleisters. Die restliche Konfiguration läuft dann wie in der RCS-e Spezifikation beschrieben ab (siehe Abbildung 3). Server im Netz von Mobilfunkanbieter HTTP 301 MOVED PERMANENTLY <Location: <Host>> <cookie> XML Konfiguration Abbildung 3 Konfiguration von externem Server mit HTTP Redirect Vorteile: Es müssen keine SSL-Zertifikate auf fremden Servern installiert werden. Der verbleibende Server im Netz des Mobilfunkanbieters kann sehr minimal sein, da immer die selbe Antwort gesendet wird. Nachteile: Die RCS-e Implementierungen auf den Endgeräten müssen die HTTP Statuscodes richtig auswerten. In einigen Situationen ist es erforderlich, dass der den Versand von Kurznachrichten veranlasst. Dazu muss ein Interface zurück zum Mobilfunkanbieter bestehen.

6 Lösung 3: Der im Netz des Mobilfunkanbieters dient als Proxy zum Konfig-Server des externen Dienstleisters. Die Endgeräte wenden sich an den ihnen bekannten Server, welcher die Anfragen unverändert an den Konfig-Server des externen Dienstleisters weiter leitet. Wichtig ist hierbei, dass der Proxy-Server intern nicht blockierende Funktionen verwendet, um nicht als bottleneck in der Kommunikation zu enden (siehe Abbildung 4). Server im Netz von Mobilfunkanbieter <cookie> <cookie> XML Config XML Config Abbildung 4 Konfiguration mit Proxy-Server Vorteile: Es müssen keine SSL-Zertifikate auf fremden Servern installiert werden. Diese Lösung ist konform zur RCS-e Spezifikation, da der grundsätzliche Ablauf der Konfiguration nicht verändert wird. Nachteile: Der Proxy-Server kann ein bottleneck in der Kommunikation darstellen, wenn dieser nicht ausreichend dimensioniert ist. In einigen Situationen ist es erforderlich, dass der den Versand von Kurznachrichten veranlasst. Dazu muss ein Interface zurück zum Mobilfunkanbieter bestehen.