FACILITAR MEDIOS TEMPRANOS EN UN SISTEMA DE COMUNCACIONES Campo de la Invención La presente invención se relaciona con facilitar a los medios tempranos en un sistema de comunicaciones y más particularmente en un sistema de comunicaciones que utiliza un Protocolo de inicio de sesión como la instalación de sesión y protocolo de control. Antecedentes de la Invención Como se define en IETF RFC 3261, el Protocolo de Inicio de Sesión (SIP) ( es un protocolo de control
(señalización) de capa de aplicación para crear, modificar, y terminar sesiones con uno o más participantes, en una red IP.
Estas sesiones incluyen llamadas telefónicas de Internet, distribución de multimedia, y conferencias de multimedia. Las invitaciones de SIP utilizadas para crear sesiones llevan descripciones de sesión para permitir a los participantes aceptar un juego de tipos de media compatibles. El SIP hace uso de elementos llamados servidores representantes para ayudar a guiar las solicitudes a la ubicación actual del usuario, autenticar y autorizar a usuarios para servicios, implementar políticas de guía de llamada de proveedor, y proporcionar particularidades a usuarios. El SIP también proporciona una función de registro que permite a los
usuarios cargar sus ubicaciones locales para uso por servidores representantes. Los llamados "Servidores de Solicitud" (ASs) se pueden proporcionar en la trayectoria de llamada, v.gr., dentro del SIP de servidores representantes o en otro lugar, a fin de implementar ciertas funciones. El SIP corre sobre diversos protocolos de transporte diferentes. El SIP utiliza el Protocolo de Descripción de Sesión (SDP) para especificar el medio o medios para usarse para la sesión. Una sesión de SIP se inicia típicamente por una terminal de SIP que envía mensaje SIP INVITAR a alguna dirección de SIP. Suponiendo que una terminal llamada desea aceptar la invitación, responde a la terminal que llama con un mensaje SIP 200 OK. La terminal que llama responde al recibo del 200 OK enviando un mensaje ACK a la terminal llamada. Al recibo del mensaje 200 IL (que contiene las terminales llamadas SDP) , la terminal que llama puede comenzar a enviar medios a la terminal llamada. La terminal llamada puede comenzar a enviar medios después del recibo del INVITAR que contiene el SDP del que llama. Cuando una terminal SIP que llama, que podría referirse como Equipo de Usuario (UE) de conformidad con la terminología 3G o a medida que un Cliente de Agente de Usuario (UAC) , inicia una llamada, recibe AS la solicitud de
INVITAR dentro de la red de control de SIP (esta red podría ser un Subsistema de Multimedia IP como se define por 3GPP) . Antes de enviar la solicitud a su destino (nb.. La AS también puede seleccionar no enviar la solicitud, dependiendo del escenario de servicio) , el AS puede desear reproducir un anuncio a la UAC. A fin de hacer esto, es deseable establecer un diálogo anterior entre la UAC y AS que involucre el intercambio de SDPs, la satisfacción de ciertas precondiciones, y un canal de medio se establece. La AS señala su intento de proporcionar medios tempranos en un mensaje 18x (en donde "x" tiene cualquier valor apropiado), el 18x incluyendo el SDP apropiado. Se observa que el AS puede enviar múltiples mensajes 18x, cada uno de los cuales puede ser reconocido por el UAC con un mensaje PRACK, antes de que el AS envíe el mensaje de respuesta 200 al UAC. Cuando el anuncio se ha reproducido, el AS puede enviar la solicitud de INVITAR a la UE llamada, o Servidor de Agente de usuario (UAS) , a fin de continuar la instalación de sesión. El UAS luego establecerá también un diálogo con el UAC. La señalación asociada con este procedimiento se ilustra en la Figura 1. El AS puede seleccionar enviar la solicitud de INVITAR mientras que todavía está reproduciendo el medio
temprano, o aun antes de empezar a reproducir el medio (dependiendo del servicio) . Puede seleccionar cesar el medio temprano cuando se recibe una respuesta (provisional o final) de la parte llamada, o cuando detecta que el medio se recibe de la parte llamada. Las especificaciones de implementación de servicio específicas definirán cuando el medio temprano ha cesado y, si se necesita, definir cuales mecanismos adicionales se van a usar para detectar el medio. De conformidad con este acercamiento a manejar medios tempranos, la respuesta 18x provisional del AS, y la respuesta final (200 (INVITAR)) del UAS, se reciben por el UAC como parte del mismo diálogo dentro de la sesión. El AS debe modificar el parámetro de etiqueta de encabezado To recibido en el mensaje de respuesta del UAS, de manera de coincidir con la etiqueta enviada por el AS en la respuesta
18x provisional. Asimismo, puesto que las solicitudes
(incorporadas en mensajes SIP) se pueden enviar del AS al
UAC, el AS puede tener que modificar el valor de Cseq en solicitudes recibidas del UE llamado, para asegurar los valores en las solicitudes enviadas al UAC son mayores que los valores en solicitudes posiblemente enviadas del AS al UAC. El AS también tendrá que manejas asuntos relacionados con el ajuste de ruta, etc., (es decir, juegos de parámetro
incluidos en el mensaje SIP) . Estos asuntos pueden ser resueltos por el AS actuando como un Agente de Usuario Espalda a Espaldo (B2BUA) . Un asunto adicional que se debe dirigir es la necesidad de proporcionar dos contestaciones de SDP remotas al UAC; el SDP para el medio temprano (iniciado por el AS) , y el SDP del UAS. La contestación SDP no puede cambiar dentro de la misma transacción de INVITAR (es decir enviando el medio temprano SDP en un mensaje 18x, y el UAS SDP EN EL 200) . Hay dos soluciones diferentes a este problema. 1. Después de que se envía el 200 IL, se envía un SIP ACTUALIZAR por el AS al UAC para proporcionar al UAS SDP. El AS de enviar este ACTUALIZAR, puesto que el UAS no tiene conocimiento del SDP previamente enviado por el AS al UAC. La respuesta de ACTUALIZAR 200puede contener un SDP cambiado en la parte del UAC. Sin embargo, si ese es el caso, la respuesta de ACTUALIZAR 200 no se puede enviar directamente al UAS, puesto que fue el AS que inició la transacción de ACTUALIZAR. La respuesta 200 para ese ACTUALIZAR, enviada desde el UAS al AS también puede contener un cambio en SDP para el UAS. Nuevamente, la respuesta 200 no se puede enviar directamente al UAC, y otro ACTUALIZAR al UAC se requiere. Este paso inicial en este procedimiento se ilustra en la
Figura 2. La complejidad de este procedimiento que involucra como lo hace múltiples intervenciones por el AS, es indeseable. 2. Una segunda solución se basa en los mecanismo llamados de "medios tempranos". Como se define por las recomendaciones SIP, "medios tempranos" se refiere a medios (v.gr., audio y video) que se intercambian antes de que una sesión particular se acepte por el usuario llamado. Dentro de un diálogo, el medio temprano puede ocurrir desde el momento en que el INVITAR inicial se envía hasta que el UAS genera una respuesta final . Los medios tempranos pueden ser unidireccionales o bidireccionales, y pueden ser generados por el que llama, el llamado, o ambos. Los ejemplos típicos de medios tempranos generados por el que llama son tonos de timbre y anuncios (v.gr., estado en fila). Los medios tempranos generados por el que llama típicamente consisten en mandos de voz o tonos de multifrecuencia de doble tono (DTMF) para impulsar los sistemas de respuesta de voz interactiva (IVR) . La especificación de SIP básica RFC3261 soporta solamente mecanismos de medio temprano muy sencillos. RFC3959 extiende la proposición original y supera el número de problemas que se pueden suscitar cuando se implementa la
proposición. Se puede hacer uso del mecanismo de disposición de sesión temprana descrito en IETF RFC3959 a fin de permitir a un AS reproducir un anuncio como medio temprano. En este caso, se usan dos SDPs separados, uno para el diálogo temprano y uno para el diálogo con el UAS, y en este caso el AS ofrece el medio temprano al UAC, que el UAC puede seleccionar aceptar o rechazar. El mensaje 18x inicial enviado del As al UAC contiene el SDP para el diálogo temprano, mientras que la respuesta 200 del UAS incluye el SDP para el diálogo de UAC a UAS. El diálogo temprano se termina automáticamente por el UAC al recibo de la respuesta 200. Este procedimiento se ilustra en la Figura 3. Los problemas se pueden presentar con este acercamiento en el caso de que otros nodos en la red también deseen enviar medio temprano. En cualquier caso, el acercamiento tiene la desventaja de que requiere soporte para RFC3959 en las terminales de usuario. Compendio de la Invención Un objeto de la presente invención es superar o cuando menos mitigar las desventajas de los acercamientos existentes proporcionan medios tempranos de un Servidor de Solicitud. Esto se logra efectivamente simulando la entrega
de un diálogo SIP en un Servidor de Solicitud, y usando la entrega simulada como el portador para el medio temprano. De conformidad con un primer aspecto de la presente invención, se proporciona un método para enviar información de un Protocolo de Inicio de Sesión de nodo intermedio a una primera terminal de protocolo de Inicio de sesión, el método comprendiendo : al recibo de una solicitud de inicio de sesión en el nodo intermedio de Protocolo de Inicio de Sesión, estableciendo un primer diálogo de Protocolo de Inicio de Sesión entre el nodo intermedio de Protocolo de Inicio de Sesión y la primera terminal de Protocolo de Inicio de Sesión; enviar información sobre el primer diálogo; y enviar la solicitud del nodo intermedio de
Protocolo de Inicio de Sesión a una segunda terminal de Protocolo de Inicio de Sesión de destino, antes, durante, o después del establecimiento del primer diálogo, y estableciendo un segundo diálogo de Protocolo de Inicio de Sesión, entre la primera y segundas terminales de Protocolo de Inicio de Sesión. El término "nodo intermedio de Protocolo de Inicio de sesión" usado aquí no se pretende para restringir la
aplicación de la invención a cualquier implementación de Protocolo de Inicio de Sesión particular. Sin embargo, un ejemplo de un nodo intermedio de Protocolo de Inicio de Sesión al que la invención se puede aplicar es un Servidor de Aplicación de Protocolo de Inicio de Sesión. Las modalidades de la presente invención se pueden usar para enviar los llamados medios tempranos del nodo intermedio a la primera terminal de Protocolo de Inicio de Sesión. Estos medios tempranos pueden ser, por ejemplo, un anuncio o tono. Sin embargo, la invención alternativamente, o de manera adicional, se puede usar para enviar otra información del AS al UAC, por ejemplo cargar mformaación. Esta otra información se puede incluir como una carga de pago en un mensaje de Protocolo de Inicio de Sesión enviado desde el nodo intermedio a la primera terminal. De preferencia, los diálogos se distinguen por diferentes parámetros de etiqueta de encabezado To en las respuestas de INVITAR . Esta etiqueta luego se usa en el encabezado A/De (to/From) (dependiendo de la dirección de la solicitudes de SIP) en mensajes SIP asociados con los diálogos . De preferencia, el primer diálgo de Protocolo de Inicio de Sesión se establece por el nodo intermedio de
Protocolo de Inicio de Sesión enviando a la primera terminal de Protocolo de Inicio de Sesión un mensaje serie 18x que contiene como su parámetro de etiqueta de encabezado A un valor generado por el nodo intermedio. El segundo diálogo se puede establecer por la segunda terminal que envía una respuesta 200 de Protocolo de Inicio de Sesión a la primera terminal, la respuesta incluyendo como su parámetro de etiqueta de encabezado A un valor generado por la segunda terminal. Alternativamente, el segundo diálogo se puede establecer por la segunda terminal que envía un mensaje serie 18x de Protocolo de Inicio de sesión a la primera terminal, la respuesta incluyendo como su parámetro de etiqueta de encabezado A un valor generado por la segunda terminal. De conformidad con un segundo aspecto de la presente invención, se proporciona un nodo intermedio de Protocolo de Inicio de Sesión dispuesto para enviar información a una primera terminal de Protocolo de Inicio de Sesión, el nodo intermedio comprendiendo: medios de procesamiento para establecer un primer diálogo de Protocolo de Inicio de Sesión entre el nodo intermedio de Protocolo de Inicio de Sesión y la primera terminal de Protocolo de Inicio de sesión, al recibo de una solicitud de inicio de sesión en el nodo intermedio de
Protocolo de Inicio de Sesión; medios para enviar información a través del primer diálogo; y medios para enviar la solicitud del nodo intermedio de Protocolo de Inicio de Sesión a una segunda terminal de Protocolo de inicio de Sesión de destino, antes, durante, o después del establecimiento para el primer diálogo, y para establecer una segundo diálogo de Protocolo de Inicio de Sesión, entre la primera y segunda terminales de Protocolo de Inicio de Sesión. Breve Descripción de los Dibujos La Figura 1 muestra un flujo de señalización SIP general para la provisión de medio temprano por un Servidor de Aplicación de SIP; La Figura 2 muestra un flujo de señalización SIP más detallado para la provisión de medios tempranos por un Servidor de aplicación de SIP incluyen solicitudes de ACTUALIZAR; La Figura 3 muestra un flujo de señalización de SIP para la provisión de medios tempranos por un Servidor de Aplicación de SIP que utilizan el mecanismo de disposición de sesión temprano; y La Figura 4 muestra un flujo de señalización de SIP
para la provisión de medios tempranos por el Servidor de Aplicación de SIP haciendo uso de múltiples diálogos. Descripción Detallada de ciertas Modalidades. IETF RFC3261 es la especificación técnica para los mecanismos de Protocolo de Inicio de sesión (SIP) básicos. Esto incluye provisión para la llamada "bifurcación" que permite que un Servidor de Aplicación (AS) de SIP entregue una solicitud de inicio de sesión SIP entrante (v.gr., un SIP INVITAR) , inicialmente dirigido a una sola terminal SIP, a dos o más terminales SIP. La bifurcación se puede usar por ejemplo para ocasionar que varias terminales SIP (v.gr., un teléfono móvil y uno de mesa) suene en respuesta a una sola solicitud de inicio de sesión. El resultado de un procedimiento de bifurcación, suponiendo que dos o más de las terminales llamadas contestan la solicitud, es que múltiples diálogos SIP se establecerán para la terminal que llama. Se propone aquí proporcionar un medio para entregar medio temprano a una terminal SIP que llama de un SIP AS simulando efectivamente el procedimiento de bifurcación en el SIP AS de manera de establecer múltiples diálogos entre el AS y la terminal que llama, asociada con una sola sesión SIP. A fin de establecer diálogos separados, después del recibo de un SIP INVITAR enviado por el cliente de
Agente de Usuario (UAC) , cualesquiera respuestas provisionales 18x del SIP AS, y la respuesta final del Servidor de Agente de Usuario (UAS) , debe contener diferentes parámetros de etiqueta de encabezado A. La Figura 4 ilustra un flujo de señalización para este acercamiento, en donde la respuesta 18x incluye una etiqueta de encabezado "como" mientras que la respuesta 200 del UAS incluye la etiqueta de encabezado "uas". Todos los mensajes subsecuentes asociados con cada uno de los diálogos incluyen la etiqueta de encabezado apropiado. Utilizando este acercamiento, el As no necesita modificar los encabezados de mensajes SIP recibidos del UAS, como se pueda requerir por el único acercamiento de diálogo. Toda comunicación UAC-a-AS se acomoda dentro de un diálogo separado, que no afecta el diálogo UAC-a-UAS. Mientras que el AS todavía puede actuar como un Agente de Usuario Espalda a Espalda (B7BUA) para otros propósitos esto no es relevante al escenario de medio temprano. Asi como evitar la necesidad de que el SIP AS modifica el parámetro de etiqueta de encabezado A en mensajes SIP recibidos del UAS, el uso de múltiple mecanismo de diálogo también facilita que el AS envía solicitudes SIP al UAC, sin usar un mecanismo de "respaldo falso" ni insertar
solicitudes SIP hacia el diálogo entre el UAC y UAS. Este es el caso en tanto que el diálogo temprano entre el UAC y AS exista. NB . El diálogo temprano se puede terminar por el UAC al recibo del mensaje 200 del UAS o se puede mantener, dependiendo de la implementación real. Las solicitudes de SIP pueden contener información generada en, o suministrarse a, el SIP AS. Por vía de ejemplo, el servicio de Aviso de Cargo propuesto, que se pretende para proporcionar información de carga a los que llaman, se puede implementar incorporando la información de carga en mensajes SIP, v.gr., SIP NOTIFICAR, enviados al UAC, los mensajes incluyendo la etiqueta de encabezado A generada por As. Se apreciará que no es necesario en realidad enviar medios tempranos usando este procedimiento. Más bien, los mensajes 18x se pueden enviar para establecer un primer diálogo que luego se puede usar, por ejemplo, exclusivamente para el envío de información en mensajes SIP. Se observa que el medio temprano se puede proporcionar en una etapa aún anterior implementando RFC3959 también se puede usar si existe un deseo de permitir al AS ofrecer una sesión temprana el AUC, en lugar de esperar hasta que una respuesta (a la oferta) se ha enviado por el AS al UAC. Esto desde luego requiere soporte para RFC3959 de parte
de las terminales. Se apreciará por la persona experta en el ramo que varias modificaciones se pueden hacer a las modalidades arriba descritas sin abandonar el alcance de la presente invención.