Enhanced media resource protocol messages

BACKGROUND

00011. Field of the Invention

0002The present invention relates to the field of telecommunications and, more particularly, to an enhanced messaging protocol for controlling media service resources.

00032. Description of the Related Art

0004The Media Resource Control Protocol (MRCP) is a protocol for interfacing with media resources developed by the Internet Engineering Task Force (IETF). The MRCP is designed to provide a mechanism for a client device requiring audio/video stream processing to control processing resources on a network. These media processing resources can include a speech recognizer, such as an automatic speech recognition (ASR) engine, a speech synthesizer, such as a text-to-speech (TTS) engine, a fax, a signal detector, and the like. Further, MRCP allows media processing resources to be utilized by a remotely located system, such as an Interactive Voice Response (IVR) system. a telephone application server, and/or a voice server.

0005The message format for MRCP is text based with mechanisms to carry embedded binary data. This allows data recognition grammars, recognition results, synthesizer speech markup, and the like to be carried within MRCP messages conveyed between a client and the media resource server.

0006MRCP addresses the issue of controlling and communicating with the resource processing the stream, and defines the requests, responses, and events needed to do that. The MRCP protocol does not, however, address session control management, media management, reliable sequencing and delivery or server or resource addressing, which are to be handled separately by a protocol like Session Initiation Protocol (SIP) or Real Time Streaming Protocol (RTSP).

0007Turning to specifics of the MRCP, an MRCP message consists of a start-line, one or more header fields, an empty line indicating the end of the header fields, and an optional message body. An empty line can be represented by a carriage return line feed (CRLF).

0008<tables id="TABLE-US-00001" num="00001"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="3"><colspec colname="offset" colwidth="35pt" align="left" /><colspec colname="1" colwidth="91pt" align="left" /><colspec colname="2" colwidth="91pt" align="left" /><thead><row><entry /><entry namest="offset" nameend="2" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry /><entry>generic-message =</entry><entry>start-line</entry></row><row><entry /><entry /><entry>message-header</entry></row><row><entry /><entry /><entry>CRLF</entry></row><row><entry /><entry /><entry>[ message-body ]</entry></row><row><entry /><entry namest="offset" nameend="2" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

0009The start line can include a request-line, a response-line, and/or an event line. Accordingly, the start line can identify the type of message contained within the MRCP message. The three possible types of messages can include a request message, a response message, and/or an event message.

0010<tables id="TABLE-US-00002" num="00002"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="3"><colspec colname="offset" colwidth="21pt" align="left" /><colspec colname="1" colwidth="56pt" align="left" /><colspec colname="2" colwidth="140pt" align="left" /><thead><row><entry /><entry namest="offset" nameend="2" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry /><entry>start-line =</entry><entry>request-line | response-line | event-line</entry></row><row><entry /><entry namest="offset" nameend="2" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

0011A request message can be conveyed from a client to a server. The request message can include the name of a method to be applied, a space (SP) used as a field separator, a method tag for a request, another SP, and a version of the MRPC protocol in use.

0012<tables id="TABLE-US-00003" num="00003"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="3"><colspec colname="offset" colwidth="21pt" align="left" /><colspec colname="1" colwidth="77pt" align="left" /><colspec colname="2" colwidth="119pt" align="left" /><thead><row><entry /><entry namest="offset" nameend="2" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry /><entry>request-line =</entry><entry>method-name SP request-id SP</entry></row><row><entry /><entry /><entry>mrpc-version CRLF</entry></row><row><entry /><entry namest="offset" nameend="2" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

0013After receiving and interpreting a request message, a server resource can respond to the client with a response message. The response message can include a version of the MRPC protocol running on the server, a SP, a request-id that must match that sent in the corresponding request message, a SP, a status-code representing the success, failure, or other of the request, a SP, and a request state field indicating if a job is pending, in-process, or complete.

0014<tables id="TABLE-US-00004" num="00004"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="3"><colspec colname="offset" colwidth="21pt" align="left" /><colspec colname="1" colwidth="77pt" align="left" /><colspec colname="2" colwidth="119pt" align="left" /><thead><row><entry /><entry namest="offset" nameend="2" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry /><entry>response-line =</entry><entry>mrcp-version SP request-id SP</entry></row><row><entry /><entry /><entry>status-code SP quest-state CRLF</entry></row><row><entry /><entry namest="offset" nameend="2" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

0015When a server resource needs to communicate a change of state or an occurrence of an event to a client, the server can generate an event message. The event message can include an event name identifying the nature of the event generated by the media resource, a SP, a request-id that matches that sent in the request that caused the event, a SP, a request-state, a SP, and an mrcp-version.

0016<tables id="TABLE-US-00005" num="00005"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="3"><colspec colname="offset" colwidth="21pt" align="left" /><colspec colname="1" colwidth="63pt" align="left" /><colspec colname="2" colwidth="133pt" align="left" /><thead><row><entry /><entry namest="offset" nameend="2" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry /><entry>event-line =</entry><entry>event-name SP request-id SP</entry></row><row><entry /><entry /><entry>request-state SP mrcp-version CRLF</entry></row><row><entry /><entry namest="offset" nameend="2" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

0017The message header can include one or more general headers and one or more resource specific headers, where resource specific headers can include request headers and response headers.

0018<tables id="TABLE-US-00006" num="00006"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="3"><colspec colname="offset" colwidth="14pt" align="left" /><colspec colname="1" colwidth="77pt" align="left" /><colspec colname="2" colwidth="126pt" align="left" /><thead><row><entry /><entry namest="offset" nameend="2" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry /><entry>message-header =</entry><entry>1*(generic-header | resource-header)</entry></row><row><entry /><entry namest="offset" nameend="2" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

0019Each header consists of a field name followed by a colon and an optional field value, where the field name is a token and the field value includes field content that does not include any leading or trailing linear white spaces (LWS). combinations of token, separators,

0020<tables id="TABLE-US-00007" num="00007"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="3"><colspec colname="offset" colwidth="14pt" align="left" /><colspec colname="1" colwidth="70pt" align="left" /><colspec colname="2" colwidth="133pt" align="left" /><thead><row><entry /><entry namest="offset" nameend="2" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry /><entry>header =</entry><entry>field-name “:” [ field-value ]</entry></row><row><entry /><entry>field-name =</entry><entry>token</entry></row><row><entry /><entry>field-value =</entry><entry>*( field-content | LWS )</entry></row><row><entry /><entry>field-content =</entry><entry><the OCTETs making up the field-value</entry></row><row><entry /><entry /><entry>and consisting of either *TEXT or</entry></row><row><entry /><entry /><entry>combinations of token, separators, and</entry></row><row><entry /><entry /><entry>quoted-string></entry></row><row><entry /><entry namest="offset" nameend="2" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

0021When used to as a communication protocol between a telephone application server and/or a componentized voice server, the MRCP has numerous shortcomings. First, MRCP messages do not include information sufficient to reference MRCP messages back to associated telephone calls. Reference back information can be useful to enable end-to-end call tracing features, which can be highly beneficial when conducting debugging operations. Additionally, access to call identity permits a speech engine or other media processing resource to reference call information from call-specific information data stores, such as data stores established by a telephone gateway, a telephone application server, and/or a voice server.

0022Another shortcoming of the MRCP when used in a telephone application server context is that the MRCP does not include information sufficient to link MRCP messages back to a media gateway, such as a media converting component of a telephone voice server. The MRCP specification includes identification of audio input and output with a focus on a one to one allocation between calls and speech engines.

0023In other words, the input/output parameters provided by the MRCP focuses on allocating one media resource per call. Once allocated, the resource is occupied for the duration of a call. This type of allocation can be referred to as call-based engine allocation, which can be highly inefficient as it fails to maximize the utilization of speech engines, such as ASR engines and TTS engines.

0024Cost effective telephony solutions do not allocate speech engines for an entire call. Rather, a speech engine is allocated for a turn of speech, where each turn represents a discrete speech request or work unit that a speech engine is to process. Because MRCP does not specify media sources within messages, utilizing the MRCP protocol for turn-based speech engine allocation can be problematic and establishment of proper communication channels for the dynamically allocated speech engines can result in processing delays.

SUMMARY OF THE INVENTION

0025The present invention defines a messaging protocol for media resource communication that includes a telephone call identification and/or audio source and sink information in accordance with the inventive arrangements disclosed herein. In one embodiment, the present invention can be an extension of the Media Resource Control Protocol (MRCP). The inclusion of telephone call identification information within media resource control messages permits speech engines to identify a telephone call for which tasks are being performed. This call identification information can enable end-to-end call tracing, can facilitate debugging operations, and can provide a key field for the speech engine to access call specific information stored within numerous data sources. The inclusion of audio source and sink information can provide the speech engine with the information necessary to send and receive media to an appropriate location.

0026As used herein, MRCP is defined as including MRCP version 5.0 as specified by Shanmugham, et. al. on Jan. 4, 2004, as well as earlier versions of MRCP approximately adhering to the details expressed herein. Further, as used herein, MRCP can include versions subsequent to MRCP version 5.0 as well as derivatives of MRCP version 5.0 and other media protocols that are relatively consistent with MRCP version 5.0. The terms “relatively consistent” are to be determined in accordance with the inventive arrangements disclosed herein and not to be gauged by protocol differences largely irrelevant to this disclosure.

0027One aspect of the present invention can include a communication system that uses a standardized messaging protocol. The communication system can include a telephony application server and at least one speech engine. The telephony application server can have at least one voice server component. The speech engines can be allocated to handle requests for the voice server component on a per turn basis. The standardized messaging protocol can define a message format for requesting messages sent from the voice server component to a selected speech engine, a message format for response messages sent from the speech engine to the voice server component, and a message format for event messages sent from the speech engine to the voice server component. Each message format can include a field for a call identifier. The standardized messaging protocol can also specify audio Uniform Resource Identifiers (URIs)s for conveying audio signals between the speech engine and a media converting component of the telephone application server.

0028Another aspect of the present invention can include a messaging protocol for media resources that can include a start line, a message header, and a message body. The start line can specify a message type, such as a request, a response, and/or an event. The start line can also include an identifier for a telephone call. The message header can include a generic-header and/or a resource header. The message body can contain message specific data.

0029Still another aspect of the present invention can include a messaging protocol for media resources that can include a start line, a message header, and a message body. The start line can specify a message type as well as message identifying data. The message header can include at least one port field for identifying a port to which a media resource is to communicatively link. Audio signals can be communicated across, such a link. The message body can include message specific data.

BRIEF DESCRIPTION OF THE DRAWINGS

0030There are shown in the drawings, embodiments that are presently preferred; it being understood, however, that the invention is not limited to the precise arrangements and instrumentalities shown.

0031<figref idref="DRAWINGS">FIG. 1</figref> is a schematic diagram illustrating a message format for a media resource messaging protocol in accordance with the inventive arrangements disclosed herein.

0032<figref idref="DRAWINGS">FIG. 2</figref> is a schematic diagram illustrating a start line for a media resource messaging protocol in accordance with the inventive arrangements disclosed herein.

0033<figref idref="DRAWINGS">FIG. 3</figref> is a schematic diagram illustrating a message header for a media resource messaging protocol in accordance with the inventive arrangements disclosed herein.

0034<figref idref="DRAWINGS">FIG. 4</figref> is a schematic diagram illustrating a system in which messages formatted using the disclosed media resource messaging protocol can be implemented in accordance with the inventive arrangements disclosed herein.

DETAILED DESCRIPTION OF THE INVENTION

0035<figref idref="DRAWINGS">FIG. 1</figref> is a schematic diagram <b>100</b> illustrating a message format for a media resource messaging protocol in accordance with the inventive arrangements disclosed herein. The protocol can control media resources like speech synthesizers, recognizers, signal generators, signal detectors, fax servers, and the like over a network. The protocol is designed to work with streaming protocols like real time streaming protocol (RTSP), session initiation protocol (SIP) and the like that help establish control connection to external media streaming devices and media delivery mechanisms, such as a Real Time Protocol (RTP). In one embodiment, the table <b>100</b> can be an extension of a Media Resource Control Protocol (MRCP) by the Internet Engineering Task Force (IETF).

0036Diagram <b>100</b> consists of a generic-message <b>105</b> to be used for the media resource messaging protocol. The generic message includes an enhanced start-line, an enhanced message-header, a field delimiter, such as a carriage return line feed (CRLF), and an optional message body. The enhanced start line can specify a message type, such as a request, a response, and/or an event. The enhanced start line can include a call identifier, which identifies a telephone number of a call for which the media resource is being requested. The enhanced message header can include a generic header and/or a resource specific header. The enhanced message header can also include an identifier for an audio source and/or an audio sink that a media resource is to utilize. The message body can contain message specific data.

0037<figref idref="DRAWINGS">FIG. 2</figref> is a schematic diagram <b>200</b> illustrating a start line for a media resource messaging protocol in accordance with the inventive arrangements disclosed herein. The diagram <b>200</b> specifies an enhanced start line <b>205</b>, a message table <b>210</b>, and an enhanced request identifier <b>215</b>. The enhanced start line <b>205</b> can consist of a request line, a response line, or an event-line.

0038The message table <b>210</b> provides a definition for the request line, the response line, and the event line. A request line defines a format for messages sent from a resource requestor to a media resource server. The request line can include a method name, an enhanced request identifier <b>215</b>, and a protocol version. The method name can define a method of the media resource that is desired. The enhanced request identifier <b>215</b> can uniquely identify a request. All subsequently conveyed messages relating to the original request will include the request identifier <b>215</b>. The protocol version identifies the version of the protocol.

0039It should be noted that the enhanced request identifier <b>215</b> can include any number of digits. A portion of these digits can identify the call. In one embodiment, the first ten digits of the enhanced request identifier <b>215</b> can specify a telephone location and following digits can specify a request reference. The request reference can be a count for the number of request being processed, where a first request can have a request reference of 1, a second request can have a request reference of 2, and so forth.

0040It should be noted that the telephone location specified within the request identifier <b>215</b> is not limited to digits representing a telephone number and that any unique identifier for a telephone location can be used. For example, a telephone location can be identified using a port identifier for a port established by a telephony gateway used for the call. Further, the call identifying data can appear anywhere within the enhanced request identifier <b>215</b> and do not necessary proceed the. request reference. For example, the request reference can proceed the call identifier and/or be interspersed with call identifying digits. Moreover, any request reference can be utilized within the enhanced request identifier <b>215</b> so long as when the call identifier and the request reference is combined, a unique identification key results.

0041Referring to the response line shown in message table <b>210</b>, the response line can define a format for messages conveyed from a media resource server to a resource requestor in response to a request message. The response line can include a protocol version, an enhanced request identifier, a status code, and a request state. The status code can indicate the current state of the request. For example, the status code can include values for success, failure, unknown, and the like. The request state can indicate a processing state for a method executing within a media resource server. For example, the processing state can include values for pending, in-process, complete, and the like.

0042Referring to the event line shown in message table <b>210</b>, the event line can define a format for messages conveyed from a media resource server to a resource requestor in response an occurrence of events relating to a request. The event line can include an event name, an enhanced request identifier, a request state, and a protocol version. The event name can include a key that uniquely identifies an event occurring within the media resource server. The enhanced request identifier, the request state, and the protocol versions can be formatted in the same manner as previously detailed within the request line and/or response line.

0043<figref idref="DRAWINGS">FIG. 3</figref> is a schematic diagram <b>300</b> illustrating a message header for a media resource messaging protocol in accordance with the inventive arrangements disclosed herein. The diagram <b>300</b> can include an enhanced message header <b>305</b>, an enhanced header <b>310</b>, a port table <b>315</b>, and field definers <b>320</b>.

0044The enhanced header <b>310</b> can be a format of at least one type of enhanced message-header <b>305</b>, where types of enhanced-message headers <b>305</b> can include a generic header and/or a resource specific header. The enhanced header <b>310</b> can include a field name, a delimiter like a “:”, and an optional field value. As shown by the field definers <b>320</b>, a field value can include multiple field-content values, each separated by a delimiter like a linear white space (LWS). Field-content values can include binary data, textual data, and the like. Binary data can include a plurality of octets. Text can include one or more strings, tokens, keys, separators, and the like.

0045The port table <b>315</b> can define one or more media URIs that the media resource can use to convey media information, where media information can include any form of audio/video information, such as streamed audio signals. The port table <b>315</b> can include a media input identifier and a media output identifier. The media input identifier can define a media input source for a media resource. The media output identifier can define a media output source for the media resource.

0046<figref idref="DRAWINGS">FIG. 4</figref> is a schematic diagram illustrating a system <b>400</b> in which media resources can communicate using a standardized messaging protocol in accordance with the inventive arrangements disclosed herein. The system <b>400</b> can include a telephone gateway <b>415</b>, one or more speech engines <b>430</b>, and a telephony application server <b>450</b>.

0047The telephone gateway <b>415</b> can include hardware and/or software that translates protocols and/or routes calls between a telephone network <b>410</b>, such as a Public Switched Telephone Network (PSTN), and the application server <b>450</b>. The telephone gateway <b>415</b> can route calls using packet-switched as well as circuit switched technologies. Further, the telephone gateway <b>415</b> can contain format converting components, data verification components, and the like. For example, the telephone gateway <b>415</b> can include a CISCO 2600 series router from Cisco Systems, Inc. of San Jose, Calif., a Cisco, a CISCO 5300 series gateway, a Digital Trunk eXtended Adapter (DTXA), an INTEL DIALOGIC (R) Adaptor from Intel Corporation of Santa Clara, Calif., and the like.

0048The speech engines <b>430</b> can include one or more automatic speech recognition engines <b>434</b>, one or more text to speech engines <b>432</b>, and other media resources. Particular ones of the speech engines <b>430</b> can include one or more application program interfaces (APIs) for facilitating communications between the speech engine <b>430</b> and external components. For example, in one embodiment, the ASR engine <b>434</b> can include an IBM ASR engine with an API such as a Speech Manager API (SMAPI).

0049Selective ones of the speech engines <b>430</b> can include a control interface <b>490</b> for conveying protocol messages <b>495</b>, where the details of the protocol messages <b>495</b> have been previously specified in <figref idref="DRAWINGS">FIGS. 1-3</figref> and the corresponding descriptions. In an embodiment where the protocol message <b>495</b> is an extension of MRCP, the control interface <b>490</b> can be an MRCP engine control interface.

0050The application server <b>450</b> can include an engine that functions as a reliable foundation for handling high volume secure transactions and Web services. In one embodiment, the application server <b>450</b> can be a Websphere Application Server (WAS).

0051The application server <b>450</b> can also include a multitude of component servers, such as telephone server <b>460</b>, dialogue server <b>470</b>, and voice server <b>480</b>, communicatively linked via one or more Web servers <b>452</b>. Each Web server <b>452</b> can include one or more. plug-ins <b>454</b>, where each plug-in <b>454</b> can include routines for conveying data to particular component servers within the application server <b>450</b>. Each of the component servers of the application server <b>450</b> can be components implemented within a Virtual Machine, such as virtual machines adhering to the JAVA 2 Enterprise Edition (J2EE) specification or other similar and/or derivative specification.

0052The telephone server <b>460</b> can control the setup, monitoring, and tear down of phone calls. In one arrangement, telephone server <b>460</b> can include a web container <b>462</b> and an Enterprise Java Beans (EJB) container <b>464</b>. Moreover, the telephone server <b>460</b> can include one or more call control servlets (servlet A), one or more call control EJBs (Bean B), and one or more call control interpreter EJBs (Bean C).

0053The dialogue server <b>470</b> can manage tasks relating to call dialogue for the application server <b>450</b>. In one arrangement, the dialogue server <b>470</b> can include web container <b>472</b> and EJB container <b>474</b>. Moreover, the dialogue server <b>470</b> can include one or more voice markup interpreter EJBs (Bean D).

0054The voice server <b>480</b> can handle one or more speech services for the application server <b>450</b>. In one arrangement, the voice server <b>480</b> can include web container <b>482</b> and EJB container <b>484</b>. Moreover, the voice server <b>480</b> can include one or more automatic speech recognition (ASR) EJBs (Bean E) as well as one or more text-to-speech EJBs (Bean F). Bean E and Bean F can be interface components, each interfacing with an identified speech engine <b>430</b>. Further, Bean E and/or Bean F can be constructed to convey protocol messages <b>495</b> between the voice server <b>480</b> and particular ones of the speech engines <b>430</b>.

0055It should be appreciated that the telephone server <b>460</b>, the dialogue server <b>470</b>, and the voice server <b>480</b> can be arranged in a multitude of fashions and that the invention is not to be limited to the illustrative arrangement presented herein.

0056The system <b>400</b> can also include a media converter <b>425</b> and a resource connector <b>420</b>. The media converter <b>425</b> can be a communication intermediary for streaming speech data configured to resolve protocol issues between the telephone gateway <b>415</b> and speech engines <b>430</b>. Audio data can be streamed bi-directionally between the telephone gateway <b>415</b> and the speech engines <b>430</b> as appropriate.

0057The resource connector <b>420</b> can be a communication intermediary between the telephone gateway <b>415</b> and the application server <b>450</b> and/or media converter <b>425</b> that allocates resources for calls. In one embodiment, the resource connector <b>420</b> can normalize a telephony request into a request that is acceptable by the application server <b>450</b>, thereby providing a generic means for the telephone gateway <b>415</b> to interface with the application server <b>450</b>. For example, if the application server <b>450</b> communicates using HyperText Transfer Protocol (HTTP) messages, the resource connector <b>420</b> can convert a telephony request into an appropriate HTTP message. In another example, if the application server <b>450</b> utilizes a Session Initiation Protocol (SIP), the resource connector <b>420</b> can convert a telephony request into an appropriate SIP message.

0058In operation, a user can initiate a telephone call. The call can be conveyed through a telephone network <b>410</b>, such as a Public Switched Telephone Network (PSTN), and can be received by the telephone gateway <b>415</b>. The telephone gateway <b>415</b> can convey call information to the resource connector <b>420</b>. The resource connector <b>420</b> can initialize the media converter <b>425</b>, which can establish one or more media ports that can be used for the call. Identifiers, which can include media Uniform Resource Identifiers (URI), associated with the reserved media ports can be conveyed to the resource connector <b>420</b>. Notably, a media URI can identify a hostname and protocol for the associated media port. The resource connector <b>420</b> can convey call identifying information as well as the media URI to the application server <b>450</b>.

0059Speech services can be triggered within the application server <b>450</b> as appropriate. Speech services can require one or more speech engines <b>430</b> to perform one or more tasks. The speech engines <b>430</b> can be allocated on a turn basis to handle the tasks as need arises.

0060Each task can be initiated by conveying a request protocol message <b>495</b> from the application server <b>450</b> to a selected speech engine <b>430</b>. The request message <b>495</b> can include a call identifier and/or the media URIs that have been established for the call. The selected speech engine <b>430</b> can connect to the media converter <b>425</b> using the media URIs. Additionally, call information, based upon the call-identifier, can be retrieved from the application server <b>450</b>, telephone gateway <b>415</b>, media converter <b>425</b>, and other system <b>400</b> components. The selected speech engine <b>430</b> can process the request as appropriate. Processing the request can involve direct communications between the speech engine <b>430</b> and the media converter <b>425</b> that are not routed through the application server <b>450</b>.

0061Once processed, a response protocol message <b>495</b> can be conveyed from the speech engine <b>430</b> to the application server <b>450</b>. The speech engine <b>430</b> can also convey one or more event messages <b>495</b> to the application server <b>450</b> to signify the occurrence of defined events. The application server <b>450</b> can take appropriate actions responsive to the receipt of response messages <b>495</b> and/or event messages <b>495</b>. For example, if a response message <b>495</b> indicates that a corresponding event failed to process correctly, the application server <b>450</b> can re-initiate the request.

0062It should be noted that conveying the media URI and/or call identifying information to the speech engine <b>430</b> along with a request facilitates turn based processing of tasks. That is, a dynamically allocated speech engine <b>430</b> receives the information necessary to handle the request (i.e. the media URI and the call identifying information) when it receives the request. The speech engine <b>430</b> need not query the telephone gateway <b>415</b>, resource connector <b>420</b>, the media converter <b>425</b>, or any application server <b>400</b> component to retrieve necessary data for processing the request. Accordingly, bottlenecks and latencies associated with communicating. through the application server <b>400</b> can be avoided when utilizing the techniques disclosed herein.

0063It should be appreciated, that <figref idref="DRAWINGS">FIG. 4</figref> is just one illustrative embodiment in which the protocol messages <b>495</b> can be utilized. Accordingly, the subject matter disclosed herein can be utilized in conjunction with any system where messages are communicated between a media processing resource and a remote component.

0064The present invention can be realized in hardware, software, or a combination of hardware and software. The present invention can be realized in a centralized fashion in one computer system or in a distributed fashion where different elements are spread across several interconnected computer systems. Any kind of computer system or other apparatus adapted for carrying out the methods described herein is suited. A typical combination of hardware and software can be a general-purpose computer system with a computer program that, when being loaded and executed, controls the computer system such that it carries out the methods described herein.

0065The present invention also can be embedded in a computer program product, which comprises all the features enabling the implementation of the methods described herein, and which when loaded in a computer system is able to carry out these methods. Computer program in the present context means any expression, in any language, code or notation, of a set of instructions intended to cause a system having an information processing capability to perform a particular function either directly or after either or both of the following: a) conversion to another language, code or notation; b) reproduction in a different material form.

0066This invention can be embodied in other forms without departing from the spirit or essential attributes thereof. Accordingly, reference should be made to the following claims, rather than to the foregoing specification, as indicating the scope of the invention.