MXPA05010163A - Servicio de lenguaje distribuido. - Google Patents

Abstract

La presente invencion se refiere a establecer un canal de medios y un canal de senal entre un cliente y un servidor. El canal de medios utiliza un codigo y protocolo elegidos para comunicacion. A traves del canal de medios y canal de senal, una aplicacion en el cliente puede utilizar servicios de lenguaje en el servidor.

Description

SERVICIO DE LENGUAJE DISTRIBUIDO REFERENCIA A SOLICITUDES DE PATENTE CO-DEPENDIENTES La presente aplicación reclama el beneficio de la solicitud de patente provisional de E. U. A. serie No. 60/621,303, presentada el 22 de Octubre del 200.4, los contenidos de la cual incorporados aquí por referencia en su totalidad.

ANTECEDENTES DE LA INVENCION La presente invención se refiere a métodos y sistemas para definir y manejar interacciones de computadora. En particular, la presente invención se refiere a métodos y sistemas para establecer protocolos de comunicación entre dispositivos en un sistema, tal como con un sistema de telecomunicación. Las Aplicaciones de Telecomunicación Soportadas de Computadora (CSTA) es un estándar ampliamente adoptado adecuado para comunicaciones globales y de empresas. Ln particular, CSTA es un estándar que especifica acceso y cont'o! programático de la infraestructura de telecomunicación. El software puede ser desarrollado para una gran variedad de tareas, que varían desde iniciar y recibir llamadas de teléfonos simples hasta manejar colaboraciones de sitio múltiple de gran escala a través de voz y vídeo.

CSTA está estandarizada en un número de estándares de ECMA/ISO (EC A International Rué du Rhone 114 CH -1204 Génova, www.ecma-international.org). El modelo de operación central y los semánticos de los objetos de CSTA, servicios y eventos están definidos en ECMA -269. Estas características de CSTA son definidas en una forma abstracta e independiente de plataforma para que puedan ser adecuadas a varias plataformas de programación. Además, CSTA está acompaña con diferentes programaciones estandarizadas o sintaxis de protocolo, entre ellos ECMA -323 que define el lenguaje de alza extensible (XML) que se une a CSTA comúnmente conocido como CSTA -XML, y ECMA -348, la unión de Lenguaje de Descripción de Servicio Web (WSDL). Estas uniones de lenguaje, consideradas como parte de la serie estándar de CSTA, aseguran interoperabilidad máxima, haciendo las características de CSTA disponibles para computadoras que corren diferentes sistemas operativos a través de cualquiera de los protocolos de transporte estándares, incluyendo Protocolo de Control de Transmisión (TCP), Protocolo de Iniciación de Sesión (SIP), o Protocolo de Acceso de Objeto Simple (SOAP). Recientemente, la CSTA ha presenciado una fuerte adopción en el área de servicios por voz interactivos. Esta adopción ha sido avanzada por servicios de voz mejorados basados en Etiquetas de Lenguaje de Aplicación de Lenguaje (SALT), que además es descrito en la especificación de SALT 1.0 encontrado en www.saltforum.org. Al utilizar SALT, los centros de llamado además pueden ser automatizados para incluir varias características relacionadas con lenguaje. Sin embargo, las diferencias en las aplicaciones de control de llamado y control de lenguaje crean dificultades al facilitar los servicios de lenguaje distribuido. De esa forma, no existe una necesidad para establecer protocolos para facilitar los servicios de lenguaje.

COMPENDIO DE LA INVENCION La presente invención se refiere a establecer un canal de medios y un canal de señal entre un cliente y un servidor. El canal de medios utiliza un código y protocolo elegidos para comunicación. A través del canal de medios y el canal de señal, una aplicación en el cliente puede utilizar servicios de lenguaje en el servidor.

BREVE DESCRIPCION DE LOS DIBUJOS Las Figuras 1-4 ilustran dispositivos de cómputo ilustrativos para utilizarse con la presente invención. La Figura 5 ilustra una arquitectura ilustrativa para servicios de lenguaje distribuidos. La Figura 6 ilustra un sistema ilustrativo para implantar servicios de lenguaje distribuidos. La Figura 7 ilustra un método ilustrativo para establecer canales en un ambiente de SIP.

La Figura 8 ilustra un método ilustrativo para establecer canales en un ambiente de servicio web.

DESCRIPCION DETALLA DE LAS MODALIDADES ILUSTRATIVAS Antes de describir una arquitectura para servicios y métodos de lenguaje distribuidos para implementar la misma, puede ser útil descubrir generalmente dispositivos de cómputo que pueden funcionar en la arquitectura. Haciendo referencia ahora a la Figura 1, una forma ilustrativa de un dispositivo de manejo de datos (PIM, PDA o similares) es ilustrado en 30. Sin embargo, se contempla que la presente invención también puede ser practicada utilizando otros dispositivos de cómputo discutidos más adelante, y en particular, es un dispositivo de cómputo que tienen áreas de superficie limitadas para botones de entrada o similares. Por ejemplo, teléfonos y/o dispositivos de manejo de datos también se beneficiarán de la presente invención. Tales dispositivos tendrán una utilidad mejorada comparada al los dispositivos de manejo de información personales portátiles existentes y otros dispositivos electrónicos portátiles, y las funciones y tamaño compacto de tales dispositivos probablemente alentarán más al usuario a portar el dispositivo todo el tiempo. Por consiguiente, no se pretende que el alcance de la arquitectura aquí descrita esté limitado por la descripción de un manejo de datos ilustrativo o dispositivo PIM, teléfono o computadora ilustrado aquí. Una forma ilustrativa de un dispositivo móvil de manejo de datos 30 es ilustrado en la Figura 1. El dispositivo móvil 30 incluye un alojamiento 32 y tiene una interfase de usuario que incluye una presentación 34, que utiliza una pantalla de presentación sensible al contacto en conjunto con un estilete 33. Ei estilete 33 es utilizado para presionar o contactar la presentación 34 en coordinas designadas para seleccionar en campo, para mover selectivamente una posición de inicio de un cursor, o para proporcionar de otra informa información de comando tal como a través de gesto o escritura a mano. Alternativamente, o además, uno o más botones 35 pueden ser incluidos en el dispositivo 30 para navegación. Además, otros mecanismos de entrada tal como ruedas que pueden girar, rodillos o similares también pueden ser proporcionados, sin embargo, se debe notar que la invención no pretende estar limitada por estas formas de mecanismos de entrada. Por ejemplo, otra forma de entrada debe incluir una entrada visual tal como a través de visión por computadora. Haciendo referencia ahora a la Figura 2, un diagrama de bloque ilustra los componentes funcionales que comprenden el dispositivo móvil 30. Una unidad de procesamiento central (CPU) 50 implementas las funciones de control de software. La CPU está acoplada a la presentación 34 para que el texto e ¡conos gráficos generados de acuerdo con el software de control aparezcan en la presente invención 34. Una bocina 43 puede estar acoplada a la CPU 50 típicamente con un convertidor digital a analógico 59 para proporcionar una salida escuchable. Los datos que son descargados o ingresados por el usuario en el dispositivo móvil 30 son almacenados en un almacenamiento de memoria de acceso aleatorio no volátil de lectura/escritura 54 bidireccionalmente acoplado a la CPU 50. La memoria de acceso aleatorio (RAM) 54 proporciona almacenamiento volátil para instrucciones que son ejecutadas a la CPU 50, y almacenamiento para datos temporales, tal como valores de registro. Los valores por omisión para opciones de configuración y otras variables son almacenados en una memoria solo de lectura (ROM) 58. La ROM 58 también puede ser utilizada para almacenar el software de sistema operativo para el dispositivo que controla la funcionalidad básica del móvil 30 y otras funciones de núcleo de sistema operativo (por ejemplo, el registro de componentes de software en RAM 54). La RAM 54 también sirve como un almacenamiento para el código en la forma análoga a la función de una unidad dura en una PC que es utilizada para almacenar programas de aplicación. Se debe notar que aunque la memoria no volátil es utilizada para almacenar el código, alternativamente puede estar almacenada en memoria volátil que no es utilizada para ejecución del código. Las señales inalámbricas pueden ser transmitidas/recibidas por el dispositivo móvil a través de un transceptor inalámbrico 52, que está acoplado a la CPU 50. Una interfase de comunicación opcional 60 también puede ser proporcionada para descargar datos directamente de una computadora (por ejemplo, computadora de escritorio), o de una red inalámbrica, si es deseado. Por consiguiente, la interfase 60 puede comprender varias formas de dispositivos de comunicación, por ejemplo, una conexión infrarroja, módem, una tarjeta de red, o similares. El dispositivo móvil 30 incluye un micrófono 29, un convertidos analógico a digital (A/D) 37, y un programa de reconocimiento opcional (lenguaje, DTMF, escritura a mano, gesto, o visión de computadora) almacenado en el almacenamiento 54. A manera de ejemplo, en respuesta a información escuchable, las instrucciones o comandos de un usuario de dispositivo 30, el micrófono 29 proporciona señales de lenguaje, que son digitalizadas por el convertidor A/D 37. El programa de reconocimiento de lenguaje puede realizar funciones de normalización y/o extracción de característica en las señales de lenguaje digitalizadas para obtener resultados de reconocimiento de lenguaje intermedio. Al utilizar el transceptor inalámbrico 52 o la interfase de comunicación 60, los datos de lenguaje son transmitidos a un servidos de lenguaje remoto 204 discutido más adelante e ilustrado en la arquitectura de la Figura 5. Los resultados de reconocimiento después son regresados al dispositivo móvil 30 para presentar (por ejemplo, visual y/o escuchable) en el mismo, y la transmisión eventual a un servidor web 202 (Figura 5), en donde el servidor web 202 y el dispositivo móvil 30 opera en una relación de cliente/servidor. El procesamiento similar puede ser utilizado para otras formas de entrada. Por ejemplo, entrada de escritura a mano puede ser digítalizada con o sin pre-procesamiento en el dispositivo 30. Como los datos de lenguaje, esta forma de entrada puede ser transmitida al servidor de lenguaje 204 para reconocimiento en donde los resultados de reconocimiento son regresados a al menos uno del dispositivo 30 y/o servidor web 202. De forma similar, los datos de DTMF, los datos de gesto y datos visuales pueden ser procesados de forma similar. Dependiendo en la forma de entrada, el dispositivo 30 (y las otras formas de clientes discutidas más adelante) incluirían hardware necesario tal como una cámara para entrada visual. La Figura 3 es una vista plana de una modalidad ilustrativa de un teléfono portátil 80. El teléfono 80 incluye una presentación 82 y una almohadilla de tecla 84. Generalmente, el diagrama de bloque de la Figura 2 aplica al teléfono de la Figura 3, aunque el circuito adicional necesario para realizar otras funciones puede ser requerido. Por ejemplo, un transceptor necesario para operar como un teléfono será requerido para la modalidad de la Figura 2;, sin embargo, tal circuito no es pertinente para la presente invención. Además de los dispositivos de cómputo portátiles o móviles descritos anteriormente, también se debe entender que la presente invención puede ser utilizada con otros dispositivos de cómputo numerosos tal como una computadora de escrito general. Por ejemplo, la presente invención permitirá a un usuario con habilidades físicas limitadas ingresar o escribir texto en una computadora u otro dispositivo de cómputo cuando otros dispositivos de entrada convencionales, tal como un teclado alfanumérico completo, son demasiado difíciles de operar. La invención también es operacional con numerosos otros sistemas de cómputo de propósito general o propósito especial, ambientes o configuraciones. Ejemplos de sistemas de cómputo bien conocidos, ambientes, y/o configuraciones que pueden ser adecuadas para usarse con la invención incluyen, pero no se limitan a, computadoras personales de teléfonos regulares (sin ninguna pantalla), computadora de servidor, dispositivos móviles o portátiles, sistemas de multiprocesador, sistemas a base de microprocesador, cajas de TV por cable, electrónica programable para el consumidor, dispositivos de identificación de radio frecuencia (RFID), PCs de red, minicomputadora, macrocomputadoras, ambientes de cómputo distribuidos que incluyen cualquiera de los sistemas o dispositivos anteriores, y similares. Lo siguiente es una breve descripción de una computadora de propósito general 120 ilustrada en la Figura 4. Sin embargo, la computador 120 de nuevo solo es un ejemplo de un ambiente de cómputo adecuado y no pretende sugerir cualquier limitación al alcance de uso o a la funcionalidad de la invención. La computadora 120 tampoco debe ser interpretada como teniendo cualquier dependencia o requerimiento relacionado a cualquiera o combinación de componentes aquí ilustrados. La invención puede ser descrita en el contexto general de instrucciones ejecutables por computadora, tal como módulos de programa, siendo ejecutados por una computadora. Generalmente, los módulos de programa incluyen rutinas, programas, objetos, componentes, estructuras de datos, etc., que realizan tareas particulares o implementan tipos de datos abstractos particulares. La invención también puede ser practicada en ambientes de cómputo distribuidos en donde las tareas son realizadas a través de dispositivos de procesamiento remoto que están conectados a través de una red de comunicaciones. En un ambiente de cómputo distribuido, los módulos de programa pueden estar localizados tanto en medios de almacenamiento de computadora locales como remotos incluyendo dispositivos de almacenamiento de memoria. Las tareas realizadas por los programas y módulos son descritas más adelante y con la ayuda de las figuras. Aquellos expertos en la técnica pueden implementar la descripción y las figuras como instrucciones ejecutables por procesador, que pueden ser escritas en cualquier forma de un medio legible por computadora. Con referencia a la Figura 4, los componentes de la computadora 120 pueden incluir, pero no están limitados a, una unidad de procesamiento 140, una memoria de sistema 150, y un conductor común de sistema 141 que acopla varios componentes de sistema incluyendo la memoria de sistema a la unidad de procesamiento 140. El conductor de sistema 141 puede ser cualquiera de diferentes tipos de estructuras de conductor común incluyendo un conductor común de memoria o controlador de memoria, un controlador común periférico, y un controlador común local que utiliza cualquiera de una variedad de arquitecturas de conductor común. Como ejemplo, y no limitación, tales arquitecturas incluyen conductor común de Arquitectura Estándar de Industria (ISA), conductor común en Serie Universal (USB), conductor común de Arquitectura de Microcanal (MCA), conductor común de ISA mejorado (EISA), conductor común local de Asociación de Estándares de Electrónicos de Video (VESA), y conductor común de Interconexión de Componente Periférico (PCI) también conocido como conductor común de Mezanine. La computadora 120 típicamente incluye una variedad de medios legibles por computadora. Los medios legibles por computadora pueden ser cualesquiera medios disponibles que puedan ser accedido a través de la computadora 120 e incluyen tanto medios volátiles como no volátiles, medios removibles como no removibles. A manera de ejemplo, y no de limitación, los medios legibles por computadora pueden comprender medios de almacenamiento por computadora y medios de comunicación. Los medios de almacenamiento por computadora incluyen medios volátiles y no volátiles, removibles y no removibles, implementados en cualquier método o tecnología para almacenamiento de información tal como instrucciones legibles por computadora, estructuras de datos, módulos de programa, u otros datos. Los medios de almacenamiento por computadora incluyen, pero no se limitan a, RAM, ROM, EEPROM, memoria instantánea u otra tecnología de memoria, CD-ROM, discos versátiles digitales (DVD), u otro almacenamiento de disco óptico, casetes magnéticos, cinta magnética, almacenamiento de disco magnético u otros dispositivos de almacenamiento magnético, o cualquier otro medio que pueda ser utilizado para almacenar la información deseada y que pueda ser accedido por la computadora 120. Los medios de comunicación típicamente representan instrucciones legibles por computadora, estructuras de datos, módulos de programa u otros datos en, una señal de datos modulada, tal como una onda de vehículo u otro mecanismo de transporte e incluyen cualquier medio de suministro de información. El término "señal de datos modulada" significa una señal que tiene una o más de sus características fijadas o cambiadas de tal manera que codifica la información en la señal. A manera de ejemplo, y no de limitación, los medios de comunicación incluyen medios mediante cables tales como una red con cables o conexión de cable directo, medios inalámbricos tales como medios acústicos, FR, infrarrojos u otros medios inalámbricos. También se deben incluir combinaciones de cualquiera de los anteriores dentro del alcance de los medios legibles por computadora. La memoria de sistema 150 incluye medios de almacenamiento por computadora en la forma de memoria volátil y/o no volátil, tal como memoria de solo lectura (ROM) 151 y memoria de acceso aleatorio (RAM) 152. Un sistema de entrada/salida básico 153 (BIOS) conteniendo las rutinas básicas que ayudan a transferir la información entre elementos dentro de la computadora 120, tal como durante el arranque, típicamente está almacenado en la ROM 151. La RAM 152 típicamente contiene datos y/o módulos de programa que son inmediatamente accesibles y/o que en realidad son operados a través de la unidad de procesamiento 140. A manera de ejemplo, y no de limitación, la Figura 4 ilustra el sistema operativo 54, programas de aplicaciones 155, otros módulos de programa 156, y datos de programa 157. La computadora 120 también puede incluir otros medios de almacenamiento por computadora removibles/no removibles, volátiles/no volátiles. A manera de ejemplo solamente, la Figura 4 ilustra una unidad de disco duro 161 que lee de o escribe a medios magnéticos no removibles, no volátiles, una unidad de disco magnético 171 que lee de o escribe a un disco magnético removible, no volátil 172, y una unidad de disco óptico 175 que lee de o escribe a un disco óptico removible, no volátil 176 tal como un CD-ROM u otros medios ópticos. Otros medios de almacenamiento por computadora removibles/no removibles, volátiles/no volátiles que pueden ser utilizados en el ambiente operativo ilustrativo incluyen, pero no se limitan a, casetes de cinta magnética, tarjetas de memoria instantánea, discos versátiles digitales, cinta de vídeo digital, RAM de estado sólido, ROM de estado sólido, y similares. La unidad de disco duro 161 típicamente está conectada al conductor común de sistema 141 a través de una interfase de memoria no removible tal como la interfase 160, y la unidad de disco magnético 171 y la unidad de disco óptico 175 típicamente están conectadas al conductor común de sistema 141 a través de una interfase de memoria removible, tal como la interfase 170.

Las unidades y sus medios de almacenamiento de computadora asociados, discutidos anteriormente e ilustrados en la Figura 4, proporcionan un almacenamiento de instrucciones legibles por computadora, estructuras de datos, módulos de programa, y otros datos para la computadora 120. En la Figura 4, por ejemplo, la unidad de disco duro 161 se ¡lustra como almacenando el sistema operativo 164, programas de aplicación 165, otros módulos de programa 166, y datos de programa 167. Observar que estos componentes pueden ser ya sea iguales o diferentes del sistema operativo 154, los programas de aplicación 155, otros módulos de programa 156, y datos de programa 157. El sistema operativo 164, los programas de aplicación 165, otros módulos de programa 166 y datos de programa 167 se les proporcionan diferentes números aquí para ilustrar que, en un mínimo, son copias diferentes. Un usuario puede ingresar comandos e información en la computadora 120 a través de dispositivos de entrada tal como un teclado 182, un micrófono 183, y dispositivo de señalamiento 181, comúnmente denominados como un ratón, seguibola, o almohadilla sensible al tacto. Otros dispositivos de entrada (no mostrado) pueden incluir un micrófono, palanca de mando, almohadilla de juegos, antena parabólica, escáner, o similares. Estos y otros dispositivos de entrada por lo regular están conectados a la unidad de procesamiento 140 a través de una interfase de entrada de usuario 180 que está acoplada al conductor común de sistema, pero pueden ser conectada a través de otra interfase y estructuras de conductor común, tales como un puerto paralelo, puerto de juegos, o un conductor común en serie universal (USB). Un monitor 184 u otro tipo de dispositivo de presentación también está conectado al conductor común de sistema 141 a través de una interfase, tal como un adaptador de vídeo 185. Además del monitor, las computadoras también pueden incluir otros dispositivos de salida periféricos tal como bocinas 187 e impresora 186, las cuales pueden ser conectadas a través de una interfase periférica de salida 188. La computadora 120 puede operar en un ambiente en red utilizando conexiones lógicas a una o más computadoras remotas, tal como una computadora remota 194. La computadora remota 194 puede ser una computadora personal, un servidor, un enrutador, una PC de red, un dispositivo par u otro nodo de red común, y típicamente incluye muchos o todos los elementos descritos anteriormente con relación a la computadora 120. Las conexiones lógicas ilustradas en la Figura 4 incluyen una red de área local (LAN) 191 y una red de área amplia (WAN) 193, pero también pueden incluir otras redes. Tales ambientes en red están comúnmente ubicados en oficinas, redes de computadora adquiridas para empresas, intranets e Internet. Cuando se utiliza en un ambiente en red de LAN, la computadora 120 se conecta a la LAN 191 a través de una interfase de red o adaptador 190. Cuando se utiliza en un entorno en red de WAN, la computadora 120 típicamente incluye un módem 192 u otro medio para establecer comunicaciones en la WAN 193, tal como Internet. El módem 192, el cual puede ser interno o externo, puede ser conectado al conductor común de sistema 141 a través de la interfase de entrada de usuario 180, u otro mecanismo apropiado. En un ambiente en red, los módulos de programa ilustrados con relación a la computadora 120, o sus porciones, pueden ser almacenados en el dispositivo de almacenamiento de memoria remoto. A manera de ejemplo, y no de limitación, la Figura 4 ilustra programas de aplicación remotos 195 como residentes en la computadora remota 194. Se apreciará que las conexiones de red mostradas son ilustrativas y se pueden utilizar otros medios para establecer un enlace de comunicaciones entre las computadoras. La Figura 5 ilustra una arquitectura 200 para servicios de lenguaje distribuidos como pueden ser representados en la presente invención. Generalmente, la información almacenada en un servidor web 202 puede ser accedida a través del dispositivo móvil 30 (que también representa aquí otras formas de dispositivos de cómputo que tienen una pantalla de presentación, un micrófono, una cámara, un panel sensible al tacto, etc., como se requirió basándose en la forma de entrada), o a través del teléfono 80 en donde la información es solicitada de forma audible o a través de tonos generados por el teléfono 80 en respuesta a teclas oprimidas y en donde la información del servidor web 202 es proporcionada solo de forma audible de regreso al usuario. Aunque de forma más importante, la arquitectura 200 es unificada si la información es obtenida a través del dispositivo 30 o teléfono 80 que utiliza reconocimiento de lenguaje, un servidor de lenguaje individual 204 puede soportar cualquier modo de operación. Además, la arquitectura 200 opera utilizando una extensión de lenguajes de alza bien conocidos (por ejemplo, HTML, XHTML, cHT L, XML, WML, y similares). De esa forma, la información almacenada en el servidor web 202 también pueden ser accedida utilizando métodos de GUI bien conocidos encontrados en estos lenguajes de marcación. Al utilizar una extensión de lenguajes de marcación bien conocidos, la creación en el servidor web 202 es más fácil, y las aplicaciones de herencia actualmente existentes también pueden ser modificadas fácilmente para incluir reconocimiento por voz. Generalmente, el dispositivo 30 ejecuta descritos de HTML+, o similares, proporcionados por el servidor web "202. Cuando se requiere el reconocimiento por voz, a manera de ejemplo, los datos de lenguaje, que pueden ser señales de audio digitalizadas o características de lenguaje en donde las señales de audio han sido preprocesadas a través del dispositivo 30 como se discutió anteriormente, son proporcionadas al servidor de lenguaje 204 con una indicación de un modelo de gramática o lenguaje para utilizarse durante el reconocimiento de lenguaje. La implementación del servidor de lenguaje 204 puede tomar muchas formas, una de las cuales es ilustrada, pero generalmente incluye un reconocedor 211. Los resultados del reconocimiento son proporcionados de regreso al dispositivo 30 para la presentación local si es deseado o apropiado.

Con la compilación de información a través del reconocimiento y cualquier inferíase de usuario . gráfico si es utilizada, el dispositivo 30 envía la información al servidor web 202 para otro procesamiento y recibo de otros escritos de HTML, si es necesario. Como se ilustra en la Figura 5, el dispositivo 30, el servidor web 202 y el servidor de lenguaje 204 comúnmente están conectados, y son dirigibles de forma separada, a través de una red 205, aquí una red de área amplia tal como Internet. Por lo tanto no es necesario que ninguno de estos dispositivos esté físicamente localizado adyacente uno a otro. En particular, no es necesario que el servidor web 202 incluya servidor de lenguaje 204. De esta forma, la creación en el servidor web 202 puede estar enfocada en la aplicación a la que se pretende sin que los autores necesiten conocer las intrincaciones del servidor de lenguaje 204. Más que eso, el servidor de lenguaje 204 puede estar independiente diseñado y conectados a la red 205, por lo tanto, puede ser actualizado y mejorado sin otros cambios requeridos en el servidor web 202. En otra modalidad, el cliente 30 directamente puede comunicarse con el servidor de lenguaje 204, sin la necesidad del servidor web 202. Además se apreciará que el servidor 202, el servidor de lenguaje 204 y el cliente 30 pueden ser combinados dependiendo en las capacidades de las máquinas de implementación. Por ejemplo, si el cliente comprende una computadora de propósito general, por ejemplo una computadora persona, el cliente puede incluir el servidor de lenguaje 204. De esa forma, si es deseado, el servidor web y el servidor de lenguaje 204 pueden ser incorporados en una máquina individual. El acceso al servidor web 202 a través del teléfono 80 incluye conexión del teléfono 80 a una red de teléfono alámbrico o inalámbrico 208, que a su vez, conecte el teléfono 80 a una entrada en tercera parte 210. La entrada 210 conecta el teléfono 80 a un navegador de voz de telefonía 212. El navegador de voz de teléfono 212 incluye un servidor de medios 214 que proporciona una interfase de telefonía y un navegador de voz 216. Similar al dispositivo 30, el navegador de voz de telefonía 212 recibe escritos de HTML o similares del servidor web 202. Aunque de forma más importante, los escritos de HTML están en la forma similar a los escritos HTML proporcionados al dispositivo 30. De esta forma, el servidor web 202 no necesita soportar el dispositivo 30 y el teléfono 80 de forma separada, o incluso soportar en forma separada a los clientes de GUI estándar. Más que eso, se puede utilizar un lenguaje de marcación común. Además, similar al dispositivo 30, el reconocimiento de voz de señales audibles transmitidas por el teléfono 80 son proporcionadas a partir del navegador de voz 216 al servidor de lenguaje 204, ya sea a través de la red 205, o a través de una línea dedicada 207, por ejemplo, utilizando TCP/IP. El servidor web 202, el servidor de lenguaje 204 y el navegador de voz de teléfono 212 pueden ser representados en cualquier ambiente de cómputo adecuado tal como la computadora de escritorio de propósito general ilustrada en la Figura 4.

Sin embargo, se debe notar que si se emplea el reconocimiento de DTMF, esta forma de reconocimiento generalmente sería realizada en el servidor de medios 214, más que en el servidor de lenguaje 204. En otras palabras, la gramática de DTMF sería utilizada por el servidor de medios. Dados los dispositivos y arquitectura descritos anteriormente, la presente invención además será descrita basándose en un ambiente de cliente/servidor simple. Como se ilustró en la Figura 6, la presente invención pertenece a un sistema 300 que comprende un servidor 302 que proporciona servicios de medios (por ejemplo, reconocimiento de lenguaje o texto para síntesis de lenguaje) y un cliente 304 que ejecuta códigos específicos de aplicación. La comunicación entre el servidor 302 y el cliente 304 está basada en un modelo de servicio en donde la información puede ser intercambiada o etiquetada o de otra forma incluye porciones identificadas tal como, pero no limitándose a, documentos de XML (Lenguaje de Alza Extendido). El servidor 302 y/o cliente 304 puede recolectar y transmitir audio además de otra información. En una modalidad, el servidor 302 puede comprender el Servidor de Lenguaje de Microsoft desarrollado por Microsoft Corporation de Redmon, Washington, mientras el cliente 304 puede tomar cualquier número de formas tal como se discutió anteriormente, incluyendo pero no limitándose a, PCs de escritorio, dispositivos móviles, etc. En este punto se debe notar que aunque el servidor 302 y el cliente 304 se comunican uno con otro basándose en un modelo de servicio, la aplicación que evoca aspectos de la presente invención no necesita ser exclusivamente escrita basándose en un modelo de servicio en esas aplicaciones basadas declarativas y/o de procedimiento pueden ser utilizadas mientras se realiza la comunicación entre el servidor 302 y un cliente 304 de acuerdo con las solicitudes de modelo de servicio. En una modalidad, la aplicación del cliente puede estar compuesta en C+ + , Java, C# u otros lenguajes de programación imperativos que no requieren un navegador como en el caso de las aplicaciones basadas en HTML descritas en la Figura 5. Un aspecto importante de CSTA (ECMA -269) edición 6 son los servicios de voz mejorados basados en las etiquetas de lenguaje de aplicación de lenguaje (SALT). Las características más recientemente agregadas incluyen reconocimiento de lenguaje automático, verificación de lenguaje, identidad de hablante, verificación de hablante y síntesis de texto a lenguaje que pueden ser implementadas en el sistema 300. Algunas o todas de estas características son proporcionadas en centros de llamado automatizados. Los aspectos de la presente invención proporcionan un subgrupo de servicios de CSTA para facilitar la red basada en servicios de lenguaje. En particular, algunos aspectos de la presente invención ilustran como se pueden aplicar ECMA -348 y uaCSTA (ECMA -TR/87) para facilitar servicios de lenguaje distribuidos en un servicio web y SIP (Protocolo Iniciación de Sesión) basado en el ambiente de Vo IP (Voz en protocolo de Internet), respectivamente.

Los servicios para Aplicaciones de Telecomunicaciones Soportadas por Computadora (CSTA) ECMA -269, y sus protocolos de servicio de XML y web son definidas por ECMA -323 y ECMA -348, respectivamente. Recientemente, ECMA -TR/87 (uaCSTA) además describe un grupo de convenciones de SIP para utilizar ECMA -323 en el ambiente VolP. Todos estos protocolos dirigen el grupo completo de CSTA en un principio, y de ahí son aplicables a los servicios de voz en específico. En la sexta edición de ECMA-269, la porción de servicios de vos de CSTA han sido aumentados basándose en la tecnología derivada de SALT. Además de los servicios de voz existentes, una nueva adición incluye características de tecla que son esenciales para la automatización de centro de llamado y aplicaciones móviles, incluyendo reconocimiento de lenguaje automático, modificación de lenguaje, identificación de hablante, verificación de hablante y síntesis de texto a lenguaje, etc. Aunque. las implementaciones de CSTA justamente integradas del control de llamado y escenarios de voz son deseables para los desarrolladores de aplicación, las competencias de centro entre el control de llamado y los vendedores de lenguaje no necesariamente son las mismas. Para el despliegue actual y el futuro previsible, los desarrolladores de aplicación de CSTA pueden necesitar involucrar a múltiples vendedores para satisfacer sus necesidades respectivas en estas áreas. Afortunadamente, el concepto de modelo de CSTA, como se ilustró en ECMA-269, permite a una aplicación individual producir servicios de proveedores de servicio de CSTA múltiples. Por lo tanto es un escenario válido en donde una aplicación de CSTA simultáneamente utilizará dos implementaciones de CSTA, una para control de llamado y otra para servicios de voz. Los perfiles de CSTA para servicios de lenguaje no han sido refinados como en el área de control de llamado. Los aspectos de la presente invención describen un perfil de CSTA para proporcionar servicios de lenguaje en un medio independiente de plataforma que utiliza XML. Aunque el perfil de CSTA es un transporte que es agnóstico en naturaleza, se ejemplifican dos aplicaciones comunes del perfil de servicio de lenguaje aquí para promocionar mejor la interoperabilidad a fin: el amiente de SIP basado en CSTA de poco uso, y el ambiente basado de servicio web basado en ECAM-348. La descripción proporcionada aquí proporciona ejemplos de cómo se pueden incluir subgrupos de Servicios de Voz de CSTA para facilitar procesamiento de lenguaje basado en tiempo-servidor. Los siguientes estándares de ECMA son incorporados aquí por referencia en su totalidad: servicio de ECMA-269 para la fase III de Aplicaciones de Telecomunicación Soportada de Computadora (CSTA); ECMA-323, protocolo de SMLP para la fase III de Aplicaciones de Telecomunicación Soportada de Computadora (CSTA); Lenguaje de Descripción de Servicio Web ECMA-348 (WSDL) para CSTA. Además, esta aplicación describe como se pueden implementar los Servicios de Lenguaje de CSTA en un ambiente de VolP basado en SIP que utiliza la propuesta de uaCSTA. ECMA TR/87 también debe ser utilizado como una referencia para uaCSTA, una copia es incorporada aquí por referencia. El procesamiento de lenguaje basado en cliente-servidor aquí descrito es capaz de controlar tipos de medios asimétricos en un ciclo de respuesta/solicitud. Por ejemplo, al proporcionar servicio de reconocimiento de lenguaje, un cliente transmite datos de audio a un servidor. El servidor convierte los datos de audio a datos de texto y transmite los datos convertidos de regreso al cliente. En el caso de síntesis de lenguaje, el cliente transmite datos de texto y el servidor responde con datos de audio convertidos. Los datos transmitidos pueden ser enviados de acuerdo con un protocolo especificado, tal como uno basado en CSTA. Como resultado, el SIP y ambiente de servicios web pueden ser extendidos para incluir interacciones de texto-audio o audio-texto - audio-un audio. ECMA TR/87 establece un transporte de "canal de señal" 308 como se ilustra en la Figura 6. El canal de señal 308 es utilizado por el servidor 302 y el cliente 304 para intercambiar información en lo que cada uno debe hacer mientras pertenezca a controles de llamado. Cuando el servidor 302 comprende un interruptor de teléfono, el uso de un canal de señal 308 es eficiente. Sin embargo, si el servidor 304 es un servidor de lenguaje y el cliente 304 está pidiendo un servicio de lenguaje, el servidor 302 también deberá saber en donde recibir y transmitir información de lenguaje. Por ejemplo, ei servidor 302 debe saber donde obtener información de reconocimiento de lenguaje y en donde enviar el lenguaje sintetizado. Por lo tanto, además de establecer un canal de señal 308, un protocolo de "canal de medios" 310 también debe ser establecido. Por ejemplo, el canal de medios 310 es utilizado para transportar datos de lenguaje (datos de audio) recolectores por el cliente 304 para el servidor 302. De esa forma, en una operación de texto a lenguaje, el cliente 304 puede enviar los datos de texto a través del canal de señal 308 mientras los datos de lenguaje sintetizados son proporcionados de regreso al cliente 304 desde el servidor 302 a través del cana! de medios 310. Con respecto a la arquitectura de la Figura 5, el canal de señal 308 y el canal de medios 310 son establecidos para cualquier comunicación al servidor de lenguaje 204. Sin embargo, se debe notar que el uso de el servidor de aplicación web 202 es opcional y que la aplicación puede residir en el cliente 30 como se ilustra en la Figura 5. Un aspecto de la presente invención es que pasos son tomados para implementar el canal de medios 310. En una modalidad ilustrativa, se discute el establecer un canal de medios 310 para CSTA en un ambiente SIP. En otra modalidad ilustrativa, se discute que pasos son tomados para implementar el canal de medios 310 para CSTA en un ambiente basado en servicio web. Es importante notar que la información semántica puede ser transferida entre el servidor 302 y el cliente 304, por ejemplo al utilizar Lenguaje de Descripción de Aplicación de Lenguaje (SADL), que puede especificar el esquema de XML para resultados regresados por la fuente oyente, es decir resultados regresados por el servidos 302 con reconocimiento de lenguaje.

ESTABLECIMIENTO DE CANALES EN UN AMBIENTE DE SIP El SIP es protocolo que está diseñado para ser "hablante", para que el servidor 302 y el cliente 304 intercambien pequeñas piezas de información frecuentemente. En el ambiente de SIP, el establecimiento del canal de medios 310 es realizado a través de Protocolo de Descripción de Sesión (SDP). Un método ilustrativo 300 para realizar esta tarea es ilustrado en la Figura 7. En el paso 402, el cliente 304 realiza una sesión con el servidor 302 utilizando una Invitación de SIP. También se envía una descripción de SDP que declara una dirección de IP (Protocolo Internet) que también debe ser utilizado y un puerto en la dirección de IP que debe ser utilizado para el audio. Además, en el paso 404, la descripción de SDP advertirá que tipo de código para codificar es utilizado para la corriente de medios y un protocolo de comunicación tal como un protocolo de control de transmisión (TCP) o protocolo de transporte de tiempo real (RTP). Al recibir a través del servidor, el servidor puede decidir si acepta la descripción de SDP mencionada por el cliente 304, en el paso 406. Si el protocolo y el código son aceptados, el servidor 302 responde con una aceptación de SIP y con su propia descripción de SDP listando su dirección de IP y puerto de audio. Después, el método 400 procede al paso 408, en donde un canal de señal es establecido. En la alternativa, si el servidor 302 no soporta el código o protocolo propuestos, el servidor 302 puede comenzar a negociar con el cliente 304 que código y/o protocolo será utilizado. En otras palabras, el servidor 302 responderá a la descripción de SDP inicial de cliente 304 por un contador-oferta proponiendo un código y/o protocolo diferente. Antes de hacer una propuesta, el método 400 procede al paso 410, en donde hace una determinación como si debe continuar el reconocimiento. Por ejemplo, en el paso 412, después de que se han propuesto un número especificado de ofertas de contador, la comunicación se detendrá. Las ofertas de contador adicionales pueden ser hechas entre el cliente 304 y el servidor 302 en el paso 414 hasta que se alcance un acuerdo o hasta que esté claro que no se alcanzará ningún acuerdo. El SIP/SDP es un estándar aprobado por la Fuerza de Tarea de Ingeniería de Internet (IETF) que es utilizado para establecer el canal de audio en IP por voz. Sin embargo, el SIP/SDP no describe un método para establecer un canal de señal implementando CSTA. En el caso 408, el canal de señal 308 es establecido por ECMA-TR/87. Después del establecimiento del canal de señal, la asociación de aplicación es considerada completa. Como resultado, los servicios de lenguaje distribuidos pueden ser ¡mplementados en el sistema 300.

ESTABLECIMIENTO DE CANALES EN UN AMBIENTE DE SERVICIO WEB En contraste a la naturaleza "hablante" de SIP como se describió anteriormente, los servicios web son diseñados y frecuentemente utilizados para comunicaciones "cortas" para que se necesiten intercambios de diálogo menores entre el servidor 302 y el cliente 304. Como resultado, las características que son negociadas en cambios de diálogo múltiples en SIP usualmente son descritas y descubiertas a través de las descripciones de servicio publicadas en los directorios públicos para los servicios web u obtenidas dinámicamente en un intercambio de metadatos de servicios web. Un ambiente de servicio web incluye un protocolo estándar de UDDI (Integración de Descubrimiento de Descripción Uniforme). Los proveedores de servicio web publican información relevante que los desabolladores pueden descubrir, obtener, y por lo tanto elegir al proveedor de servicio apropiado, que permite a los desabolladores de aplicación integrar dinámicamente el servicio web en la aplicación. Por ejemplo, ECMA -348 especifica el lenguaje de descripción de servicio web (WSDL) para CSTA para que los servicios web que ofrecen funcionalidad de CSTA puedan ser uniformemente descritos, descubiertos, e integrados utilizando protocolos de servicio web estándar. El establecimiento del canal de medios es una extensión a la ECMA-348. La Figura 8 ilustra un método ilustrativo 420 para establecer canales en un ambiente de servicio web. En la invención actual, los proveedores de servicio web listan como metadatos de servicios todos los códigos y protocolos que son soportados por el servicio web en el paso 422. Un desarrollador de aplicación puede utilizar proveedores de directorio de servicio web para obtener o descubrir que servicio web tiene un código o protocolo que puede utilizarse en el paso 424. Este paso puede ser realizado al buscar a través de los metadatos de cada servicio web proporcionado con el fin de encontrar el código y protocolo deseado que requiere. El directorio proporciona una dirección de URL (localizador de recurso universal) para cada servicio web. El cliente 304 después asigna conexión al servicio web y utiliza una aplicación con el código y protocolo deseado para comunicarse con el servidor 302. Después de que se hace una conexión, el canal de medios 310 y su canal de señal 308 son establecidos de una vez. La invención bajo el ambiente de servicio web dirige como establecer las conexiones a través de todos los niveles (aplicación y transporte) en un intercambio a través de una extensión de descripción de medios a WSDL. En una modalidad, la invención puede ser aplicada en conjunto con ECMA -348, que ya tiene un mecanismo para establecer CSTA y su protocolo de transporte de señal resaltado. Al agregar la codificación de medios y extensión de protocolos de transporte a ECMA -348, la CSTA de esa forma es mejorada para establecer los canales de señal y medios en un paso individual. En otra modalidad, la descripción de medios es transportada utilizando la extensibilidad de dirección de servicios web, o dirección de WS, el protocolo como una asociación de aplicación de CSTA de paso precedente. La dirección de WS (WSA), es una especificación que proporciona mecanismos neutrales de transporte para dirigir puntos finales de servicio web y mensajes. Tanto las funciones de cambio de CSTA como las aplicaciones de CSTA son puntos finales de servicio web. Las dirección de WS introduce una nueva especificación, llamada referencia de punto final, que soporta el uso dinámico de servicios no cubiertos apropiadamente por los elementos de <wsdl:servicio> y <wsdl:puerto> en WSDL. La dirección de WS define un tipo de documento de XML (wsa:puntofinalReferenciaTipo) para representar una referencia de punto final. Un elemento XML, wsa:PuntofinalReferencia, también es especificado para tener el tipo. Ambos residen en el espacio de nombre de XML. http : //es quemas, xmlsoap.org/ws/2004/03/dirección. Un tipo de referencia de punto final de WSA puede incluir lo siguiente: [dirección]: un URI (Identificador de Recurso Uniforme) identifica el punto final. [propiedades de referencia]: <xs:cualquiera/> (0 .. ilimitado), propiedades específicas, una para cada entidad o recurso siendo transportado. [tipo de puerto seleccionado]: QNombre (0 ..1), el nombre de tipo de puerto primario como se definió en WSDL para el punto final. [servicio y puerto]: (Úname, NCName (0 .. 1)) (0 .. 1), el servicio de puerto, como se definió en WSDL, que corresponden al punto final, [política]: elementos de política de WS opcionales que describen el comportamiento, requerimientos, y capacidades del punto final. Como en el caso de SIP, establecer un canal de audio es necesario para servicios de lenguaje de CSTA. Como un canal de audio puede ser negociado en SIP a través de SDP, la referencia de punto final de WSA puede ser utilizada para proveedores de servicio de lenguaje para declarar el punto final de medios. Los protocolos de transporte de medios y de los mecanismos de codificación están entre los artículos críticos necesarios para ser especificados con el fin de facilitar servicios de lenguaje. Estos artículos son declarados como propiedades de referencia. Para mejorar el volumen, el canal de medios en un ambiente de servicio web es modelado como un arrendamiento del servidor (proveedor de recursos de voz de CSTA) para el cliente (aplicación de CSTA), y el arrendamiento expira con el tiempo. El servidor también puede designar a un administrador de arrendamiento en donde el cliente puede cancelar o renovar el arrendamiento. Un Tipo de Referencia de Punto Final de medios de CSTA, con un esquema de XML, incluye una o múltiples referencias de punto final de WSA. Por ejemplo, un proveedor de servicio de lenguaje de CSTA que utiliza el protocolo de G.711 en el Protocolo de Transporte de Tiempo Real (RTP) en el puerto 6060 puede describir el punto final de medios como sigue: <csta:MediosPuntoFinalReferenc¡a xnlns:csta = "http://www.ecma international.org/TR/xx" xmlns:wsa = " http://esquemas.xmlsoap.Org/ws/2004/0 3/dirección"> <wsa:Dirección> rtp://Servidor.acme.com:6060 </wsa: Dirección <wsa:ReferenciaPropiedades> <csta:Código> G.711</csta:Código> <csta:SuscripciónlD> 12345</csta:SuscripciónlD> <csta:Expira> 2004-1021T21 :07:00.000 - 08:00 </csta:Expira> </wsa: ReferenciaPropiedades> </csta:MediosPuntoReferencia> Las propiedades de referencia de punto final de medios de CSTA incluyen una declaración de código, un identificador de suscrición, y una declaración de expiración de arrendamiento opcional. Como en el caso de uaCSTA, en donde un canal de medios es establecido junto con el canal de señal, la referencia de punto de final de medios anterior debe ser incluida antes de que sea considerado completo el proceso de asociación de aplicación de CSTA bajo los ambientes de servicio web. Tomar ventaja de la extensibilidad de protocolos de WS, una sesión de lenguaje puede ser establecida utilizando <wsa: Acción>. La referencia de punto final de medios puede por sí misma una propiedad de referencia en la referencia de punto final del proveedor de servicio web de CSTA. Un mensaje de Protocolo de Acceso de Objeto Simple (SOAP) está compuesto al unir la referencia de punto final de medios inmediatamente después del <wsa:Para>, como se muestra más adelante: <soap: Cubierta xmlns:soap="http:/www. w3.org/2003/05/soap -cubierta xm I ns : ws a = "http Resquemas, xmlsoap.org/ws/2004/03 /dirección xmlns:csta = "http:/www.ecma - international.org/TR/xx"> <soap: Encabe zado> <wsa:ResponderA> <wsa:Dirección> http:/ejemplo. cliente.com </wsa: Dirección> </wsa:ResponderA> <wsa:A> http:/Servidor. acme.com </wsa:A> <csta:MediosPuntoFinalReferencia> </csta: MediosPuntoFinalReferenc¡a> <wsa: Acción> http:/www.ecma - i nternational.org/TR/xx/ Crea rSe si ó n </was:Acción> <wsa:MensajelD> ... </wsa:MensajeID> </soap: Encabezado> <soap:Cuerpo> </soap:Cuerpo> </soap:Cubierta> Los servicios son descritos por metadatos tai como política de WS y WSDL. Mientras la política de WS describe capacidades generales, requerimientos y características de un servicio, el WSDL describe operaciones de mensajes abstractas y protocolos de red concretos y direcciones para alcanzar el servicio web. Intercambio de Metadatos de Servicio web, WS - MEX o WSX, es una especificación que se esfuerza para la recuperación de metadatos. Ei cliente puede enviar una solicitud de WS - MEX a un punto final para obtener sus metadatos. Un contorno normativo para la solicitud que utiliza SOAP es como sigue: <soap:Cubierta ...> <soap:Encabezado <wsa:Acción> http://esquemas.xmlsoap.org/ws/2004/09/mex/obtener metada tos/solicitud </wsa: Acción> <wsa: ensajelD> <xs:cualquierURI/> </wsa: MensajelD> <wsa: ResponderA> WS-Dirigir puntofinal referencia </wsa:ResponderA> <wsa:Para> <xs:cualquierURI/> </wsa:Para> </soap: Encabezado> <soap:Cuerpo> <wsx:ObtenerMetadatos ...> [<wsx:Dialecto [Identificado r='<xs :cualquierURI/>']?> <xs: cualquierURI/> </wsx: Dialecto> ]* </wsx:ObtenerMetadatos> </soap:Cuerpoo> </soap:Cubierta> Como se muestra en el encabezado de SOAP, el WS - MEX utiliza dirección de WS para especificar la solicitud para recuperar metadatos. El servicio de objetivo es especificado como un URI en el <wsa:Para>, y el punto final de respuesta es especificado utilizando referencia de punto final de dirección de WS en el contenido de <wsa:ResponderA>. Los tipos de metadatos a ser recuperados son especificados en el contenido de <wsx:ObtenerMetadatos> en el cuerpo de SOAP. Si un punto final acepta solicitud de obtener metadatos, debe responder con un mensaje de respuesta de obtener metadatos. El contorno normativo de la respuesta en SOAP es como sigue: <soap:Cubierta ...> <soap: Encabezado ...> <wsa: Acción> http://esquemas.xmlsoap.org/ws/2004/09/mex/Obtener Metada tos/Respuesta </wsa: Acción> <wsa:RefiereA> mensaje de id previo </wsa:RefiereA> <wsa:Para> <xs:cualquierURI/> </wsa:Para> </soap: Encabe zado> <soap:Cuerpo> <wsx:Metadatos ...> [<wsa: etadatosSección Dialecto = " dialecto URI" [ldentificador='identificador previo']> <xs:cualquier/><! — sección de datos específico de servicio -- > <wsx: Me ta datos Refere ncia> WS-Referencia de punto final de dirección de WS </wsx:MetadatosReferencia> I <wsx:Ubicación> <xs:cualquierURI/> </wsx: Ubicación> 1 </wsa: Metadatos Sección>]* </wsx: Metadatos> </soap: Cuerpo> </soap: Cubierta> Transportados en cuerpo de SOAP, los metadatos pueden ser regresados en línea como contenidos de elemento <wsx:Metadatos>, o por referencia utilizando referencia de punto final de dirección de WS o simplemente URI. Los mensajes de SOAP anteriores pueden tener uniones de WSDL como sigue: <wsd!:nombre de mensaje = "ObtenerMetadatosMensaje"> <wsdl:nombre de parte = "cuerpo" elemento = "tns:obtenermetadatos'7> </wsdl:mensaje> <wsdl: nombre de mensaje="ObtenerMetadatosRespuesta Mensaje"> <wsdl:nombre de parte = "cuerpo" elemento = "tns: Metadatos"/> </wsdl:mensaje> <wsdl:nombre TipodePuerto = "Metadatoslntercambio"> <wsdl:nombredeoperación = "ObtenerMetadatos"> <wsdl:mensaje de entrada = "tns:ObtenerMetadatos Mensaje" wsa: Acción = "http i/esquemas. xmlsoap.org/ws/2004/09/mex/Obtener Metadatos/Solicitud"/> <wsdl:salida mensaje = "tns:ObtenerMetadadosRespues ta Mensaje" wsa : Acción = "http:/esq uemas.xmlsoap.org/ws/2004/09/mex/Obtener Metadatos/ Res pu esta "/> </wsdl:operación> < / w s d I : T i p o d e p u e r t o > La descripción del medio de CSTA es un tipo de metadatos que las aplicaciones de CSTA deben obtener del proveedor de servicios de voz. WS-MEX es particularmente adecuado aquí. Más adelante está en la muestra del mensaje de SOAP para recuperar referencia de punto final de medios: <soap:Cubierta xmlns:soap="http: /www. w3.org/2003/05/soap-cubierta xm I ns : wsa = "http: /esquemas, xmlsoap.org/ws/2004/08/d i re cci ó n xmlns:wsx="http: /esquemas, xmlsoap.org/ws/2004/09/mex xmlns:csta = "http:/www,ecma internacional.org/TR/xx"> </soap:Encabezado> <wsa:acción> http:/esq uemas.xmlsoap.org/ws/2004/09/mex/Obtener Metada tos/Solicitud </wsa:Acción> <wsa:IDdeMensaje> uuid:12345edf -53cl-4923-ba23-23459cee433e </wsa:lDdeMensaje> <wsa:ResponderA> <wsa:Dirección>http:/cliente. ejemplo.com/Mi untofinal </wsa:Dirección> </wsa:Res onderA> <wsa: Para>http:/servidor. acme.org </wsa: Para> </soap:Encabezado> <soap: Cuerpo> <wsx:ObtenerMetadatos> <wsx: Diaiecto> http:/www.ecma - ¡nternacional.org/TR/XX/Puntofinalmedios </wsx: Diaiecto> </wsx:Obtener etadatos> </soap:Cuerpo> </soap:Cubierta> El ejemplo demuestra una aplicación de cliente, localizada en cliente.ejemplo.com, que solicita la referencia de punto final de medios de un proveedor de servicio de lenguaje de CSTA en servidor.acme.org. Debido a que el dialecto específico es especificado, el servidor debe responder solo a los metadatos del tipo deseado. Un mensaje de respuesta de SOAP debe ser: <soap:Cubierta ...> <soap:Encabezado> <wsa:Acción> http:/esq uemas.xmlsoap.org/ws/2004/09/mex/Obetener Meta datos/Res pues ta </wsa:Acc¡ón> <wsa: RelacionadoA> uuid:12345edf-53c1-4923-ba23-23450cee433e </wsa: Relación adoA> <wsa:Para>http: /cliente. ejemplo.com/MiPuntoF i nal>/wsa:Para> </soap:Encabezado> <soap':Body> <wsx:Metadatos> <wsx: Díale ctoteMetadatosSección = "http. www.ecma - internacional.org/TR/XX/PuntoFinalMedios"> <csta:MediosPuntofinal Referen cia> <esa: Dirección >rtp:/servidor. acme.org :6060</wsa: Dirección> <wsa:ReferenciaPropiedades> <csta:Códifo>G.7 </csta:Código> <csta:SuscripciónlD>12345</csta:suscripcionlD> <csta:Expira>2004 -10- 21T21 :00:00.0 -22:00</csta: expira s> </wsa: Referencia Propiedad es> </csta: MediosPuntofinalReferencia> </wsx:MetadatosSección> </Metadatos> </soap:Cuerpo> </soap:Cubierta> La descripción de aplicación de lenguaje es otro tipo de metadatos que un servicio de lenguaje puede proporcionar. Múltiples tipos de metadatos pueden ser obtenidos al mismo tiempo al poblar el <wsx:ObtenerMetadatos> con otros URIs respectivos a través de <wsx: Dialecto>. Lo siguiente es un ejemplo del cuerpo de SOAP para obtener tanto punto final de medios y referencia de aplicación de lenguaje: <wsx:ObtenerMetadatos> <wsx: Dialecto> http:/www.ecma internacional.org/TR/xx/PuntoFinalMedios </wsx:Dialecto http:/www.ecma - internacional. org/TR/xx/ Descripción Aplicación Lenguaje </wsx:Dialecto> </wsx:ObtenerMetadatos> La respuesta correspondiente en el cuerpo de SOAP: <wsx: Metadatos> <wsx: Dialecto de MetadatosSección "http:/www.emca -internacional.org/TR/xx/PuntoFinalMedios"> </wsx: Me ta da tos Sección > <wsx:Dialecto de MetadatosSección = "http:/www.ecma -internacional.org/TR/xx/DescripciónAplicaciónLenguaje"> <csta:id de recurso_"US_DirecciónReconocimiento"> <csta:tipo>Oyente</csta:tipo> <csta:gramática uri="urn:acme.com/dirección/calle_número.grxml" esquema = "urn:acme.com/dirección/calle_número.xsd"/> <csta:gramática uri = urn"urn:acme.com/dirección/ciudad.grxml"> <csta:id regla="código_postai" esquema = "urn:acme.com/dirección s/postal.xsd"/> <csta:id de regla = "ciudad_estado" esquema = "urn:acme.com/dirección s/ciudad.xsd"/> </csta:gramática> </csta:recurso> </wsx: etadatosSección> </wsx:Metadatos> Mientras los servicios web inician en un solo sentido, la solicitud y modelo de respuesta, los servicios web frecuentemente desean recibir mensajes cuando los eventos ocurren en otros servicios o aplicaciones. El evento de servicios web, o evento de WS (WSE), es una especificación para facilitar notificación de eventos. El evento de WS define como un servicio web puede suscribirse a eventos a favor de otro servicio o aplicación, y permite a las aplicaciones especificar como se entregan los servicios de evento. Apoya una gran variedad de topologías de evento, que permiten a la fuente de evento y al evento final hundirse para ser desacoplados. Estas propiedades son adecuadas para un gran rango de aplicaciones de CSTA, que van desde centros de llamado hasta cómputo móvil. El uso de evento de WS es proporcionado debido a que los servicios de voz de CSTA necesitan notificación de evento para funcionar. Aunque la presente invención ha sido descrita con referencia a modalidades particulares, los trabajadores expertos en la técnica reconocerán que se pueden hacer cambios en la forma y detalla sin apartarse del espíritu y alcance de la invención.

Claims (20)

1. REIVINDICACIONES 1. - Un método de comunicación entre un cliente y un servidor, que comprende: establecer un canal de medios; establecer un canal de señal; e intercambiar información entre el cliente y el servidor a través de al menos uno del canal de medios y el canal de señal. 2. - El método de acuerdo con la reivindicación 1, en donde establecer el canal de medios además comprende establecer un código y un protocolo. 3. - El método de acuerdo con la reivindicación 1, en donde el intercambio de información es realizado en un ambiente de Protocolo de Iniciación de Sesión (SIP). 4.- El método de acuerdo con la reivindicación 1, en donde el intercambio de información es realizado en un ambiente de servicios web. 5. - El método de acuerdo con la reivindicación 1, en donde establecer el canal de medios incluye proponer un código y un protocolo para ser utilizados para el canal de medios. 6. - El método de acuerdo con la reivindicación 1, en donde establecer el canal de medios incluye declarar una dirección de protocolo Internet y un puerto asociado con la dirección de protocolo Internet. 7.- El método de acuerdo con la reivindicación 1, y que además comprende proporcionar una lista de al menos un código y al menos un protocolo utilizado para establecer el canal de medios. 8. - El método de acuerdo con la reivindicación 7, y que además comprende hacer referencia a la lista para establecer el canal de medios. 9. - El método de acuerdo con la reivindicación 1, en donde el intercambio de información incluye transmitir datos de lenguaje a través del canal de medios. 10. - Un medio legible por computadora que tiene instrucciones para proporcionar servicios de lenguaje, las instrucciones comprenden: recibir información de señal a través de un canal de señal de acuerdo con un protocolo de señal establecido; recibir información de lenguaje a través de un canal de medios de acuerdo con un código y protocolo establecidos; y procesar la información de señal y la información de lenguaje. 11. - El medio legible por computadora de acuerdo con la reivindicación 10, en donde las instrucciones además comprenden realizar reconocimiento de lenguaje en la información de lenguaje. 12.- El medio legible por computadora de acuerdo con la reivindicación 10, en donde las instrucciones además comprenden establecer una sesión en un ambiente de Protocolo de Iniciación de Sesión (SIP). 13.- El medio legible por computadora de acuerdo con la reivindicación 10, en donde el procesamiento de información de señal y la información de lenguaje es realizado en un ambiente de servicios web. 14. - El medio legible por computadora de acuerdo con la reivindicación 10, en donde las instrucciones además comprenden proporcionar una inferíase de Aplicación de Telecomunicaciones soportada de Computadora (CSTA). 15. - El medio legible por computadora de acuerdo con la reivindicación 10, en donde las instrucciones además comprenden interpretar un mensaje de Protocolo de Acceso de Objeto Simple (SOAP). 16. - El medio legible por computadora de acuerdo con la reivindicación 10, en donde las instrucciones además comprenden procesar la información de lenguaje para identificar la información semántica contenida ahí. 17.- El medio legible por computadora de acuerdo con la reivindicación 10, en donde las instrucciones además comprenden transmitir información a un puerto específico asociado con una dirección de Protocolo Internet (IP). 18. - El medio legible por computadora de acuerdo con la reivindicación 10, en donde las instrucciones además comprenden transmitir un mensaje de Protocolo de Acceso de Objeto Simple (SOAP). 19. - Un método para procesar información en una red de computadora, que comprende: establecer una relación entre un cliente y un servidor en uno de un ambiente de SIP y un ambiente de servicios web; transmitir datos del cliente al servidor de acuerdo con un protocolo especificado, los datos que comprende datos de audio o datos de texto; convertir los datos de datos de audio a datos de texto si los datos son datos de audio y de datos de texto a datos de audio si los datos son datos de texto; y transmitir datos cubiertos del servidor al cliente de acuerdo con el protocolo especificado. 20.- El método de acuerdo con la reivindicación 19, en donde el protocolo especificado está basado en CSTA (Aplicaciones de Telecomunicación Soportada de Computadota).