FR 2870660 A1 20051125 FR 0451003 A 20040519 La présente invention concerne les systèmes et procédés pour échanger des informations dans un réseau informatique entre au moins un utilisateur connecté au réseau et un serveur de média. L'expression réseau informatique doit être comprise avec un sens large et le réseau informatique peut notamment être un réseau de téléphonie mobile troisième génération. L'invention concerne plus particulièrement un réseau informatique dans lequel au moins un serveur d'application (Application Server ou AS) est présent pour permettre l'échange d'informations avec au moins un serveur de média en utilisant le protocole de signalisation SIP (SESSION INITIATION PROTOCOL) . Dans la suite de la description, l'expression serveur de média englobe à la fois les serveurs pour réseau fixe (Media Server ou MS) et les serveurs pour réseau mobile (Media Ressource Function ou MRF) et leurs évolutions et dérivés. Le protocole SIP est décrit notamment dans Internet Engineering Task Force (IETF) Request For Comments (RFC) 3261 (1999) qui est incorporé à la présente par référence. Dans la suite de la description, SIP désignera à la fois le protocole SIP défini ci-dessus et ses évolutions et dérivés. Dans un réseau opérant sous protocole SIP, le serveur d'application est une entité qui est destinée à héberger un ou plusieurs programmes contenant une logique de service, par exemple celle d'un service de transmission de vidéo, de web push, d'une application collaborative telle que le partage d'écran ou la co-navigation, Presence, Immediate Messaging, la téléconférence, le clic pour appeler (click-to-call), la sonnerie simultanée (simultaneous ringing). De nombreux services nécessitent d'établir des dialogues complexes avec l'utilisateur, par exemple pour la reconnaissance DTMF, la reconnaissance vocale et la synthèse vocale ou pour manipuler des flux de média, notamment audio, lors de téléconférences ou de transcodages. Les normes TS 23.228 et TS.23218 ne précisent pas comment se déroulent des interactions vocales complexes comme lire et reporter les tonalités multiples (DTMF) ou générer des annonces multiples comportant des parties fixes et variables, par exemple des dates ou des nombres, et ne fournissent aucune solution pour faire répéter des annonces ou contrôler leur durée. Les normes existantes ne précisent pas non plus comment le serveur de média peut rapporter au serveur d'application les résultats d'une interaction avec l'utilisateur, par exemple le résultat d'une reconnaissance DTMF, laquelle peut être essentielle pour de nombreux services tels que par exemple les services prépayés ou de courrier vocal. Dans la sixième version (Release 6) de l'UMTS, les normes TS 24.147 et TR 29.847 donnent des détails pour gérer une conférence multimédia. Cependant, l'interface entre le serveur d'application et le serveur de média n'est pas abordée par ces nomes 3GPP et il demeure par conséquent un besoin d'expliciter les échanges d'information entre ces entités. Par ailleurs, certains fabricants intègrent le serveur d'application et le serveur de média dans la même entité physique. Une telle intégration présente l'inconvénient de ne pas répondre aux demandes des opérateurs d'avoir deux entités physiquement distinctes, afin par exemple de pouvoir les implanter sur des sites éloignés l'un de l'autre. Il existe également des solutions fondées sur le protocole http pour transporter les résultats de l'exécution d'un script VoiceXML entre un serveur d'application et un serveur média. Des transactions http sont utilisées pour transporter l'information résultant d'une interaction entre l'utilisateur et le serveur média au cours d'une session SIP. Il est nécessaire de corréler la session SIP et les transactions http, ce qui accroît le complexité du développement des applications. La demande de brevet US 2003/0145054 décrit un système de téléconférence entre plusieurs utilisateurs communiquant par des liaisons RTP avec un serveur de média, lequel échange des données avec un serveur d'application. Le serveur de média permet l'établissement de flux de données audio entre différents utilisateurs durant une téléconférence et permet à de nouveaux participants de joindre la conférence. A cet effet, le serveur de média reçoit du serveur d'application des instructions sous la forme de requêtes SIP INVITE. Dans un tel système de téléconférence, le serveur de média n'est pas destiné à interagir avec les utilisateurs pour diffuser des messages (par exemple des messages vocaux) ou interagir vocalement et/ou avec les codes DTMF. Il existe un besoin pour bénéficier de mécanismes additionnels permettant au 30 serveur d'application de contrôler le serveur de média. La présente invention vise notamment à répondre à ce besoin et elle y parvient grâce à un procédé pour contrôler un échange d'informations entre au moins un serveur d'application, au moins un serveur de média et au moins un utilisateur, au cours d'une session SIP, ce procédé pouvant se caractériser par le fait que le serveur d'application adresse au serveur de média une requête SIP contenant dans son corps un script VoiceXML ou un pointeur renvoyant sur un script VoiceXML, lequel peut notamment être présent dans le serveur de média ou dans un serveur de documents, l'exécution de ce script VoiceXML commandant une interaction entre le serveur de média et l'utilisateur. Grâce à l'invention, le développement d'applications est facilité, puisque le transport d'informations au cours d'une même session SIP peut s'effectuer sans avoir à prévoir une interface complexe entre le serveur d'application et le serveur de média. Par VoiceXML on désigne l'application du langage XML (Extensible Markup Language) qui est disponible à l'adresse www.w3.org/xml/ et ses variantes et dérivés capables de gérer des interactions audio entre des humains et les machines (VoiceXML est aussi standardisé par le W3C et est disponible sur le site www.w3.org). Ces interactions peuvent comporter la synthèse vocale, la reconnaissance de la voix ou de commandes DTMF et l'enregistrement de la voix, entre autres. De préférence, la requête SIP précitée est une requête SIP INVITE. Cette requête SIP INVITE peut contenir dans son corps un script VoiceXML. En variante, la requête SIP INVITE peut contenir dans son corps un pointeur renvoyant sur un script VoiceXML. Le script VoiceXML peut décrire par exemple une annonce à lire, une interaction comportant une reconnaissance vocale et/ou basées sur les codes DTMF, ou d'autres interactions encore. Lorsque la requête SIP INVITE contient un pointeur, l'adresse URL du script peut par exemple être envoyée dans le champ d'en-tête nommé RequestURl du message SIP en tant que paramètre. Dans un exemple de mise en oeuvre de l'invention, après l'exécution du script VoiceXML, le serveur de média peut envoyer au serveur d'application au moins une information concernant le résultat de l'interaction avec l'utilisateur sous la forme d'un document au format XML. Ce document au format XML peut être contenu dans le corps d'une requête SIP, notamment la requête SIP INFO. La requête SIP INFO est définie par la norme RFC 2976 (octobre 2000) et permet le transport d'informations sous une forme encapsulée au cours d'une session SIP établie. L'utilisation d'une requête SIP INFO permet plusieurs échanges d'informations entre le serveur d'application et le serveur de média durant une session existante. La requête SIP INFO découple l'établissement de la session SIP et le contrôle des ressources média au cours de la session. Ceci est particulièrement avantageux lorsque plusieurs scripts doivent être exécutés au cours d'une même session SIP. Lorsque la session SIP a déjà été établie entre le serveur de média et le serveur d'application, et que le flux média est aussi établi entre le serveur de média et l'utilisateur, le serveur d'application peut avantageusement envoyer une requête INFO appartenant à la même session SIP au serveur de média, par exemple pour commander l'exécution d'un autre script. En variante, l'échange peut également se faire en utilisant la méthode re-INVITE. L'invention a encore pour objet un système d'échange de données comportant: - un réseau informatique, - au moins un serveur d'application connecté au réseau, - au moins un serveur de média connecté au réseau, le réseau étant agencé pour permettre: - l'établissement d'une session SIP entre un utilisateur et le serveur d'application, un échange de flux média entre l'utilisateur et le serveur de média, et - un échange de données entre le serveur d'application et le serveur de média, système dans lequel le serveur d'application est agencé pour adresser au serveur de média une requête SIP INVITE contenant dans son corps un script VoiceXML ou un pointeur renvoyant sur un script VoiceXML dont l'exécution commande une interaction avec l'utilisateur. Dans un tel système, le serveur de média peut être agencé de manière à envoyer après l'exécution du script VoiceXML au serveur d'application au moins une information concernant le résultat d'une interaction avec l'utilisateur sous la forme d'un script XML. Ce script XML est avantageusement encapsulé dans le corps d'une requête SIP, notamment une requête SIP INFO. Le serveur d'application qui conserve le contrôle du déroulement de la session avec l'utilisateur peut demander au serveur de média l'exécution de plusieurs scripts au cours de la même session SIP. Le serveur d'application est avantageusement configuré pour envoyer au serveur de média, alors qu'une session SIP a été établie, une requête INFO appartenant à cette session, notamment pour commander l'exécution d'un autre script VoiceXML. L'invention pourra être mieux comprise à la lecture de la description détaillée qui va suivre, d'exemples de mise en oeuvre non limitatifs de celle-ci, et à l'examen du dessin annexé, sur lequel: - la figure 1 représente de manière schématique un réseau informatique dans lequel l'invention est susceptible d'être mise en oeuvre, - la figure 2 illustre de manière schématique des échanges de données au cours d'une session de rechargement d'un compte prépayé, et - la figure 3 est un exemple d'architecture 3GPP. On a représenté à la figure 1 un exemple de réseau informatique entre au moins un utilisateur UA (User Agent), au moins un serveur d'application AS et au moins un serveur de média. On a également représenté un serveur S-CSCF entre l'utilisateur et le serveur d'application. Il est bien entendu que le réseau informatique n'est pas limité à une architecture particulière. Son architecture peut notamment être celle illustrée à la figure 3, dans le cas d'un réseau 3GPP connu en soi. L'échange d'informations entre l'utilisateur et le serveur d'application est fondé sur le protocole SIP. Le réseau informatique permet par ailleurs l'établissement d'une liaison Real Time Transport Protocol (RTP) entre l'utilisateur et le serveur de média ou tout autre protocole permettant la transmission de données multimédia. Le protocole RTP est décrit dans IETF RFC 1889 (1996). Conformément à l'invention, le serveur d'application est configuré pour permettre une interaction média complexe avec l'utilisateur en provoquant l'exécution par le serveur de média d'au moins un script VoiceXML décrivant par exemple des interactions vocales et/ou DTMF entre le serveur de média et l'utilisateur. Dans l'exemple considéré, les informations sont transmises entre le serveur d'application et le serveur de média grâce aux requêtes SIP INVITE et INFO. Ces requêtes appartenant à la même session SIP que celle pour laquelle le script est exécuté, il n'y a pas besoin d'un mécanisme additionnel de corrélation comme pour les transactions http telles que visées plus haut. Cela simplifie l'implémentation de la logique du service dans le serveur d'application et dans le serveur de média. Etablissement de la session Une requête SIP INVITE peut être envoyée par le serveur d'application au serveur de média notamment pour initier une session SIP. Cette requête SIP INVITE peut être utilisée pour transporter un script initial de commande au serveur média. Le serveur d'application peut soit adresser un script VoiceXML au serveur de média, soit pointer sur un script VoiceXML. L'envoi d'un script VoiceXML encapsulé dans une requête SIP INVITE est de préférence réservé aux scripts relativement courts, par exemple de longueur inférieure à 1,3 koctets. Lorsque le serveur d'application envoie un script VoiceXML encapsulé dans la requête SIP, le type MIME du contenu du corps peut être fixé à application/Voicexml+xml . Lorsque le serveur d'application envoie au serveur de média un pointeur sur un script VoiceXML, une première possibilité est que l'adresse URL du script à exécuter soit transmise comme un paramètre du champ d'en-tête RequestURl (Universal Resource Identifier) du message SIP. Le serveur d'application peut également associer un SIP URI à chaque script VoiceXML. L'adresse URL du script à exécuter peut encore être aussi transmise comme contenu du corps d'un message SIP, le type MIME du contenu du corps étant fixé à application /uri . Les réponses et la requête ACK renvoyées par le serveur de média au serveur d'application ne devraient de préférence pas contenir d'éléments VoiceXML ou XML. Le corps du message INVITE peut contenir une description SDP en supplément d'une description d'un script VoiceXML ou URI. Ainsi, il est préférable que le serveur d'application et le serveur de média puissent être compatibles avec le type MIME multipart/mixed tel que défini dans RFC 2046. Lors de la réception d'une requête SIP INVITE pour l'exécution du script, le serveur de média peut répondre en envoyant un message d'erreur s'il n'est pas capable 5 d'exécuter le script VoiceXML demandé par manque de ressources disponibles. Pendant le déroulement d'une session SIP établie Une fois la session SIP établie entre le serveur d'application et le serveur de média, des scripts de commande et de réponse peuvent être envoyés entre ces deux entités. Avantageusement, la requête SIP INFO est utilisée pour transporter ces 10 éléments. Pour adresser des résultats pour chaque commande de script, le serveur de média peut répondre avec une requête INFO. De préférence, le serveur de média ne prend pas l'initiative de terminer une session en adressant un message BYE. Lorsque le serveur de média reçoit une requête INFO pour l'exécution d'un script, le serveur de média peut envoyer au serveur d'application une réponse 200 0K lorsqu'il est capable d'effectuer le service. Autrement, lorsqu'aucune resssource n'est disponible, il peut envoyer une réponse 480 'temporally unavailable' ou une réponse 503 Service Unavailable'. Lorsque le serveur d'application reçoit une requête INFO contenant les 20 résultats liés à l'exécution du script, il peut répondre automatiquement avec une réponse 200 0K. En fonction du script, le serveur de média peut renvoyer au serveur d'application des résultats ou non. Dans tous les cas, le serveur de média peut informer le serveur d'application de 25 la fin de l'exécution du script VoiceXML et de la nature de cette fin (fin d'exécution normale du script ou avec erreur). Une fois le script exécuté, le serveur de média envoie une requête INFO au serveur d'application de manière à l'informer de la fin du script et peut éventuellement transmettre des résultats d'exécution, concernant par exemple la nature des touches enfoncées sur le clavier de l'utilisateur. Dans la version 2.0 de VoiceXML, l'exécution d'une application peut se terminer dans les cas suivants: 1) Le standard VoiceXML indique que le traitement de l'élément dépend entièrement du contexte. Si cet élément est rencontré par le serveur de média, il provoque la fin de l'exécution. Une telle fin est considérée comme normale. L'élément peut contenir l'un des deux attributs suivants: i) L'attribut name list. Cet attribut précise les noms de variables à renvoyer par l'élément exit. Par défaut, aucune variable n'est renvoyée. Si une liste de noms de variables est précisée par cet attribut, le serveur de média doit envoyer au serveur d'application, comme résultat de l'exécution, la liste des valeurs de ces variables associées à leurs noms. Les résultats sont envoyés sous la forme d'une chaîne de caractère. Les valeurs des variables du script ECMA tel que défini à l'adresse http://www.ecmainternational.org/publications/standards/ECMA-262.HTM doivent être converties en chaîne de caractères avant d'être envoyées. Les objets du script ECMA ne peuvent pas être envoyés mais le serveur de média peut envoyer les propriétés de l'objet, par exemple date jour ou date.heure. Les enregistrements audios ne doivent normalement pas être envoyés comme résultat dans une requête INFO. De plus, le rôle du serveur d'application n'est pas de gérer les ressources média. Cependant, le serveur de média peut stocker un enregistrement audio dans un serveur http et envoyer l'adresse URL correspondante au serveur d'application comme résultat. A titre d'exemple, on peut avoir les résultats suivants: ii) L'attribut Expr Cet attribut correspond à une expression d'un script ECMA évaluant la valeur du résultat à renvoyer. Une valeur unique est ainsi renvoyée. Le serveur de média peut par exemple envoyer cette valeur associée avec le nom result , par exemple . Si l'élément ne retourne aucune valeur, le serveur de média peut informer le serveur d'application de la fin de l'exécution du script VoiceXML en indiquant que ceci est une fin normale. 2) Lorsque l'interpréteur atteint la fin du script et qu'aucun document n'est donné comme suite de l'exécution, la fin d'exécution du script est considérée comme normale. Le serveur de média peut informer le serveur d'application de la fin de l'exécution du script en précisant que ceci est une fin normale. 3) Lorsqu'un événement anormal survient, pour lequel le traitement par défaut est de quitter l'exécution du script, par exemple une erreur survenant lors du chargement d'un document, la fin de l'exécution est considérée comme anormale. Le serveur de média peut informer le serveur d'application de la fin anormale et envoyer une description de l'événement qui indique la cause de la fin de la session VoiceXML. Utilisation du format XML pour communiquer les résultats de l'interaction avec l'utilisateur Avantageusement, le serveur de média utilise le format XML pour adresser les résultats au serveur d'application, ce format étant déjà largement utilisé dans les standards 3GPP, par exemple pour le service Presence. L'information structurée en format XML peut être envoyée dans le corps de la requête INFO en utilisant le type MIME application.MediaServer-control+xml . A la fin de l'exécution du script, le serveur de média peut envoyer au serveur d'application une requête SIP INFO pour l'informer du résultat d'exécution du script. Une telle requête INFO peut contenir: - une information indiquant l'exécution normale, par exemple le fait que l'interpréteur a atteint la fin du script ou a rencontré l'élément exit ou une erreur, par 25 exemple liée à un événement qui a provoqué l'interruption de l'exécution, - si l'exécution se termine normalement et que l'interpréteur a rencontré un élément contenant un attribut expr ou namelist, cette information peut être associée à une liste de noms de variables et à leurs valeurs. Si l'attribut expr est présent, cette liste va contenir seulement un élément (résultat, valeur de expr). Le document XML envoyé par le serveur de média au serveur d'application peut ainsi contenir un élément qui peut être associé à un élément . L'élément doit contenir un attribut obligatoire appelé status qui peut prendre soit la valeur 1 indiquant une exécution réussie ou la valeur 0 indiquant une erreur de traitement. La cause de l'erreur peut être contenue dans un attribut optionnel event. L'élément peut contenir une liste d'éléments de type . L'élément contient deux attributs obligatoires: - l'attribut nom Var qui est de type chaîne de caractères et correspond au nom de la variable retournée, - l'attribut val Val qui est de type chaîne de caractères et correspond à la valeur 10 de la variable retournée. Exemple de schéma XML L'espace de nommage URI pour les éléments définis ci-dessus peut être un URN selon la nome RFC 2141, utilisant l'identificateur de nom d'espace ieft' défini par 15 la norme RFC 2648 et étendu par la norme RFC 30-23 (janvier 2001) XML media Types . Cet URN peut être: urn: ietf params: xml:ns: MediaServer-control type= "xsd: string" /> 25 30 35 40 type = "xsd: string" use = "required" /> Exemple d'application On va maintenant décrire un exemple d'échange de données dans le cas d'un service prépayé qui met en oeuvre l'invention. Dans cet exemple, un utilisateur recharge un compte prépayé en accédant à un service correspondant au cours d'une session SIP. Il lui est demandé d'entrer un numéro de rechargement. Après vérification de ce numéro, une annonce est lue par le serveur de média indiquant la nouvelle valeur de son crédit. La figure 2 donne un exemple des échanges de données pour un tel service 30 entre l'utilisateur, le serveur d'application et le serveur de média. Dans un souci de clarté de l'exposé, les proxies SIP n'ont pas été représentés sur cette figure. Lors de l'étape (1), le serveur d'application joue le rôle d'un tiers contrôlant l'appel. Il crée une session SIP avec l'utilisateur et une autre avec le serveur de média. De plus, il permet l'établissement d'un flux de média directement entre l'utilisateur et le serveur de média. L'établissement de la session SIP, qui est décrite dans TS 23.218, n'a pas été représenté sur la figure 1, dans un souci de simplification de l'exposé. A l'étape (2), le serveur d'application sélectionne un script visant à demander à l'utilisateur d'entrer un numéro de rechargement de carte. Il envoie une requête INFO au 10 15 20 serveur de média contenant dans son corps l'adresse URL du script VoiceXML correspondant, par exemple: ... /prepaid/RequestNumber.vxml. Le type de contenu du champ de tête de ce message est fixé à application/uri . En variante, une commande de script peut être adressée en tant que requête INVITE. A l'étape (3), le serveur de média répond avec un message 200 0K puisqu'il est capable d'exécuter le script. A l'étape (4), à la fin de l'exécution du script, le serveur de média envoie une requête INFO contenant dans son corps un script XML qui encapsule le numéro de rechargement de la carte, donné par l'utilisateur. Le type de contenu du champ d'en-tête de cette requête est fixé à application/MediaServer-control+xml . Le script XML contenu dans le corps de la requête INFO est par exemple: 1 varName = "cardNumber" var Value = "12345678901234" A l'étape (5), le serveur d'application répond avec une réponse 200 0K. A l'étape (6), après avoir vérifié le numéro de carte donné par l'utilisateur, le serveur d'application envoie une requête INFO contenant dans son corps l'adresse URL du script VoiceXML (... /prepaid/AnnounceServlet ? Credit = 20) qui décrit la communication à l'utilisateur du crédit restant sur le compte prépayé. Cette adresse URL contient un paramètre appelé crédit qui indique la valeur du crédit, en l'espèce 20, et pointe sur un Servlet Java destiné à créer le script VoiceXML de manière dynamique avec ce paramètre. Le type de contenu du champ d'en-tête de cette requête est fixé à application/uri . 20 A l'étape (7), le serveur de média répond avec un message 200 0K puisqu'il est capable d'exécuter le script. Aux étapes (8) et (9), à la fin de l'exécution du script, le serveur de média envoie une requête INFO au serveur d'application pour l'informer de la fin du traitement. Le serveur d'application répond avec une réponse 200 0K. Le type de contenu du champ d'en-tête de cette requête est fixé application/MediaServer-control+xml . Le script XML contenu dans le corps de la requête INFO est par exemple: 1 Aux étapes (10) à (13), le serveur d'application termine la session SIP avec le serveur de média et avec l'utilisateur. La clôture de la session est décrite dans TS 32.218 et 15 n'a pas été représentée à la figure 2 dans un souci de clarté du dessin. Bien entendu, l'invention n'est pas limitée à cet exemple et couvre d'autres applications. Dans toute la description, y compris les revendications, l'expression comportant un doit être comprise comme étant synonyme de comportant au moins 20 un , sauf si le contraire est spécifié. REVENDICATIONS 1. Procédé d'échange d'informations entre au moins un serveur d'application (AS), au moins un serveur de média et au moins un utilisateur (UA), au cours d'une session SIP, procédé dans lequel le serveur d'application adresse au serveur de média une requête SIP contenant dans son corps un script VoiceXML ou un pointeur renvoyant sur un script VoiceXML, lequel peut être présent notamment dans le serveur de média ou dans un serveur de documents, l'exécution de ce script VoiceXML commandant une interaction entre le serveur de média et l'utilisateur (UA) . 2. Procédé selon la revendication 1, caractérisé par le fait que la requête SIP est une requête SIP INVITE. 3. Procédé selon la revendication 1, caractérisé par le fait que la requête SIP contient dans son corps un script VoiceXML. 4. Procédé selon la revendication 1, caractérisé par le fait que la requête SIP 15 contient dans son corps un pointeur renvoyant sur un script VoiceXML. 5. Procédé selon la revendication 1, caractérisé par le fait qu'après l'exécution du script VoiceXML, le serveur de média envoie au serveur d'application au moins une information concernant le résultat de l'interaction avec l'utilisateur sous la forme d'un document au format XML. 6. Procédé selon la revendication précédente, caractérisé par le fait que le document au format XML est contenu dans le corps d'une requête SIP, notamment une requête SIP INFO. 7. Procédé selon l'une quelconque des revendications précédentes, caractérisé par le fait que le script VoiceXML décrit une interaction vocale et/ou basée sur les codes DTMF avec l'utilisateur. 8. Procédé selon l'une quelconque des revendications précédentes, caractérisé par le fait que le serveur d'application envoie au serveur de média, alors qu'une session SIP a été établie, une requête INFO appartenant à cette session, notamment pour commander l'exécution d'un autre script VoiceXML. 9. Système d'échange de données, comportant: - un réseau informatique, au moins un serveur d'application (AS) connecté au réseau, et - au moins un serveur de média connecté au réseau, le réseau étant agencé pour permettre l'établissement d'une session SIP entre un utilisateur et le serveur d'application, l'échange de flux audio entre l'utilisateur et le serveur de média ainsi qu'un échange de données entre le serveur d'application et le serveur de média, système dans lequel le serveur d'application est agencé pour adresser au serveur de média une requête SIP, notamment une requête SIP INVITE, contenant un script VoiceXML dans son corps ou un pointeur renvoyant sur un script VoiceXML, l'exécution de ce script commandant une interaction avec l'utilisateur. 10. Système selon la revendication 9, caractérisé par le fait que le serveur de média est agencé de manière à envoyer, après l'exécution du script VoiceXML, au serveur d'application au moins une information concernant le résultat d'une interaction avec l'utilisateur sous la forme d'un document au format XML. 11. Système selon la revendication précédente, caractérisé par le fait que le document au format XML est contenu dans le corps d'une requête SIP, notamment une 15 requête SIP INFO. 12. Système selon l'une quelconque des revendications 9 à 11, caractérisé par le fait que le serveur d'application est configuré pour envoyer au serveur de média, alors qu'une cession SIP a été établie, une requête INFO appartenant à cette session, notamment pour commander l'exécution d'au autre script VoiceXML.