Services Ims Efort

Architecture de Services IMSEFORT http://www.efort.comL introduction de l IMS (IP Multimedia Subsystem) dans les rseaux fixe et mobile reprsente un changement fondamental dans les rseaux de tlcommunication de type voix. Les nouvelles capacits des rseaux et des terminaux, le mariage entre l Internet et la voix, le contenu et la mobilit donnent naissance des nouveaux modles de rseaux et surtout offrent un formidable potentiel pour dvelopper de nouveaux services. Dans cet objectif, l IMS est conu pour offrir aux utilisateurs la possibilit d tablir des sessions multimdia en utilisant un rseau IP. L architecture de l IMS utilise le protocole SIP (Session Initiation Protocol) dfini par l IETF. Les opportunits de dveloppement de ce protocole suscitent depuis quelques annes un engouement considrable des communauts informatiques et des tlcommunications. Ceci laisse penser que les futurs services de communication multimdia dans les rseaux seront en grande partie bass sur le protocole SIP. Par consquent, l IMS introduit deux aspects fondamentaux : Un rseau de transport bas sur le protocole IP pour tout type de communication un modle d appel (session) comprenant le multimdia. Ces deux aspects sont trs importants car ils peuvent bouleverser les processus de communication et apportent la dimension multimdia dans les communications. Les rseaux fixes et mobiles ne se contentent plus d tre un rseau tlphonique classique. L IMS est d ailleurs la seule architecture de service IP Multimdia, permettant l accs des serveurs d application. L IMS permet d tablir des communications entre multiples terminaux/utilisateurs, et il permet d intgrer des services temps-rel, pseudo temps-rel et non temps-rel dans une mme session. De plus, il est possible de crer de nouveaux usages en utilisant des interactions entre ces services. Le premier paragraphe prsente larchitecture de service IMS. Le second paragraphe dcrit le profil de lusager avec ses profils de service associs. Le paragraphe 3 introduit lentit serveur dapplication travers ses fonctions, ses interfaces et ses modes dopration. Le paragraphe 4 dtaille les fonctions du serveur de mdia ainsi que ses interfaces. Le cinquime paragraphe numre les capacits de service dfinies pour IMS.

1 Architecture de service IMSL'architecture de service consiste en un ensemble de serveurs d'application interagissant avec le rseau IMS (i.e., S-CSCF) travers l'interface ISC (IP Multimedia Service Control) supporte par le protocole SIP (Figure 1). Les serveurs d'application sont : Les serveurs d'application SIP qui excutent des services (e.g., Push To Talk, Prsence, Confrence, Instant messaging, etc.) et qui peuvent influencer le droulement de la session la demande du service. Le point de commutation au service IMS (IM-SSF, IP Multimedia Service Switching Function) qui est un type particulier de serveur d'application qui termine la signalisation SIP sur l'interface ISC d'une part et qui joue le rle de SSP CAMEL d'autre part (i.e., il dispose des modles d'appel O-IM-BCSM et T-IM-BCSM, des points de dtection CAMEL et du protocole CAP) pour interagir avec les plates-formes de service CAMEL appeles CSE (CAMEL Service Environment).

Copyright EFORT 2010

La passerelle OSA (OSA SCS, OSA Service Capability Server) qui est un type particulier de serveur d'application qui termine la signalisation SIP sur l'interface ISC et qui interagit avec des serveurs d'application OSA en utilisant l'API OSA. Un type spcialis de serveur d'application SIP appel gestionnaire d'interaction de service (SCIM, Service Capability Interaction Manager) qui permet la gestion des interactions entre serveurs d'application SIP.

Lentit S-CSCF invoque les applications via linterface ISC supporte par le protocole SIP. Les Serveurs d'application SIP peuvent interagir avec le HSS afin dobtenir les donnes de service dun usager donn travers l'interface Sh qui s'appuie sur le protocole DIAMETER. L'entit S-CSCF interagit avec le HSS pour obtenir les profils de service de l'usager en utilisant l'interface Cx supporte par le protocole DIAMETER. L'interface Si permet au serveur d'application IM-SSF d'obtenir auprs du HSS les informations de souscription CAMEL d'un usager donn, i.e., O-IM-CSI et T-IM-CSI. Cette interface est supporte par le protocole MAP. L'entit CAMEL Service Environment (CSE) correspond au concept de Service Control Point (SCP) du Rseau Intelligent. Le CSE dialogue d'une part avec l'entit IM-SSF travers le protocole CAP Phase 4 (CAMEL Application Part) et d'autre part avec le HSS en utilisant le protocole MAP.

AS

AS

SCIMSIP Application SIP Application Ser ver Ser ver

Sh ISCOSA service OSA service capability server capability server (SCS) (SCS) OSA OSA application application server serverOSA API

HSS HSS

S-CSCF S-CSCF Cx Si ISC

ISC

Mr IM-SSF IM-SSFMAP

CAPCamel Service Camel Service Environment Environment

MRFC MRFC

Figure 1 : Architecture de service IMS Larchitecture dispose aussi de serveur de mdia appel MRF (Multimedia Resource Function). Ce dernier tablit des confrences multimdias, joue des annonces vocales ou multimdia et collecte des informations utilisateur. Il sagit de lvolution de lentit SRF (Specialized Resource Function) dans le monde multimdia. L'entit MRF est dcompose en deux fonctions : La fonction MRFP (MRF Processor) qui traite le mdia travers le transport RTP/UDP/IP, La fonction MRFC (MRF Controller) qui traite la signalisation. L'interface Mr entre les entits S-CSCF et MRFC est supporte par le protocole SIP.


Tous les serveurs d'applications (IM-SSF et OSA SCS inclus) se comportent comme des serveurs d'application SIP. Par ailleurs ces serveurs d'application peuvent interagir avec l'entit MRFC travers le S-CSCF afin de contrler les activits mdia mises en uvre par l'entit MRFP.

2 Profil dusager et profil de serviceA chaque usager IMS est associ un profil dusager dans le HSS. Un profil dusager consiste en un ensemble de profils de service. Un profil de service contient (Figure 2): une ou plusieurs IMPUs (IMS Public User Identities) ayant la forme dune adresse tlphonique ou dune URI SIP, zro ou une instance de la classe Core Network Service Authorization indiquant les diffrents mdia pouvant tre utiliss pour les sessions tablies avec ces identits publiques, un ensemble (0 N) de critres de filtrage (iFC, initial Filter Criteria). Un critre de filtrage est une information statique correspondant une souscription d'un usager un service du domaine IMS. Un ensemble (0 N) de Shared iFC set. Un Shared iFC Set pointe sur un ensemble diFC administrs localement et stocks sur le S-CSCF. Un Shared iFC Set peut tre partag par plusieurs profils de service, permettant de minimiser la taille du profil de lusager.

Le profil de service est obtenu par l'entit S-CSCF auprs du HSS travers l'interface Cx lorsque l'usager s'enregistre au sous-systme IMS. Dans le futur, on pourra envisager des critres de filtrage dynamiques, la manire de points de dtection programmables dynamiquement dans les modles d appel O-BCSM et T-BCSM du rseau intelligent. Un critre de filtrage ne peut s'appliquer qu' une mthode SIP qui est une requte initiale, c'est dire REGISTER, INVITE, SUBSCRIBE, MESSAGE. Un critre de filtrage consiste en les informations suivantes : AS address : Adresse du serveur d'application contacter (adresse SIP) Priority : Priorit du critre de filtrage indiquant sa position dans la liste. Trigger Point : Un trigger Point est compos de une N instances de SPTs (Service Point Trigger). Des SPTs peuvent tre combins laide d'oprateurs logiques (AND, OR, NOT, etc.). Default handling : Prise en charge par dfaut si l'entit S-CSCF n'arrive pas contacter l'AS Optional Service Information : Information de service facultative rajoute au contenu de la mthode SIP avant qu'elle soit achemine l'AS (e.g., l'IMSI).


Service Profile

1...n Public Identification

0...1 Core Network Service Authorization Subscribed Media Profile Id: Integer

0...n Initial Filter Criteria

0...n Shared iFC Set Identifier: Integer

Figure 2 : Profil de service Des points de dclenchement de service appels Service Point Triggers (SPTs) sont des points dans la signalisation SIP sur lesquels des conditions (Filter Criteria) peuvent tre places. Les points de dclenchement suivants sont dfinis : Request-URI : identifie la ressource adresse par la requte (e.g., sip:[email protected]) Initial method : Toute mthode initiale SIP connue ou inconnue (e.g. REGISTER, INVITE, SUBSCRIBE, MESSAGE); Registration type : indique si la requte REGISTRE reprsente un enregistrement initial ou r-enregistrement ou annulation denregistrement. SIP header : prsence ou absence dun header connu ou inconnu; ou contenu dun header connu ou inconnu. La valeur du contenu est une chane de caractres interprte comme une expression rgulire. Session case : Sens de la requte SIP tel que originating ou terminating_registered pour un usager enregistr ou terminating_unregistered pour un usager non enregistr Session Description : Dfinit un SPT pour le contenu de tout champ SDP dans le corps dune mthode SIP.

Lorsqu'une entit S-CSCF reoit une requte SIP concernant un usager donn, elle value les critres de filtrage associs cet usager un un selon leur ordre de priorit. Si la requte SIP vrifie le critre de filtrage, l'entit S-CSCF achemine la requte SIP au serveur d'application correspondant (i.e., AS SIP, IM-SSF, OSA SCS). Une priorit est affecte chaque Filter Criteria afin de permettre au S-CSCF de les traiter dans l'ordre. Si l'entit S-CSCF ne peut pas joindre le serveur d'application (AS, Application Server) associ un critre de filtrage (e.g., Serveur d application hors service), elle applique une prise en charge par dfaut indique dans le critre de filtrage par le paramtre "Default call handling" dont la valeur peut tre : Continuer analyser les critres de filtrage de plus basse priorit dans la liste (continue), ou Abandonner l'analyse des autres critres de filtrage et librer le dialogue (release). Considrons le cas dun client souscrivant aux services IMS suivants : Filtrage dappel larrive (TCS, Terminating Call Screening), Renvoi dappel sur occupation (CFB, Call Forwarding on Busy et Customized Ring-Back Tone (CRBT). Son profil de service contient trois Filter Criteria


FC1 AS address = sip:[email protected] Priority = 1 Tigger point = [(Initial method = INVITE) AND (Session case = Terminating_Registered)] Default handling : Release FC2 AS address = sip:[email protected] Priority = 2 Trigger point = [(Initial method = INVITE) AND (Session case = Terminating_Registered)] Default handling : Release FC3 AS address = sip:[email protected] Priority = 3 Trigger point = [(Initial method = INVITE AND (Session case = Terminating_Registered) AND (Session Description Line = m Content = audio OR video)] Default handling : Continue Si l on considre le mme exemple mais avec un SCIM, le profile de service de l usager n aura qu un seul Filter Criteria comme suit : FC1 AS address = sip:[email protected] Priority = 1 Tigger point = [(Initial method = INVITE) AND (Session case = Terminating_Registered)] Default handling : Release Pour tout appel entrant (INVITE), si l appel est enregistr, l INVITE sera soumis par le SCSCF au workflow du SCIM qui saura traiter cette combinaison de service. Le SCIM joue le rle de B2BUA. Il termine la requte INVITE, invoque le service TCS, puis le service RBT. Si l appel n est pas occup, il n aura pas invoqu le service CFB. Sans le SCIM, le S-CSCF invoquera systmatiquement TCS, CFB puis CRBT.

2.1

Invocation d'un service pour un appel sortant

Lorsqu'une requte SIP initiale est reue par l'entit S-CSCF, cette dernire vrifie si des Filter Criteria sont prsents pour l'usager appelant et si leur Trigger Point correspondant indique le SPT (direction = originating). Si de tels Filter Criteria existent, l'entit S-CSCF doit : Vrifier si la requte SIP est en adquation avec le Filter Criteria de plus haute priorit de cet usager. Dans l'affirmative, le S-CSCF relaye la requte SIP au serveur d'application dont l'adresse est spcifie dans le Filter Criteria. Le S-CSCF applique le Filter Criteria de priorit juste infrieure sur la mthode SIP retourne par le serveur d'application. Dans la ngative, le S-CSCF applique le Filter Criteria de priorit juste infrieure la requte SIP. Lorsque tous les Filter Criteria ont t traits selon la procdure vue ci-dessus, le SCSCF route la requte en fonction des informations fournies par le dernier serveur d'application invoqu.

2.2

Invocation d'un service pour un appel entrant

Lorsqu'une requte SIP initiale est reue par l'entit S-CSCF, cette dernire vrifie si des Filter Criteria sont prsents pour l'usager appel et si leur Trigger Point correspondant indique le SPT (direction = MT). Si de tels Filter Criteria existent, l'entit S-CSCF doit :


Vrifier si la requte SIP est en adquation avec le Filter Criteria de plus haute priorit de cet usager. Dans l'affirmative, le S-CSCF relaye la requte SIP au serveur d'application dont l'adresse est spcifie dans le Filter Criteria. Le S-CSCF applique le Filter Criteria de priorit juste infrieure sur la mthode SIP retourne par le serveur d'application. Dans la ngative, le S-CSCF applique le Filter Criteria de priorit juste infrieure la requte SIP. Lorsque tous les Filter Criteria ont t traits selon la procdure vue ci-dessus, le SCSCF route la requte en fonction des informations fournies par le dernier serveur d'application invoqu.

3 Lentit Application Server (AS)3.1 Fonctionnalits dun AS

Un serveur d application SIP fournit un environnement d excution pour des applications, appel SLEE (Service Logic Execution Environment). Il fournit un ensemble de services permettant de simplifier les tches des dveloppeurs d application et des administrateurs. Le but est de disposer d une plate-forme mettant en uvre toutes les fonctionnalits permettant ainsi au dveloppeur de ne se focaliser que sur la logique mtier de l application. Les fonctions dun serveur d application sont : La gestion des ressources : Le serveur d application contrle la cration et l utilisation des ressources telles que les threads, les connexions de transport, les composants applicatifs (e.g., scripts CPL, servlets SIP) ainsi que les sessions d application. La gestion d application : L application peut tre associe un profil de configuration lors de son dploiement. Ce profil peut contenir des paramtres pouvant tre modifis travers l interface administrative lors du dploiement de l application ou pendant son excution. La composition d application : Le serveur d application doit permettre l excution de plusieurs applications pour une mme requte SIP. Cela fournit une capacit de modularisation. En effet, des lments de service peuvent tre dvelopps indpendamment et peuvent tre combins en fonction des besoins d application. Cela permet par ailleurs un meilleur contrle des interactions de service. L intgration WEB : afin de fournir une GUI Web pour l administration et pour l interfonctionnement avec des serveurs WEB fournissant des services. La programmation : Le serveur d application fournit un support pour le dveloppement d application, i.e., des APIs (JAIN API, SIP Servlet API, etc.) et des langages de script. Les scripts peuvent tre crs l aide d environnements de cration de service. L interfonctionnement : Le serveur d application communique en utilisant le protocole SIP avec le MRF pour les interactions avec l usager et avec le serveur d appel (CSCF) pour le routage de la signalisation. La scurit : Le serveur d application doit fournir des mcanismes d authentification et d autorisation, ventuellement aussi de chiffrement, afin d assurer un accs scuris aux services. Les capacits non fonctionnelles : haute disponibilit, partage de charge, tolrance aux fautes. Ces caractristiques sont similaires celles exiges pour un SCP dans l architecture Rseau Intelligent.

3.2

Interfaces dun AS

LAS dispose de plusieurs interfaces : Une interface de contrle sur la base du protocole SIP par laquelle lAS peut dlguer au MRF des demandes dinteractions avec lusager. Cette interface doit tre conforme aux


spcifications du RFC 4240 de lIETF, intitul Basic Network Media Services with SIP . Une interface daccs aux donnes de service entre lAS et le HSS. L AS utilise linterface Sh de deux faons : Afin de lire ou de modifier une donne de lusager stocke dans le HSS. Afin de souscrire et d tre notifi lorsquune donne dusager est modifie sur le HSS. Les donnes usager peuvent tre des donnes spcifiques un service que lAS excute (repository data) ou des donnes du profil de lusager stocke dans le HSS. La spcification de linterface Sh (3GPP TS 29.328) dfinit les donnes du profil de lusager qui peuvent tre lues ou modifies par linterface Sh. Toutes les donnes usager accessibles par linterface Sh sont prsentes sous la forme de document XML avec un schma dfini dans la recommandation 3GPP TS 29.328. Une interface de taxation qui permet lAS de remonter des tickets de taxation appels AS-CDR au CCF (Charge Collection Function) dans le cas de la taxation offline, et qui permet lAS dobtenir un crdit dans le cas de la taxation online. Linterface de taxation offline est appele Rf et linterface de taxation online est Ro. Rf et Ro sappuient sur le protocole DIAMETER.

3.3

Mode de fonctionnement d'un AS

Un serveur d'application peut utiliser quatre modes de fonctionnement pour le traitement des requtes SIP. Des services peuvent tre conus en utilisant une combinaison de ces modes entre le serveur d'application et l'entit S-CSCF. Dans le mode de fonctionnement "Terminating UA ou Redirect Server", la requte SIP reue par le S-CSCF est route au serveur d'application qui joue le rle de "Terminating UA" ou "Redirect Server". Si le mode est "Terminating UA", le serveur dapplication termine la requte SIP et retourne une rponse lmetteur de la requte SIP. Si le mode est "Redirect Server", alors le serveur dapplication retourne une rponse de redirection lmetteur ; Cette rponse contient ladresse o la destination peut tre contacte. Dans le mode de fonctionnement "Originating UA", le serveur d'application joue le rle de "Originating UA" et gnre une requte SIP qu'il met au S-CSCF ; ce dernier la route vers la destination. Ce mode de fonctionnement correspond l'initiation de la session par le serveur d'application (e.g., click-to-dial). Dans le mode de fonctionnement "Proxy", la requte SIP reue par le S-CSCF est relaye au serveur d'application jouant le rle de "Proxy". Le serveur d'application peut alors modifier le contenu de la mthode SIP reue et la retourner au S-CSCF qui la relayer la destination. Ce mode s'applique par exemple aux services de traduction de numro ou de renvoi d'appel sophistiqu en fonction de l'heure du jour, du jour de la semaine, du numro de l'appelant, etc. Dans le mode de fonctionnement "B2BUA", la requte SIP reue par le S-CSCF est relaye au serveur d'application qui gnre une nouvelle session SIP qu'il envoie au S-CSCF qui la relaye la destination. Le serveur d'application joue le rle de "Back-To-Back User Agent" (B2BUA) et gre ainsi plusieurs legs dans la session indpendamment les uns des autres. Ce mode est adapt pour un service comme Le Customized Ring Back Tone (CRBT). Le serveur d'application correspondant gre trois sessions (trois legs) : La premire avec l'appelant, une seconde avec l'appel et une troisime avec le MRF. Lorsque lappel est alert, il joint les legs relatifs lappelant et au MRF ; ce dernier joue un message personnalis lappelant. Ds que lappel dcroche, le serveur dapplication libre le leg relatif au MRF et joint les leg appelant et appel.


4 Lentit Multimedia Resource Function (MRF)4.1 Fonctionnalits dun MRF

Les fonctionnalits dun MRF (Multimedia Resource Function) incluent les fonctions de contrle du mdia et de ressources mdia. Annonces : La plupart des services volus utilise des formes dannonces, quil sagisse dun message de bienvenue lors de laccs sa boite de message unifie ou dun message dintroduction un portail vocal. Lutilisation dun MRF pour raliser des services dannonces permet de ne pas avoir dployer un nouveau serveur dannonces; rduisant ainsi le nombre dlments de rseau et simplifiant la gestion de rseau. Un quipement de stockage externe peut tre utilis afin de stocker les annonces crant ainsi une solution fiable et scalable. Automated Speech Recognition (ASR, Automated Speech Recognition) : La reconnaissance de la parole est un composant de la plupart des services lusager tels que messagerie vocale (voicemail), la messagerie unifie, les jeux interactifs, et les portails vocaux. Gnration d information de taxation : Une taxation prcise et juste est une exigence pour les oprateurs de service afin d offrir des services voix et donnes forte valeur ajoute. Le MRF gnre des informations de taxation (MRFC-CDR) qui respectent un format standard dfini par le 3GPP. Ces informations sont soumises une entit de mdiation appel CCF (Charge Collection Function). Interactive Voice Response (IVR) : Le MRF doit supporter la dtection des tonalits DTMF envoyes dans la bande ainsi que les digits reus via la mthode SIP INFO. Enregistrement : Le MRF a des capacits d enregistrement et de restitution (playback). De nombreuses applications telles que la messagerie vocale, la messagerie unifie, le push-totalk et la confrence utilisent cette fonction, i.e., enregistrement dun message multimdia afin quil soit restitu ultrieurement. Le MRF utilise des serveurs de stockage existants chez l oprateur de service. Text-To-Speech : La technologie text-to-speech est troitement associe la fonctionnalit IVR. Le text-to-speech est utilis dans des applications telles que la messagerie unifie afin de lire des E-mail ou des fax travers le tlphone. La traduction peut tre ralise en plusieurs langues. Gestion du multiparties : Le MRF doit tre capable de fournir tous les mcanismes de contrle des appels plusieurs participants Cette fonctionnalit est utilise dans de nombreuses applications telles que la confrence ou le push to talk. Transcodage : Le transcodage permet de convertir un schma d encodage numrique en un autre. Dans le cas d une confrence ou les participants ne disposent pas d un mme codec commun, le MRF assurera alors les traductions de mdia ncessaires. Interfaces standard ouvertes : Le MRF doit pouvoir tre contrl travers le protocole SIP et doit pouvoir excuter des scripts VoiceXML.

4.2

Interfaces dun MRF

Le MRF dispose de diffrentes interfaces : Une interface de transport multimdia par laquelle il dlivre des flux audio et vido. Le protocole de transport utilis est RTP (Real-Time Transport Protocol). Le protocole RTCP (Real-Time Control Transport Protocol) peut tre aussi considr notamment pour permettre au serveur de mdia IP de recevoir des feed-back sur la Qos de la session et ainsi produire des tickets de taxation prenant en compte ces informations. RTCP peut aussi tre utilis pour mettre en uvre des mcanismes de contrle de session, e.g., le floor control dans une session push-to-talk. Le "Floor Control" est l'ensemble des moyens permettant de coordonner les diffrentes interventions dans une confrence et de permettre le contrle du partage des ressources (e.g., canaux audio) sans conflit


d'accs. Dans le contexte de la confrence de donnes, les participants peuvent changer travers le MRF des donnes telles que des photos, des fichiers, des messages courts et non pas des flux audio ou vido. Dan ce cas prcis, le protocole utilis est MSRP (Message Session Relay Protocol). Une interface de contrle par laquelle le MRF peut recevoir des commandes depuis un serveur d application. Le protocole de contrle est SIP. Les requtes SIP peuvent contenir des rfrences de messages audio/vido devant tre jous par le MRF ou encore des rfrences de scripts voiceXML devant tre excuts par le MRF. Une interface vers les serveurs de stockage contenant les messages audio/vido jouer. Le protocole HTTP es un exemple de protocole qui peut tre utilis pour crire ou lire les fichiers. Une interface vers les serveurs ASR / TTS tels que ceux de Nuance. Il est aussi possible que le MRF intgre les fonctions ASR/TTS directement. Le protocole utilis entre le MRF et le serveur ASR/TTS externe est MRCP (Media Resource Control Protocol) ou ventuellement SpeechSC (Speech Services Control) appel aussi MRCPv2. Une interface de taxation qui permet au MRF de remonter des tickets de taxation appels MRFC-CDR au CCF (Charge Collection Function) dans le cas de la taxation offline, et qui permet au MRF dobtenir un crdit dans le cas de la taxation online. Linterface de taxation offline est appele Rf et linterface de taxation online est Ro. Rf et Ro sappuient sur le protocole DIAMETER. Une interface de gestion de session interactive permet l usager de contrler sa session interactive similaire un contrle de son magntoscope (avance rapide, marche arrire, pause, etc). Il sagit du protocole RTSP (Real Time Streaming Protocol).

5 Capacits de services IMSLIMS dfinit un ensemble de capacits de service : La capacit de service Multimedia Telephony permet des communications conversationnelles entre deux ou plusieurs participants. Cette capacit inclut les services complmentaires comparables ceux fournis par le domaine circuit tels que le renvoi dappel, le signal dappel, la mise en garde, le rappel automatique sur occupation, etc. La capacit de service Presence permet un usager de souscrire ltat de prsence un contact et dtre notifi chaque changement dtat de ce contact. La capacit de service Push-to-talk over Cellular (PoC, Push To Talk over Cellular) consiste utiliser son tlphone comme un talkie-walkie, simplement en poussant un bouton pour dialoguer les uns avec les autres. La technologie se veut l'quivalent voix du SMS. Le service PoC permet la transmission de messages vocaux entre utilisateurs mobiles sur rseaux de donnes. L'utilisateur slectionne un ou plusieurs correspondants dans son carnet d'adresses, puis presse un bouton sur son terminal pour enregistrer son message vocal. Le message est ensuite encod puis transmis par paquet RTP/UDP/IP via le rseau daccs large bande mobile. La transmission de messages par ce biais introduit un dlai de latence qui n'autorise pas, en thorie, des changes vocaux en "quasi-temps rel", mais qui, en pratique, pourrait voir le service PoC utilis plutt pour des services de type "messagerie instantane vocale". La capacit de service Conference fonctionne selon deux modes: Le mode Ad-hoc qui permet de crer des confrences la demande. Il sagit de confrences non planifies et de courte dure. Le mode pre-arranged (Plannifi) qui permet de crer des confrence lavance en utilisant le protocole Conference Policy Control Protocol (CPCP). Il spcifie un schma XML qui numre les lments d information de politique de confrence permettant l usager de dfinir sa politique de confrence. La capacit de service Messaging fonctionne selon deux modes :


Pager-mode messaging : Des messages SIP contenant les donnes changer son routs de manire asynchrone entre lmetteur et le rcepteur. Session-mode messaging : Une session IMS est tablie pour la session de donne (de type Tchat). Le protocole MSRP est alors utilis pour transporter les donnes entre usagers et non pas le protocole SIP. Les capacits de service Hosted Enterprise Services (IP Centrex), IP TV (Mode broadcast et mode video la demande), video sharing, on aussi t rcemment dfinies.

Les formations proposes par EFORT prsentent outre les aspects architecturaux et normatifs de lIMS, les lments ncessaires llaboration de stratgies de dploiement de business de services sur IP base sur IMS : Mise en uvre des nouveaux services supports par lIMS et les principes de leur facturation ; Scnarii de migration vers une architecture IMS en particulier scnarii de migration du rseau intelligent tlphonique, Niveau des investissements ncessaires, Taxation et facturation des services de lIMS Exploitation des rseaux et des services IMS.


Documents

Services Ims Efort