ES2337836T3 - Encaminamiento de llamadas ims utilizando identificadores de recursos uniformes de telefonos (tel-uris). - Google Patents

Encaminamiento de llamadas ims utilizando identificadores de recursos uniformes de telefonos (tel-uris). Download PDF

Info

Publication number
ES2337836T3
ES2337836T3 ES06809094T ES06809094T ES2337836T3 ES 2337836 T3 ES2337836 T3 ES 2337836T3 ES 06809094 T ES06809094 T ES 06809094T ES 06809094 T ES06809094 T ES 06809094T ES 2337836 T3 ES2337836 T3 ES 2337836T3
Authority
ES
Spain
Prior art keywords
uri
sip
tel
phone
quad
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
ES06809094T
Other languages
English (en)
Inventor
Jesus-Javier Arauz-Rosado
Fredrik Alriksson
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Telefonaktiebolaget LM Ericsson AB
Original Assignee
Telefonaktiebolaget LM Ericsson AB
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Telefonaktiebolaget LM Ericsson AB filed Critical Telefonaktiebolaget LM Ericsson AB
Application granted granted Critical
Publication of ES2337836T3 publication Critical patent/ES2337836T3/es
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L61/00—Network arrangements, protocols or services for addressing or naming
    • H04L61/09—Mapping addresses
    • H04L61/25—Mapping addresses of the same type
    • H04L61/2596—Translation of addresses of the same type other than IP, e.g. translation from MAC to MAC addresses
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00—Routing or path finding of packets in data switching networks
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L61/00—Network arrangements, protocols or services for addressing or naming
    • H04L61/45—Network directories; Name-to-address mapping
    • H04L61/4557—Directories for hybrid networks, e.g. including telephone numbers
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2101/00—Indexing scheme associated with group H04L61/00
    • H04L2101/60—Types of network addresses
    • H04L2101/618—Details of network addresses
    • H04L2101/65—Telephone numbers
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/10—Architectures or entities
    • H04L65/1016—IP multimedia subsystem [IMS]

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Power Engineering (AREA)
  • Telephonic Communication Services (AREA)
  • Nitrogen Condensed Heterocyclic Rings (AREA)
  • Mobile Radio Communication Systems (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

Un módulo de conversión (308), que comprende: un procesador; y una memoria con instrucciones almacenadas allí dentro que son accesibles y procesables por dicho procesador para facilitar los siguientes pasos: recibir una petición URI; y determinar si la petición URI tiene un SIP URI con un número global reconocible; si es no, poner a la salida un mensaje de error; y si es sí, generar un número de teléfono "tel URI" usando el SIP URI y entonces poner a la salida el número de teléfono "tel URI".

Description

Encaminamiento de llamadas IMS utilizando identificadores de recursos uniformes de teléfonos (tel-URIs).
Campo técnico
La presente invención se refiere en general a una red de terminación IMS que permite el encaminamiento de llamadas a usuarios objetivo usando números de teléfono tel URIs (y no SIP URIs con números de teléfono integrados) como identificadores de los usuarios objetivo particulares.
Antecedentes
Las siguientes abreviaturas se definen adjuntas, al menos a alguna de las cuales se hace referencia en la descripción posterior de la técnica previa y la presente invención.
3GPP
Proyecto de Cooperación de Tercera Generación
AS
Servidor de Aplicaciones
CSCF
Función de Control de Sesión de Llamada
DNS
Sistema de Nombres de Dominio
HSS
Servidor de Abonado Local
IAM
Mensaje de Dirección Inicial
IBCF
Función de Control de Frontera de Interfuncionamiento
I-CSCF
CSCF de Interrogación
IMS
Subsistema Multimedia IP
IP
Protocolo de Internet
MGCF
Función de Control de Pasarela de Medios
MMS
Servicio de Mensajería Multimedia
POTS
Servicio Telefónico Convencional
PSTN
Red Pública Telefónica Conmutada
PUI
Identidad Pública de Usuario
RFC
Petición de Comentarios
RTP
Protocolo de Transporte en Tiempo Real
S-CSCF
CSCF de Servicio
SIP
Protocolo de Inicio de Sesión
SLF
Función de Localización de Suscripciones
TCP
Protocolo de Control de Transmisión
UA
Agente de Usuario
UE
Equipo de Usuario
URI
Identificador de Recursos Uniformes
UTM
Módulo de Traducción URI
Una red IMS es una red basada en IP que permite a los Agentes de Usuario (UAs) de una red IMS, así como a los Equipos de Usuario (UEs) de otras redes legadas, establecer sesiones multimedia a otros UAs de manera que pueden intercambiar cualquier tipo de información en tiempo real (por ejemplo voz, vídeo) o información no en tiempo real (por ejemplo mensajes, fotos). En su estado actual, la red IMS usa un protocolo SIP para establecer las sesiones multimedia y un protocolo de transporte como por ejemplo RTP para llevar la carga útil de las sesiones multimedia.
En la red IMS, la información se encamina en una sesión multimedia que se estableció con el usuario objetivo usando un URI que identifica ese usuario y usando un conjunto de reglas de encaminamiento bien definidas que deben ser seguidas por todos los elementos dentro de la red IMS. Este conjunto de reglas se define para las redes IMS conformes a 3GPP en 3GPP TS 24.229 V.5.14.0 (Octubre 2005) que se titula "Protocolo de Control de Llamadas Multimedia IP basado en el Protocolo de Inicio de Sesión (SIP) y Protocolo de Descripción de Sesión (SDP)" (los contenidos de los cuales se incorporan por referencia aquí dentro).
\vskip1.000000\baselineskip
Hay dos tipos de URIs que se pueden usar para identificar un usuario objetivo particular cuando se establece una sesión multimedia: (1) SIP URIs; y (2) tel URIs. Un SIP URI tiene un formato que se define en la RFC3261 la cual se titula "SIP: Protocolo de Inicio de Sesión" Junio de 2002 (los contenidos del cual se incorporan por referencia aquí dentro). Ejemplos de SIP URIs son:
sip:peter@yahoo.com
sip:James.Rowling@RowlingAndAssociates.co.uk
sip:voice_mail@vodafone.com;reason=no_answer
\vskip1.000000\baselineskip
Mientras, el formato de un tel URI se define en la RFC3966 que se titula "El tel URI para Números de Teléfono" (los contenidos de la cual se incorporan por referencia aquí dentro). Ejemplos de tel URIs son:
tel:+1-234-567-89
te1:2997;phone-context=+3491339
\vskip1.000000\baselineskip
Además, hay una forma de expresar un SIP URI con un tel URI integrado lo cual se trata en la RFC3261. Por ejemplo, los tel URIs ejemplares se podrían integrar dentro de los SIP URIs como sigue:
sip:+1-234-567-89@cingular.com;user=phone
sip:2997;phone-context=+3491339@vodafone.com;user=phone
\vskip1.000000\baselineskip
Una parte del conjunto de reglas de encaminamiento mencionadas arriba está dedicada a encaminar las llamadas entre dos operadores de red distintos. Específicamente, cuando se encamina una llamada entre dos operadores de red se debe usar un SIP URI o SIP URI/tel URI integrado para identificar el usuario objetivo para la llamada. La Figura 1 (Técnica previa) es un diagrama de flujo de señal usado para ayudar a describir un primer proceso de encaminamiento, a saber el proceso interoperador de uso de un SIP URI SIP/tel URI integrado para encaminar una llamada desde un UA_{1} situado en una red de origen 102 a un UA_{2} situado en una red de terminación/destino 104. Los pasos son como siguen (se hace referencia al 3GPP TS 24.229 para más detalles):
1-3.
La S-CSCF_{1} de origen recibe una petición SIP (por ejemplo un INIVITE tel: +123) desde el UA_{1} (paso 1). La S-CSCF_{1} toma una Petición URI a partir de la petición INVITE de inicio de sesión recibida y si la Petición URI contiene un tel URI entonces la S-CSCF_{1} consulta un servicio ENUM_{1} (paso 2). El ENUM_{1} cambia el tel URI dentro de un SIP URI/tel URI integrado (por ejemplo, sip: +123@op.com;user=phone) y lo envía a la S-CSCF_{1} (paso 3). La S-CSCF_{1} sustituye la Petición URI original en la petición SIP con el SIP URI/tel URI integrado obtenido a partir de la consulta para formar una nueva petición SIP (por ejemplo, INVITE sip: +123@op.com;user=phone).
4.
La S-CSCF_{1} de origen toma la parte del dominio (por ejemplo, op. com) de la nueva Petición URI y envía la nueva petición INVITE SIP a la dirección identificada por ese dominio (si el dominio es una dirección IPv4 o IPv6 el INVITE se puede enviar a esa dirección de inmediato, de otra manera necesita ser consultada una DNS usando la parte del dominio para obtener una dirección IP de destino, que corresponde o bien a una IBCF o a una I-CSCF_{2} en la red de terminación 104). En este ejemplo, la S-CSCF_{1} envía la nueva petición SIP (por ejemplo, INVITE sip: +123@op.com;user=phone) directamente a la I-CSCF_{2} (paso 4).
5-6.
La I-CSCF_{2} es la primera CSCF contactada para la llamada de terminación y tiene el papel de localizar la S-CSCF_{2} que está sirviendo al UA_{2} al cual va dirigida la llamada. Para localizar la S-CSCF_{2} que sirve al UA_{2}, la I-CSCF_{2} puede necesitar usar dos bases de datos de red: (1) la SLF_{2;} y (2) el HSS_{2.} La SLF_{2} es una función de localización de bases de datos que encuentra el ejemplo del HSS_{2} específico que mantiene los datos de abonado del UA_{2} (incluyendo la S-CSCF_{2} que está actualmente sirviéndolos), y se usa cuando hay múltiples ejemplos de HSSs en la red de terminación 104. En este ejemplo, la I-CSCF_{2} usa la Petición URI en la petición SIP como un identificador público de usuario para enviar una consulta (por ejemplo, Dx-Location-Query PUI= sip: +123@op.com;user=phone) a la SLF_{2} (paso 5). Entonces, la SLF_{2} envía una respuesta (por ejemplo, Dx-Location-Query_Rsp Server-Name=HSS_{2}) que indica al HSS_{2} que vuelva a la I-CSCF_{2} (paso 6). En el caso que haya un único HSS en la red, entonces se pueden omitir la SLF_{2} y los pasos 5-6.
7-8.
La I-CSCF_{2} usa la Petición URI en la petición SIP como una identidad pública de usuario para enviar una consulta (por ejemplo, Cx-Location-Query PUI=sip: +123@op.com;user=phone) al HSS_{2} (paso 7). Entonces, el HSS_{2} envía una respuesta (por ejemplo, Cx-Location-Query_Rsp Server-Name=S-CSCF2_{2}) que indica a la S-CSCF_{2} que vuelva a la I-CSCF_{2} (paso 8).
9-10.
Una vez que la I-CSCF_{2} ha localizado la S-CSCF_{2} ella encamina la llamada (por ejemplo, INVITE sip: +123@op.com;user=phone) a esa S-CSCF_{2} (paso 9). La S-CSCF_{2} de terminación entonces usa su tabla de localización interna para encaminar la petición INVITE a la dirección de contacto registrada por el UA_{2} del usuario objetivo (en el ejemplo de arriba esta dirección de contacto es B-UE@op.com) (paso 10). Si no hay dirección de contacto registrada, pero el UA_{2} del usuario objetivo ha activado algún servicio que tiene un estado no registrado, entonces la S-CSCF_{2} envía la petición SIP al AS indicado por la información de servicio almacenada dentro de la S-CSCF_{2}.
\vskip1.000000\baselineskip
Con referencia a la Figura 2 (Técnica previa), hay un diagrama de flujo de señal que se usa para ayudar a describir un segundo proceso de encaminamiento, a saber el proceso de encaminamiento que tiene lugar cuando una llamada no viene desde una S-CSCF_{1} igual en una red remota 102 como se trató arriba sino en su lugar cuando viene de una MGCF_{1}. Este segundo proceso de encaminamiento particular ocurre cuando un UE_{3} de usuario se localiza en una PSTN 202 e inicia una llamada con un tel URI hacia el UA_{2} que se localiza en la red de terminación IMS 104. Los pasos para este proceso de encaminamiento particular son como siguen (se hace referencia al 3GPP TS 24.229 para más detalles):
1a.
La MGCF_{1} tiene un interfaz de señalización de PSTN que recibe un IAM enviado desde el UE_{3} (paso 1a). La MGCF_{1} usa el IAM para obtener el número E.164 del usuario objetivo y generar una petición INVITE SIP que incluye un campo de Petición URI que tiene o bien un tel URI (que contiene el número E.164) o bien un SIP URI (con el número E.164 integrado).
2a.
En este ejemplo particular, la petición INVITE SIP incluye un tel URI (por ejemplo, tel:+123) (comparar este paso 2a con el paso 4 en la Figura 1). La MGCF_{1} envía la petición INVITE SIP (por ejemplo, INVITE tel:+123) a la I-CSCF_{2} que se localiza en la red de terminación 104 (paso 2a).
3a-8a.
Los pasos 3a-8a son similares a los pasos 5-10 del procedimiento de encaminamiento previo mostrado en la Figura 1 excepto que se usa un tel URI (por ejemplo, tel:+123) en algunas de las señales más que el SIP URI (por ejemplo, sip:+123@op.com;user=phone).
\vskip1.000000\baselineskip
Desafortunadamente, los procedimientos de encaminamiento descritos arriba presentan algunos problemas:
1.
En el primer proceso de encaminamiento, el número de teléfono objetivo usado para iniciar la llamada se pierde antes de que la petición INVITE SIP llegue a la red de terminación 104. En particular; el número de teléfono objetivo se elimina de la Petición URI dentro la petición SIP por la S-CSCF_{1} de origen cuando sustituye el tel URI marcado originalmente con el SIP URI/tel URI integrado que se obtuvo del ENUM_{1} (ver pasos 2-3). Esto no es muy deseable porque puede ser necesario para la red de terminación 104 proporcionar este número de teléfono a ciertos servicios (por ejemplo, MMS).
2.
En ambos procesos de encaminamiento, para encaminar internamente una llamada en la red de terminación 104, el perfil de usuario dentro del HSS_{2} y la asociación usuario-servidor dentro de la SLF_{2} debe incluir tanto el tel URI como la forma SIP de ese tel URI (SIP URI/tel URI integrado). Esto es necesario porque hay casos en el procedimiento de encaminamiento donde la petición SIP recibida en la red de terminación 104 puede contener o bien un SIP URI/tel URI integrado (ver Figura 1) o bien un tel URI (ver Figura 2). Dado que, no se conoce a priori qué formato se está usando realmente por una red de origen dada 102, para ser capaz de encaminar internamente la llamada dentro de la red de terminación 104 la asociación usuario-servidor dentro de la SLF_{2} y el perfil de usuario dentro del HSS_{2} necesita incluir tanto el tel URI como la forma SIP de ese tel URI (el SIP URI/tel URI integrado). De esta manera, la SLF_{2} y el HSS_{2} cada uno necesita mantener información duplicada tanto para el tel URI como para el SIP URI/tel URI integrado que no solamente aumenta la carga administrativa sino que también gasta espacio en memoria. Esto no es deseable.
El documento WO2004071043 expone un sistema IMS en el que o bien un número de teléfono E.164 o bien un TEL-URI se traduce siempre a un SIP-URI antes de que una llamada se encamine a una red de destino.
Por consiguiente, ha habido y hay una necesidad de abordar estos defectos y otros defectos asociados con la técnica previa. Estas necesidades y otras necesidades se satisfacen por la presente invención.
Compendio
La presente invención propone un manejo específico de los tel URIs en una red de terminación IMS de manera que permita el encaminamiento de llamadas usando números de teléfono (y no SIP URIs con números de teléfono integrados) como identificadores de los usuarios objetivo de esas llamadas. Específicamente, la presente invención introduce un módulo de conversión de acuerdo con la reivindicación 1 que se sitúa dentro de la red de terminación IMS y es capaz de convertir los SIP URIs con números de teléfono integrados en tel URIs equivalentes que entonces se usan por una S-CSCF e I-CSCF de terminación para consultar la SLF y/o HSS de manera que pueden encaminar las llamadas a los usuarios objetivo.
En un escenario, el módulo de conversión puede convertir un SIP URI/integrado con un número de teléfono en un tel URI equivalente: (1) extrayendo una parte del usuario objetivo a partir del SIP URI/integrado con el número de teléfono; y (2) dejando pendiente con anterioridad la parte del usuario objetivo con una cadena "tel:" para generar el tel URI equivalente. En otro escenario, el módulo de conversión puede convertir un SIP URI/integrado con un número de teléfono en un tel URI equivalente: (1) extrayendo un primer conjunto de dígitos, a saber un descriptor de contexto de teléfono (el descriptor de contexto de teléfono puede ser o bien un nombre de dominio o bien un prefijo de número global), situado después del argumento "phone-context" en el SIP URI/integrado con el número de teléfono; (2) extrayendo un segundo conjunto de dígitos situados después de un argumento "sip:" en el SIP URI/integrado con el número de teléfono y antes del argumento "phone-context"; y (3) dejando pendiente con anterioridad una cadena "tel:" antes del primer conjunto de dígitos después de que el segundo conjunto de dígitos se inserte para generar el tel URI equivalente. En otro escenario, el módulo de conversión puede convertir un SIP URI/integrado con un número de teléfono en un tel URI equivalente: (1) extrayendo un primer conjunto de dígitos, a saber un descriptor de contexto de teléfono, situado después del argumento "phone-context"; (2) extrayendo un segundo conjunto de dígitos que se sitúa después del "sip: " pero antes del argumento "phone-context"; (3) usando el primer conjunto de dígitos (descriptor de contexto de teléfono/prefijo de red global) como clave para una tabla preconfigurada de reglas de sustitución para encontrar un conjunto de reglas de sustitución; (4) aplicando estas reglas de sustitución al segundo conjunto de dígitos para producir un tercer conjunto de dígitos, y (5) dejar pendiente con anterioridad una cadena "tel:" antes del tercer conjunto de dígitos para generar el tel URI equivalente.
Además, la presente invención incluye una I-CSCF de acuerdo con la reivindicación 18 que tiene el receptor para recibir una Petición SIP y un procesador para determinar si la Petición SIP tiene una petición URI que incluye un SIP URI/número de teléfono integrado. En un escenario, el procesador determina que la petición SIP tiene un SIP URI/número de teléfono integrado si hay un argumento "user=phone" en la petición URI. Si la petición SIP tiene un SIP URI/número de teléfono integrado, entonces la I-CSCF tiene un dispositivo de consulta que envía la petición URI hacia un módulo de conversión (que genera un tel URI correspondiente a partir del SIP URI/número de teléfono integrado) y entonces recibe el tel URI correspondiente desde el módulo de conversión. A partir de entonces, el procesador elimina el SIP URI/número de teléfono integrado e inserta el tel URI recibido en la petición URI de la petición SIP para formar una petición SIP revisada. Finalmente, la I-CSCF tiene un remitente que envía la petición SIP revisada incluyendo la petición URI con el tel URI correspondiente hacia una S-CSCF.
Además, la presente invención incluye una S-CSCF de acuerdo con la reivindicación 21 que tiene el receptor para recibir una Petición SIP y un procesador para determinar si la Petición SIP tiene una petición URI que incluye un SIP URI/número de teléfono integrado. En un escenario, el procesador determina que la petición SIP tiene un SIP URI/número de teléfono integrado si hay un argumento "user=phone" en la petición URI. Si la petición SIP tiene un SIP URI/número de teléfono integrado, entonces la S-CSCF tiene un dispositivo de consulta que envía la petición URI hacia un módulo de conversión (que genera un tel URI correspondiente a partir del SIP URI/número de teléfono integrado) y entonces recibe el tel URI correspondiente desde el módulo de conversión. A partir de entonces, el procesador elimina el SIP URI/número de teléfono integrado e inserta el tel URI recibido en la petición URI de la petición SIP para formar una petición SIP revisada. Finalmente, la S-CSCF tiene un remitente que envía la petición SIP revisada incluyendo la petición URI con el tel URI correspondiente hacia una red de terminación.
Una ventaja de la presente invención es que dado que la I-CSCF y la S-CSCF pueden encaminar las llamadas usando los tel URIs equivalentes entonces la SLF y/o el HSS solamente necesitan mantener los tel URIs de los usuarios objetivo y no mantener tanto los tel URIs como los SIP URI/tel URIs integrados de los usuarios objetivo. Otra ventaja de la presente invención es que el módulo de conversión puede obtener los números de teléfono de los usuarios objetivo marcados originalmente que pueden haber sido quitados de la petición SIP por una S-CSCF en la red de origen y esto es deseable dado que la red de terminación puede necesitar los números de teléfono de origen para soportar los servicios basados en el número de teléfono o servicios legados como por ejemplo el MMS.
La presente invención también se refiere a un método de acuerdo con la reivindicación 5 y una red de acuerdo con la reivindicación 9.
Otras realizaciones se exponen en las reivindicaciones dependientes.
Breve descripción de los dibujos
Se puede obtener una compresión más completa de la presente invención por referencia a la siguiente descripción detallada cuando se toma en unión con los dibujos anexos en donde:
La Figura 1 (Técnica previa) es un diagrama de flujo de señal usado para ayudar a describir los problemas asociados con el proceso tradicional de encaminamiento de una llamada desde un UA que se sitúa dentro de una red de origen IMS a un UA que se sitúa dentro de una red de terminación IMS;
La Figura 2 (Técnica previa) es un diagrama de flujo de señal usado para ayudar a describir los problemas asociados con el proceso tradicional para encaminar una llamada de un UE que se sitúa en una PSTN a un UA que se sitúa en una red de terminación IMS;
La Figura 3 es un diagrama de bloques de una red de terminación IMS que se ha mejorado con un UTM que funciona para abordar los problemas asociados con la técnica previa de acuerdo con la presente invención;
La Figura 4 es un diagrama de flujo de señal ejemplar usado para ayudar a explicar cómo una llamada, que se recibe por una I-CSCF (situada dentro de la red de terminación IMS), se puede encaminar a una S-CSCF (situada dentro de la red de terminación IMS) de acuerdo con una primera realización de la presente invención;
La Figura 5 es un diagrama de flujo de señal ejemplar usado para ayudar a explicar cómo una llamada, que se recibe por una S-CSCF (situada dentro de una red de tránsito IMS), se puede encaminar a un siguiente salto (situado dentro de la red de terminación IMS) de acuerdo con una segunda realización de la presente invención;
La Figura 6 es un diagrama de flujo que ilustra los pasos básicos que realiza el UTM para obtener un tel URI equivalente a partir de un SIP URI que tiene un número de teléfono integrado de acuerdo con la presente invención; y
La Figura 7 es un diagrama de flujo de señal usado para ayudar a describir el proceso de encaminamiento de una llamada a partir de un UA_{1} que se sitúa dentro de una red de origen IMS a un UA_{2} que se sitúa dentro de una red de terminación IMS de acuerdo con una realización de la presente invención.
Descripción detallada
Con referencia a la Figura 3, hay un diagrama de bloques de una red de terminación IMS ejemplar 300 que tiene una CSCF 302 (que incluye una I-CSCF 302a y una S-CSCF 302b), una SLF 304, un HSS 306 y un UTM 308 que se usa para ayudar a explicar la presente invención. Como se muestra, la I-CSCF 302a comunica respectivamente con la SLF 304, en su caso, y el HSS 306 a través de los enlaces 310 y 312 mientras que la S-CSCF 302b comunica respectivamente con el HSS 306 a través del enlace 314. Además, la I-CSCF 302a y la S-CSCF 302b comunican respectivamente con el UTM 308 en los enlaces 316 y 318 usando por ejemplo un protocolo de consulta-respuesta que funciona en la parte superior del TCP/IP. Alternativamente, el UTM 308 se podría integrar con la CSCF 302 o, más concretamente, con la I-CSCF 302a o con la S-CSCF 302b, en cuyo caso los enlaces de comunicación entre ellos podrían ser enlaces internos que no serían visibles desde fuera de la CSCF 302. O, el UTM 308 se podría integrar con la SLF 304 y el HSS 306, en cuyo caso sería posible unir el interfaz CSCF-UTM con el interfaz CSCF-HSS 312, 314 (Cx) y el interfaz CSCF-SLF 310 (Dx). Se apreciará que la descripción proporcionada aquí dentro no trata otros detalles asociados con la CSCF 302, la SLF 304 y el HSS 306 que son bien conocidos por aquellos expertos en la industria y no son necesarios para comprender la presente invención.
Con referencia a la Figura 4, hay un diagrama de señal ejemplar que se usa para ayudar a explicar cómo cuando se recibe una llamada por la I-CSCF 302a (que incorpora al menos un receptor 402, un procesador 404, un dispositivo de consulta 406 y un remitente 408) se puede encaminar entonces a la S-CSCF 302b de acuerdo con la presente invención. Básicamente, cuando la I-CSCF 302a y en particular el receptor 402 recibe una petición SIP tiene que inspeccionar el procesador 404 la petición SIP (pero no inspecciona una petición REGISTER SIP dado que los tel URIs no están registrados actualmente) para ver si la Petición URI incluye la forma SIP URI de un tel URI (ver los pasos 1-2). Para hacer esto, la I-CSCF 302a y en particular el procesador 404 busca un argumento URI "user=phone" en la Petición URI y, si lo encuentra, entonces la I-CSCF 302a y en particular el dispositivo de consulta 406 envía la Petición URI completa en una consulta al UTM 308 (ver paso 3). El UTM 308 funciona para: (a) recibir la consulta; (b) tomar el SIP URI/número de teléfono integrado; (c) generar un tel URI equivalente; y (d) enviar una respuesta de la consulta que contiene el tel URI equivalente de vuelta a la I-CSCF 302a (ver los pasos 4-5 y la Fig. 6).
A partir de entonces, la I-CSCF 302a y en particular el remitente 408 usa el tel URI recibido desde el UTM 308 como un Id Público cuando se consulta la SLF 304, en su caso, y el HSS 306 (ver pasos 6-9). Adicionalmente, la I-CSCF 302a y en particular el procesador 404 sustituye el SIP URI/tel URI integrado en la petición SIP original con el tel URI recibido desde el UTM 308 de manera que el remitente 408 pueda enviar la petición SIP revisada a la S-CSCF 302b (ver paso 10). Dado que, la I-CSCF 302a sustituye el SIP URI/tel URI integrado en la petición SIP original con el tel URI recibido desde el UTM 308 esto supone que el encaminamiento de la petición SIP revisada dentro de la red objetivo IMS 300 se puede basar en el tel URI a partir de entonces. Como resultado, la SLF 304 y el HSS 306 solamente necesitan almacenar los IDs públicos asociados con el tel URI y no almacenar los IDs públicos tanto para el tel URI como para la forma SIP de ese tel URI. Esta es una mejora marcada sobre el proceso de encaminamiento tradicional en el que la SLF_{2} y el HSS_{2} tienen que almacenar información tanto sobre el tel URI como sobre el SIP URI/tel URI integrado.
Con referencia a la Figura 5, hay un diagrama de flujo de señal ejemplar que se usa para ayudar a explicar cómo cuando se recibe una llamada por una S-CSCF 302b (que incorpora al menos un receptor 502, un procesador 504, un dispositivo de consulta 506 y un remitente 508) en una red de tránsito, la llamada entonces se puede encaminar a un siguiente salto 320 de acuerdo con la presente invención. Básicamente, cuando la S-CSCF 302b y en particular el receptor 502 recibe una petición SIP tiene que inspeccionar el procesador 504 la petición SIP (pero no inspecciona una petición REGISTER SIP dado que los tel URIs no están registrados actualmente) para ver si la Petición URI incluye la forma SIP URI de un tel URI (ver los pasos 1-2). Para hacer esto, la S-CSCF 302b y en particular el procesador 504 busca un argumento URI "user=phone" en la Petición URI y, si lo encuentra, entonces la S-CSCF 302b y en particular el dispositivo de consulta 506 envía la Petición URI completa en una consulta al UTM 308 (ver paso 3). El UTM 308 funciona para: (a) recibir la consulta; (b) tomar el SIP URI/número de teléfono integrado; (c) generar un tel URI equivalente; y (d) enviar una respuesta de la consulta que contiene el tel URI equivalente de vuelta a la S-CSCF 302b (ver pasos 4-5 y la Fig. 6).
A partir de entonces, la S-CSCF 302b y en particular el remitente 508 usa el tel URI recibido desde el UTM 308 como un Id Público cuando se consulta la SLF 304, en su caso, y el HSS 306 (ver pasos 6-9). Adicionalmente, la S-CSCF 302b y en particular el procesador 504 sustituye el SIP URI/tel URI integrado en la petición SIP con el tel URI recibido desde el UTM 308 de manera que el remitente 508 puede enviar la petición SIP revisada al siguiente salto 320 (ver paso 10). Dado que, la S-CSCF 302b sustituye el SIP URI/tel URI integrado en la petición SIP original con el tel URI recibido desde el UTM 308 esto supone que el encaminamiento de la petición SIP revisada dentro de la red objetivo IMS 300 se puede basar en el tel URI a partir de entonces. Como resultado, la SLF 304 y el HSS 306 solamente necesitan almacenar los IDs públicos asociados con el tel URI y no almacenar los IDs públicos tanto para el tel URI como para la forma SIP de ese tel URI. Esta es una mejora marcada sobre el proceso de encaminamiento tradicional en el que la SLF_{2} y el HSS_{2} tienen que almacenar información tanto sobre el tel URI como sobre el SIP URI/tel URI integrado.
En cualquiera de las dos realizaciones de arriba, puede ocurrir que la respuesta a la consulta enviada desde el UTM 308 incluya un mensaje o código de error (ver discusión abajo). En ese caso, la I-CSCF 302a/S-CSCF 302b podría responder la petición enviando un 404 respuesta (no encontrada) incluyendo algún texto descriptivo como por ejemplo "dominio equivocado en el tel URI" de vuelta a la persona que llama de origen. Esto da la oportunidad a la persona que llama de origen que inició la petición SIP de reenviar la petición SIP usando un SIP URI en lugar de un tel URI, en caso de que sean capaces de hacerlo de esta manera (por ejemplo una persona que llama de origen que usa un teléfono POTS no sería capaz de reenviar la petición usando un SIP URI).
Con referencia a la Figura 6, hay un diagrama de flujo que ilustra los pasos básicos de un método 600 que realiza el UTM 308 de manera que puede obtener un tel URI equivalente a partir de un SIP URI que tiene un número de teléfono integrado de acuerdo con la presente invención. Básicamente, el UTM 308 incluye un procesador 322 y una memoria 324 que tiene instrucciones almacenadas allí dentro que son accesibles y procesables por el procesador 322 para tomar un SIP URI/número de teléfono integrado y generar un tel URI equivalente.
Comenzando en el paso 602, el UTM 308 recibe una petición URI que contiene un SIP URI/tel URI integrado (ver paso 3 en las Figs. 4-5). En el paso 604, el UTM 308 determina si el SIP URI/tel URI integrado tiene un número global reconocible. Si es no, entonces el UTM 308 en el paso 606 pone a la salida un mensaje de error (por ejemplo, 404 respuesta (no encontrada)). Por ejemplo, el UTM 308 determinaría que el SIP URI/tel URI integrado no representa un número global reconocible si incluye un argumento "phone-context" con un prefijo de red local no reconocible o un prefijo privado no reconocible como por ejemplo "tel:2997;phone-context=91339". Además, el UTM 308 puede determinar que el SIP URI/tel URI integrado no representa un número global reconocible si incluye un argumento "phone-context" con un nombre de dominio que el UTM 308 no reconoce como por ejemplo "tel:2997;phone-context=unknown.domain.net". Generalmente, el UTM 308 implementaría algún tipo de política dependiente del operador que le permitiría reconocer o no reconocer cierto dominio o dominios. Por ejemplo, el UTM 308 puede ser capaz de reconocer el(los) nombre(s) de dominio del operador asignado.
Si la respuesta al paso 604 es sí, entonces el UTM 308 en el paso 608 determina si el SIP URI/tel URI integrado contiene un argumento "phone-context". Si es no, entonces el UTM 308 en el paso 610 genera el tel URI equivalente extrayendo una parte del usuario objetivo a partir del SIP URI/tel URI integrado y entonces dejando pendiente con anterioridad la parte del usuario objetivo con una cadena "tel:" para generar tel URI equivalente. Por ejemplo, el UTM 308 puede extraer parte del usuario objetivo (por ejemplo, +1-234-567-89) del SIP URI (por ejemplo, sip:+1-234-567-89@cingular.com;user=phone) y entonces dejar pendiente con anterioridad la parte del usuario objetivo extraída (por ejemplo, +1-234-567-89) con la cadena "tel:" para formar el tel URI equivalente (por ejemplo, tel:+1-234-567-89). En el paso 612, el UTM 308 almacena el tel URI equivalente en memoria 324 y entonces pone a la salida el tel URI equivalente (ver paso 5 en las Figs. 4-5).
Si la respuesta al paso 608 es sí, entonces el UTM 308 en el paso 614 genera el tel URI equivalente extrayendo un primer conjunto de dígitos situados después del argumento "phone-context", extrayendo un segundo conjunto de dígitos que se sitúan después del "sip:" pero antes del argumento "phone-context" y entonces dejando pendiente con anterioridad una cadena "tel:" antes del primer conjunto de dígitos después de que el segundo conjunto de dígitos se inserte para generar el tel URI equivalente. Por ejemplo, si el SIP URI/tel URI integrado recibido (por ejemplo "tel:2997;phone-context=+3491339") incluye el argumento "phone-context" con un prefijo de red global o un nombre de dominio que el UTM 308 reconoce, se incorpora un tel URI equivalente (por ejemplo, tel:+34913392997) insertando el primer conjunto de dígitos asociado con el prefijo de red global (por ejemplo, 3491339) entre el prefijo "tel:" y el segundo conjunto de dígitos (por ejemplo, 2997) que siguió a la cadena original "tel:". Además, el UTM 308 eliminaría cualesquiera caracteres que no sean dígitos incluyendo el argumento "phone-context" y el argumento "service-provider" (si está presente). En el paso 612, el UTM 308 almacena el tel URI equivalente en memoria 324 y entonces pone a la salida el tel URI equivalente (ver paso 5 en las Figs. 4-5).
En una realización alternativa cuando la respuesta al paso 608 es sí, el UTM 308 en el paso 614' genera el tel URI equivalente extrayendo un primer conjunto de dígitos, a saber un descriptor de contexto de teléfono, situado después del argumento "phone-context", extrayendo un segundo conjunto de dígitos que se sitúan después del "sip": pero antes del argumento "phone-context", usando el primer conjunto de dígitos (descriptor del contexto de teléfono/prefijo de red global) como clave para una tabla preconfigurada de reglas de sustitución para encontrar un conjunto de reglas de sustitución, aplicando estas reglas de sustitución al segundo conjunto de dígitos para producir un tercer conjunto de dígitos, y finalmente dejar pendiente con anterioridad una cadena "tel:" antes del tercer conjunto de dígitos para generar el tel URI equivalente. Por ejemplo, si el SIP URI/tel URI integrado recibido (por ejemplo "tel:2997;phone-context=+3491339") incluye el argumento "phone-context" con un prefijo de red global que el UTM 308 reconoce, un tel URI equivalente (por ejemplo, tel:+34913392997) se incorpora usando el primer conjunto de dígitos asociado con el prefijo de red global (por ejemplo, 3491339) como una clave para la tabla preconfigurada de reglas de sustitución para encontrar un conjunto de reglas de sustitución válido para el prefijo de red global, aplicando estas reglas de sustitución en el segundo conjunto de dígitos (por ejemplo, 2997) para producir un tercer conjunto de dígitos (por ejemplo, +34913392997), y finalmente dejar pendiente con anterioridad una cadena "tel:" antes del tercer conjunto de dígitos para obtener el tel URI equivalente (por ejemplo, tel:+34913392997). En el paso 612, el UTM 308 almacena el tel URI equivalente en memoria 324 y entonces pone a la salida el tel URI equivalente (ver paso 5 en las Figs. 4-5).
Con referencia a la Figura 7, hay un diagrama de flujo de señal usado para ayudar a describir el proceso interoperador de encaminamiento de una llamada desde un UA_{1} situado dentro de una red de origen 702 a un UA_{2} situado dentro de una red de terminación/destino 704 de acuerdo con la presente invención (comparar con la Figura 1). Las etapas son como sigue:
1-3.
La S-CSCF 706 de origen recibe una petición SIP (por ejemplo, INIVITE tel: +123) desde el UA_{1} (paso 1). La S-CSCF 706 toma una Petición URI a partir de la petición INVITE de inicio de sesión recibida y si la Petición URI contiene un tel URI entonces la S-CSCF 706 consulta un servicio ENUM 708 (paso 2). El ENUM 708 cambia el tel URI en un SIP URI/tel URI integrado (por ejemplo, sip: +123@op.com;user=phone) y lo envía a la S-CSCF 706 (paso 3). La S-CSCF 706 también sustituiría el tel URI original en la petición SIP con el SIP URI/tel URI integrado obtenido de la consulta para formar una nueva petición SIP (por ejemplo, INVITE sip: +123@op.com;user=phone).
4.
La S-CSCF de origen 706 toma la parte del dominio (por ejemplo, op.com) de la nueva Petición URI y envía la nueva petición INVITE SIP a la dirección identificada por ese dominio (si el dominio es una dirección IPv4 o IPv6 el INVITE se puede enviar a esa dirección de inmediato, de otra manera necesita ser consultada una DNS usando la parte del dominio para obtener una dirección IP destino, que corresponde o bien a una IBCF o bien a una I-CSCF 302a en la red de terminación 704). En este ejemplo, la S-CSCF 706 envía la nueva petición SIP (por ejemplo, INVITE sip: +123@op.com;user=phone) directamente a la I-CSCF 302a (paso 4).
5-8.
La I-CSCF302a recibe e inspecciona la petición SIP (por ejemplo, INVITE sip: +123@op.com;user= phone) para ver si incluye la forma SIP URI de un tel URI en la Petición URI (paso 5). Para hacer esto, la I-CSCF 302a busca un argumento URI "user=phone" en la Petición URI y, si lo encuentra, entonces la I-CSCF 302a envía la Petición URI completa en una consulta (por ejemplo, Query sip:+123@op.com;user=phone) al UTM 308 (paso 6). El UTM 308 recibe la consulta y usa el SIP URI/número de usuario integrado para generar un tel URI equivalente (por ejemplo, tel:+123) implementando el método 600 (paso 7). Entonces, el UTM 308 envía una respuesta de la consulta (por ejemplo, Rsp tel:+123) de vuelta a la I-CSCF 302a (paso 8).
9-10.
La I-CSCF 302a usa el tel URI recibido desde el UTM 308 como un Id Público para enviar una consulta (por ejemplo, Dx-Location-Query PUI=tel:+ 123) a la SLF 304 (ver paso 9), si existe más de un HSS en la red de terminación. Entonces, la SLF 304 envía una respuesta (por ejemplo, Dx-Location-Query_Rsp Server-Name=HSS 306) indicando al HSS 306 que vuelva a la I-CSCF 302a (paso 10). Si solo existe un HSS, entonces se pueden omitir la SLF 304 y los pasos 9-10.
11-12.
La I-CSCF 302a usa el tel URI recibido desde el UTM 308 como un Id Público para enviar una consulta (por ejemplo, Cx- Location-Query PUI=tel: +123) al HSS 306 (paso 11). Entonces, el HSS 306 envía una respuesta (por ejemplo, Cx-Location-Query_Rsp Server-Name=S-CSCF 302b) indicando a la S-CSCF 302b que vuelva a la I-CSCF 302a (paso 12). Nota: la I-CSCF 302a realiza los pasos 9-12 para localizar la S-CSCF 302b que sirve al UA_{2} de usuario al que va dirigida la llamada.
13-14.
Una vez que la I-CSCF 302a ha localizado la S-CSCF 302b encamina la llamada (por ejemplo, INVITE sip: +123) a la S-CSCF 302b (paso 13). La S-CSCF 302b de terminación entonces usa su tabla de localización interna para encaminar la petición INVITE a la dirección de contacto registrada por el UA_{2} del usuario objetivo (en el ejemplo de arriba esta dirección de contacto es B-UE@op.com) (paso 14). Si no hay dirección de contacto registrada, pero el UA_{2} del usuario objetivo ha activado algún servicio que tiene un estado no registrado, entonces la S-CSCF 302b envía la petición SIP al AS indicado en la información de servicio almacenada dentro de la S-CSCF 302b.
De lo anteriormente mencionado, se debería apreciar por aquellos expertos en la técnica que la presente invención propone un manejo específico de los tel URIs en la red de terminación IMS 300 y 704 a fin de permitir el encaminamiento de las llamadas que usan los números de teléfono (y no el SIP URI con números de teléfono integrados) como los identificadores de los usuarios objetivo de esas llamadas. Específicamente, la presente invención introduce un módulo de conversión 308 que se sitúa en la red de terminación IMS 300 y 704 y es capaz de convertir los SIP URIs con números de teléfono integrados en los tel URIs equivalentes que entonces se usan por la S-CSCF y la I-CSCF de terminación IMS para consultar a la SLF y/o el HSS de manera que puedan encaminar las llamadas a los usuarios objetivo. Básicamente, la presente invención mejora el proceso de encaminamiento de llamadas en una red de terminación IMS de las siguientes maneras (por ejemplo):
El UTM 308 permite el uso de los números de teléfono con servicio Portadora-ENUM en un proceso de encaminamiento interoperador sin los problemas implicados asociados con la gestión de dos tipos de Identidades Públicas de Usuario en el HSS y la SLF.
El UTM 308 permite el envío de implementación independiente del número de teléfono marcado originalmente y sus características a la red de terminación IMS que podrían ser necesarias para soportar los servicios basados en el número de teléfono o los servicios legados como por ejemplo el MMS.
El UTM 308 permite a los operadores de red desplegar un servicio Portadora-ENUM de manera que no habría necesidad de suministro de las SLFs y los HSSs con más de un URI completo por usuario. Esto conduce a una economía asociada en la administración y gestión del servicio porque solamente se necesita proporcionar el tel URI de un usuario mientras en el pasado necesitaban ser proporcionados tanto el tel URI y la versión SIP de ese mismo URI.
El UTM 308 permite la interconexión con varias MGCFs que usan distintas formas de codificación de los números E.164 de los usuarios de origen sin la necesidad de actualizar las bases de datos SLF o HSS con identidades públicas duplicadas del usuario objetivo.
Aunque han sido ilustradas varias realizaciones de la presente invención en los Dibujos anexos y descritos en la Descripción Detallada anteriormente mencionada, se debería comprender que la invención no está limitada a las realizaciones expuestas, sino que en su lugar es capaz también de numerosas readaptaciones, modificaciones y sustituciones dentro del alcance de la invención como se establece adelante y se define por las siguientes reivindicaciones.

Claims (23)

1. Un módulo de conversión (308), que comprende:
\quad
un procesador; y
\quad
una memoria con instrucciones almacenadas allí dentro que son accesibles y procesables por dicho procesador para facilitar los siguientes pasos:
recibir una petición URI; y
determinar si la petición URI tiene un SIP URI con un número global reconocible;
si es no, poner a la salida un mensaje de error; y
si es sí, generar un número de teléfono "tel URI" usando el SIP URI y entonces poner a la salida el número de teléfono "tel URI".
\vskip1.000000\baselineskip
2. El módulo de conversión de la Reivindicación 1, en donde si el SIP URI no contiene un argumento "phone-context" entonces dicho procesador facilita el paso de generación realizando los siguientes pasos:
\quad
extraer una parte del usuario objetivo a partir del SIP URI; y
\quad
dejar pendiente con anterioridad la parte del usuario objetivo con una cadena "tel:" para generar el número de teléfono "tel URI".
\vskip1.000000\baselineskip
3. El módulo de conversión de la Reivindicación 1, en donde si el SIP URI contiene un argumento "phone-context" entonces dicho procesador facilita el paso de generación realizando los siguientes pasos:
\quad
extraer un primer conjunto de dígitos situados después del argumento "phone-context";
\quad
extraer un segundo conjunto de dígitos situados después de un "sip:" en el SIP URI y antes del argumento "phone-context"; y
\quad
dejar pendiente con anterioridad una cadena "tel:" antes del primer conjunto de dígitos después del cual el segundo conjunto de dígitos se insertan para generar el número de teléfono "tel URI".
\vskip1.000000\baselineskip
4. El módulo de conversión de la Reivindicación 1, en donde si el SIP URI contiene un argumento "phone-context" entonces dicho procesador facilita el paso de generación realizando los siguientes pasos:
\quad
extraer un primer conjunto de dígitos situados después del argumento "phone-context";
\quad
extraer un segundo conjunto de dígitos situados después de un "sip:" en el SIP URI y antes del argumento "phone-context";
\quad
usar el primer conjunto de dígitos como una clave para una tabla preconfigurada de reglas de sustitución para encontrar un conjunto de reglas de sustitución;
\quad
aplicar el conjunto de reglas de sustitución al segundo conjunto de dígitos para producir un tercer conjunto de dígitos; y
\quad
dejar pendiente con anterioridad una cadena "tel:" antes del tercer conjunto de dígitos para generar el tel URI equivalente.
\vskip1.000000\baselineskip
5. Un método para obtener un tel URI a partir de un SIP URI que tiene un número de teléfono integrado, dicho método que comprende los pasos de:
\quad
recibir una petición URI; y
\quad
determinar si la petición URI tiene un SIP URI con un número global reconocible;
si es no, poner a la salida un mensaje de error; y
si es sí, generar un número de teléfono "tel URI" usando el SIP URI y entonces poner a la salida el número de teléfono "tel URI".
\vskip1.000000\baselineskip
6. El método de la Reivindicación 5, en donde si el SIP URI no contiene un argumento "phone-context" entonces dicho paso de generación incluye los siguientes pasos:
\quad
extraer una parte del usuario objetivo a partir del SIP URI; y
\quad
dejar pendiente con anterioridad la parte del usuario objetivo con una cadena "tel:" para generar el número de teléfono "tel URI".
\vskip1.000000\baselineskip
7. El método de la Reivindicación 5, en donde si el SIP URI contiene un argumento "phone-context" entonces dicho paso de generación incluye además los siguientes pasos:
\quad
extraer un primer conjunto de dígitos situados del argumento "phone-context";
\quad
extraer un segundo conjunto de dígitos situados después de un "sip:" en el SIP URI y antes del argumento "phone-context"; y
\quad
dejar pendiente con anterioridad una cadena "tel:" antes del primer conjunto de dígitos después del cual el segundo conjunto de dígitos se inserta para generar el número de teléfono "tel URI".
\vskip1.000000\baselineskip
8. El método de la Reivindicación 5, en donde si el SIP URI contiene un argumento "phone-context" entonces dicho paso de generación incluye además los siguientes pasos:
\quad
extraer un primer conjunto de dígitos situado después del argumento "phone-context";
\quad
extraer un segundo conjunto de dígitos situado después de un "sip:" en el SIP URI y antes del argumento "phone-context";
\quad
usar el primer conjunto de dígitos como una clave para una tabla preconfigurada de reglas de sustitución para encontrar un conjunto de reglas de sustitución;
\quad
aplicar el conjunto de reglas de sustitución al segundo conjunto de dígitos para producir un tercer conjunto de dígitos; y
\quad
dejar pendiente con anterioridad una cadena "tel:" antes del tercer conjunto de dígitos para generar el tel URI equivalente.
\vskip1.000000\baselineskip
9. Una red (300), que comprende:
\quad
un nodo (302);
\quad
un módulo de conversión (308); y
\quad
una base de datos (306);
\quad
dicho nodo recibe una petición SIP y determina si la petición SIP tiene un SIP URI/número de teléfono integrado:
si es sí, entonces dicho nodo envía el SIP URI/número de teléfono integrado a dicho módulo de conversión que determina si el SIP URI/número de teléfono integrado tiene un número global reconocible;
si es no, dicho módulo de conversión envía un mensaje de error a dicho nodo; y
si es sí, dicho módulo de conversión genera un número de teléfono "tel URI" que usa el SIP URI/nú- mero de teléfono integrado y entonces envía el número de teléfono "tel URI" a dicho nodo que usa el número de teléfono "tel URI" para consultar dicha base de datos para determinar donde encaminar a continuación la petición SIP;
si es no, entonces dicho nodo usa el SIP URI el cual no tiene el número de teléfono integrado para consultar dicha base de datos para determinar dónde encaminar a continuación la petición SIP.
\vskip1.000000\baselineskip
10. La red de la Reivindicación 9, en donde dicho nodo determina que la petición SIP tiene un SIP URI/número de teléfono integrado si la petición SIP tiene una Petición URI con un argumento "user=phone".
11. La red de la Reivindicación 9, en donde dicho nodo tras recibir el número de teléfono "tel URI" desde el módulo de conversión sustituye el SIP URI/número de teléfono integrado con el número de teléfono "tel URI" en la petición SIP y encamina la petición SIP revisada.
12. La red de la Reivindicación 9, en donde dicho nodo es una Función de Control de Señalización de Llamada-de Interrogación o una Función de Control de Señalización de Llamada-de Servicio.
13. La red de la Reivindicación 9, en donde dicha base de datos contiene información relativa al número de teléfono "tel URI" y no contiene información relativa al SIP URI/número de teléfono integrado.
14. La red de la Reivindicación 9, en donde la base de datos es una Función de Localización de Servidor o un Servidor de Abonado Local.
\vskip1.000000\baselineskip
15. La red de la Reivindicación 9, en donde módulo de conversión realiza los siguientes pasos cuando el SIP URI/número de teléfono integrado no contiene un argumento "phone-context":
\quad
extraer una parte del usuario objetivo a partir del SIP URI/número de teléfono integrado; y
\quad
dejar pendiente con anterioridad la parte del usuario objetivo con una cadena "tel:" para generar el número de teléfono "tel URI".
\vskip1.000000\baselineskip
16. La red de la Reivindicación 9, en donde dicho módulo de conversión realiza los siguientes pasos cuando el SIP URI/número de teléfono integrado contiene un argumento "phone-context":
\quad
extraer el primer conjunto de dígitos situado después del argumento "phone-context";
\quad
extraer un segundo conjunto de dígitos situado después de un "sip:" en el SIP URI/número de teléfono integrado y antes del argumento "phone-context"; y
\quad
dejar pendiente con anterioridad una cadena "tel:" antes del primer conjunto de dígitos después del cual se inserta el segundo conjunto de dígitos para generar el número de teléfono "tel URI".
\vskip1.000000\baselineskip
17. La red de la Reivindicación 9, en donde dicho módulo de conversión realiza los siguientes pasos cuando el SIP URI/número de teléfono integrado contiene un argumento "phone-context":
\quad
extraer un primer conjunto de dígitos situado después del argumento "phone-context";
\quad
extraer un segundo conjunto de dígitos situado después de un "sip:" en el SIP URI y antes del argumento "phone-context";
\quad
usar el primer conjunto de dígitos como una clave para una tabla preconfigurada de reglas de sustitución para encontrar un conjunto de reglas de sustitución;
\quad
aplicar el conjunto de reglas de sustitución al segundo conjunto de dígitos para producir un tercer conjunto de dígitos; y
\quad
dejar pendiente con anterioridad una cadena "tel: " antes del tercer conjunto de dígitos para generar el tel URI equivalente.
\vskip1.000000\baselineskip
18. Una Función de Control de Sesión de Llamada de Interrogación (302a) para encaminar una petición SIP en una red de terminación hacia una Función de Control de Sesión de Llamada de Servicio, que comprende:
\quad
un receptor para recibir la Petición SIP;
\quad
un procesador para determinar si la Petición SIP tiene una petición URI que incluye un SIP URI/número de teléfono integrado;
\quad
un dispositivo de consulta para enviar la petición URI hacia un módulo de conversión y para recibir un tel URI correspondiente desde el módulo de conversión;
\quad
dicho procesador que elimina el SIP URI/número de teléfono integrado e inserta el tel URI recibido en la petición URI de la petición SIP para formar una petición SIP revisada; y
\quad
un remitente para enviar la petición SIP revisada incluyendo la petición URI con el tel URI hacia la Función de Control de Sesión de Llamada de Servicio.
\vskip1.000000\baselineskip
19. La Función de Control de Sesión de Llamada de Interrogación de la Reivindicación 18, en donde dicho procesador determina que la petición SIP tiene el SIP URI/número de teléfono integrado si hay un argumento "user=phone" en la petición URI.
20. La Función de Control de Sesión de Llamada de Interrogación de la Reivindicación 18, en donde tras recibir el tel URI correspondiente desde el módulo de conversión el procesador entonces sustituye el SIP URI/número de teléfono integrado con el tel URI correspondiente en la petición SIP y encamina la petición SIP revisada.
\vskip1.000000\baselineskip
21. Una Función de Control de Sesión de Llamada de Servicio (302b) para encaminar una petición SIP a través de una red de tránsito hacia una red de terminación, que comprende:
\quad
un receptor para recibir la Petición SIP;
\quad
un procesador para determinar si la Petición SIP tiene una petición URI que incluye un SIP URI/número de teléfono integrado;
\quad
el dispositivo de consulta para enviar la petición URI hacia un módulo de conversión y para recibir un tel URI correspondiente desde el módulo de conversión;
\quad
dicho procesador que elimina el SIP URI/número de teléfono integrado e inserta el tel URI recibido en la petición URI de la petición SIP para formar una petición SIP revisada; y
\quad
un remitente para enviar la petición SIP revisada con el tel URI hacia la red de terminación.
\vskip1.000000\baselineskip
22. La Función de Control de Sesión de Llamada de Servicio de la Reivindicación 21, en donde dicho procesador determina que la petición SIP tiene el SIP URI/número de teléfono integrado si hay un argumento "user=phone" en la petición URI.
23. La Función de Control de Sesión de Llamada de Servicio de la Reivindicación 21, en donde tras recibir el tel URI correspondiente desde el módulo de conversión el procesador entonces sustituye el SIP URI/número de teléfono integrado con el tel URI correspondiente en la petición SIP y encamina la petición SIP revisada.
ES06809094T 2005-10-21 2006-10-20 Encaminamiento de llamadas ims utilizando identificadores de recursos uniformes de telefonos (tel-uris). Active ES2337836T3 (es)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US72901205P 2005-10-21 2005-10-21
US729012P 2005-10-21

Publications (1)

Publication Number Publication Date
ES2337836T3 true ES2337836T3 (es) 2010-04-29

Family

ID=37734966

Family Applications (1)

Application Number Title Priority Date Filing Date
ES06809094T Active ES2337836T3 (es) 2005-10-21 2006-10-20 Encaminamiento de llamadas ims utilizando identificadores de recursos uniformes de telefonos (tel-uris).

Country Status (9)

Country Link
US (2) US8619794B2 (es)
EP (1) EP1938554B1 (es)
JP (2) JP5161784B2 (es)
CN (1) CN101292498B (es)
AT (1) ATE451779T1 (es)
DE (1) DE602006011040D1 (es)
ES (1) ES2337836T3 (es)
PL (1) PL1938554T3 (es)
WO (1) WO2007045991A1 (es)

Families Citing this family (60)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7848767B2 (en) 2002-10-15 2010-12-07 Tekelec Methods and systems for migrating between application layer mobile signaling protocols
US20070115934A1 (en) * 2005-11-22 2007-05-24 Samsung Electronics Co., Ltd. Method and system for locating subscriber data in an IP multimedia subsystem
US7889716B2 (en) 2005-12-01 2011-02-15 Tekelec Methods, systems, and computer program products for using an E.164 number (ENUM) database for message service message routing resolution among 2G and subsequent generation network systems
US7630372B1 (en) 2005-12-30 2009-12-08 At&T Corp. Method and apparatus for providing access and egress uniform resource identifiers for routing
BRPI0707819A2 (pt) 2006-02-15 2011-05-10 Tekelec Us mÉtodo, sistemas e produÇço de programa de computador para seletivamente processar ou redirecionar mensagens de parte de controle de conexço de sinalizaÇço ( sccp )
US8184798B2 (en) 2006-06-13 2012-05-22 Tekelec Methods, systems and computer program products for accessing number portability (NP) and E.164 number (ENUM) data using a common NP/ENUM data locator structure
US7787445B2 (en) 2006-07-20 2010-08-31 Tekelec Methods, systems, and computer program products for routing and processing ENUM queries
CN101110758A (zh) * 2006-07-21 2008-01-23 华为技术有限公司 建立紧急会话的方法、系统及代理呼叫会话控制功能
ATE513418T1 (de) * 2006-08-17 2011-07-15 Comverse Ltd Netz-interoperabilität
US8254551B2 (en) 2006-12-07 2012-08-28 Tekelec, Inc. Methods, systems, and computer program products for providing quality of service using E.164 number mapping (ENUM) data in a communications network
WO2008083631A1 (fr) * 2007-01-10 2008-07-17 Huawei Technologies Co., Ltd. Appareil de conversion d'identité d'utilisateur, ims et procédés d'enregistrement, de lancement et de fin d'appel
US8363640B2 (en) * 2007-01-31 2013-01-29 At&T Intellectual Property I, L.P. Methods and apparatus for handling a communication session for an unregistered internet protocol multimedia subsystem (IMS) device
JP5430553B2 (ja) * 2007-04-20 2014-03-05 テレフオンアクチーボラゲット エル エム エリクソン（パブル） Ｉｐマルチメディアサブシステムにおけるユーザｉｄの処理
US9049209B2 (en) * 2007-05-08 2015-06-02 At&T Intellectual Property I, L.P. Methods and apparatus to route a communication session in an internet protocol (IP) multimedia subsystem (IMS) network
DE102007032824B4 (de) 2007-05-18 2015-02-26 Vodafone Holding Gmbh Fernsteuerungseinrichtung
US7996541B2 (en) 2007-06-15 2011-08-09 Tekelec Methods, systems, and computer program products for identifying a serving home subscriber server (HSS) in a communications network
WO2009021430A1 (fr) * 2007-08-10 2009-02-19 Huawei Technologies Co., Ltd. Procédé de connexion d'appel, équipement et système dans un sous-système multimédia ip
CN101365240B (zh) 2007-08-10 2011-11-02 华为技术有限公司 Ip多媒体子系统中的呼叫接续方法、装置和系统
US8270344B2 (en) 2007-09-10 2012-09-18 At&T Intellectual Property I, Lp System for communicating between internet protocol multimedia subsystem networks
US20090106437A1 (en) * 2007-10-22 2009-04-23 Nokia Corporation Method and device for handling different addressing schemes in session initiation protocol communication
JP5000548B2 (ja) * 2008-02-27 2012-08-15 株式会社エヌ・ティ・ティ・ドコモ 呼制御システム及び呼制御方法
US8594679B2 (en) 2008-03-07 2013-11-26 Tekelec Global, Inc. Methods, systems, and computer readable media for routing a message service message through a communications network
WO2010060087A2 (en) 2008-11-24 2010-05-27 Tekelec Systems, methods, and computer readable media for location-sensitive called-party number translation in a telecommunications network
US9397862B2 (en) 2008-12-12 2016-07-19 At&T Intellectual Property I, L.P. Method and apparatus for completing a circuit switched service call in an internet protocol network
US9184940B2 (en) * 2008-12-12 2015-11-10 At&T Intellectual Property I, L.P. Method and apparatus for completing a circuit switched service call in an internet protocol network
US8750132B2 (en) * 2008-12-16 2014-06-10 At&T Intellectual Property I, L.P. Method and apparatus for completing a call in a network with ENUM failure
US9021014B2 (en) 2009-03-25 2015-04-28 Tekelec, Inc. Methods, systems, and computer readable media for providing home subscriber server (HSS) proxy
WO2010132436A2 (en) 2009-05-11 2010-11-18 Tekelec Methods, systems, and computer readable media for providing scalable number portability (np) home location register (hlr)
US8620316B2 (en) 2009-08-17 2013-12-31 Telefonaktiebolaget L M Ericsson (Publ) Method and apparatus in a telecommunications network
US8750126B2 (en) 2009-10-16 2014-06-10 Tekelec, Inc. Methods, systems, and computer readable media for multi-interface monitoring and correlation of diameter signaling information
US9313759B2 (en) 2009-10-16 2016-04-12 Tekelec, Inc. Methods, systems, and computer readable media for providing triggerless equipment identity register (EIR) service in a diameter network
EP3264686B1 (en) 2009-10-16 2018-12-12 Tekelec, Inc. Methods, systems, and computer readable media for providing diameter signaling router with integrated monitoring and/or firewall functionality
JP5544150B2 (ja) * 2009-11-24 2014-07-09 株式会社日立国際電気 無線通信システム
US8451841B2 (en) * 2009-12-28 2013-05-28 At&T Intellectual Property I, L.P. Method and apparatus for processing a call to an aggregate endpoint device
US8793388B2 (en) * 2009-12-28 2014-07-29 At&T Intellectual Property I, L.P. Method and apparatus for processing a call to an aggregate endpoint device
US8750292B2 (en) 2010-02-25 2014-06-10 Tekelec, Inc. Systems, methods, and computer readable media for using a signaling message routing node to provide backup subscriber information management service
EP2656647B1 (en) 2010-12-23 2019-04-24 Tekelec, Inc. Method, system, and computer readable media for modifying a diameter signaling message directed to a charging function node
EP2666263B1 (en) 2011-01-21 2019-07-24 Tekelec, Inc. Methods, systems, and computer readable media for screening diameter messages within a diameter signaling router (dsr) having a distributed message processor architecture
JP5640764B2 (ja) * 2011-01-24 2014-12-17 沖電気工業株式会社 信号処理装置及びプログラム
EP2686986B1 (en) 2011-03-18 2019-09-11 Tekelec, Inc. Method, system, and computer readable media for configurable diameter address resolution
US20120275450A1 (en) * 2011-04-29 2012-11-01 Comcast Cable Communications, Llc Obtaining Services Through a Local Network
US9578180B2 (en) * 2011-12-08 2017-02-21 Institute For Information Industry Communication network system, calling terminal and voice call establishing method thereof
US9100796B2 (en) 2011-12-15 2015-08-04 Tekelec, Inc. Methods, systems, and computer readable media for seamless roaming between diameter and non-diameter networks
JP2013168840A (ja) * 2012-02-16 2013-08-29 Canon Inc 通信機器、その制御方法、および制御プログラム
CN103516675A (zh) * 2012-06-21 2014-01-15 华为软件技术有限公司 资源标识共享方法、终端和管理平台
TWI528776B (zh) * 2012-11-27 2016-04-01 鴻海精密工業股份有限公司 終端設備及網路協定語音通信方法
JP5994630B2 (ja) * 2012-12-26 2016-09-21 アイコム株式会社 中継装置
JP6064588B2 (ja) * 2012-12-26 2017-01-25 アイコム株式会社 中継装置
US8855654B2 (en) 2013-01-28 2014-10-07 Tekelec Global, Inc. Methods, systems, and computer readable media for tracking and communicating long term evolution (LTE) handset communication capability
US9635526B2 (en) 2013-03-15 2017-04-25 Tekelec, Inc. Methods, systems, and computer readable media for utilizing a diameter proxy agent to communicate short message service (SMS) messages
JP5898650B2 (ja) * 2013-07-01 2016-04-06 日本電信電話株式会社 呼制御システム
US20150252310A1 (en) 2014-03-07 2015-09-10 Ecolab Usa Inc. Alkyl amides for enhanced food soil removal and asphalt dissolution
FR3021832A1 (fr) * 2014-05-28 2015-12-04 Orange Procede de conversion d'un numero forme selon un plan de numerotation local vers un numero forme selon un plan de numerotation global
US10117127B2 (en) 2015-07-08 2018-10-30 Oracle International Corporation Methods, systems, and computer readable media for communicating radio access network congestion status information for large numbers of users
CN106559536A (zh) * 2015-09-25 2017-04-05 联发科技（新加坡）私人有限公司 支持统一资源识别符的通信方法和通信装置
JP2019165266A (ja) * 2016-06-24 2019-09-26 日本電気株式会社 通信接続管理装置、ｉｐマルチメディアサブシステム、登録装置、通信接続管理方法、プログラム
US11165833B2 (en) * 2016-11-02 2021-11-02 T-Mobile Usa, Inc. Network routing based on terminal's media path
US10237418B2 (en) 2017-04-21 2019-03-19 Oracle International Corporation Methods, systems, and computer readable media for charging based on radio congestion in mobile networks
JP6797757B2 (ja) * 2017-06-29 2020-12-09 株式会社Ｎｔｔドコモ 通信制御装置および通信システム
CN115766668A (zh) * 2021-09-03 2023-03-07 中国移动通信集团山东有限公司 自动容灾方法、电子设备和存储介质

Family Cites Families (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7463615B2 (en) * 2001-07-13 2008-12-09 Qualcomm, Incorporated System and method for extended SIP headers for CDMA parameters
US7480915B2 (en) * 2002-10-03 2009-01-20 Nokia Corporation WV-IMS relay and interoperability methods
US20040156394A1 (en) 2003-02-10 2004-08-12 Ilkka Westman Handling of user identity
AU2004214336A1 (en) * 2003-02-19 2004-09-02 Nokia Corporation Routing messages via an IMS system
US8571011B2 (en) 2004-08-13 2013-10-29 Verizon Business Global Llc Method and system for providing voice over IP managed services utilizing a centralized data store
US20060050686A1 (en) * 2004-09-08 2006-03-09 Commoca, Inc. Software platform for developing, delivering and managing data-voice applications operating on an internet protocol (IP) phone
FI20041659A0 (fi) * 2004-12-23 2004-12-23 Nokia Corp Menetelmä liikkeen reitittämiseksi VoIP-päätteeseen matkaviestinjärjestelmässä
US8832792B2 (en) * 2005-08-03 2014-09-09 At&T Mobility Ii Llc Limiting services based on location

Also Published As

Publication number Publication date
JP2009513052A (ja) 2009-03-26
JP5620965B2 (ja) 2014-11-05
EP1938554A1 (en) 2008-07-02
JP2013059100A (ja) 2013-03-28
US20130114592A1 (en) 2013-05-09
PL1938554T3 (pl) 2010-05-31
US9237088B2 (en) 2016-01-12
CN101292498B (zh) 2013-02-06
WO2007045991A1 (en) 2007-04-26
JP5161784B2 (ja) 2013-03-13
DE602006011040D1 (de) 2010-01-21
CN101292498A (zh) 2008-10-22
US8619794B2 (en) 2013-12-31
ATE451779T1 (de) 2009-12-15
US20080247384A1 (en) 2008-10-09
EP1938554B1 (en) 2009-12-09

Similar Documents

Publication Publication Date Title
ES2337836T3 (es) Encaminamiento de llamadas ims utilizando identificadores de recursos uniformes de telefonos (tel-uris).
ES2375871T3 (es) Acceso de grupo a un servicio del subsistema multimedia ip.
US9332041B2 (en) System and method for providing a circuit switched domain number
ES2373357T3 (es) Técnica para realizar la conversión de señalización entre los dominios http y sip.
ES2325378T3 (es) Metodo y aparato para identificar un servicio ims.
CN107925848B (zh) 用于跨多个平面的标识管理的方法和系统
US8045568B2 (en) Enterprise mobility
US8230109B2 (en) System and method for handling a session initiation protocol message in a communications network
US7701974B2 (en) Routing information processing for network hiding scheme
US8345666B2 (en) Redirecting a call by a circuit switched network to an internet protocol multimedia subsystem (IMS) network
BRPI0714929A2 (pt) mÉtodos, sistemas, e produtos de programa de computador para redirecionamento de serviÇos de controle de chamada de uma primeira rede de um primeiro tipo para uma segunda rede de um segundo tipo
ES2518994T3 (es) Tratamiento de identidades de usuario en el Subsistema Multimedia IP
MX2007012244A (es) Sistema y metodo para manejar continuidad de llamada en ambiente de red de ims utilizando mensajeria de sip.
EP2489210B1 (en) Delivery of a message between an ims domain and a cs domain
ES2374058T3 (es) Subsistema multimedia ip (ims) y método para enviar un mensaje http a través de un ims.
CN101212478B (zh) 分组业务实现方法和网络设备
US20110286446A1 (en) Method and Apparatus for Use in an IP Multimedia
ES2795876T3 (es) Método y aparatos para el servicio de múltiples identidades basado en el registro de identidades compartidas
ES2365743T3 (es) Métodos y aparatos para procesar peticiones sip en una red ims comprendiendo un as.
Calme et al. A common SIP profile for next-generation networks
CN101247323A (zh) 一种传输历史标识信息的方法和系统
WO2011095652A1 (es) Sistema y método de encaminamiento de llamadas en una red ims