MXPA03008511A

MXPA03008511A - Consulta recursiva para datos de red de comunicaciones.

Info

Publication number: MXPA03008511A
Application number: MXPA03008511A
Authority: MX
Inventors: A Mcmurry Kathleen
Original assignee: Worldcom Inc
Priority date: 2001-03-20
Filing date: 2002-03-20
Publication date: 2005-09-15
Also published as: EP1373912A1; BR0208231A; CA2441344A1; US20100175125A1; US20090285204A1; EP1374508A4; US8700528B2; EP1374508A1; EP1374509A4; US20120246043A1; US7289522B2; US7809860B2; JP2005518681A; US20020136370A1; US20020137490A1; BR0208232A; BR0208268A; MXPA03008479A; EP1373912A4; US8543734B2

Abstract

Se describe un planteamiento para proporcionar telefonia y otros servicios sobre una red de datos. Un sistema de comunicaciones (100) incluye un servidor de ubicacion (115) que genera un primer subconjunto del conjunto de todas las direcciones relacionadas con una parte a la que se llama (118). Un servidor proxy (113) obtiene un primer subconjunto de direcciones desde el servidor de ubicacion (115) e intenta establecer una sesion con la parte a la que se llama (118) con base en el subconjunto de direcciones. En respuesta a si el primer subconjunto de direcciones da como resultado el establecimiento de la sesion, el servidor proxy (113) puede solicitar entonces un segundo subconjunto desde el servidor de ubicacion (115). La informacion de contexto que proporciona el servidor de ubicacion (115) con el primer. subconjunto se puede regresar al servidor de ubicacion (115) como parte de la solicitud para el segundo subconjunto.

Description

CONSULTA RECURSIVA PARA DATOS DE RED DE COMUNICACIONES CAMPO DE LA INVENCION La presente invención se relaciona con un sistema de comunicaciones, y está relacionada más particularmente con la determinación de direcciones para establecer sesiones de comunicaciones .

ANTECEDENTES La proliferación de redes de transporte de datos, más notablemente la Internet, está provocando una revolución en la telefonía y otras formas de comunicación en tiempo real. Los negocios que se han acostumbrado a tener tráfico de telefonía y tráfico de datos separadamente, soportados sobre diferentes sistemas y redes, ahora se están moviendo hacia las llamadas "redes convergentes", en donde el tráfico de voz telefónico y otras formas de medios en tiempo real se convierten a forma digital, y una red de datos de paquetes los transporta junto con otras formas de datos. Ahora que es factible que las tecnologías lo soporten, el transporte de voz sobre datos ofrece muchas ventajas en términos de capital reducido y costos operativos, eficiencia de los recursos y flexibilidad . Por ejemplo, en instalaciones comerciales, las inversiones de equipo de las instalaciones del cliente se reducen sustancialmente como la mayoría de las funciones mejoradas, tales como PBX y las funciones de distribución de llamadas automáticas, pueden residir en una red de proveedores de servicios. Diferentes tipos de puertas de enlace permiten que se establezcan sesiones aún entre diferentes sistemas tales como teléfonos IP, teléfonos analógicos convencionales, y PBXs, así como con computadoras de escritorio conectadas en red. Para satisfacer la demanda de transporte de voz sobre datos, los proveedores de servicios y los vendedores de equipo de red se enfrentan con los retos de establecer nuevos protocolos y estándares, reconocer nuevos modelos de negocios, implementar nuevos servicios, y diseñar nuevo equipo de una manera que hubiera sido difícil imaginar hace veinte años . Por ejemplo, una nueva generación de dispositivos terminales de usuario final ahora están reemplazando los teléfonos tradicionales y hasta a los más recientes aparatos telefónicos PBX. Estos nuevos aparatos, tales como aquellos que ofrecen Cisco y Pingtel, pueden conectarse directamente a una red de datos de paquetes común, por medio de una conexión Ethernet por ejemplo, y caracterizan despliegues visuales grandes para mejorar la riqueza de la interfase del usuario.

Aún antes de que se desarrollaran esos dispositivos, las computadoras equipadas con adaptadores de audio y conectadas a la Internet eran capaces de conducir alguna forma rudimentaria de telefonía por Internet, aunque la calidad era impredecible, y frecuentemente muy deficiente. Ahora el énfasis está sobre la adaptación de las redes de protocolo de Internet (IP, por sus siglas en inglés) y otras redes de transporte de paquetes, para proporcionar conexiones de calidad de tarifa de llamada de larga distancia, fácil establecimiento de llamadas, y características mejoradas para suministrar telefonía completamente caracterizada, así como otras formas de transporte de medios. Algunos otros tipos de sesiones de medios habilitadas mediante esas técnicas pueden incluir video, audio de alta calidad, conferencia de múltiples partes, mensajería y aplicaciones participativas. Por supuesto, a medida que un suscriptor de comunicaciones de negocios o residencial empiece a usar esas comunicaciones de voz sobre paquetes para reemplazar la telefonía convencional, naturalmente existirá una expectativa de que la calidad de las conexiones y la diversidad de los servicios será cuando menos tan buena como en la red telefónica anterior. En términos de servicios, por ejemplo, algunos negocios han llegado a confiar en las características PBX o características "Centrex" residentes en la red, tales como adelantamiento de llamada y manejo condicional de llamadas . En el futuro cercano, se espera que esos servicios especiales vean un uso incrementado debido a que los dispositivos terminales nuevos mencionados anteriormente pueden proporcionar una interfase mucho más intuitiva para los usuarios. Con los sistemas existentes, los usuarios frecuentemente olvidan qué combinaciones de golpes de tecla se requieren para invocar características mejoradas. Para establecer una sesión de comunicaciones en una red, han surgido nuevos protocolos y arquitecturas de control. Es digno de notar que éstos se han inspirado por la migración a una voz sobre datos, pero no están necesariamente limitados a ese medio ambiente. En algunos aspectos, los protocolos y arquitecturas de control descritos se pudieran usar después para establecer llamadas a través de cualquier forma de transporte. Tanto el estándar ITU H.323 como el Protocolo de Inicio de Sesión (SIP, por sus siglas en inglés) de la IETF son ejemplos de protocolos que se pueden usar para establecer una sesión de comunicaciones entre terminales conectadas a una red. El protocolo SIP se describe en el documento RFC 2543 de la IETF y sus sucesores. Se han propuesto diferentes arquitecturas en conjunción con estos protocolos con un tema común de tener una función de resolución de dirección, a la que se hace referencia como un "servidor de ubicación", en algún lugar de la red, para mantener información actual sobre cómo llegar a cualquier destino, y para controlar las características en beneficio de los usuarios.

Para el desarrollo a gran escala del transporte de voz sobre datos, asi como otras comunicaciones en tiempo real, es esencial que las arquitecturas de control de la red sean extremadamente robustas y altamente escalables para acomodar de manera confiable millones de sesiones sobre una base diaria. La robustez puede necesitar diseño en los mecanismos de redundancia y de fallas repetidas . De Preferencia, estas medidas hasta proporcionarán una continuidad transparente de sesiones y características existentes aún si ocurre una falla a la mitad de una sesión. Para asegurar este nivel de conflabilidad y para aumentar al máximo la escalabilidad, generalmente es preferible reducir al mínimo la demanda sobre las funciones de control, tal como los servidores de ubicación, para mantener cualquier información de estado persistente para cada llamada en la red .

COMPENDIO La presente invención da atención a la necesidad de robustez y escalabilidad en un sistema de procesamiento de sesiones, así como otras necesidades, en la cual un sistema de comunicaciones integrado proporciona servicios de telefonía y datos sobre una red de datos. El sistema utiliza, en una modalidad ejemplar, el Protocolo de Inicio de Sesión (SIP) para establecer sesiones de comunicaciones.

Brevemente, una sesión se inicia de la siguiente manera: Primeramente el servidor proxy recibe una solicitud, tal como un mensaje "INVITAR" ("INVITE") SIP, típicamente desde una estación de llamada en donde un primer usuario desea contactar a un segundo usuario. El segundo usuario se puede identificar por el número telefónico, la dirección IP, o el localizador uniforme de recursos (ÜRL, por sus siglas en inglés), por ejemplo. El servidor proxy puede entonces retransmitir una solicitud de ruteamiento al servidor de ubicación para propósitos tales como verificar los privilegios del primer usuario para llegar al segundo usuario, encontrar una o más ubicaciones para el segundo usuario y realizar cualesquier características de manejo de llamadas proporcionadas para el primero o segundo usuarios . Generalmente, el servidor de ubicación responde a la solicitud del proxy por medio de regresar al servidor proxy una o más direcciones de las terminales en donde se puede contactar al segundo usuario. Después de la recepción de la información de dirección desde el servidor de ubicación, el servidor proxy comienza a enviar un mensaje "INVITAR", o similar, a cada dirección. De esta manera, el servidor proxy intenta llegar al segundo usuario por medio de probar las direcciones ya sea serialmente o en paralelo. El servidor de ubicación puede regresar múltiples direcciones si, por ejemplo, un perfil de usuario dado indica una lista "Encuéntrame" ("Find-Me") , esto es, un conjunto de contactos que se deben probar para llegar al segundo usuario al que se está llamando. Mediante la provisión de su perfil que mantiene el servidor de ubicación, un usuario puede especificar, por ejemplo, que las llamadas entrantes van a un teléfono IP primero, después a otro teléfono, después a un teléfono móvil y, si todavía no hay ninguna respuesta en estas ubicaciones, entonces a un sistema de correo de voz. Una entrada en una lista Encuéntrame puede ser una dirección que represente todavía otra cuenta adentro de la red. Esta cuenta puede tener, a su vez, su propio perfil asociado que incluya una lista Encuéntrame. Por lo tanto, es posible que una sola parte a la que se llama, solicitada por un usuario, corresponda a una jerarquía de direcciones de contacto en el servidor de ubicación. Este fenómeno coloca una carga considerable sobre el servidor de ubicación porque se pudiera tener que determinar un número potencialmente grande de direcciones de contacto, y regresarse por cada solicitud INVITAR, aún cuando pudiera llegarse a la parte a la que se llame en una de las primeras direcciones de contacto intentadas por el servidor proxy. En un aspecto, la presente invención proporciona un planteamiento alternativo en donde el servidor de ubicación pudiera tener que determinar un número grande de direcciones a la vez. En su lugar, el servidor de ubicación pudiera regresar un primer conjunto de direcciones después de una solicitud de ruteamiento inicial desde el servidor proxy, y después pudiera regresar otras direcciones después de solicitudes subsecuentes de ruteamiento desde el servidor proxy . De conformidad con una modalidad preferida, el servidor de ubicación regresa una lista de direcciones, algunas de las cuales pudieran corresponder con otras cuentas que, por si mismas, producirán múltiples contactos. Esta lista inicial que se regresa al proxy no incluye el listado "expandido" completo de estos últimos contactos. Más bien, de conformidad con una modalidad preferida, cada una de esas direcciones "expansibles" simplemente se reporta en la lista inicial junto con una bandera o etiqueta asociada con la dirección, para indicar que ésta se pudiera expandir a múltiples direcciones. Al trabajar a través de la lista inicial de direcciones, el servidor proxy usa esta etiqueta para activar la recuperación subsecuente de los conjuntos de direcciones expandidos únicamente si, y cuando se necesiten éstas . Para habilitar al servidor de ubicación para manejar de manera eficiente estas solicitudes subsecuentes del proxy, sin mantener la información de estado persistente para la sesión, se proporciona información de contexto adicional con la senda dirección regresada por el servidor de ubicación al servidor proxy. A medida que el servidor proxy solicite subsecuentemente contactos adicionales del servidor de ubicación, el servidor proxy incluye la información de contexto en las solicitudes subsecuentes. Como se explicará con mayor detalle posteriormente, el pasar esta información de contexto de regreso al servidor de ubicación permite convenientemente que el servidor de ubicación pase por alto muchos pasos que se necesitan realizar únicamente para una solicitud de ruteamiento inicial. También es especialmente importante liberar al servidor de ubicación de mantener el estado de esta manera, para permitir que cualquiera de los servidores de ubicación disponibles maneje las solicitudes subsecuentes. En otras palabras, el servidor de ubicación que da servicio a una solicitud subsecuente para un conjunto de direcciones expandido no tiene que ser la misma instancia del servidor de ubicación que proporcionó la lista inicial. Todos los servidores de ubicación deben operar equivalentemente y mantener una imagen consistente del direccionamiento y la información de perfil del usuario. La necesidad de consultar diferentes servidores de ubicación puede surgir debido a los mecanismos de fallas repetidas o de equilibrio de carga. En un aspecto de la presente invención, se describe un método para establecer una sesión de comunicaciones con una parte usando múltiples contactos. Un servidor de ubicación mantiene un conjunto de contactos para la parte. El método generalmente comprende los pasos de obtener un conjunto inicial de contactos desde el servidor de ubicación, intentar establecer una sesión con la parte usando el conjunto de contactos inicial, y, si la sesión no se establece exitosamente usando el primer conjunto de contactos, obtener un conjunto de contactos subsecuente para tratar . En otro aspecto de la presente invención, la información de contexto relacionada con el procesamiento que ocurre en el servidor de ubicación se obtiene del servidor de ubicación en conjunción con una solicitud de contactos para una parte. La misma información de contexto se proporciona al servidor de ubicación en conjunción con una solicitud subsecuente para facilitar el procesamiento de la solicitud subsecuente por parte del servidor de ubicación. En otro aspecto de la presente invención, uno o más contactos obtenidos de un servidor de ubicación pueden activar solicitudes adicionales al servidor de ubicación. En otro aspecto de la presente invención, uno o más contactos obtenidos de un servidor de ubicación pueden llevar una indicación de si una solicitud subsecuente al servidor de ubicación es apropiada o no para el contacto dado. En otro aspecto de la presente invención, se describe un elemento del servidor de ubicación, el cual es capaz de proporcionar información del contacto para una parte, en respuesta a las solicitudes inicial y subsecuentes. De conformidad con una modalidad preferida, el elemento del servidor de ubicación incluye un elemento para proporcionar y recibir información de contexto relacionada con el procesamiento en el servidor de ubicación. Además, de conformidad con una modalidad preferida, el elemento del servidor de ubicación incluye un elemento para proporcionar un indicador de finalidad con cada contacto proporcionado en respuesta a una solicitud. En otro aspecto de la presente invención, se describe un elemento del servidor proxy para manejar las solicitudes de sesión mediante la obtención de contactos desde un servidor de ubicación, e intentando establecer una sesión con una parte usando los contactos proporcionados. De conformidad con una modalidad preferida, el elemento del servidor proxy determina si una sesión se estableció usando los contactos y, en respuesta, determina si debe obtener contactos adicionales del servidor de ubicación. De conformidad con una modalidad preferida, el elemento del servidor proxy acepta procesar la información de contexto del servidor de ubicación, en conjunción con la obtención de un conjunto de contactos, y después proporciona la información de contexto al servidor de ubicación en conjunción con una solicitud subsecuente por contactos. De conformidad con una modalidad preferida, el elemento del servidor proxy interpreta una respuesta desde un servidor de ubicación para determinar si se debe presentar una solicitud subsecuente por más contactos. De conformidad con una modalidad preferida, el elemento del servidor proxy inicia una solicitud subsecuente por contactos desde el servidor de ubicación, en respuesta a un contacto proporcionado en una respuesta anterior. De conformidad con una modalidad preferida, el elemento del servidor proxy interpreta un indicador asociado con un contacto, para determinar si se debe presentar una solicitud subsecuente al servidor de ubicación, en respuesta al contacto. En otro aspecto de la presente invención, se describe un medio legible por computadora, que tiene instrucciones ejecutables por computadora para realizar un método para implementar el elemento del servidor de ubicación. En otro aspecto de la presente invención, se describe un medio legible por computadora, que tiene instrucciones ejecutables por computadora para realizar un método para implementar el elemento del servidor proxy. Por la siguiente descripción detallada serán rápidamente evidentes todavía otros aspectos, características, y ventajas de la presente invención, simplemente mediante la ilustración de un número de modalidades e implementaciones particulares, incluyendo el mejor modo contemplado para realizar la presente invención. La presente invención también es capaz de otras modalidades diferentes, y sus muchos detalles se pueden modificar en diferentes aspectos, sin apartarse del espíritu y alcance de la presente invención. De conformidad con lo anterior, los dibujos y la descripción que siguen se contemplarán como ilustrativos en naturaleza, y no como restrictivos.

BREVE DESCRIPCION DE LOS DIBUJOS La presente invención se ilustra a manera de ejemplo, y no a manera de limitación, en las figuras de los dibujos acompañantes, y en los cuales los mismos números de referencia se refieren a elementos similares, y en los cuales : La Figura 1 es un diagrama de un sistema de comunicaciones de datos capaz de soportar servicios de voz, de conformidad con una modalidad ejemplar de la presente invención . La Figura 2 es un diagrama de los elementos funcionales envueltos en el establecimiento de una sesión entre partes, de conformidad con una modalidad ejemplar de la presente invención. La Figura 3 es un diagrama de flujo de llamada que describe cómo ocurre típicamente la mensajería para establecer una sesión cuando una parte de destino pudiera tener múltiples contactos. La Figura 4 es un esquemático que ilustra un anidamiento de contactos de ejemplo para una parte de destino. La Figura 5 es un diagrama de un mensaje de múltiples opciones SIP típico, de conformidad con la técnica anterior.

La Figura 6 es un diagrama de bloques de los elementos funcionales envueltos en el inicio de sesión, de conformidad con una modalidad ejemplar preferida de la presente invención. La Figura 7 es un diagrama de un mensaje de múltiples opciones SIP, de conformidad con una modalidad ejemplar preferida de la presente invención. La Figura 8 es un diagrama de un mensaje INVITAR SIP, de conformidad con una modalidad ejemplar preferida de la presente invención. Las Figuras 9A-9B son diagramas de flujo de un proceso para manejar solicitudes de sesiones como las realiza un servidor de ubicación, de conformidad con una modalidad ejemplar preferida de la presente invención. La Figura 10 es un diagrama de flujo de un proceso para manejar solicitudes de sesiones como las realiza un servidor proxy, de conformidad con una modalidad ejemplar preferida de la presente invención.

La Figura 11 es un diagrama de flujo de un proceso en un sistema de comunicaciones, para obtener y probar múltiples contactos en subconj untos , de conformidad con una modalidad ejemplar preferida de la presente invención. La Figura 12 es un diagrama de un sistema de computadora que se puede usar para implementar una modalidad de la presente invención.

DESCRIPCION DETALLADA En la siguiente descripción, se pueden mostrar estructuras y dispositivos bien conocidos en forma de diagrama de bloques, o resumirse de otra manera con el propósito de evitar el oscurecimiento innecesario de la presente invención. Para propósitos de explicación, se establecen numerosos detalles específicos con el propósito de proporcionar un entendimiento profundo de la presente invención. Se debe entender, sin embargo, que la presente invención se puede practicar en una diversidad de maneras más allá de estos detalles específicos. Por ejemplo, aunque la presente invención se describe en el contexto del Protocolo de Inicio de Sesión (SIP) y una red basada en el Protocolo de Internet (IP) , uno de experiencia ordinaria en la técnica reconocerá que la presente invención se puede aplicar generalmente a otros protocolos de comunicación o redes de comunicaciones equivalentes o análogos. A lo largo de esta descripción se debe entender que, aunque se muestran los mensajes tipo SIP por conveniencia, se puede aplicar cualquier tipo de protocolo o una mezcla de esos protocolos, en diferentes partes del sistema global. En particular, las solicitudes de ruteamiento y las respuestas entre el servidor proxy y el servidor de ubicación se pueden conformar estrictamente o libremente a SIP o algún otro protocolo estandarizado, o pueden ser propietarias en naturaleza. La Figura 1 muestra un diagrama de un sistema de comunicaciones de datos capaz de soportar servicios de voz, de conformidad con una modalidad ejemplar de la presente invención. El sistema de comunicaciones 100 incluye una red de transporte de datos de paquetes 101, la cual, en una modalidad ejemplar, es una red basada en Protocolo de Internet (IP) . El sistema 100 proporciona la habilidad para establecer comunicaciones entre diferentes equipos terminales acoplados al mismo, tales como el teléfono 125, el teléfono PBX 118, y el teléfono SIP 109. En la práctica, pudiera haber miles de millones de esos dispositivos terminales a los que da servicio uno o más sistemas 100. Como se usa en la presente, el término "teléfono SIP" se refiere a cualquier cliente (por ejemplo, una computadora personal, un aparto Web, etcétera) que esté configurado para proporcionar funcionalidades de teléfono SIP. Los teléfonos SIP 109 pudieran tomar la forma de dispositivos autónomos -por ejemplo, un teléfono SIP pudiera estar diseñado y configurado para funcionar y aparecer como una estación telefónica de Servicio Telefónico Antiguo Simple (POST, por sus siglas en inglés) . Un cliente SIP 111, sin embargo, es un cliente de software y pudiera ejecutarse, por ejemplo, en una computadora personal (PC, por sus siglas en inglés) convencional o computadora laptop . Desde una perspectiva de señalización, estos dispositivos 109, 111 pudieran operar de manera muy similar, con las diferencias principales relacionadas con la interfase del usuario. A menos que se declare de otra manera, se reconoce que las funcionalidades tanto de los teléfonos SIP 109 como del cliente SIP 111 son comparables, y que la red opera de manera similar con cualquier tipo de dispositivo. El sistema 100 proporciona un número de elementos para soportar los servicios de voz, incluyendo una puerta de enlace de empresa 103, una puerta de enlace de Linea de Acceso Dedicada (DAL, por sus siglas en inglés) 105, una puerta de enlace de red 107, y la plataforma de conferencias SIP 127. En particular, el sistema 100 comprende los elementos importantes de un servidor proxy 113 (también conocido como un servidor de red (NS, por sus siglas en inglés) ) y de un servidor de ubicación (LS, por sus siglas en inglés) 115. El servidor de ubicación 115 da servicio como un depósito para la información del usuario final, para habilitar la validación de direcciones, el estado de características, y la configuración de características del suscriptor en tiempo real. Adicionalmente , el LS 115 puede almacenar información de configuración. Para los propósitos de explicación, las capacidades del sistema 100 se describen con respecto a usuarios de empresas grandes. Se nota que la característica/funcionalidad del sistema 100 se puede aplicar a una diversidad de tipos de usuario y necesidades de comunicaciones. El sistema 100 es capaz de soportar clientes para mantener múltiples ubicaciones con requerimientos de voz y datos. Como se muestra, la puerta de enlace de empresa 103 proporciona conectividad desde un PBX 117, el cual contiene líneas interurbanas o líneas frecuentemente para un solo cliente o ubicación de negocio (por ejemplo, los teléfonos 118) . La señalización para llamadas desde el PBX 117 en la red IP comprende información que identifica de manera única al cliente, grupo de líneas interurbanas, o portador. Esto permite que los números privados se interpreten en su contexto correcto. Para interconectarse al PBX 117, la puerta de enlace de empresa 103 puede usar la Red de Servicios Digitales Integrados (ISDN, por sus siglas en inglés), la Señalización Asociada de Circuitos (CAS, por sus siglas en inglés) , u otras interfases PBX (por ejemplo, PRI, R2 del Instituto Europeo de Estándares de Telecomunicaciones (ETSI, por sus siglas en inglés) ) . La puerta de enlace de la Linea de Acceso Dedicada (DAL) 105 se emplea en el sistema 100 para permitir que los clientes de la red privada virtual (VPN, por sus siglas en inglés) sean capaces de accesar su servicio aún desde un teléfono convencional al que no de servicio la VPN. A través del sistema 100, se pueden establecer comunicaciones entre las estaciones de voz 125 a las que se da servicio a través de la PSTN 123, y las computadoras personales (por ejemplo, la PC 111) que están unidas a la red de datos de paquetes 101. Teniendo en mente la naturaleza similar de los clientes suaves de PC y los teléfonos IP autónomos, se podría decir que existen cuatro posibles escenarios con la colocación de una llamada de voz sobre IP: (1) de teléfono -a - teléfono, (2) de teléfono - a - PC, (3) de PC - a -teléfono, y (4) de PC - a - PC. En el primer escenario de establecimiento de llamada de teléfono - a - teléfono, una llamada desde el teléfono 125 se conmuta a través de la PSTN 123, por medio de un conmutador, a la puerta de enlace de red 107, la cual envía la llamada a través de la red vertebral IP 101. Después se enruta la llamada de voz paquetizada, a través de la red 101, posiblemente a otra puerta de enlace de red 107 similar, para estar en otro teléfono PSTN (no se muestra) . Bajo el segundo escenario, el teléfono 125 coloca una llamada a una PC a través de un conmutador a la PSTN 123. Esta llamada de voz se conmuta entonces por medio de la PSTN 123 a la puerta de enlace de red SIP 107, la cual envia la llamada de voz a una PC 111 por medio de la red 101. El tercer escenario envuelve una PC 111 que coloca una llamada a una estación de voz (por ejemplo, el teléfono 125) . Usando un codificador de voz, la PC 111 introduce un flujo de paquetes de voz en la red 101, que están destinados para la puerta de enlace de red SIP 107. La puerta de enlace de red SIP 107 convierte la información de voz paquetizada a una señal eléctrica POST, la cual se conmuta por circuitos a la estación de voz (por ejemplo, el teléfono 125). Finalmente, en el cuarto escenario, una PC 111 establece una llamada de voz con otra PC (no se muestra) ; en este caso, los datos de voz paquetizados se transmiten de la PC 111, por medio de la red 101, a la otra PC (no se muestra) , en donde se descodifican los datos de voz paquetizados. Como se mencionó, el sistema 100 puede emplear SIP para intercambiar mensajes de establecimiento de sesión. Se hace referencia a otro protocolo de establecimiento de sesiones popular como el protocolo H.323, aunque éste es actualmente un conjunto de protocolos relacionados, promulgados por la Unión Internacional de Telecomunicaciones (ITU, por sus siglas en inglés) para realizar la comunicación multimedia. El SIP es un estándar alternativo que ha desarrollado la Fuerza de Trabajo de la Ingeniería de Internet (IETF, por sus siglas en inglés) . El SIP es un protocolo de señalización que se basa en un modelo de cliente - servidor, queriendo decir generalmente que los clientes invocan los servicios, mediante solicitudes de mensajería, a los servidores que pueden proporcionar los servicios. De manera similar a otros protocolos IETF (por ejemplo, el protocolo de transferencia de correo simple (SMTP, por sus siglas en inglés) y el Protocolo de Transferencia de Hipertexto (HTTP, por sus siglas en inglés) ) , el SIP es un protocolo textual, legible por el hombre. Se pudiera notar que ni el protocolo H.323 ni el protocolo SIP están limitados a aplicaciones de telefonía IP, sino que tiene aplicabilidad a servicios de multimedia en general. En una modalidad de la presente invención, se usa SIP para establecer llamadas telefónicas y otros tipos de sesiones, a través del sistema 100. Sin embargo, para aquellos de experiencia ordinaria en la técnica será evidente que se podrían utilizar el protocolo H.323 (con algunas modificaciones o extensiones) u otros protocolos similares en lugar de SIP. Aparte de SIP, pero frecuentemente usado en conjunción con el SIP, está el Protocolo de Descripción de Sesión (SDP, por sus siglas en inglés), el cual proporciona información acerca de flujos de medios en las sesiones multimedia para permitir que los receptores de la descripción de sesión participen en la sesión. El protocolo SIP de la Fuerza de Trabajo de la Ingeniería de Internet define numerosos tipos de solicitudes, a las cuales también se hace referencia como métodos. Un método importante es el método INVITAR el cual invita a un usuario a una conferencia. Otro método es la solicitud ADIOS (BYE) , la cual indica que se puede liberar la llamada. En otras palabras, ADIOS termina una conexión entre dos usuarios o partes en una conferencia. Otro método es el método OPCIONES (OPTIONS) . Este método solicita información acerca de las capacidades sin establecer necesariamente una llamada. El método REGISTRO (REGISTER) se puede usar para proporcionar información a un servidor SIP acerca de la ubicación presente •de un usuario . En IETF RFC 2543 y en el Anteproyecto de Internet de la IETF "SIP Cali Control Services" ("Servicios de Control de Llamadas SIP"), 17 de junio de 1999; ambos documentos están incorporados a la presente como referencia en su totalidad, se describen detalles respecto a SIP y sus servicios de control de llamadas . La transmisión de mensajes SIP puede tener lugar en una red IP, a través del bien conocido Protocolo de Datagrama del Usuario (UDP, por sus siglas en inglés) , o a través del más confiable Protocolo de Control de Transacción (TCP, por sus siglas en inglés) . Aunque se pueden usar el SIP, el H.323, u otros protocolos para establecer sesiones a través de una red de datos, los medios actuales o "tráfico" que se va a comunicar entre los usuarios puede tener lugar de conformidad con el bien conocido Protocolo de Transporte en Tiempo Real (RTP, por sus siglas en inglés) como se describe en el documento RFC 1889 de la IETF. Es probable, aunque no esencial, que todo de la señalización de control de llamada (SIP, H.323), el tráfico de medios (RTP/RTCP) y la administración y provisión de red se comuniquen a través de la red de transporte común 101. Asi, en la Figura 1, todos los elementos aparecen en una configuración de cubo alrededor de la red de transporte 101. En la red telefónica tradicional, las llamadas se dirigen a ubicaciones especificas o dispositivos terminales identificados de manera única por el número telefónico al que se llama. En contraste, el sistema 100 habilita a la persona que llama para especificar una parte a la que se llama a la que se va a llegar independientemente de cualquier ubicación o terminal particular. El usuario puede moverse de una terminal a otra y, en cada terminal, puede registrarse como estando presente, de tal manera que las llamadas que entran se dirijan a la ubicación más recientemente registrada. Además, un usuario puede tener ajustes de perfil tanto personales como por grupo, que afecten la activación de las características, tales como bloqueo de llamadas, hasta como una función de la hora del día. Debido a la naturaleza dinámica de la ubicación del usuario y de las características de manejo de la llamada, cada solicitud para establecer una sesión primero se enruta a un servidor proxy, de tal manera que se puedan verificar los permisos del usuario, se puedan encontrar las direcciones de destino, y se puedan aplicar a la llamada las características especiales relacionadas con un usuario o un negocio. A las solicitudes se les da servicio internamente o por medio de pasarlas, posiblemente después de la traslación, a otros servidores. Un proxy interpreta, y, si es necesario, vuelve a escribir un mensaje de solicitud antes de enviarlo. En general, el servidor de ubicación 115 acepta una solicitud de ruteamiento, tal como desde un servidor proxy, y determina las direcciones o "contactos" correspondientes a la parte de destino expresada en la solicitud de ruteamiento. En respuesta a la solicitud, el servidor de ubicación puede regresar la respuesta de volver a dirigir, que comprenda información del contacto para la parte. Se nota que la mensajería entre el NS 113 y el LS 115 puede usar una versión modificada del SIP. Por ejemplo, pudieran ser innecesarios los mensajes de reconocimiento SIP entre el NS 113 y el LS 115. De otra manera, la mensajería entre las funciones de la red, tales como NS 113 y LS 115, puede usar el estándar SIP o hasta alternativas no SIP. El sistema 100 incluye además un Sistema de Soporte Operativo (OSS, por sus siglas en inglés) 121 para proporcionar aprovisionamiento, facturación, y capacidades de administración de la red. El OSS 121 pudiera proporcionar un medio ambiente o una inferíase, tal como una interfase basada en la Web, para el aprovisionamiento de muchos aspectos de los planes de marcación, permisos del usuario, y cómo operan las características en beneficio de cada usuario. Muchos de estos aspectos se configuran por medio del OSS 121 por medio de cambiar la información adentro de los servidores de ubicación o las bases de datos adentro del sistema 100. Algunas características específicas que se podrían configurar mediante el OSS 121 incluyen características Centrex heredadas tales como Adelantamiento Incondicional de Llamadas, Adelantamiento Condicional de Llamadas, Bloqueo de Llamadas y Clasificación de Llamadas. Una característica que se podría configurar envuelve el servicio llamado "Encuéntrame". Un programa Encuéntrame proporciona un mecanismo para rutear las llamadas usando una lista de posibles destinos, en donde cada destino se prueba a la vez. Una lista Encuéntrame se podría especificar para aplicarse durante una hora del día o día de la semana, o se pudiera asociar con diferentes categorías de números de llamada. Por otra parte, se podría proporcionar una lista Encuéntrame establecida previamente para determinar el manejo general cuando no estén en efecto las listas Encuéntrame más específicas. Los posibles destinos en una lista Encuéntrame pueden ser direcciones específicas asociadas con el perfil de una cuenta. Por ejemplo, un número de teléfono celular o número de teléfono alámbrico específico puede ser una posible dirección de destino. Por otra parte, cuando un usuario registra su presencia en una terminal, tal como un teléfono SIP, la dirección de la terminal se podría añadir temporalmente a la lista Encuéntrame. Para un perfil de teléfono SIP, la lista Encuéntrame podría contener direcciones de destino específicas aprovisionadas en el perfil de usuario, y/o una referencia a las direcciones actuales registradas. Para un teléfono tradicional detrás del perfil de una puerta de enlace de empresa, la lista Encuéntrame puede contener direcciones de destino específicas aprovisionadas en el perfil del usuario y/o la referencia al teléfono PBX del usuario. La característica de lista Encuéntrame se puede habilitar para un usuario durante la creación de la cuenta, y después el usuario la puede actualizar. Las entradas hechas a la lista Encuéntrame se pueden verificar contra la Lista de Bloqueo de Característica para el plan de marcación del suscriptor. El perfil de usuario tiene un enlace para actualizar la lista Encuéntrame. Específicamente, el sistema 100 permite que el usuario Cree, Lea, Actualice, y Suprima un inventario de dispositivos potenciales, los cuales se pueden usar para llenar los listados Encuéntrame. Los teléfonos SIP 109 les permiten a los usuarios registrar y quitar del registro, o conectarse y desconectarse, del teléfono. En una modalidad ejemplar, para proporcionar movilidad, los teléfonos SIP 109 permiten que se introduzcan nombres de usuarios y palabras clave para los visitantes. La conexión le permite al teléfono SIP suponer el perfil del visitante. Mediante la conexión, las llamadas entrantes del perfil del visitante se dirigen al teléfono. Cuando un visitante se conecta, los teléfonos SIP 109 registran al visitante con el Servidor de Red 113 y el Servidor de Ubicación 115. Cualquier llamada entrante a cualquiera de los perfiles registrados por el teléfono se puede dirigir al teléfono. El Servidor de Red 113 y el Servidor de Ubicación 115 pueden responder de manera similar a ambas situaciones en donde un usuario se conecta como un visitante, o en donde el usuario se conecta a su dispositivo de inicio usual, si hay alguno. El lógico del Servidor de Red 113 y el Servidor de Ubicación 115 puede depender del nombre de usuario enviado como un resultado del reto de autorización proxy. Con respecto al direccionamiento E.164 y DNS, los teléfonos SIP 109 pueden soportar el servicio ENUM (siglas en inglés para Número Electrónico) , el cual se usa para enrutar las llamadas que se originan en el dominio IP, o con redes habilitadas por ENUM . El servicio ENUM se detalla en IETF RFC 2916, titulado "ENUM", que está incorporado a la presente como referencia en su totalidad. Los teléfonos SIP 109 también pueden soportar LINCP para la búsqueda de directorios basados en el cliente. Una característica "No Molestar" ("Do Not Disturb") puede estar disponible en una terminal, de tal manera que se declinen las llamadas entrantes y, en el caso de teléfonos y localizadores por ejemplo, no ocurre ningún timbrado que perturbe a los usuarios cercanos. Cuando se invoca "No Molestar" en un teléfono SIP 109, el teléfono SIP 109 regresa un mensaje de Ocupado (Busy) si lo contacta el NS 113. Por ejemplo, el teléfono regresa una señal de ocupado en lugar de timbrar cuando llega una llamada entrante. Cuando el teléfono SIP 109 regresa un mensaje "486 Ocupado", el Servidor de Red 113 y el Servidor de Ubicación 115 pueden tomar decisiones de ruteamiento inteligentes con base en un perfil de usuario, tal como si se ha aprovisionado una característica de Adelantamiento de Llamada En Ocupado . La Figura 2 es un diagrama que ilustra la interacción típica de los elementos básicos de conformidad con la técnica anterior, para realizar un establecimiento de sesión mediante el uso del protocolo SIP. Las comunicaciones entre estos elementos típicamente tendrá lugar a través de una red de datos de paquetes común, tal como la red IP 101 de la Figura 1. En la Figura 2, el Usuario A 210 desea establecer comunicaciones con el Usuario B 220. El Usuario B 220 puede estar disponible en cualquiera de muchas direcciones. Estas direcciones o contactos pueden corresponder a teléfonos convencionales, teléfonos IP, teléfonos inalámbricos, localizadores, etcétera. La lista de direcciones hasta puede estar cambiando a medida que el Usuario B se mueve y se registra como estando presente en diferentes dispositivos terminales 222. La información actual acerca de la información de contacto del Usuario B típicamente se mantiene en el servidor de ubicación 240, o en un registro de presencia de algún tipo que no se muestra en la presente. Para iniciar el contacto, el Usuario A 210 accesa una terminal, la estación de llamada 212, y especifica al Usuario B como el destino que se alcanzará. Esta expresión del destino deseado específico pudiera tomar la forma de marcación de dígitos, o de selección de un nombre de usuario o de dirección estilo URL de una lista. En algunos casos, el Usuario A también podría ser capaz de expresar qué tipo de sesión se desea (video, alta calidad, mensajería, etcétera), o especificar un nivel de calidad deseado para la sesión. Una vez que se especifica la solicitud en la estación 212, se compone un mensaje "INVITAR" SIP que describe la solicitud, y se envía al servidor proxy 230. El servidor proxy 230 típicamente envía una solicitud al servidor de ubicación 240 para recuperar uno o más contactos en los cuales se pudiera llegar al usuario B. Como se describió anteriormente, el servidor proxy 230 consulta al servidor de ubicación 240 por una diversidad de propósitos, tales como invocar el comportamiento de característica controlado por el perfil, y la obtención de la última información de ubicación conocida relacionada con el Usuario B. El servidor de ubicación 240 analiza la solicitud y responde al servidor proxy 230 en una de muchas maneras posibles. El servidor de ubicación 240 puede no permitir la sesión, si no se permite el Usuario ? contactar al usuario B, si no se puede reconocer la dirección del Usuario B, o si el Usuario B tiene una característica activada que hace al Usuario B inalcanzable para el usuario A. El servidor de ubicación 240 puede responder al servidor proxy 230 que el Usuario A debe autenticarse a sí mismo con el sistema, antes de que se pueda establecer la sesión. El servidor de ubicación 240 puede determinar que se le permite al Usuario A contactar al Usuario B, y hasta puede encontrar múltiples direcciones en las cuales el usuario B pudiera estar disponible. Si éste es el caso, el servidor de ubicación 240 regresa un mensaje ?300 Múltiples Opciones" SIP que contenga una lista de los contactos que se van a probar.

Después de recibir esa respuesta, el servidor proxy 230 comienza entonces a probar los contactos para ver si se puede llegar exitosamente al Usuario B en cualquiera de las terminales correspondientes 222. Esta funcionalidad "Encuéntrame" usualmente se realiza en secuencia, empezando con la ubicación registrada más reciente, o siguiendo un orden especifico según esté aprovisionado para el Usuario B (teléfono después localizador) . En algunas configuraciones, es concebible que el servidor proxy 230 pueda probar todos los contactos en paralelo. Un intento para establecer contacto con una terminal 222 envuelve enviar un "INVITAR" SIP a la terminal y esperar una respuesta indicativa de éxito o falla. En la Figura 3 se describe en mayor detalle este proceso . La Figura 3 es un diagrama de flujo de llamada que ilustra la secuencia típica de la mensajería que ocurre entre diferentes elementos, para establecer una sesión usando el protocolo SIP, aunque se podrían usar otros protocolos. En este ejemplo, la estación asociada con el Usuario A se denota "Usuario A". Sin embargo, debido a que el Usuario B pudiera estar asociado con cualquier número de dispositivos (o clientes) bajo la característica Encuéntrame, se hace referencia a estos dispositivos como "Terminal 1", "Terminal 2", y "Terminal 3". Se nota que, en general, se pueden especificar cualquier número de terminaciones (es decir, clientes de destino) en la lista Encuéntrame del Usuario B. Bajo este escenario, se presume que eventualmente se llega al Usuario B por medio de la Terminal 3. Cada uno del Usuario ? del dispositivo terminal y las Terminales 1, 2, y 3 puede ser un teléfono SIP u otro tipo de teléfono, y se puede acoplar a través de una puerta de enlace de empresa o una puerta de enlace de red 107 o similar. El Usuario B tiene una característica Encuéntrame como parte de su perfil, dando como resultado que se prueben múltiples contactos. Con base en esto, el NS1 responde a la solicitud del Usuario A para llegar al Usuario B, por medio de enviar mensajes INVITAR primero a la Terminal 1, después a la Terminal 2, después a la Terminal 3, en donde finalmente se completa la llamada. En este ejemplo, se presume que las Terminales 1, 2 y 3 son teléfonos SIP. Se hará referencia a cada instancia de un mensaje que se está enviando desde un elemento hacia otro como un paso, como en un proceso o secuencia. En el paso 301, se envía un mensaje "INVITAR" SIP que indica que el Usuario A intenta llegar al Usuario B, desde la terminal del Usuario A hacia el proxy, NS1. En el paso 303, el proxy responde con un mensaje "407 Autorización Requerida" para impugnar la autenticidad del Usuario A, antes de promover cualesquxer solicitudes. Para proporcionar cierre en este intercambio inicial, el Usuario A manda de regreso un mensaje de reconocimiento SIP al proxy en el paso 305. El Usuario A subsecuentemente repite la solicitud INVITAR en el paso 307, pero esta vez incluye un encabezador de autenticación en respuesta a la impugnación del paso 303. Si la autenticación del Usuario A es satisfactoria, entonces, en el paso 309, se envía INVITAR al servidor de ubicación. El servidor de ubicación empieza a examinar la solicitud y a determinar si el Usuario B tiene un perfil, y qué características están actualmente activas. Mientras tanto, se envía de regreso una respuesta provisional "100 Tratando" a la terminal de Usuario A como un indicador de clases de progreso de la llamada. Pronto después de lo mismo, el servidor de ubicación responde en el paso 313 con un mensaje "300 Múltiples Opciones" SIP indicando que éste ha encontrado la lista Encuéntrame para el Usuario B. Esta respuesta comprende una lista de contactos en los cuales se debe intentar la comunicación con el Usuario B, en este caso las Terminales 1, 2, y 3. Después, el proxy NS1 empieza a probar los contactos secuencialmente . En el paso 315, el NS1 envía un mensaje INVITAR a la Terminal 1, después de lo cual la Terminal 1 responde en el paso 617 con un mensaje "404 No Se Encontró". Este indica que no se podrá llegar al Usuario B en la Terminal 1. El NSl reconoce el mensaje "404" por medio de enviar un mensaje "REC" ("ACK") en el paso 319. Sin este reconocimiento la Terminal 1 repetiría la respuesta "404" a intervalos para asegurarse de que se ha recibido su respuesta . En el paso 321, el proxy NSl intenta el contacto por medio de la Terminal 2, mediante el envío de un mensaje INVITAR. En el paso 323, la Terminal 2 envía de regreso una respuesta provisional "180 Timbrando" como un indicador de progreso que le dice a la parte que llama que la terminal está timbrando (teléfono) , o alertando de otra manera a los usuarios en la vecindad de una llamada entrante. En el paso 325, este mensaje de timbrando se pasa del proxy a la terminal del Usuario ?. Eventualmente, después de que la Terminal 2 ha estado timbrando durante un tiempo, sin ser contestada, se declara un intervalo y el NSl emite un mensaje "CANCELAR" en el paso 327, de tal manera que la Terminal 2 dejará de timbrar. Después el proxy NSl trata de llegar al Usuario B por medio de la Terminal 3 y envía un mensaje INVITAR a la Terminal 3 en el paso 327. Mientras se está comenzando este nuevo contacto, sucede que la Terminal 2 responde a "CANCELAR" ("CANCEL") anterior por medio de enviar de regreso un mensaje "200 Está Bien" en el paso 331. La Terminal 2 envía entonces un mensaje "487 Solicitud Cancelada" en el paso 333 para indicar su entendimiento de la cancelación reciente. El proxy NS1 termina la transacción con la Terminal 2 por medio de enviar un "REC" en el paso 335, confirmando que se canceló el intento de llamada a la Terminal 2. En el paso 337, la Terminal 3 envía de regreso una respuesta "180 Timbrando", la cual se repite de regreso al Usuario ? en el paso 339. En el paso 641, la Terminal 3 envía un mensaje "200 Está Bien" indicando que se ha aceptado la llamada en esta terminal. El "200 Está Bien" se envía de regreso a la terminal del Usuario A, así como en el paso 343. En los pasos 345 y 347 se regresa el reconocimiento de la conexión viable. En este punto, la terminal del Usuario ? y la Terminal 3 ahora están mutuamente conscientes de las direcciones una de la otra, y se puede establecer una conexión de medios RTP en dos direcciones, a través de la red entre el Usuario A y el Usuario B. Para proporcionar un entendimiento de la presente invención y una apreciación de sus ventajas, la Figura 4 ilustra una situación que tanto se habilita como se maneja apropiadamente de conformidad con una modalidad preferida de la presente invención. En la Figura 4, un servidor de ubicación recibe un mensaje INVITAR 402 que identifica al Usuario B. Después de probablemente verificar la validez de otros aspectos de la solicitud, el servidor de ubicación determina una primera lista de contactos 410 relacionada con el Usuario B al momento de la solicitud. Entre la primera lista de contactos 410, uno o más de los contactos pudieran, de hecho, representar otras cuentas que tuvieran perfiles accesibles mediante el servidor de ubicación. Por ejemplo, como se muestra en la Figura 4, el contacto ?2 en la primera lista de contactos 410 pudiera tener un perfil que, a su vez, especifique una segunda lista de contactos 420. Es concebible que una primera lista de contactos pudiera comprender un número de contactos, cada uno de los cuales pudiera tener un perfil que especifique otra lista de contactos. Este efecto pudiera continuar hasta cualquier profundidad. Se podria demostrar rápidamente que pudiera seguir un número muy grande de contactos a partir de una sola consulta. El cálculo de todos estos contactos pudiera ser engorroso para un servidor de ubicación, y hasta pudiera ser muy innecesario si se puede llegar a la parte a la que se llama entro de los primeros contactos probados. La presente invención busca mejorar la escalabilidad y eficiencia por medio de disminuir esta carga en el servidor de ubicación. La Figura 5 ilustra un mensaje de respuesta de volver a dirigir 500 como lo podria regresar un servidor de ubicación en la situación establecida en la Figura 4. Por conveniencia, el mensaje 500 se muestra que se va a modelar después de un mensaje "300 Múltiples Opciones" SIP, aunque se pueden usar otros formatos. El mensaje 500 se identifica como una respuesta "múltiples opciones" en virtud de la primera linea del encabezador 502. La trayectoria que ha atravesado ese mensaje 500 al ir desde una terminal de origen a un servidor proxy se refleja en el conjunto de lineas de dirección "Via" 504. Este aspecto de "vía pila" de SIP es útil para rutear mensajes entre los servidores proxy, servidores de ubicación, terminales, y otros elementos de familiarizados con SIP, envueltos en el establecimiento de la sesión. En la sección de encabezador 506 se proporciona otra información de encabezamiento típica relacionada con la llamada, y usualmente se copia del mensaje INVITAR original enviado por la terminal de origen. La sección de contacto 508 comprende la lista de contactos que ha determinado el servidor de ubicación para el Usuario B. En respuesta al mensaje 500 un servidor proxy consultará la sección de contactos 508, y empezará a enviar mensajes INVITAR a cada contacto en la lista. Se debe observar que el mensaje 500 es representativo de la situación en donde se han calculado todos los posibles contactos para el Usuario B , y se han regresado en un solo mensaje. La Figura 6 es un esquemático de la interacción entre los elementos para establecer una sesión de conformidad con una modalidad ejemplar preferida de la presente invención. Como en los escenario previos, un usuario A 610 desea establecer una sesión con el usuario B 620, quien podría estar en uno de muchos diferentes contactos. Note que, en este ejemplo, los contactos 622 son consistentes con la situación que se ilustra en la Figura 4. El Usuario A origina la solicitud de sesión usando la terminal 612, la cual ensambla entonces un mensaje INVITAR SIP, indicando el intento de llegar al Usuario B. A los largo de la trayectoria de mensaje 650, la terminal 612 envía el mensaje INVITAR a un servidor proxy SIP, el servidor de red (NS) 630a. Para obtener información acerca de dónde se puede contactar al Usuario B, el NS 630a envía una solicitud de ruteamiento a un servidor de ubicación, representado por el servidor de ubicación (LS) 640, como se indica por la trayectoria del mensaje 651. Esta solicitud de ruteamiento opcionalmente puede tomar la forma de un mensaje INVITAR SIP. Después del procesamiento de la solicitud de ruteamiento, el LS 640 responde al NS 630a a lo largo de la trayectoria del mensaje 652. Para propósitos de ilustración, se presume que esta respuesta se asemeja al mensaje "300 Múltiples Opciones" SIP que se ilustra en la Figura 7. Volviendo brevemente ala Figura 7, el mensaje SIP 700 es representativo de una respuesta desde un servidor de ubicación, de conformidad con una modalidad ejemplar de la presente invención. El mensaje SIP 700 se identifica como la respuesta ^múltiples opciones" por parte del encabezador 702. Como se describió anteriormente, el conjunto de encabezadores "vía" 704 se usan para el ruteamiento de los mensajes SIP entre los elementos SIP, tales como el NS 630a y el LS 640. La sección 706 del mensaje 700 comprende información que identifica la llamada y las partes que se van a envolver en la sesión. Las secciones 702, 704 y 706 son comparables al mensaje SIP de la técnica anterior que se muestra en la Figura 5. Sin embargo, la sección de contactos 708 es significativamente diferente de la sección 508 de la Figura 5. En la sección 708, la lista de contactos es notablemente más corta que la sección 508, aún cuando las circunstancias de la llamada son equivalentes. Por otra parte, cada contacto enlistado en la sección 708 también comprende un parámetro añadido que no se encuentra entre los contactos en la sección 508. Específicamente, algunos contactos tienen un parámetro final=si" 714. De conformidad con una modalidad preferida de la presente invención, éstos corresponden a las direcciones de contacto para las cuales no es necesaria más búsqueda del servidor de ubicación. En otras palabras, éstas son direcciones que no tienen perfiles que pudieran dar como resultado direcciones adicionales . Una entrada en la sección de contactos 708 tiene un parámetro "final=no" 710 junto con el parámetro de información de contexto 712. De conformidad con una modalidad preferida, este parámetro indica que el contacto pudiera tener un perfil correspondiente que podria desprender otras direcciones de contactos, aunque éstas direcciones adicionales no se hayan explorado todavía. La sección de lista de contactos 708 se puede comparar con la situación de la Figura 4, para mostrar claramente por qué la respuesta inicial del LS 640 indica que el contacto ?2 es "no final" . Para un claro entendimiento de cómo el NS 630a responde a estos parámetros o "banderas" en la lista de contactos, es útil ahora resumir la explicación de la Figura 6. Después de recibir la respuesta de "múltiples opciones" desde el LS 640, el NS 630a empieza la secuencia de mensajería a cada contacto en la lista de contactos que proporcionó el LS 640. Como se ve en el mensaje 700, el primer contacto Al tiene un parámetro "final=si" que indica que no se requiere ninguna búsqueda de direcciones adicional. De conformidad con lo anterior, el NS 630a simplemente envía un mensaje INVITAR a lo largo de la trayectoria de mensajes 653, directamente a una terminal 622 que corresponde con el contacto Al. Esta actividad es similar a la manera usual en la cual un proxy intenta llegar a un destino. Es posible que la terminal 622 pueda regresar al mensaje "404 No Se Encontró" como una respuesta final, indicando que el Usuario B definitivamente no se podrá alcanzar en el contacto. Alternativamente, la terminal 622 puede regresar una respuesta provisional a lo largo de la trayectoria de mensajes 65.4, tal como un mensaje "180 Timbrando" para indicar que la terminal está tratando de llamar a alguien para que conteste la llamada. Si se llega al Usuario B exitosamente en el contacto Al, entonces la terminal 622a regresa un mensaje "200 Está Bien", después de lo cual el Usuario A y el Usuario B establecen una conexión de medios uno con el otro, y se inicia exitosamente la sesión. Los mensajes de respuesta desde la terminal Al se pueden regresar a la terminal de origen 612 a lo largo de la trayectoria de mensajes 659. Si no se llega al Usuario B en el contacto Al, entonces el NS 630a procede al contacto A2 enlistado en la sección 708. El contacto A2 lleva un parámetro "final=no" 710 que representa la posible existencia de una lista secundaria de direcciones, tal como la lista de contactos 420. De conformidad con una modalidad preferida de la presente invención, el NS 630a envía un mensaje INVITAR a si mismo, en lugar de a un contacto de terminal. Este comportamiento se ilustra en la Figura 6 por la presencia del NS 630b. El NS 630b es de hecho el mismo servidor proxy que el NS 630a, aunque es probable que éste sea una instancia diferente del proceso de colocación en proxy en el medio ambiente de procesamiento del servidor. El mostrar al NS 630a y al NS 630b por separado es útil para ilustrar el comportamiento de la mensajería. Después de llegar al contacto A2 no final, el servidor proxy envía un mensaje INVITAR a sí mismo a lo largo de la trayectoria de mensajes 655. En la Figura 8 se muestra un ejemplo de este mensaje INVITAR como el mensaje 800. De conformidad con una modalidad ejemplar preferida, la porción de Solicitud-ÜRI 802 del mensaje 800 lleva información adicional copiada directamente de la entrada de lista de contactos A2 que se ve en el mensaje 700. La importancia de esta información añadida será más evidente en la descripción posterior . Después de la recepción del mensaje INVITAR desde el NS 630a, se instancia al NS 630b igual que si se hubiera recibido un nuevo mensaje INVITAR desde un originador. El mensaje INVITAR dirigido a sí mismo a lo largo de la trayectoria 655 se maneja como cualquier otro mensaje INVITAR entrante. De conformidad con lo anterior, el NS 630b envía una solicitud de ruteamiento a lo largo de la trayectoria de mensajes 656 al LS 640 para buscar información de contactos para el destinatario, en este caso el contacto A2. Es en este momento que el LS 640 "expande" el único contacto A2 a la lista de contactos más larga que comprende los contactos Bl a B4. El LS 640 regresa esta lista en respuesta al NS 630b a lo largo de la trayectoria de mensajes 657. Después el NS 630b intenta contactar al Usuario B en estas ubicaciones B1-B4. Por ejemplo, el NS 630b primero envía un mensaje INVITAR a la terminal Bl a lo largo de la trayectoria de mensajes 658. Las respuestas de cada intento de contacto se regresan al proxy y al originador a través de las trayectorias de mensajes 660, 661 y 659. Este comportamiento de mensajería de regreso es parte del mecanismo SIP. Si ninguno de los contactos B1-B4 es exitoso, entonces el NS 630a continúa con las direcciones ?3 y ?4. En el presente ejemplo, el NS 630b únicamente se emplea para explorar las direcciones adicionales asociadas con el contacto A2. Los contactos ?1, ?3 y ?4 solamente se realizan directamente mediante el NS 630a de la manera usual, sin la creación ni la utilización del NS 630b. Note además que, en este escenario, si se fuera a llegar exitosamente al Usuario B en el contacto Al, entonces se evitarían todas las siguientes actividades, reduciendo mediante lo mismo la carga sobre el LS 640: 1) Búsqueda de direcciones de los contactos Bl-B4 con base en el perfil del contacto A2 2) Otras invocaciones de características relacionadas con el perfil A2 3) El uso del segundo NS 630b 4) Mensajería a lo largo de las trayectorias 655, 656, 657, 661.

En el escenario de ejemplo que se muestra, la recuperación de un conjunto inicial de direcciones a lo largo de las trayectorias 651 y 652 tendría lugar exactamente una vez de conformidad con una modalidad ejemplar, dando como resultado que se regrese la lista de contactos del mensaje 700 al NS 630a. (Pudiera ocurrir otra mensajería preparatoria entre el NS y el LS durante la autenticación del Usuario ?, por ej emplo) . En el escenario de ejemplo que se muestra, la mensajería a lo largo de las trayectorias 655, 656 y 657 ocurriría únicamente una vez, dando como resultado que se regrese la lista de los contactos B1-B4 al NS 630b, y aún entonces únicamente después de que el contacto ?1 se pruebe no exitoso. El NS 630b entonces enviaría INVITAR a cada uno de los cuatro contactos B1-B . Para generalizar más allá del escenario específico, la "mensajería a sí mismo" representada por el NS 630b y las trayectorias de mensajes 655, 654, 657 y 669 se repetirían una vez por cada contacto no final enlistado en la respuesta de volver a dirigir, regresado a lo largo de la trayectoria de mensaje 652. Por otra parte, es posible que uno o más de los segundos contactos de la hilera, tales como los contactos Bl-B4, también pudieran tener un perfil que produjera direcciones adicionales. Si se encuentra esto, ocurre un nivel adicional de anidamiento, y el servidor proxy envia nuevamente un mensaje INVITAR a si mismo. Como se puede prever por la Figura 6, esto ascendería a la instanciación de un tercer NS recibiendo la mensajería INVITAR desde el segundo NS 630b. Ahora se proporciona una descripción adicional para reforzar el entendimiento de los procesos anteriores, así como para describir cómo el parámetro de información de contexto mencionado hasta ahora mejora la eficiencia y la robustez de la técnica. Ahora la descripción se enfocará en los procesos realizados por un servidor de ubicación y un servidor de red. Las Figuras 9A-B son diagramas de flujo que describen un proceso 900 por medio del cual un servidor de ubicación maneja las solicitudes de ruteamiento entrantes. Otros procesamientos, tal como el procesamiento de otros tipos de mensajes, pueden tener lugar en el servidor de ubicación, pero no es importante para el entendimiento de la presente invención. El procesamiento de otros tipos de mensajes SIP es bien entendido entre aquellos de experiencia ordinaria en la técnica, y se excluye en la presente por el bien de la claridad y la brevedad. El proceso 900 comienza con el paso 902 después de la recepción de una solicitud de ruteamiento entrante. Después, en el paso 904, se determina si la porción de contactos, tal como la porción Solicitud-URI de un mensaje INVITAR, lleva un parámetro "final=no" similar al parámetro 804 en la Figura 8. Si no, entonces la solicitud de ruteamiento se trata como una solicitud original, y el proceso procede al paso 908 para analizar más la solicitud y el originador. El paso 908 puede envolver la recuperación de la información desde una base de datos, respecto al originador y el destino pretendido. Esa información de contexto puede incluir, por ejemplo, un identificador de plan de marcación, de tal manera que las direcciones de origen y de destino se interpreten en el contexto apropiado. Una ID de plan de marcación es una función de un cliente de empresa particular que tiene una VPN con su propio plan de marcación. La ID de plan de marcación asegura que puedan coexistir múltiples VPNs, y ser adecuadamente diferenciadas en el sistema 100. Por ejemplo, una extensión de marcación del originador "2665205" en una red privada que pertenezca a la Compañía A debe llegar al destino pretendido dentro de la compañía A, aún si sucede que la Compañía B que comparte el mismo sistema 100 también tiene una ubicación "2665205" en su plan de numeración privado. Otro ejemplo de información de contexto pudiera ser una "naturaleza de dirección" que se usa para distinguir entre, por ejemplo, los números telefónicos públicos, números de plan de marcación privados, y direcciones IP. Todavía otro ejemplo de información de contexto es un identificador de ubicación, el cual puede ser una división geográfica o lógica, y puede corresponder con prefijos de plan de marcación, por ejemplo. En general, la información de contexto puede ser cualquier información acerca del originador, el destino o la solicitud de sesión que debe buscar o determinar de otra manera el servidor de ubicación para asegurar el manejo apropiado de la solicitud. Esta información de contexto puede comprender una diversidad y pluralidad de elementos, pero se resume en la presente mediante la notación "contextinfo=" . Note que servidor de ubicación nunca debe recibir un parámetro "final=si". Después de detectar el parámetro "final=si", el NS debe abstenerse de volver a consultar el servidor de ubicación. No obstante, si se recibe esa solicitud de ruteamiento, el LS puede simplemente regresar una respuesta comparable a un mensaje "302 Movido Temporalmente" SIP con un solo contacto comprendiendo el mismo contacto solicitado que se proporciona en la solicitud de ruteamiento. Después de que se obtiene la información de contexto adicional en el paso 908, el proceso continúa con el paso 910, en donde se determina si la solicitud del originador es válida. Esta determinación se puede basar en factores tales como si se permite que el originador contacte el destino, si se puede autenticar el originador, y si el servidor de ubicación reconoce el destino. Si en el paso 910 no se puede validar la solicitud, entonces, en el paso 909, se regresa un mensaje de rechazo de algún tipo al servidor de red en el paso 909, y se concluye el procesamiento del LS en el paso 916. De otra manera, si, en el paso 910, se encuentra que la solicitud de sesión es válida, entonces el procesamiento continúa en el paso 912 para empezar la recuperación de contactos en los cuales se puede llegar a la parte de destino . Antes de describir el procesamiento del paso 912 y más allá, es importante describir el papel del paso 906 puesto que éste se relaciona con las eficiencias significativas que se ganan al pasar la información de contexto con la solicitud de ruteamiento. Regresando al paso de decisión 904, si se determina que la Solicitud-URI de la solicitud de ruteamiento tiene el parámetro "final=no", esto significa que la solicitud de ruteamiento es una solicitud subsecuente que proviene de una solicitud inicial previa. La presencia del parámetro "final=no" indica un mensaje entrante del tipo que el NS 630b envia a lo largo de la trayectoria 656 en la Figura 6. Después de reconocer este aspecto de la solicitud de ruteamiento, el servidor de ubicación omite los pasos 908 y 910, y en su lugar ejecuta el paso 906 para recuperar la información de contexto necesaria desde el mensaje mismo. Considerando que los pasos de obtener la información de contexto y validar la solicitud del originador ya se han realizado al procesar una solicitud de ruteamiento inicial, no hay necesidad de que el servidor de ubicación repita estos pasos para solicitudes subsecuentes. Por lo tanto, la información de contexto, una vez obtenida, se anexa a los mensajes entre el NS y el LS . El mensaje 700, introducido antes, muestra el parámetro de información de contexto 712 que proporciona el LS en respuesta a la solicitud de ruteamiento. El mensaje 800 muestra cómo se proporciona esta información de regreso al servidor de ubicación como el parámetro de información de contexto 804. Para solicitudes subsecuentes, esto salva al servidor de ubicación de repetir los pasos que proporcionaron primero la información de contexto. Esto también salva al servidor de ubicación de mantener cualquier información de estado entre el momento del ruteamiento inicial desde el NS 630a y una solicitud de ruteamiento subsecuente desde el NS 630b. Debido al tiempo de timbrado en cada contacto, se pudiera presentar una solicitud de ruteamiento subsecuente, si es que se presenta, muchos segundos o hasta un minuto después de una solicitud inicial correspondiente. Como se mencionó anteriormente, el hecho de que las solicitudes subsecuentes estén autocontenidas y no requieran ninguna persistencia en el servidor de ubicación también proporciona muchas ventajas en términos de equilibrio de carga y fallas repetidas . Cualquier servidor de ubicación puede manej r cualquier solicitud inicial o subsecuente de un servidor de red. De esta manera, la Figura 9?, paso 906, se relaciona con los pasos omitidos 908 y 910 y en su lugar lee los valores de información de contexto previamente derivados, directamente del encabezador del mensaje. Después se realiza el paso 912 cuando la información de contexto ya sea se ha obtenido mediante los pasos 908 y 910, o se ha recuperado en el paso 906. En el paso 912, se determina si el destino especificado en la solicitud de ruteamiento, tal como la Solicitud-URI de un mensaje INVITAR, tiene un perfil. Este perfil pudiera haber sido proporcionado a través de un OSS como se describió anteriormente. Este perfil puede contener una diversidad de información que afecte el manejo de las llamadas entrantes. Por ejemplo, un perfil pudiera contener una lista Encuéntrame, bloqueo de llamadas o información de adelantamiento de llamada, y hasta información de contacto variable de hora del día y día de la semana. El perfil también puede comprender contactos temporalmente registrados en donde el usuario de destino tiene presencia recientemente indicada. Si no se encuentra ese perfil, entonces, en el paso 914, se regresa una respuesta tal como un mensaje "302" SIP al servidor proxy que envió la solicitud de ruteamiento, indicando un solo contacto determinado para el destino. En algunos casos, si el contacto con el destino es un número telefónico convencional, se pueden tomar pasos adicionales para identificar una puerta de enlace, tal como la puerta de enlace de red 107 en la Figura 1, para lo cual se debe volver a dirigir el NS . Entonces el mensaje que se regresa al proxy contendrá la dirección de la puerta de enlace. Después de responder al NS en el paso 914, se hace el LS procesando la solicitud de ruteamiento recibida en el paso 902 y el procesamiento concluye en el paso 916. Si, en el paso 912, se encuentra un perfil para el destino, entonces se ejecuta el paso 918 para aplicar cualquier procesamiento de característica indicado por el perfil, incluyendo la invocación de una lista Encuéntrame, si es aplicable. El resultado del paso 918 frecuentemente será una lista de contactos. También es posible que el paso 918 pudiera no producir contactos, especialmente si el procesamiento de característica de conformidad con el perfil de destino especifica el bloqueo del intento de llamada del originador . El proceso 900 continúa entonces en la Figura 9B con el paso 920. Si no hay contactos que se proporcionen por la ejecución del paso 918, entonces se realiza el paso 924 para regresar al proxy un mensaje "403" SIP o similar. Después el procesamiento termina en el paso 940. De otra manera, si, en el paso 920, hay contactos generados por el procesamiento de característica y perfil, entonces, en el paso 926, se crea una respuesta de volver a dirigir, tal como un mensaje "3XX" SIP. La manera general para construir esa respuesta de la serie 300 SIP es bien conocida en SIP y se describe en el documento RFC 2543 de la IETF. La respuesta en este punto pudiera asemejarse a las secciones 702, 704, y 706 de la Figura 7. Después se realizan los pasos 928 a 936 para anexar uno o más contactos a la respuesta de volver a dirigir. El paso 928 envuelve seleccionar uno de los contactos. Después se realiza el paso 930 para determinar si el contacto es de un tipo que pudiera tener un perfil. Si es asi, entonces se ejecuta el paso 932 en donde se anexa un parámetro wfinal=no" al contacto, junto con la información de contexto que se haya descrito previamente. De otra manera, si, en el paso 930, el contacto es de un tipo que no puede tener un perfil, entonces, en el paso 933, únicamente se añade un parámetro "final=si" al texto de la información de contacto. Un ejemplo de un tipo de contacto que pudiera ser apropiado para un parámetro "final=si" es una dirección registrada en donde la parte de destino se haya registrado temporalmente como estando presente en un dispositivo terminal particular. En este caso, debido a que la parte es solamente un usuario "visitante", pudiera ser inapropiado invocar el perfil del usuario regular de la terminal, si hay alguno. Sea que se ejecute el paso 932 o el paso 933, después se ejecuta el paso 934 para añadir el contacto seleccionado a la lista de contactos de la respuesta, de volver a dirigir. Después se ejecuta el paso 936 para determinar si hay más contactos para procesar. Si es así, entonces la ejecución regresa al paso 928 para repetir los pasos 930 a 934 para todos los contactos que se determinaron en el paso 918. Después de que se han procesado asi todos los contactos, la ejecución procede al paso 938, después de lo cual se despacha la respuesta de volver a dirigir de regreso al proxy que envió la solicitud de ruteamiento en el paso 902, y después concluye el procesamiento con el paso 940. Para terminar el proceso 900, la Figura 10 describe un proceso 1000 por medio del cual un servidor proxy maneja mensajes INVITAR e interactúa con un servidor de ubicación. El proceso 1000 empieza en el paso 1002 después de la recepción de un mensaje INVITAR desde una terminal originadora, por ejemplo. Después, en el paso 1004, el proxy envía un solicitud de ruteamiento correspondiente al servidor de ubicación, y espera una respuesta. Cuando se recibe la respuesta, se ejecuta el paso 1006 para determinar si la respuesta es una respuesta de volver a dirigir, tal como una respuesta de la serie 300 SIP, indicando el regreso de direcciones de contactos desde el servidor de ubicación. Si no es asi, entonces, en el paso 1008, se ejecuta otro procesamiento para manejar los mensajes del tipo no volver a dirigir, y entonces concluye el proceso en el paso 1032. El paso 1008 resume el procesamiento de otros innumerables posibles tipos de mensajes, cuyos detalles se conocen razonablemente bien y que no son importantes para describir la presente invención. Si, en el paso 1006, se determina que la respuesta desde el LS es una respuesta de volver a dirigir, que tiene direcciones de contactos, el procesamiento se mueve al paso 1010 para seleccionar uno de los contactos que regresaron en el mensaje. Después, en el paso 1012, se examina el contacto seleccionado para determinar si aparece un parámetro "final=no" con la dirección de contacto. Si es asi, entonces se ejecuta el paso 1016, en donde se envia un mensaje INVITAR al servidor proxy mismo. Este mensaje usará la linea de contacto en la respuesta de volver a dirigir como el contacto solicitado (tal como la Solicitud-URI de un mensaje INVITAR) , incluyendo la bandera de finalidad y cualquier información de contexto. Anteriormente se han descrito completamente las razones y efectos de hacer esto. De otra manera, si no se encuentra ninguna bandera "final=no" en el paso 1012, entonces el proxy sencillamente envia un mensaje INVITAR de la manera usual al contacto, y espera una respuesta en el paso 1020. El paso 1020 de esperar- y manejar respuestas desde el contacto puede envolver manejar tanto respuestas provisionales como respuestas finales. Por ejemplo, el contacto puede enviar de regreso un mensaje provisional "180 Timbrando" SIP que se podria pasar a lo largo de regreso al servidor de red y terminal originadora . El contacto puede más bien, o subsecuentemente, enviar una respuesta final que indique ya sea el éxito o la falla del contacto para llegar a la parte pretendida. Se pretende que el paso 1020 abarque todas las variedades de respuestas que se pudieran recibir. El paso 1020 envuelve el manejo apropiado de una diversidad de posibles respuestas, de una manera que es familiar para, o que pueden prever rápidamente aquellos de experiencia ordinaria en técnicas de inicio de sesión. En el paso 1022, se determina si se ha establecido exitosamente una sesión, usando el contacto que se seleccionó en el paso 1010. Si es asi, entonces no se necesitan probar contactos adicionales, por lo tanto el procesamiento termina en el paso 1026. De otra manera, si el contacto que se prueba no da como resultado el establecimiento de la sesión, entonces se ejecuta el paso 1024 para determinar si existen más contactos para probar. Si es asi, entonces el procesamiento regresa al paso 1010 para seleccionar el siguiente contacto disponible. De otra manera, si no están disponibles más contactos, entonces, en el paso 1026, se concluye el procesamiento del mensaje INVITAR que se recibió en el paso 1002. Para resumir la interacción neta del servidor de red y el servidor de ubicación, la Figura 11 es un diagrama de flujo de un proceso global 1100 para realizar la consulta recursiva para establecer una sesión de conformidad con una modalidad de la presente invención. El proceso de la Figura 11 también generaliza las presentes enseñanzas en el sentido de que un servidor de ubicación puede proporcionar subconjuntos de contactos sobre una base según se necesite, en lugar de proporcionar todos los contactos de una sola vez. Los subconjuntos de contactos se pueden derivar de la recursión de los contactos anidados, como se muestra mediante el ejemplo en la presente, o mediante iteración a través de alguna otra división arbitraria del superconjunto de contactos . Aquellos de experiencia ordinaria también notarán que la información de contexto que se pasa entre los proxies y los servidores de ubicación también puede ayudar al servidor de ubicación al seleccionar los lotes subsecuentes de contactos a recuperar. Por ejemplo, la información de contexto puede incluir un número de secuencia o un contacto final intentado" para servir como un índice para el servidor de ubicación para buscar y traer el siguiente grupo de contactos para el proxy. El proceso 1100 empieza en el paso 1102 cuando un usuario accesa una terminal e inicia una solicitud de sesión para llegar a otra parte. Moviéndose al paso 1104, la terminal originadora envía una solicitud de sesión, tal como un mensaje INVITAR SIP, a un servidor de red o proxy. En el paso 1106, el proxy envía una solicitud de ruteamiento correspondiente a un servidor de ubicación. En el paso 1108, el servidor de ubicación examina la solicitud y, con base en los perfiles, las características y otros factores del usuario, recopila una lista de direcciones de contactos por medio de la cual se podría llegar a la parte de destino. De conformidad con una modalidad preferida de la presente invención, el servidor de ubicación puede proporcionar un subconjunto de contactos, junto con suficiente información de contexto para permitir una consulta repetida subsecuente del servidor de ubicación para recuperar contactos adicionales, si y cuando se necesiten éstos. En el paso 1110, el servidor de ubicación regresa el conjunto de contactos al proxy, junto con la información de contexto mencionada anteriormente. En el paso 1112, el proxy intenta llegar a la parte de destino usando la lista de contactos que se proporcionó en el paso 1110. En el paso 1114, se determina si alguno de los contactos llegó exitosamente a la parte de destino, como se hace evidente por el regreso de un mensaje "200 Está Bien" SIP. Si es asi, entonces el procesamiento continúa en el paso 1118, en donde se establece una sesión de medios entre la terminal originadora y la dirección de contacto exitosa, y se concluye el proceso 1100 en el paso 1120. Regresando al paso 1114, si se determina de otra manera que ninguno de los contactos que se proporcionaron hasta ese momento son exitosos para llegar a la parte pretendida, entonces, en el paso 1116 el proxy consulta nuevamente el servidor de ubicación para obtener un conjunto adicional de direcciones de contactos. En el paso 1117, si se determina, probablemente mediante el servidor de ubicación, que se han agotado todos los contactos, entonces en el paso 1122 se declara que no se puede establecer la sesión en ese momento. Esta condición se puede manejar, por ejemplo, mediante la indicación a la parte originadora, de que no se puede llegar al destino. Después de cualquier acción que sea apropiada en el paso 1122, el proceso 1100 termina entonces en el paso 1120. Regresando al paso 1117, si existen más contactos conocidos para el servidor de ubicación, que no se hayan dado al servidor proxy, entonces, en el paso 1118, el servidor de ubicación determina un conjunto adicional de direcciones de contacto para que se prueben. Al hacer eso, el servidor de ubicación puede usar la información de contexto que proporcionó con la solicitud, para tal vez evitar esfuerzos redundantes, o para ayudar a determinar cuál conjunto de direcciones se debe regresar después. Entonces el procesamiento regresa a 1110, en donde el servidor de ubicación responde con la lista adicional de contactos. El procesamiento de los pasos 1110 a 1118 continúa hasta que ya sea se llegue a la parte de destino, o se hayan probado todos los contactos sin éxito. La Figura 12 ilustra un sistema de computadora 1200 adentro del cual se puede implementar una modalidad de conformidad con la presente invención. El sistema de computadora 1200 incluye una barra colectora 1201 u otro mecanismo de comunicación para comunicar información, y un procesador 1203 acoplado a la barra colectora 1201 para el procesamiento de la información. El sistema de computadora 1200 además incluye la memoria principal 1205, tal como una memoria de acceso directo (RAM, por sus siglas en inglés) u otro dispositivo de almacenamiento dinámico, acoplado a la barra colectora 1201 para almacenar información e instrucciones que se vayan a ejecutar mediante el procesador 1203. La memoria principal 1205 también se puede usar para almacenar variables temporales u otra información intermedia durante la ejecución de instrucciones que va a ejecutar el procesador 1203. El sistema de computadora 1200 incluye además una memoria de sólo lectura (ROM, por sus siglas en inglés) 1207 u otro dispositivo de almacenamiento estático acoplado a la barra colectora 1201, para almacenar información estática e instrucciones para el procesador 1203. ün dispositivo de almacenamiento 1209, tal como un disco magnético o disco óptico, está adicionalmente acoplado a la barra colectora 1201 para el almacenamiento de información e instrucciones . El sistema de computadora 1200 se puede acoplar por medio de la barra colectora 1201 a un despliegue visual 1211, tal como un tubo de rayos catódicos (CRT, por sus siglas en inglés), despliegue visual de cristal liquido, despliegue visual de matriz activa, o despliegue visual de plasma, para desplegar visualmente la información a un usuario de la computadora. Un dispositivo de entrada 1213, tal como un teclado que incluye teclas alfanuméricas u otras teclas, está acoplado a la barra colectora 1201 para la comunicación de información y selecciones de comandos al procesador 1203. Otro tipo de dispositivo de entrada de usuario es el control de cursor 1215, tal como un ratón, una bola de seguimiento, o teclas de dirección del cursor, para la comunicación de información de dirección y selecciones de comandos al procesador 1203, y para controlar el movimiento del cursor en el despliegue visual 1211. De conformidad con una modalidad de la invención, las funcionalidades del servidor SIP (particularmente la capacidad de consulta recursiva como se describió en la Figura 9) se proporcionan por medio del sistema de computadora 1200, en respuesta al procesador 1203 que ejecuta una configuración de instrucciones contenidas en la memoria principal 1205. Esas instrucciones se pueden leer dentro de la memoria principal 1205 desde otro medio legible por computadora, tal como el dispositivo de almacenamiento 1209. La ejecución de la configuración de instrucciones contenidas en la memoria principal 1205 provoca que el procesador 1203 realice los pasos del proceso que se describen en la presente. También se pueden emplear uno o más procesadores en una configuración de múltiples procesamientos, para ejecutar las instrucciones contenidas en la memoria principal 1205. En modalidades alternativas, se puede usar un sistema de circuitos alambrado de forma permanente, en lugar de, o en combinación con las instrucciones de software, para implementar la modalidad de la presente invención. De esta manera, las modalidades de la presente invención no están limitadas a ninguna combinación especifica de sistema de circuito de hardware y software. El sistema de computadora 1200 también incluye una interfase de comunicaciones 1217 acoplada a la barra colectora 1201. La interfase de comunicaciones 1217 proporciona un acoplamiento de comunicación de datos en dos direcciones a un enlace de red 1219 conectado a una red local 1221. Por ejemplo, la interfase de comunicaciones 1217 puede ser una tarjeta o módem de linea suscriptora digital (DSL, por sus siglas en inglés), una tarjeta de red digital de servicios integrados (ISDN, por sus siglas en inglés) un módem por cable, o un módem de teléfono para proporcionar una conexión de comunicación de datos a un tipo correspondiente de linea telefónica. Como otro ejemplo, la interfase de comunicaciones 1217 puede ser una tarjeta de red de área local (LAN, por sus siglas en inglés) (por ejemplo, Ethernet™ o una red de Modelo de Transferencia Asincrónica (ATM, por sus siglas en inglés)) para proporcionar una conexión de comunicación de datos a una LAN compatible. También se pueden implementar enlaces inalámbricos . En cualquiera de tales implementaciones, la interfase de comunicaciones 1217 envía y recibe señales eléctricas, electromagnéticas, u ópticas que llevan flujos de datos digitales que representan diferentes tipos de información. Además, la interfase de comunicaciones 1217 puede incluir dispositivos de interfase periféricos, tales como una interfase de Barra Colectora en Serie Universal (USB, por sus siglas en inglés) , una interfase PCMCIA (siglas en inglés para Asociación Internacional de Tarjetas de Memoria para Computadoras Personales), etcétera. Aunque se muestra solamente una sola interfase de comunicaciones 1217, se reconoce que se pueden emplear múltiples interfases de comunicaciones para comunicarse con diferentes redes y dispositivos. El enlace de red 1219 típicamente proporciona comunicación de datos a través de una o más redes a otros dispositivos de datos. Por ejemplo, el enlace de red 1219 puede proporcionar una conexión a través de la red local 1221 a una computadora huésped 1223, la cual tiene conectividad a una red 1225 (por ejemplo, una red de área amplia (WAN, por sus siglas en inglés) o la red de comunicación de datos de paquetes global, a la que ahora se hace referencia comúnmente como la "Internet") o a equipo de datos operado por el proveedor de servicios. La red local 1221 y la red 1225 usan señales eléctricas, electromagnéticas, u ópticas para transportar información e instrucciones. Las señales a través de diferentes redes y las señales en el enlace de red 1219 y a través de la interf se de comunicaciones 1217, que comunican datos digitales con el sistema de computadora 1200, son formas ejemplares de ondas portadoras que llevan la información y las instrucciones. El sistema de computadora 1200 puede enviar mensajes y recibir datos, incluyendo el código del programa, a través de las redes, el enlace de red 1219, y la interfase de comunicaciones 1217. En el ejemplo de la Internet, un servidor (no se muestra) puede transmitir el código solicitado que pertenece a un programa de aplicación para implementar una modalidad de la presente invención a través de la red 1225, la red local 1221 y la interfase de comunicaciones 1217. El procesador 1204 puede ejecutar el código transmitido, mientras se esté recibiendo y/o almacenando el código en el dispositivo de almacenamiento 129, u otro almacenamiento volátil para ejecución posterior. De esta manera, el sistema de computadora 1200 puede obtener el código de aplicación en la forma de una onda portadora. El término "medio legible por computadora", como se usa en la presente, se refiere a cualquier medio que participe en proporcionar instrucciones al procesador 1204 para ejecución. Ese medio puede tomar muchas formas, incluyendo, pero no limitándose a medios no volátiles, medios volátiles, y medios de transmisión. Los medios no volátiles incluyen, por ejemplo, discos ópticos o magnéticos, tales como el dispositivo de almacenamiento 1209. Los medios volátiles incluyen memoria dinámica, tal como la memoria principal 1205. Los medios de transmisión incluyen cables coaxiales, alambre de cobre y fibra óptica, incluyendo los alambres que comprenden la barra colectora 1201. Los medios de transmisión también pueden tomar la forma de ondas acústicas, ópticas o electromagnéticas, tales como aquellas que se generan durante las comunicaciones de datos por radiofrecuencia (RF) y rayos infrarrojos (IR). Las formas comunes de medios legibles por computadora incluyen, por ejemplo, un disco floppy, un disco flexible, disco duro, cinta magnética, cualquier otro medio magnético, un CD-ROM, CDRW, DVD, cualquier otro medio óptico, tarjetas perforadas, cinta de papel, hojas de marcas ópticas, cualquier otro medio físico con patrones de orificios u otros indicios ópticamente reconocibles, una RAM, una PROM, una EPROM, una FLASH-EPROM, cualquier otro chip o cartucho de memoria, una onda portadora, o cualquier otro medio desde el cual pueda leer una computadora. Al proporcionar instrucciones a un procesador para ejecución pueden estar envueltas diferentes formas de medios legibles por computadora. Por ejemplo, las instrucciones para realizar cuando menos parte de la presente invención pudieran originarse inicialmente en un disco magnético de una computadora remota. En tal escenario, la computadora remota carga las instrucciones dentro de la memoria principal y envía las instrucciones a través de una línea telefónica usando un módem. Un módem de un sistema de computadora local recibe los datos en la línea telefónica, y usa un transmisor infrarrojo para convertir los datos a una señal infrarroja, y transmitir la señal infrarroja a un dispositivo de computación portátil, tal como un asistente digital personal (PDA, por sus siglas en inglés) y una laptop. Un detector infrarrojo en el dispositivo de computación portátil recibe la información y las instrucciones originadas por la señal infrarroja, y coloca los datos en una barra colectora. La barra colectora transporta los datos a la memoria principal, desde la cual un procesador recupera y ejecuta las instrucciones. Las instrucciones que recibe la memoria principal se pueden almacenar opcionalmente en el dispositivo de almacenamiento ya sea antes o después de la ejecución por parte del procesador. Aunque se ha descrito la presente invención en conexión con un número de modalidades e implementaciones , la presente invención no está limitada de esta manera, sino que cubre diferentes modificaciones y configuraciones equivalentes obvias, que caen dentro de la competencia de las reivindicaciones anexas.

REFERENCIAS [1] Handley, y colaboradores, "SIP: Session Initiation Protocol", IETF RFC 2543, 1999. [2] Handley, y colaboradores, VRFC 2543bis", IETF Internet_Draft, Trabajo en Progreso. [3] Sparks, R.f "SIP Cali Control: REFER". IETF Internet-Draft, Trabajo en Progreso. [4] Johnston, y colaboradores, "SIP Telephony Cali Flow Examples", IETF Internet-Draft, Trabajo en Progreso. [5] Johnston, y colaboradores, "SIP Services Examples", IETF Internet 127-Draft, Trabajo en Progreso.

Claims

REIVINDICACIONES

1. Un método para establecer una sesión de comunicación con cuando menos una parte acoplada a un sistema de comunicaciones, que comprende los pasos de: desde un servidor de ubicación, obtener cuando menos un primer conjunto de información relacionada con la comunicación con la parte; intentar establecer la sesión a través del sistema de comunicaciones usando el primer conjunto de información; y dependiendo de si se establece la sesión usando el primer conjunto de información, obtener desde el servidor de ubicación cuando menos un segundo conjunto de información relacionada con la comunicación con la parte, e intentar establecer la sesión usando el segundo conjunto de información .

2. El método de la reivindicación 1, en donde el primer conjunto de información comprende cuando menos una dirección del sistema de comunicaciones, asociada con la parte.

3. El método de la reivindicación 1, que además comprende proporcionar, al servidor de ubicación, información de contexto relacionada con el procesamiento que ocurre en el servidor de ubicación.

4. El método de la reivindicación 3, en donde la información de contexto comprende cuando menos uno de : un indicador de naturaleza de la dirección, un identificador de plan de marcación, y un identificador de ubicación.

5. El método de la reivindicación 1, que además comprende obtener, desde el servidor de ubicación, información de contexto relacionada con el procesamiento que ocurre en el servidor de ubicación.

6. El método de la reivindicación 5, en donde la información de contexto comprende cuando menos uno de: un indicador de naturaleza de la dirección, un identificador de plan de marcación, y un identificador de ubicación.

7. El método de la reivindicación 1, en donde la información de contexto se obtiene desde el servidor de ubicación en conjunción con la obtención del primer conjunto de información, y la información de contexto se proporciona al servidor de ubicación en conjunción con la obtención del segundo conjunto de información.

8. El método de la reivindicación 7, en donde el servidor de ubicación usa la información de contexto en el curso de proporcionar el segundo conjunto de información.

9. El método de la reivindicación 7, en donde la información de contexto comprende cuando menos uno de: un indicador de naturaleza de la dirección, un identificador de plan de marcación, y un identificador de ubicación.

10. En un sistema de comunicaciones que comprende un servidor de ubicación, un método para establecer una sesión de comunicación con cuando menos una parte acoplada al sistema de comunicaciones, que comprende los pasos de: presentar una primera solicitud al servidor de ubicación por información de contacto asociada con la parte; obtener una primera respuesta del servidor de ubicación que responde a la primera solicitud, la primera respuesta comprendiendo cuando menos un primer conjunto de uno o más contactos asociados con la parte; intentar establecer la sesión con la parte usando el primer conjunto de contactos; en respuesta a si el primer conjunto de contactos da como resultado el establecimiento de la sesión, realizar condicionalmente los pasos de: presentar cuando menos una segunda solicitud al servidor de ubicación; obtener una segunda respuesta desde el servidor de ubicación en respuesta a la segunda solicitud, la segunda respuesta comprendiendo cuando menos un segundo conjunto de uno o más contactos para la parte; e intentar establecer la sesión con la parte usando el segundo conjunto de contactos.

11. El método de la reivindicación 7, en donde la segunda solicitud se relaciona con cuando menos un contacto proporcionado en la primera respuesta.

12. El método de la reivindicación 7, en donde la segunda solicitud se inicia en respuesta a cuando menos un contacto en el primer conjunto de contactos en la primera respuesta .

13. El método de la reivindicación 7, en donde la segunda solicitud se presenta condicionalmente después del contenido de la primera respuesta.

14. El método de la reivindicación 13, en donde la primera respuesta comprende información relacionada con si se debe presentar la segunda solicitud.

15. El método de la reivindicación 14, en donde cuando menos un contacto en la primera respuesta comprende información relacionada con si se debe presentar la segunda solicitud .

16. El método de la reivindicación 10, que además comprende proporcionar, al servidor de ubicación, información de contexto relacionada con el procesamiento que ocurre en el servidor de ubicación.

17. El método de la reivindicación 16, en donde la información de contexto comprende cuando menos uno de : un indicador de naturaleza de la dirección, uri identificador de plan de marcación, y un identificador de ubicación.

18. El método de la reivindicación 16, en donde el servidor de ubicación usa la información de contexto que se proporcionó en conjunción con la segunda solicitud, en el curso de preparar la segunda respuesta.

19. El método de la reivindicación 10, que además comprende obtener desde el servidor de ubicación, información de contexto relacionada con el procesamiento que ocurre en el servidor de ubicación.

20. El método de la reivindicación 19, en donde la información de contexto comprende cuando menos uno de : un indicador de naturaleza de la dirección, un identificador de plan de marcación, y un identificador de ubicación.

21. El método de la reivindicación 19, en donde el servidor de ubicación usa la información de contexto que se proporcionó en conjunción con la segunda solicitud, en el curso de preparar la segunda respuesta.

22. El método de la reivindicación 10, en donde la información de contexto se obtiene desde el servidor de ubicación en conjunción con la primera respuesta, y la información de contexto se proporciona al servidor de ubicación en conjunción con la segunda solicitud.

23. El método de la reivindicación 22, en donde la información de contexto comprende cuando menos uno de : un indicador de naturaleza de la dirección, un identificador de plan de marcación, y un identificador de ubicación.

24. El método de la reivindicación 22, en donde el servidor de ubicación usa la información de contexto que se proporcionó en conjunción con la segunda solicitud, en el curso de preparar la segunda respuesta.

25. Un servidor para proporcionar información de contacto acerca de cuando menos una parte en un sistema de comunicaciones, que comprende: un elemento para recibir una primera solicitud por información de contactos para la parte; un elemento para determinar un primer conjunto de contactos que comprende cero o más contactos para la parte; un elemento para dar salida a una primera respuesta, que responde a la primera solicitud, que comprende el primer conjunto de contactos; un elemento para recibir una segunda solicitud, subsecuente a la primera solicitud, por información de contactos para la parte; un elemento para determinar un segundo conjunto de contactos que comprende cero o más contactos para la parte; un elemento para dar salida a una segunda respuesta a la segunda solicitud, que comprende el segundo conjunto de contactos; y en donde el segundo conjunto de contactos difiere del primer conjunto de contactos.

26. El servidor de la reivindicación 25, en donde cuando menos uno del primer conjunto de contactos y el segundo conjunto de contactos es un subconjunto de todos los contactos para la parte, que mantiene el servidor de ubicación.

27. El servidor de la reivindicación 25, en donde la segunda solicitud se relaciona con cuando menos un contacto proporcionado en la primera respuesta.

28. El servidor de la reivindicación 25, en donde la segunda solicitud se inicia en respuesta a cuando menos un contacto en el conjunto de contactos en la primera respuesta.

29. El servidor de la reivindicación 25, en donde la segunda solicitud se presenta condicionalmente según el contenido de la primera respuesta.

30. El servidor de la reivindicación 29, en donde la primera respuesta comprende información relacionada con si se debe presentar la segunda solicitud.

31. El servidor de la reivindicación 25, que además comprende un elemento para proporcionar, en conjunción con la primera respuesta, cuando menos un indicador en cuanto a si se debe presentar la segunda solicitud.

32. El servidor de la reivindicación 25, en donde cuando menos un contacto en la primera respuesta comprende información relacionada con si se debe presentar la segunda respuesta.

33. El servidor de la reivindicación 25, que además comprende un elemento para determinar información de contexto que tiene que ver con la primera solicitud.

34. El servidor de la reivindicación 33, en donde la segunda solicitud comprende información de contexto.

35. El servidor de la reivindicación 34, en donde el servidor de ubicación usa la información de contexto que se proporcionó en la segunda solicitud, en el curso de preparar la segunda respuesta.

36. El servidor de la reivindicación 33, en donde la información de contexto comprende cuando menos uno de : un indicador de naturaleza de la dirección, un identificador de plan de marcación, y un identificador de ubicación.

37. El servidor de la reivindicación 36, en donde la primera respuesta comprende la información de contexto.

38. El servidor de la reivindicación 36, en donde el servidor de ubicación usa la información de contexto que se proporcionó en la segunda solicitud, en el curso de preparar la segunda respuesta.

39. El servidor de la reivindicación 36, en donde la información de contexto comprende cuando menos uno de: un indicador de naturaleza de la dirección, un identificador de plan de marcación, y un identificador de ubicación.

40. El servidor de la reivindicación 36, en donde la segunda solicitud comprende la información de contexto.

41. El servidor de la reivindicación 40, en donde el servidor de ubicación usa la información de contexto que se proporcionó en la segunda solicitud, en el curso de preparar la segunda respuesta.

42. El servidor de la reivindicación 40, en donde la información de contexto comprende cuando menos uno de: un indicador de naturaleza de la dirección, un identificador de plan de marcación, y un identificador de ubicación.

43. ün servidor proxy para procesar cuando menos una solicitud para establecer una sesión con una parte en un sistema de comunicaciones, que comprende: un elemento para presentar a un servidor de ubicación una primera solicitud por información de contactos para la parte; un elemento para recibir desde el servidor de ubicación, una primera respuesta a la primera solicitud, la primera respuesta comprendiendo un primer conjunto de contactos; un elemento para determinar por la primera respuesta, si se puede realizar una segunda solicitud para obtener más información de contactos; y un elemento para iniciar la segunda solicitud con base en la primera respuesta.

44. El servidor proxy de la reivindicación 43, que además comprende un elemento para presentar al servidor de ubicación la segunda solicitud.

45. El servidor proxy de la reivindicación 43, en donde cuando menos un contacto en la primera respuesta comprende información que indica la necesidad de realizar la segunda solicitud .

46. El servidor proxy de la reivindicación 43, que además comprende un elemento para intentar establecer la sesión usando cuando menos uno del primer conjunto de contactos y el segundo conjunto de contactos del servidor de ubicación .

47. El servidor proxy de la reivindicación 43, en donde, dependiendo del contenido de la primera respuesta, el servidor proxy despacha la segunda solicitud a si mismo.

48. El servidor proxy de la reivindicación 43, en donde el servidor de ubicación asocia un indicador de finalidad con cuando menos un contacto, y la segunda solicitud se presenta condicionalmente en respuesta a un estado del indicador de finalidad .

49. El servidor proxy de la reivindicación 43, que además comprende: un elemento para recibir cuando menos una información de contexto desde el servidor de ubicación, en conjunción con la primera respuesta; y un elemento para proporcionar la información de contexto en conjunción con la segunda solicitud.

50. El servidor proxy de la reivindicación 49, en donde la información de contexto comprende cuando menos uno de: un indicador de naturaleza de la dirección, un identificador de plan de marcación, y un identificador de ubicación.

51. Un medio legible por computadora que tiene instrucciones ejecutables por computadora, para realizar un método para proporcionar información de contactos para una parte, el método comprendiendo los pasos de: recibir una primera solicitud por información de contacto para la parte; determinar un primer conjunto de contactos que comprende cero o más contactos para la parte; dar salida a una primera respuesta para la primera solicitud, que comprende el primer conjunto de contactos; recibir cuando menos una segunda solicitud, subsecuente a la primera solicitud, por información de contactos para la parte; determinar un segundo conjunto de contactos que comprende cero o más contactos para la parte; y dar salida a la segunda respuesta a la segunda solicitud, que comprende el segundo conjunto de contactos; en donde el segundo conjunto de contactos difiere del primer conjunto de contactos.

52. El medio legible por computadora de la reivindicación 51, en donde el método comprende además los pasos de: determinar información de contexto relacionada con la primera solicitud; dar salida a la información de contexto en conjunción con la salida de la primera respuesta; recibir la información de contexto en conjunción con la recepción de la segunda solicitud; y aplicar la información de contexto para determinar el segundo conjunto de contactos.

53. Un medio legible por computadora que tiene instrucciones ejecutables por computadora para realizar un método para obtener información de contactos para una parte, el método comprendiendo los pasos de: presentar a un servidor de ubicación una primera solicitud por información de contactos para la parte; recibir desde el servidor de ubicación una primera respuesta a la primera solicitud, la primera respuesta comprendiendo un primer conjunto de contactos; determinar por la primera respuesta si se debe realizar cuando menos una segunda solicitud para obtener más información de contactos; e iniciar la segunda solicitud con base en la primera respuesta .

54. El medio legible por computadora de la reivindicación 53, en donde el método comprende además los pasos de: recibir información de contexto desde el servidor de ubicación en conjunción con la primera respuesta; y proporcionar la información de contexto al servidor de ubicación en conjunción con la segunda solicitud.