Serveur d’application IMS : où réside la logique de service dans le cœur IMS

Un cœur IMS peut enregistrer un abonné, l’authentifier et router une session vers sa destination sans jamais délivrer la moindre fonctionnalité. Le renvoi d’appel, la mise en attente, la conférence multipartite, le SMS sur IP, le transfert qui maintient un appel mobile en vie lorsqu’il quitte la couverture LTE : rien de tout cela ne vit dans la couche de routage. Tout cela vit dans le serveur d’application. Le S-CSCF sait comment atteindre le bon serveur d’application et quand l’invoquer, mais la logique de service elle-même se situe un plan au-dessus, dans un logiciel conçu exactement pour ce travail.

Cet article se concentre spécifiquement sur le serveur d’application (AS) : ce qu’il est, l’interface ISC qui le connecte au cœur IMS, comment le S-CSCF décide de lui transmettre une session, les modes dans lesquels il peut fonctionner, et les serveurs d’application courants qu’un ingénieur voix rencontre réellement en production. Si vous souhaitez d’abord l’architecture IMS complète, notre guide sur ce qu’est l’IMS couvre le plan de contrôle et les passerelles. Ici, nous approfondissons l’unique élément où naissent les fonctionnalités. TelcoBridges travaille depuis plus de vingt ans à la frontière où ce trafic rencontre le reste du monde.

Qu’est-ce qu’un serveur d’application IMS

L’IMS est généralement représenté comme trois plans horizontaux : un plan d’accès où le terminal se connecte, un plan de contrôle qui enregistre les utilisateurs et route les sessions, et un plan applicatif où s’exécute la logique de service. Le serveur d’application vit dans ce plan supérieur. Là où les éléments du plan de contrôle se préoccupent d’atteindre le bon abonné, l’AS se préoccupe de ce qui se passe une fois la session en cours : s’il faut la transférer, la dupliquer vers plusieurs destinations, jouer une annonce, la mettre en attente ou générer un message de son propre chef.

Un AS est une entité SIP spécialisée. Il parle le même Session Initiation Protocol que le reste du cœur, défini dans le RFC 3261, et du point de vue du S-CSCF c’est simplement une autre destination SIP vers laquelle les sessions peuvent être routées. Les équipementiers vendent des produits serveur d’application, et chacun transpose le comportement normalisé dans son propre logiciel, mais l’architecture de référence et l’interface vers le cœur restent cohérentes. C’est ce qui permet à un opérateur d’acheter un serveur d’application de téléphonie chez un fournisseur et un serveur d’application de messagerie chez un autre, et de les faire fonctionner tous les deux derrière le même S-CSCF. Si la couche protocolaire n’est pas familière, notre introduction aux fondamentaux de la signalisation SIP couvre les méthodes et les réponses sur lesquelles tout ceci repose.

L’architecture est définie par le 3GPP, principalement dans le TS 23.228 pour l’IMS global et dans le TS 23.218 pour l’interaction entre l’AS et le cœur. Le point à retenir est la séparation des responsabilités : le cœur route, l’AS délivre les fonctionnalités, et une seule interface SIP relie les deux.

L’interface ISC : comment le cœur atteint l’AS

Le lien entre le S-CSCF et un serveur d’application est l’interface ISC, abréviation d’IP Multimedia Service Control. Ce n’est pas un nouveau protocole. L’ISC est du SIP, utilisé comme point de référence avec un comportement défini, c’est pourquoi un AS peut être traité comme un serveur SIP ordinaire par le reste du cœur.

Lorsque le S-CSCF décide qu’une session a besoin de logique de service, il route la requête vers l’AS via l’ISC, l’AS fait son travail, et dans la plupart des cas l’AS renvoie la session au S-CSCF pour qu’elle continue vers sa destination. La session quitte la couche de routage, traverse la couche de fonctionnalités et revient. Cet aller-retour est ce qui rend les fonctionnalités composables : le S-CSCF peut envoyer une seule session à travers plusieurs serveurs d’application successivement, chacun ajoutant son propre comportement, sans qu’aucun d’entre eux n’ait besoin de connaître les autres.

Parce que l’ISC est du SIP, l’AS voit la même ligne de requête, les mêmes en-têtes et le même corps SDP qui circulent sur n’importe quel trunk. Si vous souhaitez une vue au niveau des champs de ce que contiennent ces messages, notre référence sur le flux d’appel SIP étape par étape les parcourt un par un. La différence dans l’IMS n’est pas les messages eux-mêmes mais l’orchestration qui les entoure, et cette orchestration est pilotée par l’élément suivant.

Comment le S-CSCF décide d’invoquer un AS

Le S-CSCF ne transmet pas chaque session à chaque serveur d’application. Il consulte un ensemble de règles appelées Initial Filter Criteria, les iFC, qui résident dans le profil de service de l’abonné. Ce profil est stocké dans le Home Subscriber Server (HSS) et téléchargé vers le S-CSCF lorsque l’utilisateur s’enregistre, de sorte qu’au moment où une session arrive, le cœur connaît déjà les droits de service de l’abonné.

Chaque entrée dans les iFC associe un déclencheur à une cible. Le déclencheur est construit à partir d’un ou plusieurs Service Point Triggers, les SPT, chacun testant quelque chose à propos de la requête : la méthode SIP, la direction de la session, la présence ou la valeur d’un en-tête, ou une ligne dans le SDP. Lorsqu’une requête correspond, le S-CSCF la route via l’ISC vers le serveur d’application nommé dans cette entrée. Les entrées portent une priorité, de sorte que le S-CSCF les évalue dans l’ordre et peut chaîner plusieurs serveurs d’application dans une seule session, chacun invoqué lorsque son propre déclencheur se déclenche.

Un serveur d’application a souvent besoin de plus d’informations sur l’abonné que ce qu’une seule requête SIP transporte. Pour cela, il communique directement avec le HSS via l’interface Sh, un point de référence Diameter qu’il utilise pour lire et écrire les données de service dont une fonctionnalité dépend, comme un numéro de renvoi ou une liste de présence. La division reste nette : les iFC décident s’il faut invoquer l’AS, l’ISC transporte la session vers lui, et le Sh fournit les données d’abonné sur lesquelles le service s’exécute.

Les modes de fonctionnement d’un serveur d’application

Le 3GPP TS 23.218 définit comment un serveur d’application se comporte en tant qu’entité SIP, et le comportement n’est pas un rôle unique et figé. Selon la fonctionnalité qu’il délivre, un AS agit dans l’un de plusieurs modes sur l’interface ISC.

En tant qu’agent utilisateur terminant, l’AS est le point final de la session. Un serveur de messagerie vocale qui répond à un appel que l’abonné n’a pas décroché agit de cette manière, mettant fin à la session plutôt que de la transmettre. En tant qu’agent utilisateur originant, l’AS crée une session de son propre chef, c’est ainsi qu’un serveur génère un appel de notification ou envoie un message qu’aucun abonné n’a initié. En tant que proxy SIP, l’AS observe et transmet la requête avec des modifications mineures, adapté à la journalisation, au filtrage ou aux décisions de routage légères où la session n’est pas transformée.

Le mode le plus puissant est le Back-to-Back User Agent (B2BUA), où l’AS termine le segment entrant et en génère un nouveau, lui donnant un contrôle total de la session. Le contrôle d’appel tiers dépend de ce mode : des fonctionnalités comme le transfert d’appel, la conférence et le renvoi complexe nécessitent que l’AS manipule les deux côtés d’un appel, ce qu’un proxy ne peut pas faire. La distinction entre un proxy de transmission et un véritable B2BUA est la même que celle qui sépare un routeur léger d’un véritable contrôleur de session, et notre article sur ce qu’est un proxy SIP versus un B2BUA explique exactement pourquoi la différence compte. Un AS peut également agir comme serveur de redirection SIP, indiquant au cœur où envoyer la session au lieu de la transporter.

Les serveurs d’application courants et ce qu’ils font

Les normes laissent l’AS délibérément générique pour que n’importe quel service puisse être construit dessus, mais une poignée de serveurs d’application apparaissent dans presque tous les réseaux d’opérateurs, chacun avec une mission reconnaissable.

Le MMTel AS, pour la téléphonie multimédia, est celui que la plupart des sessions traversent. Il délivre les services supplémentaires que les abonnés attendent d’une ligne téléphonique : la mise en attente et la reprise, le renvoi d’appel dans ses différentes déclinaisons, l’interdiction d’appel, la conférence multipartite et les services d’identité qui présentent ou masquent le numéro de l’appelant. Lorsqu’un abonné VoLTE renvoie un appel ou rejoint une conférence, le MMTel AS est l’élément qui le rend possible.

Le SCC AS, pour la centralisation et la continuité de service, existe pour maintenir les sessions en vie à travers les frontières. Sa fonction la plus connue est le SRVCC, la continuité d’appel voix à radio unique, qui transfère un appel VoLTE en cours vers un réseau à commutation de circuits lorsque l’abonné sort de la couverture LTE. Pour cela, le SCC AS ancre la session de sorte qu’il y ait un point de contrôle fixe à transférer, ce qui n’est possible que parce qu’il se trouve dans le chemin en tant que B2BUA.

L’IP-SM-GW, la passerelle de messages courts sur IP, transporte les SMS sur le réseau IMS. Elle assure l’interfonctionnement des messages courts entre le domaine IP et l’infrastructure SMS historique, de sorte qu’un message envoyé depuis un terminal VoLTE atteigne un abonné sur un réseau plus ancien et inversement. La messagerie et les services enrichis suivent le même modèle : un serveur de présence suit qui est disponible, et un serveur d’application RCS délivre les services de communication enrichis qui étendent la messagerie simple. Si vous évaluez le volet messagerie de l’IMS, notre comparaison RCS versus SMS couvre les cas d’usage de chacun.

Au-delà de ceux-ci, les opérateurs exploitent des serveurs d’application pour tout, des tonalités de rappel à l’enregistrement réglementaire. La forme est toujours la même : une entité SIP que le S-CSCF invoque par iFC, communiquant avec le HSS via Sh pour les données d’abonné dont la fonctionnalité a besoin.

Enregistrement tiers : comment un AS sait que vous êtes en ligne

Une fonctionnalité comme le renvoi d’appel ou la présence n’est utile que si le serveur d’application sait si l’abonné est enregistré. L’AS ne voit pas le REGISTER original, parce que celui-ci circule entre le terminal et le S-CSCF, alors l’IMS utilise un mécanisme appelé enregistrement tiers pour combler cette lacune.

Lorsqu’un abonné s’enregistre et que le S-CSCF charge son profil de service, les iFC peuvent inclure un déclencheur qui se déclenche sur le REGISTER lui-même. Lorsque c’est le cas, le S-CSCF envoie un REGISTER séparé au serveur d’application nommé au nom de l’abonné. Cet enregistrement tiers informe l’AS que l’utilisateur est maintenant en ligne et quel S-CSCF le dessert, de sorte que l’AS peut s’abonner aux événements d’enregistrement, préparer son état et être prêt dès qu’une session arrive. C’est la poignée de main silencieuse qui permet à un serveur de fonctionnalités de rester synchronisé avec un abonné auquel il ne parle jamais directement lors de la connexion.

Où le SBC se situe par rapport au serveur d’application

Pour quiconque achète, déploie ou exploite des Session Border Controllers, la question utile est de savoir comment l’AS et le SBC sont liés. Ils sont complémentaires, pas concurrents. Le serveur d’application se situe dans le plan applicatif et possède la logique de service. Le SBC se situe aux frontières du réseau et possède la frontière, en périphérie d’accès vers les terminaux et à l’interface réseau-à-réseau vers les autres opérateurs. Un SBC n’héberge pas de fonctionnalités, et un AS ne sécurise pas un périmètre.

Les deux interagissent néanmoins, parce que le trafic façonné par un serveur d’application doit traverser les mêmes frontières que tout le reste. Lorsqu’un AS ancre des médias, par exemple une annonce ou un pont de conférence issu de la fonction de ressource média, ces médias entrent et sortent tout de même du réseau par le SBC. Lorsque des sessions traitées par un AS sont transmises à un autre opérateur, le SBC à l’interface réseau-à-réseau effectue le masquage de topologie pour que les adresses internes du cœur et de ses serveurs d’application ne soient jamais exposées au côté distant. Et parce que différents opérateurs exploitent des serveurs d’application de différents équipementiers, le SBC normalise le SIP entre les dialectes que chaque côté parle, de sorte qu’une session qui a quitté l’AS d’un réseau soit comprise par le suivant. Cette normalisation est le même travail d’interopérabilité multi-équipementier qu’un SBC fait sur toute interconnexion, ici appliqué au trafic issu de l’IMS.

Il y a un mode qui mérite d’être nommé explicitement. Un AS riche en fonctionnalités et un SBC de niveau opérateur fonctionnent tous deux comme des Back-to-Back User Agents, mais pour des fins différentes. L’AS est un B2BUA dans le cœur pour pouvoir contrôler les deux segments d’un appel afin de délivrer un service. Le SBC est un B2BUA à la frontière pour pouvoir terminer et régénérer complètement la signalisation et les médias, ce qui rend possibles le masquage de topologie, la manipulation des en-têtes et la sécurité média. Même architecture, endroit différent dans le réseau, travail différent.

Questions fréquemment posées

Conclusion

Le serveur d’application est l’endroit où l’IMS cesse de router et commence à délivrer. Le S-CSCF l’atteint via l’interface ISC basée sur SIP, décide quand l’invoquer à partir des Initial Filter Criteria du profil de l’abonné, et peut chaîner plusieurs serveurs d’application dans une seule session. Le MMTel AS couvre les fonctionnalités de téléphonie, le SCC AS maintient les appels en vie à travers les transferts, l’IP-SM-GW transporte la messagerie, et l’enregistrement tiers maintient chacun synchronisé avec l’abonné. Pour un ingénieur voix à la frontière, la leçon est la délimitation : la logique de service appartient au serveur d’application dans le cœur, tandis que la périphérie contrôlée et sécurisée que ce trafic traverse appartient au SBC.