FR2870660A1 - Information exchanging method for e.g. third generation mobile telephone network, involves addressing session initiation protocol INVITE request to media server by utilizing address server - Google Patents

Abstract

The method involves addressing a session initiation protocol (SIP) INVITE request to a media server, by utilizing an address server, where the request has a extensible markup language (XML) voice script or a pointer that returns the XML voice script which is stored in a media server or in a document server. The XML voice script is executed for controlling interaction between the media server and a user agent (UA). An independent claim is also included for a data exchange system implementing an information exchanging method.

Description

The present invention relates to systems and methods for exchanging

  information in a computer network between at least one user connected to the network and a media server.

  The term computer network must be understood in a broad sense and the computer network may in particular be a third generation mobile telephony network.

  The invention more particularly relates to a computer network in which at least one application server (Application Server or AS) is present to allow the exchange of information with at least one media server using the SIP signaling protocol (SESSION INITIATION PROTOCOL). In the remainder of the description, the term media server encompasses both fixed-network servers (Media Server or MS) and the Media Resource Function (MRF) servers and their evolutions and derivatives.

  The SIP protocol is described in particular in the Internet Engineering Task Force (IETF) Request For Comments (RFC) 3261 (1999) which is incorporated herein by reference. In the remainder of the description, SIP will designate both the SIP protocol defined above and its evolutions and derivatives.

  In a network operating under SIP protocol, the application server is an entity that is intended to host one or more programs containing a service logic, for example that of a video transmission service, web push, a collaborative application such as screen sharing or co-navigation, Presence, Immediate Messaging, teleconferencing, click-to-call, simultaneous ringing.

  Many services require complex dialogues with the user, such as for DTMF recognition, speech recognition and speech synthesis, or for handling media streams, such as audio, during teleconferences or transcoding.

  TS 23.228 and TS.23218 do not specify how complex voice interactions occur such as reading and reporting multiple tones (DTMF) or generating multiple announcements with fixed and variable parts, such as dates or numbers, and provide no solution to repeat ads or control their duration.

  Existing standards also do not specify how the media server can report the results of an interaction with the user to the application server, such as the result of a DTMF discovery, which may be essential for many services such as such as prepaid services or voice mail.

  In the sixth release (Release 6) of UMTS, TS 24.147 and TR 29.847 provide details for managing a multimedia conference. However, the interface between the application server and the media server is not addressed by these 3GPP names and there is therefore a need to explain the information exchanges between these entities.

  In addition, some manufacturers integrate the application server and the media server into the same physical entity. Such an integration has the disadvantage of not responding to operators' requests to have two physically distinct entities, for example to be able to implement them on remote sites one from the other.

  There are also http-based solutions for transporting the results of running a VoiceXML script between an application server and a media server. HTTP transactions are used to carry information resulting from an interaction between the user and the media server during a SIP session. It is necessary to correlate SIP session and http transactions, which increases the complexity of application development.

  The patent application US 2003/0145054 describes a teleconference system between several users communicating via RTP links with a media server, which exchange data with an application server. The media server allows the establishment of audio streams between different users during a conference call and allows new participants to join the conference. For this purpose, the media server receives instructions from the application server in the form of SIP INVITE requests. In such a teleconference system, the media server is not intended to interact with users to broadcast messages (eg voice messages) or to interact voice and / or with DTMF codes.

  There is a need for additional mechanisms for the application server to control the media server.

  The present invention aims in particular to meet this need and it achieves this through a method for controlling an exchange of information between at least one application server, at least one media server and at least one user, in the course of a SIP session, this method being characterized by the fact that the application server sends to the media server a SIP request containing in its body a VoiceXML script or a pointer returning to a VoiceXML script, which can notably be present in the server or in a document server, executing this VoiceXML script controlling an interaction between the media server and the user.

  Thanks to the invention, the development of applications is facilitated, since the transport of information during the same SIP session can be performed without having to provide a complex interface between the application server and the media server .

  VoiceXML refers to the application of the Extensible Markup Language (XML), which is available at www.w3.org/xml/ and its variants and derivatives capable of handling audio interactions between humans and machines (VoiceXML is also standardized by W3C and is available at www.w3.org). These interactions can include voice synthesis, voice recognition or DTMF commands, and voice recording, among others.

  Preferably, the aforementioned SIP request is a SIP INVITE request. This SIP INVITE request can contain in its body a VoiceXML script. As a variant, the SIP INVITE request may contain in its body a pointer pointing to a VoiceXML script.

  The VoiceXML script may for example describe an advertisement to be read, an interaction with voice recognition and / or based on DTMF codes, or other interactions.

  When the SIP INVITE request contains a pointer, the URL of the script may for example be sent in the header field RequestURl of the SIP message as a parameter.

  In an exemplary implementation of the invention, after the execution of the VoiceXML script, the media server can send to the application server at least one information concerning the result of the interaction with the user in the form of a document in XML format. This document in XML format can be contained in the body of a SIP request, including the SIP INFO request.

  The SIP INFO request is defined by RFC 2976 (October 2000) and allows the transport of information in an encapsulated form during an established SIP session.

  Using a SIP INFO query allows multiple exchanges of information between the application server and the media server during an existing session. The SIP INFO query decouples the establishment of the SIP session and the control of the media resources during the session. This is particularly advantageous when several scripts must be executed during the same SIP session.

  When the SIP session has already been established between the media server and the application server, and the media stream is also established between the media server and the user, the application server can advantageously send an INFO request belonging to at the same SIP session to the media server, for example to control the execution of another script. Alternatively, the exchange can also be done using the re-INVITE method.

  The invention also relates to a data exchange system comprising: - a computer network, - at least one application server connected to the network, - at least one media server connected to the network, the network being arranged to allow : - the establishment of a SIP session between a user and the application server, a media flow exchange between the user and the media server, and - an exchange of data between the application server and the server of media, system in which the application server is arranged to send to the media server an INVITE SIP request containing in its body a VoiceXML script or a pointer returning on a script VoiceXML whose execution commands an interaction with the user.

  In such a system, the media server can be arranged to send at least one piece of information about the result of a user interaction in the form of a script after the execution of the VoiceXML script to the application server. XML. This XML script is advantageously encapsulated in the body of a SIP request, in particular a SIP INFO request.

  The application server that maintains control of the session flow with the user may request the media server to execute multiple scripts during the same SIP session.

  The application server is advantageously configured to send to the media server, while a SIP session has been established, an INFO request belonging to this session, in particular to control the execution of another VoiceXML script.

  The invention will be better understood on reading the following detailed description, non-limiting examples of implementation thereof, and on examining the appended drawing, in which: FIG. schematically a computer network in which the invention is likely to be implemented, - Figure 2 schematically illustrates data exchanges during a reloading session of a prepaid account, and - Figure 3 is an example of 3GPP architecture.

  FIG. 1 shows an example of a computer network between at least one User Agent (UA), at least one Application Server AS and at least one Media Server.

  An S-CSCF server has also been shown between the user and the application server.

  It is understood that the computer network is not limited to a particular architecture. Its architecture can notably be that illustrated in FIG. 3, in the case of a 3GPP network known per se.

  The exchange of information between the user and the application server is based on the SIP protocol.

  The computer network also makes it possible to establish a Real Time Transport Protocol (RTP) link between the user and the media server or any other protocol allowing the transmission of multimedia data. The RTP protocol is described in IETF RFC 1889 (1996).

  According to the invention, the application server is configured to allow a complex media interaction with the user by causing the media server to execute at least one VoiceXML script describing, for example, voice and / or DTMF interactions. between the media server and the user.

  In the example considered, the information is transmitted between the application server and the media server thanks to the SIP INVITE and INFO requests.

  Since these requests belong to the same SIP session for which the script is executed, there is no need for an additional correlation mechanism as for the http transactions as referred to above. This simplifies the implementation of the service logic in the application server and in the media server.

  Establishing the session A SIP INVITE request may be sent by the application server to the media server, in particular to initiate a SIP session. This SIP INVITE request can be used to transport an initial command script to the media server.

  The application server can either address a VoiceXML script to the media server or point to a VoiceXML script.

  The sending of a VoiceXML script encapsulated in a SIP INVITE request is preferably reserved for relatively short scripts, for example of length less than 1.3 kbytes. When the application server sends a VoiceXML script encapsulated in the SIP request, the MIME type of the body content can be set to application / Voicexml + xml.

  When the application server sends a pointer to a VoiceXML script to the media server, the first possibility is that the URL of the script to be executed is passed as a parameter in the RequestURl (Universal Resource Identifier) header field of the application. SIP message. The application server can also associate a SIP URI with each VoiceXML script.

  The URL of the script to be executed can also be transmitted as the body content of a SIP message, the MIME type of the body content being set to application / uri.

  The ACK responses and the ACK request returned by the media server to the application server should preferably not contain VoiceXML or XML elements.

  The body of the INVITE message may contain an SDP description in addition to a description of a VoiceXML or URI script. Thus, it is preferable that the application server and the media server can be compatible with the multipart / mixed MIME type as defined in RFC 2046.

  When receiving a SIP INVITE request for script execution, the media server may respond by sending an error message if it is unable to execute the requested VoiceXML script due to lack of resources available.

  During an Established SIP Session Once the SIP session is established between the application server and the media server, command and response scripts can be sent between these two entities.

  Advantageously, the SIP INFO request is used to transport these 10 elements.

  To address results for each script command, the media server can respond with an INFO request. Preferably, the media server does not take the initiative to terminate a session by addressing a BYE message.

  When the media server receives an INFO request for execution of a script, the media server can send the application server a 200K response when it is able to perform the service. Otherwise, when no resource is available, it can send a response 480 'temporally unavailable' or a response 503 Service Unavailable '.

  When the application server receives an INFO request containing the results related to the execution of the script, it can respond automatically with a 200 0K response.

  Depending on the script, the media server may return results to the application server or not.

  In any case, the media server can inform the application server of the completion of the execution of the VoiceXML script and the nature of this purpose (normal completion of the script or error).

  Once the script is executed, the media server sends an INFO request to the application server so as to inform it of the end of the script and can possibly transmit execution results, for example concerning the nature of the keys pressed on the server. keyboard of the user.

  In version 2.0 of VoiceXML, the execution of an application can end in the following cases: 1) The VoiceXML standard indicates that the processing of the <exit> element depends entirely on the context. If this element is encountered by the media server, it causes the end of the execution. Such an end is considered normal.

  The <exit> element can contain one of two attributes: i) The name list attribute. This attribute specifies the variable names to be returned by the exit element. By default, no variable is returned.

  If a list of variable names is specified by this attribute, the media server must send to the application server, as a result of execution, the list of values of these variables associated with their names.

  The results are sent as a string of characters. The values of ECMA script variables as defined at http://www.ecmainternational.org/publications/standards/ECMA-262.HTM must be converted to a string before being sent. ECMA script objects can not be sent, but the media server can send the properties of the object, for example date day or date.time.

  Audio recordings should not normally be sent as a result in an INFO request. In addition, the role of the application server is not to manage media resources. However, the media server can store an audio recording in an http server and send the corresponding URL to the application server as a result.

  For example, we can have the following results: <first-name, dupont> <second-name, paul> <message, http: // MediaServer / messages / paul / 3 3.wav> ii) The attribute Expr This attribute corresponds to an expression of an ECMA script evaluating the value of the result to be returned. A unique value is returned. For example, the media server can send this value associated with the name result, for example <result, 43424465>.

  If the <exit> element does not return a value, the media server can inform the application server that the execution of the VoiceXML script has finished, indicating that this is a normal end.

  2) When the interpreter reaches the end of the script and no document is given as a result of the execution, the execution of the script is considered normal. The media server can inform the application server of the completion of the script by specifying that this is a normal end.

  3) When an abnormal event occurs, for which the default processing is to leave the execution of the script, for example an error occurring during the loading of a document, the end of the execution is considered as abnormal. The media server can inform the application server of the abend and send a description of the event that indicates the cause of the end of the VoiceXML session.

  Using the XML format to communicate the results of the interaction with the user Advantageously, the media server uses the XML format to address the results to the application server, this format is already widely used in 3GPP standards, for example to the Presence service. Structured information in XML format can be sent in the body of the INFO request using the MIME type application.MediaServer-control + xml.

  At the end of the execution of the script, the media server can send to the application server a SIP INFO request to inform it of the result of execution of the script. Such an INFO request may contain: - information indicating the normal execution, for example the fact that the interpreter has reached the end of the script or has encountered the exit element or an error, for example related to an event which has caused the execution to stop, - if the execution ends normally and the interpreter encounters an <exit> element containing an expr or namelist attribute, this information can be associated with a list of variable names and their values. If the expr attribute is present, this list will contain only one element (result, value of expr).

  The XML document sent by the media server to the application server can thus contain a <TerminationStatus> element that can be associated with a <Results> element.

  The <TerminationStatus> element must contain a mandatory attribute called status that can take either a value of 1 indicating successful execution or a value of 0 indicating a processing error. The cause of the error can be contained in an optional event attribute.

  The <Results> element can contain a list of elements of type <result>. The <result> element contains two mandatory attributes: - the attribute name Var which is of type string and corresponds to the name of the returned variable, - the attribute val Val which is of type string and corresponds to the value 10 of the returned variable.

  XML schema example The URI namespace for the elements defined above can be a URN according to RFC 2141, using the space name identifier ieft 'defined by RFC 2648 and extended by the standard RFC 30-23 (January 2001) XML media Types.

  This URN can be: urn: ietf params: xml: ns: MediaServer-control <? Xml version = "1.0" encoding = "UTF-8"?> <Xsd.Eschema xmlns: xsd = http: //www.w3. org / 2001 / XMLSchema target / Namespace = "urn: ietf.Eparams: xml: ns: MediaServer-control" xmlns = http: //www.ietf. org elementFormDefault = "qualified"> <xsd: element name = Media-Control> <xsd: complex Type> <xsd: element name = TerminationStatus> <xsd: complexType> <xsd: attribute name = "status" use = "required "> <xsd: simpleType> <xsd: base restriction =" xsd: integer "> <xsd: enumeration value =" 0 "/> <xsd: enumeration value =" 1 "/> </ xsd: restriction> <xsd: simpleType> <xsd: attribute name = "event" use = "optional"> type = "xsd: string" / </ xsd: complexType> </ xsd element> 25 30 35 40 <xsd: element name = "Results" ninOccurs = "0"> <xsd.EcomplexType> <xsd: sequence> <xsd.:elementname = "result"> <xsd: complexType> <xsd: attribute name = "varName" type = "xsd: string" use = " required "/> <xsd attribute name =" var Value "> type =" xsd: string "use =" required "/> </ xsd: complex Type> </ xsd. element> </ xsd: sequence> </ xsd : complexType> </ xsd: element> </ xsd: complex Type> </ xsd: element> <xsd: schema> Application Example We will now describe an example of data exchange in the case of a prepaid service that implements the invention.

  In this example, a user reloads a prepaid account by accessing a corresponding service during a SIP session. He is asked to enter a reload number. After verifying this number, an advertisement is read by the media server indicating the new value of its credit.

  FIG. 2 gives an example of the data exchanges for such a service between the user, the application server and the media server.

  For the sake of clarity, SIP proxies have not been shown in this figure.

  In step (1), the application server plays the role of a third party controlling the call. It creates a SIP session with the user and another with the media server. In addition, it allows the establishment of a media flow directly between the user and the media server. The establishment of the SIP session, which is described in TS 23.218, has not been shown in FIG. 1, for the sake of simplifying the presentation.

  In step (2), the application server selects a script to ask the user to enter a card reload number. It sends an INFO request to the media server containing in its body the URL of the corresponding VoiceXML script, for example: ... /prepaid/RequestNumber.vxml. The content type of the header field of this message is set to application / uri.

  Alternatively, a script command may be addressed as an INVITE request.

  In step (3), the media server responds with a 200K message since it is able to execute the script.

  In step (4), at the end of the execution of the script, the media server sends an INFO request containing in its body an XML script which encapsulates the reloading number of the card, given by the user. The content type of the header field of this request is set to application / MediaServer-control + xml.

  The XML script contained in the body of the INFO query is for example: <? Xml version = "1. 0" encoding = "utf-8"? <Media-control> <TerminationStatus> 1 </ TerminationStatus> <Results> <Result> varName = "cardNumber" var Value = "12345678901234" </ Result> <Results> </ Media-control> At step (5 ), the application server responds with a 200 0K response.

  In step (6), after verifying the card number given by the user, the application server sends an INFO request containing in its body the URL address of the VoiceXML script (... / prepaid / AnnounceServlet? Credit = 20) which describes the communication to the user of the credit remaining on the prepaid account. This URL contains a parameter called credit that indicates the value of the credit, in this case 20, and points to a Java Servlet for creating the VoiceXML script dynamically with this parameter.

  The content type of the header field of this request is set to application / uri. 20

  In step (7), the media server responds with a message 200 0K since it is capable of executing the script.

  In steps (8) and (9), at the end of the execution of the script, the media server sends an INFO request to the application server to inform it of the end of the processing.

  The application server responds with a 200 0K response. The content type of the header field of this request is app / MediaServer-control + xml.

  The XML script contained in the body of the INFO query is for example: <? Xml version = "1.0" encoding = "utf-8"? > <Media-control> <TerminationStatus> 1 </ TerminationStatus> </ Media-control> In steps (10) to (13), the application server terminates the SIP session with the media server and with the user. The closing of the session is described in TS 32.218 and is not shown in FIG. 2 for the sake of clarity of the drawing.

  Of course, the invention is not limited to this example and covers other applications.

  Throughout the description, including the claims, the phrase having one must be understood to be synonymous with at least one, unless the opposite is specified.

Claims (12)

  A method of exchanging information between at least one application server (AS), at least one media server and at least one user (UA), during a SIP session, wherein the server application sends to the media server a SIP request containing in its body a VoiceXML script or a pointer to a VoiceXML script, which may be present notably in the media server or in a document server, the execution of this VoiceXML script controlling an interaction between the media server and the user (UA).   2. Method according to claim 1, characterized in that the SIP request is a SIP INVITE request.   3. Method according to claim 1, characterized in that the SIP request contains in its body a VoiceXML script.   4. Method according to claim 1, characterized in that the SIP request contains in its body a pointer returning to a VoiceXML script.   5. Method according to claim 1, characterized in that after the execution of the VoiceXML script, the media server sends the application server at least one information concerning the result of the interaction with the user in the form a document in XML format.   6. Method according to the preceding claim, characterized in that the document in XML format is contained in the body of a SIP request, including a SIP INFO request.   7. Method according to any one of the preceding claims, characterized in that the VoiceXML script describes a voice interaction and / or based on the DTMF codes with the user.   8. Method according to any one of the preceding claims, characterized in that the application server sends to the media server, while a SIP session has been established, an INFO request belonging to this session, in particular to control the execution of another VoiceXML script.   9. Data exchange system, comprising: - a computer network, at least one application server (AS) connected to the network, and - at least one media server connected to the network, the network being arranged to enable the network to be connected to the network. establishing a SIP session between a user and the application server, exchanging audio streams between the user and the media server, and exchanging data between the application server and the media server, a system in which the application server is arranged to send to the media server a SIP request, in particular a SIP INVITE request, containing a VoiceXML script in its body or a pointer pointing to a VoiceXML script, the execution of this script controlling a interaction with the user.   10. System according to claim 9, characterized in that the media server is arranged to send, after the execution of the script VoiceXML, at least one information about the result of an interaction with the application server. user in the form of a document in XML format.   11. System according to the preceding claim, characterized in that the document in XML format is contained in the body of a SIP request, including a SIP INFO request.   12. System according to any one of claims 9 to 11, characterized in that the application server is configured to send to the media server, while a SIP assignment has been established, an INFO request belonging to this session. , especially to control the execution of the other VoiceXML script.