VoLTE, VoNR, IMS Data Channels, WebRTC… Derrière ces technologies se dessine une évolution majeure : la transformation de l’appel téléphonique en une expérience multimédia interactive. Comment l’architecture IMS accompagne-t-elle cette évolution et quel rôle conserve le MMTEL AS ?
1. Le MMTEL AS : au cœur de la téléphonie IMS
Avec le déploiement de la VoLTE (Voice over LTE), puis de la VoNR (Voice over New Radio), les opérateurs mobiles ont progressivement fait évoluer leurs services téléphoniques vers une architecture entièrement IP.
Cette évolution repose sur le réseau IMS (IP Multimedia Subsystem), une architecture normalisée par le 3GPP permettant de fournir des services de communication multimédia sur différents réseaux d’accès.
Pour enrichir les services voix, le MMTEL AS (Multimedia Telephony Application Server), souvent désigné sous le terme TAS (Telephony Application Server) apporte des fonctionnalités supplémentaires.
le rôle du MMTEL AS ?
Le MMTEL AS assure la logique applicative des services téléphoniques IMS comme :
- Des renvois et transferts d’appels.
- De la mise en attente et du double appel.
- Des conférences téléphoniques.
- De la présentation ou de la restriction de l’identité de l’appelant.
- Des services supplémentaires associés aux communications multimédias.
Le MMTEL AS intervient principalement dans le plan de contrôle des services. Il s’appuie sur le protocole SIP (Session Initiation Protocol) pour participer à l’établissement, à la modification et à la terminaison des sessions IMS. Lors de l’établissement de la communication, les messages SIP transportent des descriptions SDP permettant aux extrémités de négocier les caractéristiques des médias, notamment les codecs et les paramètres de transport. Une fois la session établie, les flux vocaux sont transportés en RTP, éventuellement à travers des fonctions média intermédiaires. Le MMTEL AS peut intervenir dans la logique de service sans nécessairement traiter ces flux. Le MMTEL AS apporte des fonctions supplémentaires comme un renvoi d’appel, une pré-image qui sera affichée sur le poste de l’appelé, une sonnerie personnalisée…
le MMTEL AS contrôle la logique du service téléphonique, mais n’est pas un équipement de transport de la voix. Le transport de la voix est ensuite assuré par le protocole RTP (Real-time Transport Protocol) entre l’appelant et l’appelé.
2. L’architecture IMS : comment fonctionne le cœur des services VoLTE et VoNR ?
Pour comprendre le rôle du MMTEL AS et les évolutions apportées par NG-RTC, il est utile de revenir sur l’architecture IMS (IP Multimedia Subsystem) et de la comprendre.
L’IMS repose sur plusieurs fonctions spécialisées qui assurent l’enregistrement des utilisateurs, la signalisation des appels, l’exécution des services téléphoniques et, lorsque cela est nécessaire, le traitement des médias.
Son principe fondamental est de séparer le contrôle de la communication du transport de la voix.
Les CSCF : les fonctions de contrôle des sessions SIP
L’architecture IMS comprend trois fonctions principales de contrôle des sessions, appelées CSCF (Call Session Control Function).
Le P-CSCF (Proxy-CSCF)
Il constitue le premier point de contact du terminal avec l’IMS. Il reçoit les messages SIP du smartphone et les transmet aux autres fonctions du réseau. Il participe également à la sécurisation de la signalisation et aux mécanismes de contrôle de la qualité de service.
L’I-CSCF (Interrogating-CSCF)
Il intervient lors de l’enregistrement IMS et de l’établissement des communications. Il permet d’identifier le S-CSCF chargé de prendre en charge l’abonné, en s’appuyant sur les informations du réseau de rattachement.
Le S-CSCF (Serving-CSCF)
Il constitue la fonction centrale de contrôle des sessions SIP de l’abonné. Il assure :
- La gestion de l’enregistrement IMS.
- Le traitement et le routage des messages SIP.
- L’application des règles de déclenchement des services.
- L’interaction avec les serveurs d’applications IMS.
Dans cette architecture, c’est la fonction S-CSCF qui fait intervenir le MMTEL AS lorsqu’un service téléphonique doit être exécuté.
Le HSS : les informations d’abonnement
Le HSS (Home Subscriber Server) conserve les données nécessaires au fonctionnement des services IMS. Il contient les identités IMS, les informations d’authentification, les profils de service et les informations nécessaires à l’affectation du S-CSCF.
Dans les architectures IMS classiques, le S-CSCF et l’I-CSCF communiquent avec le HSS à travers les interfaces Cx fondées sur Diameter.
Dans les architectures plus récentes, les données d’abonnement peuvent également être accessibles au moyen de fonctions adaptées à l’environnement 5G.
Les Application Servers : la logique des services
Les serveurs d’applications, ou IMS AS (IMS Application Servers), exécutent les services associés aux communications.
Le MMTEL AS en est un exemple majeur.
Lorsqu’un abonné dispose d’un service de renvoi d’appel, le S-CSCF peut déclencher le MMTEL AS afin que celui-ci applique la logique correspondante.
L’interface entre le S-CSCF et l’IMS AS est appelée ISC (IMS Service Control). Elle repose sur SIP.
L’IMS peut également intégrer d’autres serveurs d’applications, selon les services proposés par l’opérateur.
La MRF : le traitement des médias
La MRF (Media Resource Function) fournit des ressources de traitement média lorsque les services en ont besoin.
Elle peut intervenir pour :
- Diffuser des annonces vocales.
- Générer certaines tonalités.
- Mixer plusieurs flux audio lors de conférences.
L’architecture MRF distingue traditionnellement une fonction de contrôle, le MRFC, et une fonction de traitement média, le MRFP.
Il ne faut pas confondre cette MRF avec la MF (Media Function) introduite dans l’architecture IMS Data Channel, dont nous détaillerons le rôle plus loin.
Les fonctions d’interconnexion
L’IMS peut également comporter des fonctions permettant de communiquer avec d’autres réseaux.
Par exemple, le BGCF (Breakout Gateway Control Function) participe à la sélection du réseau de sortie vers les réseaux téléphoniques à commutation de circuits.
Le MGCF (Media Gateway Control Function) assure des fonctions de contrôle de l’interfonctionnement avec ces réseaux, en association avec une passerelle média.
Ces fonctions sont particulièrement utiles lorsqu’un appel IMS doit joindre un correspondant situé sur un réseau téléphonique traditionnel.
Exemple : établissement d’un appel VoLTE ou VoNR
Prenons le cas d’un utilisateur qui appelle un correspondant depuis son smartphone.
- Enregistrement IMS : le terminal s’enregistre auprès de l’IMS via le P-CSCF. Le S-CSCF prend en charge l’enregistrement de l’abonné.
- Initiation de l’appel : le terminal envoie un message SIP INVITE contenant une description SDP des médias proposés, comme les codecs audio et les paramètres de transport.
- Contrôle de la session : les fonctions CSCF acheminent la signalisation SIP. Le S-CSCF peut faire intervenir le MMTEL AS selon les services de l’abonné.
- Négociation des médias : les échanges SIP/SDP permettent aux extrémités de convenir des caractéristiques de la communication, du codec et des adresses IP et ports utilisés pour les flux média.
- Transport de la voix : une fois la communication établie, les paquets vocaux sont transportés en RTP, éventuellement à travers des équipements intermédiaires.
Le MMTEL AS peut donc intervenir dans le contrôle de l’appel sans transporter lui-même les paquets de voix.
Pourquoi cette architecture est-elle importante pour NG-RTC ?
Cette organisation permet à l’IMS d’évoluer sans remettre en cause ses fonctions fondamentales.
Avec NG-RTC, les fonctions CSCF continuent de gérer la signalisation des sessions IMS, tandis que les serveurs d’applications conservent leur rôle dans l’exécution des services.
De nouveaux composants nommés DCSF, DCAR, DC Application Server et la MF, viennent compléter cette architecture pour prendre en charge les canaux de transport de service nommés IMS Data Channels.
L’IMS Application Server
L’IMS AS conserve un rôle central dans la coordination des services et des ressources associées à la session IMS. L’IMS AS interagit avec le DCSF et la MF pour assurer la cohérence entre le contrôle de la communication et les ressources Data Channel.
Le DCSF : Data Channel Signalling Function
Le DCSF assure les fonctions de contrôle spécifiques aux IMS Data Channels. Il intervient dans les procédures de négociation, d’établissement et de gestion des canaux de données.
Le DCSF ne pilote pas directement la MF.
La chaîne de contrôle passe par l’IMS AS :
- Le DCSF détermine les opérations nécessaires à la gestion du Data Channel.
- L’IMS AS reçoit les instructions du DCSF.
- L’IMS AS interagit avec la MF pour gérer les ressources média correspondantes.
Cette organisation maintient l’IMS AS au centre de la coordination des services.
Le DCAR : Data Channel Application Repository
Le DCAR constitue un référentiel de ressources applicatives Data Channel. Il intervient dans la découverte et la mise à disposition des applications utilisables dans l’environnement IMS Data Channel.
Il ne doit pas être confondu avec le serveur qui assure la logique métier d’une application.
Le DC AS : Data Channel Application Server
Le DC AS est le serveur applicatif associé à un fournisseur de service. Le 3GPP définit son intégration dans l’architecture IMS Data Channel, mais ne spécifie pas ses fonctionnalités applicatives internes.
Cette souplesse permet d’envisager différents types de services.
La MF : Media Function
La Media Function assure les fonctions média nécessaires aux IMS Data Channels.
Les principales interfaces de l’architecture
| Interface | Fonctions reliées |
|---|---|
| DC1 | IMS AS ↔ DCSF |
| DC2 | IMS AS ↔ MF |
| DC3 | DCSF ↔ NEF |
| DC4 | DCSF ↔ DC AS |
| DC5 | DCSF ↔ DCAR |
| MDC1 | MF ↔ DCSF, trafic Bootstrap |
| MDC2 | MF ↔ DC AS, trafic applicatif A2P/P2A |
Les interfaces de contrôle reposent sur une approche service-based, avec les services Nimsas, Ndcsf et Nmf, décrits dans les spécifications 3GPP de la famille TS 29.175.
Cette organisation distingue clairement le contrôle des services, la gestion des ressources média et la logique applicative.
la MRF
Les premières évolutions de l’architecture IMS Data Channel ont également envisagé l’utilisation d’une MRF (Media Resource Function).
Cette possibilité pouvait présenter un intérêt pour les opérateurs disposant déjà d’infrastructures MRF.
Toutefois, l’architecture a évolué au fil des versions de la Release 18, avec la suppression de cette variante dans les versions ultérieures de l’annexe AC de TS 23.228.
Il convient donc de ne pas présenter aujourd’hui MF et MRF comme deux solutions systématiquement équivalentes dans l’architecture normalisée.
NG-RTC ne remplace donc pas le cœur IMS : il étend ses capacités en ajoutant de nouvelles fonctions de contrôle, de transport et d’exécution applicative.
3. Call Composer : enrichir l’appel avant même de décrocher
L’enrichissement des communications IMS n’a pas commencé avec NG-RTC. La spécification GSMA RCC.20 (Enriched Calling) définit le Call Composer, qui permet d’associer des informations contextuelles à un appel.
L’appelant peut, par exemple, transmettre le sujet de son appel, son importance ou une image associée.
Deux variantes techniques doivent être distinguées.
Le MMTEL-based Call Composer
Dans cette première variante, les informations sont intégrées directement à la signalisation SIP de l’appel MMTEL.
L’INVITE SIP peut contenir :
- Subject : sujet de l’appel.
- Priority : niveau de priorité.
- Call-Info : lien vers une image associée.
Les informations sont ainsi transmises dans le cadre de l’établissement de l’appel.
Cette variante n’utilise pas le protocole MSRP.
Le Session-based Call Composer
La seconde variante repose sur une session Enriched Calling dédiée.
Elle utilise :
- SIP/SDP pour établir et négocier la session.
- MSRP (Message Session Relay Protocol) pour transporter les messages.
- CPIM/XML pour encapsuler et structurer les informations applicatives.
Ces deux variantes répondent au même objectif fonctionnel, mais utilisent des mécanismes techniques différents.
Le Call Composer constitue ainsi une étape vers les appels enrichis. Il reste toutefois distinct des IMS Data Channels, dont l’ambition est de permettre des interactions applicatives plus étendues pendant une communication.
4. NG-RTC : vers des communications interactives de nouvelle génération
Le NG-RTC (Next Generation Real-Time Communication) désigne les évolutions des communications temps réel IMS, autour des services multimédias enrichis.
L’un des mécanismes majeurs de cette évolution est l’IMS Data Channel, qui permet d’associer des échanges de données applicatives à une communication IMS.
L’objectif n’est plus seulement de transmettre de la voix ou de la vidéo, mais également de permettre aux utilisateurs d’interagir avec des services numériques pendant leur communication.
Quelques exemples d’utilisation
Dans le secteur bancaire, un conseiller pourrait proposer à son client une simulation interactive d’un prêt pendant un appel.
Dans l’assurance, un assuré pourrait compléter un formulaire ou transmettre des informations concernant un sinistre sans quitter l’environnement de communication.
Dans l’assistance technique, un utilisateur pourrait accéder à une interface de diagnostic ou partager des informations avec un service d’assistance.
Ces scénarios nécessitent des fonctions applicatives qui dépassent les services téléphoniques traditionnels du MMTEL AS.
C’est pourquoi l’architecture IMS évolue avec de nouveaux composants spécialisés, tout en conservant ses mécanismes fondamentaux de signalisation et de contrôle.
Le DCAR : Data Channel Application Repository
Dans la section II, ous avons présenté le rôle du DCAR en expliquant qu’il intervient dans la découverte et la mise à disposition des applications utilisables dans l’environnement IMS Data Channel.
Prenons l’exemple d’un appel à une compagnie d’assurance. Pendant la conversation, le conseiller propose au client de remplir un formulaire de déclaration de sinistre directement sur son smartphone.
Le DCAR peut fournir les ressources nécessaires au chargement de cette application, notamment ses fichiers HTML, JavaScript et CSS. Ces ressources sont récupérées à travers le Bootstrap Data Channel, avec l’intervention de la MF et du DCSF.
Une fois le formulaire affiché, les interactions avec le système d’information de l’assureur peuvent être assurées par un Application Data Channel connecté au DC Application Server (DC AS).
Le DCAR fournit donc les ressources de l’application, tandis que le DC AS assure sa logique métier et le traitement des données échangées.
5. IMS Data Channel : un nouveau média dans la session IMS
Dans une communication IMS classique, les principaux médias sont l’audio et éventuellement la vidéo. Avec les IMS Data Channels, un nouveau type de média peut être associé à la session.
| Type de média | Fonction |
|---|---|
| Audio | Communication vocale |
| Vidéo | Communication visuelle |
| Data Channel | Échanges de données et interactions applicatives |
Les Data Channels utilisent les mécanismes de transport des WebRTC Data Channels. Il ne faut cependant pas en déduire que l’ensemble de la communication IMS devient une communication WebRTC classique.
SIP et SDP restent utilisés pour la signalisation et la négociation de la session IMS. Les mécanismes WebRTC Data Channel interviennent au niveau du transport des données applicatives.
Bootstrap Data Channel et Application Data Channel
L’architecture distingue deux types de canaux.
Le Bootstrap Data Channel permet d’initialiser l’environnement applicatif et de récupérer les ressources nécessaires à l’utilisation des applications Data Channel.
Reprenons l’architecture du réseau IMS avec les fonctions NG-RTC.
Dans l’architecture utilisant une Media Function (MF), le Bootstrap Data Channel est terminé par la fonction MF. Celle-ci agit comme un proxy HTTP et relaie les requêtes du terminal vers le DCSF via l’interface MDC1.
L’Application Data Channel est ensuite utilisée pour les échanges de données nécessaires au fonctionnement de l’application.
Les mécanismes de multiplexage SCTP distinguent les canaux à l’aide de plages de stream IDs :
| Type de canal | Plage de stream IDs SCTP |
|---|---|
| Bootstrap Data Channel | 0 à 999 |
| Application Data Channel | 1000 et au-delà |
Cette distinction permet de séparer les échanges nécessaires à l’initialisation des services des données échangées par les applications.
Trois modèles de communication
Les IMS Data Channels prennent en charge trois grands modèles :
P2P (Person-to-Person) : échange de données applicatives entre deux utilisateurs.
A2P (Application-to-Person) : communication applicative depuis un service vers un utilisateur.
P2A (Person-to-Application) : interaction d’un utilisateur avec une application serveur.
Ces modèles permettent de couvrir des scénarios de communication entre particuliers, mais également des services professionnels ou des interactions entre une entreprise et ses clients.
Ainsi, la fonction MF assure :
Pour le Bootstrap Data Channel :
- La MF termine le canal établi avec le terminal.
- Elle relaie les échanges HTTP vers le DCSF via MDC1.
Pour les Application Data Channels A2P/P2A :
- La MF relaie le trafic entre le terminal et le DC AS.
- Elle utilise l’interface MDC2 du côté du serveur applicatif.
La MF intervient donc dans le plan média, tandis que les décisions de contrôle des ressources passent par l’IMS AS.
6. La pile protocolaire SCTP et DTLS ?
Les IMS Data Channels s’appuient sur des mécanismes issus de WebRTC pour le transport des données applicatives.
La pile protocolaire typique est la suivante :
Données applicatives → SCTP → DTLS → UDP → IP
Chaque protocole joue un rôle particulier.
SCTP : multiplexage et fiabilité configurable
SCTP (Stream Control Transmission Protocol) permet :
- De transporter plusieurs flux logiques indépendants au sein d’une même association.
- D’utiliser une livraison fiable ou partiellement fiable.
- De configurer l’ordonnancement des messages.
Cette souplesse est particulièrement intéressante pour les applications interactives.
Par exemple, la transmission d’un document exige généralement une livraison fiable, tandis que certaines mises à jour d’interface peuvent perdre leur intérêt si elles arrivent trop tard.
SCTP n’est donc pas intrinsèquement plus rapide que TCP. Son avantage réside dans le multiplexage et la flexibilité des mécanismes de livraison.
DTLS : la sécurité des échanges
DTLS (Datagram Transport Layer Security) assure la protection cryptographique des échanges, leur confidentialité et leur intégrité, ainsi que l’authentification des extrémités de la connexion sécurisée.
UDP : le transport sous-jacent
UDP transporte les datagrammes sans garantir lui-même leur livraison ni leur ordonnancement.
Les mécanismes nécessaires à la fiabilité sont assurés par SCTP lorsque l’application en a besoin.
Cette combinaison permet de prendre en charge des échanges applicatifs interactifs tout en conservant les mécanismes de sécurité nécessaires.
7. NG-RTC est-il réservé à la VoNR ?
NG-RTC est une évolution des services IMS et non une fonctionnalité exclusivement liée à la 5G NR. La VoLTE et la VoNR utilisent toutes deux l’architecture IMS.
La différence réside principalement dans le réseau d’accès et le cœur de réseau :
- VoLTE : LTE, EPC et IMS.
- VoNR : 5G NR, 5GC et IMS.
Les IMS Data Channels peuvent être utilisés sur différents accès compatibles, sous réserve de la prise en charge des fonctionnalités par les terminaux et les infrastructures.
La 5G SA peut offrir un environnement favorable à certains services enrichis grâce à ses mécanismes de qualité de service et aux capacités du réseau.
Il serait toutefois incorrect d’affirmer que la VoNR constitue un prérequis obligatoire à NG-RTC.
8. L’évolution des IMS Data Channels dans les Releases 3GPP
L’architecture IMS Data Channel s’est progressivement structurée dans les spécifications 3GPP.
| Release | Principales évolutions |
|---|---|
| Release 18 | Introduction de l’architecture IMS Data Channel dans l’annexe AC de TS 23.228 : DCSF, DCAR, MF, DC AS et procédures de gestion des canaux. |
| Release 19 | Améliorations architecturales et procédurales, concernant l’interfonctionnement, les sessions Data Channel autonomes et le multiplexage applicatif SCTP. |
| Release 20 — travaux en cours | Étude SA4 TR 26.814 sur les améliorations des IMS Data Channels et la clarification de certaines ambiguïtés d’interopérabilité. |
La Release 18 constitue une étape structurante dans la normalisation de l’architecture.
La Release 19 apporte des améliorations destinées à enrichir les possibilités d’utilisation et à faciliter l’interfonctionnement.
Les travaux ultérieurs portent sur la clarification des comportements protocolaires et l’interopérabilité entre implémentations.
Cette progression illustre une distinction essentielle : une fonction peut être normalisée sans être immédiatement disponible ou interopérable dans les réseaux commerciaux.
9. Quels enjeux pour les opérateurs télécoms ?
Les IMS Data Channels ouvrent des perspectives intéressantes, mais leur déploiement ne dépend pas uniquement de leur faisabilité technique.
Valoriser les services de communication
Les opérateurs peuvent envisager des services enrichis, pour les relations entre entreprises et clients.
L’appel téléphonique devient potentiellement un environnement d’interaction intégrant voix, vidéo et données applicatives.
Assurer l’interopérabilité
Les services doivent fonctionner entre différents terminaux, infrastructures IMS et fournisseurs d’équipements.
Les travaux de clarification des spécifications sont donc particulièrement importants pour les déploiements multi-constructeurs.
Garantir la sécurité
Les IMS Data Channels introduisent de nouveaux échanges applicatifs et de nouvelles interfaces.
La protection des données, l’authentification, la sécurité des applications et la maîtrise des interactions avec les serveurs tiers constituent des exigences essentielles.
Prendre en compte l’interception légale
L’interception légale (Lawful Interception) représente un enjeu réglementaire majeur.
Les Data Channels peuvent transporter des contenus applicatifs protégés par DTLS, avec différents modèles de terminaison de la sécurité.
Ces mécanismes soulèvent des questions sur les capacités d’interception et la fourniture des informations légalement requises.
La spécification 3GPP TS 33.328 traite de la sécurité du plan média IMS, mais ne définit pas elle-même l’architecture d’interception légale.
Des propositions discutées dans les groupes de normalisation soulignent la nécessité de clarifier et de compléter les mécanismes applicables aux IMS Data Channels.
Ces positions doivent être distinguées des exigences définitivement adoptées : elles reflètent des travaux de normalisation en cours.
Pour les opérateurs soumis à des obligations d’interception légale, cette question peut constituer un frein important au déploiement commercial tant que les mécanismes de conformité ne sont pas suffisamment définis et implémentés.
Construire un modèle économique viable
Enfin, l’intérêt technologique ne garantit pas l’adoption commerciale.
Les opérateurs doivent également évaluer les investissements nécessaires, les capacités des terminaux, les besoins réels des utilisateurs et les modèles de partenariat avec les fournisseurs d’applications.
Le déploiement de NG-RTC dépend donc autant de la maturité de l’écosystème que des possibilités offertes par les spécifications.
Conclusion : du service téléphonique à la plateforme de communication interactive
Le MMTEL AS a joué un rôle essentiel dans la modernisation de la téléphonie mobile en permettant de fournir des services téléphoniques avancés sur une architecture IMS entièrement IP.
Avec NG-RTC et les IMS Data Channels, cette architecture franchit une nouvelle étape.
L’appel téléphonique peut désormais devenir un environnement de communication intégrant des interactions applicatives, des échanges de données et de nouveaux services multimédias.
Cette évolution ne remet pas en cause les principes fondamentaux de l’IMS.
Au contraire, l’IMS Application Server conserve un rôle central dans la coordination des services, tandis que de nouvelles fonctions spécialisées prennent en charge le contrôle des Data Channels, les ressources média et les applications.
Pour les opérateurs, l’enjeu est désormais de transformer ces possibilités techniques en services interopérables, sécurisés, conformes aux exigences réglementaires et économiquement viables.
NG-RTC ne remplace pas la téléphonie IMS : il en élargit les possibilités.
Références techniques
- 3GPP TS 23.228 — IP Multimedia Subsystem (IMS), annexe AC relative aux IMS Data Channels.
- 3GPP TS 24.186 — IMS Data Channel, procédures et protocoles.
- 3GPP TS 29.175 — Interfaces de services pour les fonctions IMS Data Channel.
- 3GPP TS 33.328 — Sécurité du plan média IMS.
- 3GPP TR 26.814 — Étude des améliorations IMS Data Channel.
- GSMA RCC.20 — Enriched Calling.
- GSMA NG.134 — IMS Data Channel.
- RFC 4975 — Message Session Relay Protocol.
- RFC 8831 — WebRTC Data Channels.