ES2345410T3 - Procedimiento de encaminamiento de un mensaje sip en caso de no disponibilidad de nodos intermedios. - Google Patents
Procedimiento de encaminamiento de un mensaje sip en caso de no disponibilidad de nodos intermedios. Download PDFInfo
- Publication number
- ES2345410T3 ES2345410T3 ES07858586T ES07858586T ES2345410T3 ES 2345410 T3 ES2345410 T3 ES 2345410T3 ES 07858586 T ES07858586 T ES 07858586T ES 07858586 T ES07858586 T ES 07858586T ES 2345410 T3 ES2345410 T3 ES 2345410T3
- Authority
- ES
- Spain
- Prior art keywords
- entity
- header
- message
- sip
- request
- 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
Links
Classifications
-
- 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
- H04L45/22—Alternate routing
-
- 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
- H04L45/02—Topology update or discovery
-
- 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
- H04L45/28—Routing or path finding of packets in data switching networks using route fault recovery
-
- 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/1066—Session management
- H04L65/1101—Session protocols
-
- 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/1066—Session management
- H04L65/1101—Session protocols
- H04L65/1104—Session initiation protocol [SIP]
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Business, Economics & Management (AREA)
- General Business, Economics & Management (AREA)
- Multimedia (AREA)
- Telephonic Communication Services (AREA)
- Mobile Radio Communication Systems (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
Abstract
Procedimiento de encaminamiento en una red de telecomunicaciones de un mensaje SIP (Session Initiation Protocol) destinado a encaminarse a través de entidades intermedias que constituyen nodos de un camino de señalización, caracterizado porque comprende una etapa de elusión de al menos una entidad intermedia susceptible de ser eludida en caso de no disponibilidad, realizándose dicha etapa de elusión por supresión de la identidad URI (Uniform Resource Identifier) de dicha entidad intermedia a eludir en una cabecera "Route" o "Vía" de un mensaje SIP que contiene la lista de las identidades de las entidades a atravesar.
Description
Procedimiento de encaminamiento de un mensaje
SIP en caso de no disponibilidad de nodos intermedios.
La presente invención se refiere a un
procedimiento de encaminamiento de un mensaje SIP destinado a ser
encaminado a través de entidades intermedias que constituyen nodos
de un camino de señalización.
La invención encuentra una aplicación
particularmente ventajosa en las situaciones en las que una o más
entidades intermedias por las cuales debe transitar el mensaje no
están disponibles y por lo tanto no pueden ser contactadas por
otras entidades que se encuentran en el mismo camino de
señalización.
Una red de telecomunicaciones se compone de
diferentes entidades intermedias por las cuales transitan los
mensajes de señalización transmitidos entre una entidad emisora y
una entidad destinataria. Un mensaje de señalización contiene
información ligada a una llamada de la entidad emisora hacia la
entidad destinataria, como la petición de establecimiento de
llamada, así como otras informaciones, como por ejemplo la
notificación de la presencia de mensajes en una mensajería.
Estas entidades intermedias pueden tener
funciones muy diversas que van desde el encaminamiento de
señalización a las acciones que se llevan a cabo en este mensaje,
tales como la inserción o la supresión de algunas informaciones
para proporcionar un servicio particular.
El protocolo SIP ("Session Initiation
Protocol") es un protocolo definido por el IETF ("Internet
Engineering Task Force") que tiene por objetivo inicial permitir
el establecimiento, la notificación y la terminación de sesiones
multimedia en una red IP. El protocolo SIP ha sido elegido también
por diferentes organismos de normalización o consorcio como el 3GPP
("3rd Generation Partnership Project") o TISPAN ("Telecoms
& Internet converged Services & Protocols for Advanced
Networks") en el marco de su definición de arquitecturas de
control de redes basadas en un transporte IP. Entre estas
arquitecturas, se pueden citar las conocidas con el acrónimo IMS
("IP Multimedia Sub-system"). SIP tiene por lo
tanto tendencia a imponerse en el futuro como el protocolo de
establecimiento de sesiones utilizado en las redes públicas
operativas, sean éstas móviles o fijas.
Con respecto a los otros protocolos de
señalización, SIP se caracteriza por su capacidad de transmitir las
informaciones de encaminamiento a través de los propios mensajes
SIP. En efecto, la primera petición que inicia una sesión,
denominada petición inicial, puede contener las direcciones de las
entidades que debe atravesar. Estos datos se notifican en el
mensaje de petición inicial por la entidad emisora que se encuentra
en el origen de la sesión, habiendo sido estos datos recuperados
por la entidad emisora en el omento de su registro en la red o por
otros mecanismos. El camino de señalización que corresponde a la
sesión se establece en el momento del paso de la petición inicial
en función del destino de la llamada, de la arquitectura de la red y
de los servicios necesarios para esta sesión. Las siguientes
peticiones y las respuestas SIP contienen todos los datos
necesarios para su encaminamiento. Es una diferencia importante con
respecto a los otros protocolos para los cuales el encaminamiento
se basa esencialmente en tablas presentes en las entidades de red y
en la memorización de los datos de encaminamiento ligados a la
llamada por las entidades implicadas en esta llamada.
Los mensajes SIP son de dos tipos: las
peticiones y sus respuestas. Las respuestas siguen el camino inverso
al de la petición a la cual se asocian.
Entre las peticiones, se distinguen las
peticiones iniciales y las peticiones subsiguientes. Las peticiones
subsiguientes son las peticiones que pertenecen a un mismo diálogo
SIP creado por una petición inicial emitida por una entidad
emisora. Sólo algunas peticiones iniciales pueden crear un diálogo
SIP, es el caso, por ejemplo, del mensaje INVITE. El camino de las
peticiones subsiguientes, es decir el conjunto de las entidades SIP
de la red que deben atravesar todas las peticiones que pertenecen a
este diálogo, se determina durante el paso de la petición inicial
que crea este
diálogo.
diálogo.
Un mensaje SIP de petición inicial comprende una
cabecera "Request-URI" (URI por "Uniform
Resource Identifier") que contiene la dirección de la entidad
destinataria de la petición. Una petición SIP puede comprender
opcionalmente una cabecera particular denominada "Route", que
contiene por orden decreciente, la lista de las identidades, en
forma de URI, las entidades a atravesar antes de alcanzar el
destino, las cuales son las entidades intermedias por las cuales
debe pasar la petición.
Una entidad SIP intermedia, normalmente un proxy
SIP, que recibe una petición inicial procede al análisis de la
misma. Si esta petición contiene una cabecera "Route", entonces
considera la primera entidad SIP presente en esta cabecera como la
entidad a la cual debe hacer llegar la petición. En caso contrario,
determina la siguiente entidad a la cual la petición debe ser
enviada a partir de la cabecera "Request-URI"
utilizando mecanismos específicos de encaminamiento.
Toda entidad SIP, intermedia o no, tiene la
posibilidad de añadir una cabecera "Route" o añadir la
identidad URI de entidades adicionales en una cabecera "Route"
existente. Los usos de esta funcionalidad son muy numerosos.
Permite por ejemplo que la primera entidad contactada de la red
añada en la cabecera "Route" la identidad de la entidad
responsable de la gestión de los servicios asignados al usuario de
la entidad emisora de la petición, con el fin de garantizar que la
petición pase por esta entidad. Las entidades responsables de la
gestión de los servicios se conocen con el nombre de servidores de
aplicación AS ("Application Server").
Las entidades SIP intermedias atravesadas por la
petición inicial que desean permanecer en el camino de señalización
insertan su identidad en una cabecera
"Record-Route" de la petición inicial antes de
transferirla al siguiente nodo.
Las identidades presentes en la cabecera
"Record-Route" durante el paso de la petición
inicial se retoman en la cabecera "Route" de las peticiones
subsiguientes. El encaminamiento de estas peticiones se realiza del
siguiente modo. Una entidad SIP intermedia que recibe una petición
subsiguiente SIP procede a su análisis. Si la petición contiene una
cabecera "Route", entonces considera la primera entidad SIP
presente en esta cabecera como la identidad a la cual debe hacer
llegar la petición. En caso contrario, considera la entidad presente
en la cabecera "Request-URI" como la entidad a
la cual debe hacer llegar la cabecera.
Durante el paso de una petición SIP, cada
entidad atravesada añade su dirección en una cabecera denominada
"Vía". De este modo, esta cabecera acumula de manera ordenada
todas las direcciones de las entidades SIP atravesadas incluso la
dirección de la entidad emisora de la petición.
Cuando una entidad genera una respuesta a una
petición, pudiendo esta entidad ser la entidad destinataria de la
petición o una entidad intermedia, inserta en la misma una cabecera
"Vía" que contiene las direcciones recibidas en el campo
"Vía" de la petición conservando el mismo orden. Cada entidad
recibe esta respuesta, y si decide transferirla al siguiente nodo,
la envía a la dirección que figura en primer lugar en la cabecera
"Vía" de esta respuesta.
De manera general, se puede dar el caso de que
unas entidades intermedias no sean accesibles en un momento dado,
por ejemplo en caso de avería del equipo o de sobrecarga. En tales
circunstancias, la red puede tener dos comportamientos: o bien se
rechaza un mensaje que debe transitar por tal entidad, o bien se
encuentra un camino alternativo para permitir que el mensaje sea,
sin embargo, transmitido hacia su destino. Este comportamiento
puede depender especialmente de las características de la entidad en
cuestión, a saber si es indispensable o no, y del tipo de mensaje
de señalización.
Por su parte, el protocolo SIP no ofrece
generalmente esta alternativa y no autoriza más que la primera
solución, es decir el rechazo del mensaje.
De este modo cuando una entidad intermedia
determina que la primera entidad SIP presente en la cabecera
"Route" de una petición no es accesible, entonces puede enviar
una respuesta de fallo a la entidad emisora, incluso si hubiese
sido preferible hacer transitar la petición hasta el destino
evitando esta entidad intermedia inaccesible, con riesgo de no
beneficiarse de los tratamientos que hubiese debido efectuar.
Del mismo modo, cuando una entidad intermedia
decide transmitir una respuesta SIP al siguiente nodo, si la
entidad SIP cuya dirección es la primera en la cabecera "Vía"
de esta respuesta no es accesible, entonces detiene el envío de
esta respuesta y puede incluso anular la transacción que corresponde
a esta respuesta, incluso si hubiese sido preferible hacer
transitar esta respuesta hasta el destino evitando esta entidad
intermedia inaccesible. El documento WO 2005/077014 describe un
procedimiento de encaminamiento de un mensaje SIP en una red de
telecomunicaciones.
Igualmente, existe la necesidad de una técnica
que permita evitar el rechazo de un mensaje cuando una entidad
intermedia situada en un camino de señalización del mensaje no esté
disponible.
La invención responde a esta necesidad
proponiendo un procedimiento de encaminamiento en una red de
telecomunicaciones de un mensaje SIP destinado a ser encaminado a
través de las entidades intermedias que constituyen nodos de un
camino de señalización, relevante porque dicho procedimiento
comprende una etapa de elusión de al menos una entidad intermedia
susceptible de ser eludida en caso de indisponibilidad, realizándose
dicha etapa de elusión por supresión de la identidad de dicha
entidad intermedia a eludir en una cabecera de un mensaje SIP que
contiene la lista de las identidades de las entidades a
atravesar.
La invención presenta por lo tanto la ventaja de
permitir el tránsito de un mensaje SIP hasta su destino incluso si
no puede transitar por una entidad intermedia indicada por la
cabecera "Route" o "Vía". Esta funcionalidad es de gran
utilidad cuando las funciones proporcionadas por la entidad
inaccesible no son primordiales para el buen funcionamiento del
sistema y cuando es preferible que la petición o la respuesta
transite hasta su destino evitando esta entidad en vez de
rechazarla.
De manera ventajosa, el procedimiento de
encaminamiento según la invención comprende una etapa destinada a
determinar si una entidad intermedia es susceptible de ser eludida
en caso de indisponibilidad.
Según una primera realización, dicha etapa de
determinación se lleva a cabo por una entidad mediante un dato
local que indica si dicha entidad intermedia es susceptible de ser
eludida.
Según una segunda realización, dicha etapa de
determinación se lleva a cabo por una entidad consultando una base
de datos externa que indica si dicha entidad intermedia es
susceptible de ser eludida.
Según una tercera realización, dicha etapa de
determinación se lleva a cabo por inserción en una cabecera de
encaminamiento de dicho mensaje SIP de un indicador de elusión de
dicha entidad intermedia susceptible de ser eludida.
Se observará que la invención no presenta
ninguna divergencia importante respecto del protocolo SIP. No
necesita en efecto la implementación de un funcionamiento
particular más que mediante la entidad intermedia que aplica el
procedimiento objeto de la invención, pudiendo esta entidad
insertarse muy bien en medio de otras entidades según SIP y que
funcionan de manera habitual.
Según una realización de la invención relativa a
los mensajes de petición, dicha cabecera es la cabecera "Route"
de un mensaje SIP de petición emitido por una entidad emisora.
Según una primera aplicación de esta
realización, dicho indicador de elusión de dicha entidad intermedia
se comunica a la entidad emisora de un mensaje de petición inicial
durante el registro de dicha entidad emisora en la red de
telecomunicaciones. Las cabeceras utilizadas son entonces
"Path" del mensaje REGISTER y
"Service-Route" del mensaje 200 OK de
respuesta al mensaje REGISTER.
Según una segunda aplicación de esta
realización, dicho indicador de elusión de dicha entidad intermedia
se comunica a la entidad emisora con anterioridad a la emisión de
un mensaje de petición inicial.
En una tercera aplicación de esta realización,
dicho indicador de elusión se inserta por dicha entidad intermedia
en la cabecera "Record-Route" al paso de un
mensaje de petición inicial, siendo dicha cabecera
"Record-Route" recibida por la entidad emisora
de dicho mensaje de petición inicial en un mensaje de respuesta a
dicha petición inicial y copiada de nuevo por dicha entidad emisora
en la cabecera "Route" de un mensaje de petición
subsiguiente.
En una cuarta aplicación de esta realización,
dicho indicador de elusión se inserta por una entidad intermedia
distinta a dicha entidad intermedia en la cabecera "Route" al
paso de un mensaje de petición inicial.
Según otra realización relativa a los mensajes
de respuesta, dicha cabecera es la cabecera "Vía" de un mensaje
SIP de petición.
En esta realización, la invención prevé que
dicho indicador de elusión se inserte por dicha entidad intermedia
en la cabecera "Vía" de un mensaje de petición. La cabecera
"Vía" se vuelve a copiar en los mensajes de respuesta por la
entidad que emite estas respuestas.
La invención se refiere igualmente a una entidad
intermedia que constituye un nodo de un camino de señalización para
el encaminamiento de un mensaje SIP en una red de
telecomunicaciones, importante porque dicha entidad intermedia es
capaz de insertar en una cabecera de encaminamiento de dicho mensaje
SIP un indicador de elusión cuando dicha entidad está en situación
de indisponibilidad.
La invención se refiere, además, a una entidad
que constituye un nodo de un camino de señalización para el
encaminamiento de un mensaje SIP en una red de telecomunicaciones,
relevante porque dicha entidad comprende medios para eludir una
entidad intermedia en caso de indisponibilidad de dicha entidad
intermedia, siendo dichos medios capaces de suprimir la identidad
de dicha entidad intermedia a eludir en una cabecera de un mensaje
SIP que contiene la lista de las identidades de las entidades a
atravesar.
La invención prevé igualmente que dicha entidad
comprenda medios para determinar si una entidad intermedia es
susceptible de ser eludida en caso de indisponibilidad.
La invención se refiere, por otra parte, a un
programa de ordenador que comprende instrucciones de programa para
la aplicación del procedimiento según la invención cuando dicho
programa es ejecutado por un ordenador.
Finalmente, la invención se refiere a una señal
que transporta un mensaje SIP que comprende en una cabecera de
encaminamiento un indicador de elusión de al menos una entidad
intermedia susceptible de ser eludida en caso de indisponibilidad
en un camino de señalización.
La descripción que sigue con respecto a los
dibujos anexos, dados a título de ejemplos no limitativos, hará que
se entienda correctamente en qué consiste la invención y cómo se
puede realizar.
La figura 1 es un esquema que ilustra un
procedimiento de encaminamiento de un mensaje de petición SIP en
una red con arquitectura IMS.
La figura 2 es un diagrama de encaminamiento
según la invención de mensajes de señalización entre diversas
entidades que constituyen los nodos de la red IMS de la figura
1.
En la figura 1 se representa un camino de
señalización de un mensaje de petición SIP emitido en una red IMS
por una entidad emisora A hacia una entidad destinataria B. Estas
entidades A y B son, por ejemplo, terminales telefónicos, fijos o
móviles, iniciando el terminal A una llamada telefónica con destino
al terminal B.
La arquitectura IMS se define actualmente para
aplicaciones de tipo telefonía, videofonía, presencia y mensajería
instantánea.
Entre los dos terminales A y B, la red de la
figura 1 comprende diversas entidades intermedias entre las cuales
se encuentran:
- Servidores mandatarios, o proxy,
P-CSF ("Proxy-Call Server Control
Function") PA y PB que son los primeros puntos de contacto de
los terminales A y B en la red IMS y que administran la interacción
con los recursos de la red de transporte.
- Un servidor S-CSCF
("Serving-Call Server Control Function") S que
administra el terminal A en la red IMS y, especialmente, los puntos
de disparo hacia servidores de aplicación con los cuales el usuario
del terminal A se ha abonado a uno o más servicios. Se atribuye el
servidor S-CSCF S al terminal A durante su registro
en la red
IMS.
IMS.
- Un servidor de aplicaciones AS ("Application
Server"), asociado al servicio considerado, por ejemplo el
servicio de "transferencia de llamada". El servidor de
aplicaciones AS contiene todas las informaciones relativas al
servicio suscrito.
\vskip1.000000\baselineskip
Cuando una entidad intermedia recibe un mensaje
SIP de petición inicial o subsiguiente que contiene una cabecera
"Route", o un mensaje SIP de respuesta que contiene una
cabecera "Vía", debe transferir este mensaje al siguiente nodo
del camino de señalización indicado en la cabecera "Route" o la
cabecera "Vía". Sin embargo, si no se puede contactar con esta
cabecera por no estar disponible, la entidad intermedia puede
decidir eludirlo y enviar el mensaje SIP al siguiente nodo en la
cabecera en cuestión. Si tampoco se puede acceder a este último, la
entidad intermedia también puede decidir eludirlo.
Entonces se deben distinguir tres
mecanismos:
- determinar que no se puede acceder a una
entidad,
- en caso de que no se pueda acceder a una
entidad, determinar si esta entidad se debe eludir o no,
- eludir una entidad presente en la cabecera
"Route" en caso de una petición SIP o en la cabecera "Vía"
en caso de una respuesta SIP.
\vskip1.000000\baselineskip
Una entidad SIP puede determinar que otra
entidad es inaccesible de dos maneras:
- Mediante un mecanismo de detección de
actividad ("Keep alive") a nivel de la capa física de
transporte entre las dos entidades. Se pueden mencionar, por
ejemplo, los mensajes Hello que los terminales envían periódicamente
para indicar su presencia en la red. Si un terminal ya no emite tal
mensaje, se considera como no disponible.
- Emisión de un mensaje de fallo por la capa
física de transporte durante la tentativa de transmisión de la
petición o de la respuesta SIP.
\vskip1.000000\baselineskip
Después de haber determinado que otra entidad no
está disponible, una entidad intermedia debe saber si esta otra
entidad se puede eludir o no en función del carácter indispensable o
no del paso del mensaje SIP por la entidad no disponible. Por
ejemplo, la función "transferencia de llamada" no es
indispensable para el establecimiento y el mantenimiento de una
llamada telefónica entre los terminales A y B. Igualmente, en el
caso en el que el servidor de aplicaciones AS encargado de esta
función se vuelve no disponible, debe poder ser eludido por los
mensajes SIP de petición o de respuesta.
La determinación por una primera entidad de si
otra entidad no accesible deber ser eludida o no se puede realizar
de diversas formas.
Según un primer método, la primera entidad
dispone de un dato local que le permite saber si la entidad no
accesible se puede eludir o no en un contexto dado. Por ejemplo, el
terminal A contiene un dato que le permite eludir el servidor proxy
PA en caso de no disponibilidad.
Según un segundo método, la primera entidad
consulta un servidor o una base de datos externa para obtener esta
misma información.
La invención propone también otro método según
el cual la información relativa al hecho de saber si la entidad no
accesible se puede eludir si no es accesible se asocia a la
identidad de esta entidad en la cabecera "Route" o "Vía"
del mensaje SIP en cuestión. Esta información queda contenida en un
nuevo parámetro del URI de la entidad no disponible, denominado
indicador de elusión o "bypass" en lo sucesivo. El parámetro
"bypass" puede adoptar por ejemplo los siguientes valores:
"sí" ("yes"), "no". La ausencia de este parámetro
significa que esta extensión del URI no se puede aplicar.
En lo relativo a las respuestas SIP, se puede
añadir este parámetro mediante la entidad no accesible durante la
inserción de su URI en la cabecera "Vía" de la petición
correspondiente.
En lo relativo a las peticiones, el indicador de
elusión "bypass" se puede insertar en el URI de la entidad no
accesible de varias maneras:
* Durante la fase de registro de la entidad
emisora en la red, el URI de la entidad intermedia mejorado con el
parámetro "bypass" se inserta en la cabecera "Path" del
mensaje REGISTER o la cabecera "Service-Route"
en el mensaje 200 OK de respuesta al mensaje REGISTER.
La cabecera "Path" se utiliza durante la
fase de registro de un terminal para registrar el camino en forma
de una lista de URIs para alcanzar este terminal. Esta información
se utiliza a continuación por el servidor proxy
S-CSCF que ha registrado este terminal para indicar,
en la cabecera "Route" peticiones iniciales que se destinan al
terminal, permitiendo el camino de señalización alcanzar este
terminal.
La cabecera "Service-Route"
se utiliza para registrar el camino que permite alcanzar el servidor
proxy S-CSCF S que administra los servicios del
usuario. Este camino se inserta a continuación en la cabecera
"Route" de las peticiones iniciales emitidas por el terminal
registrado con el fin de que estas peticiones sean encaminadas
hacia el S-CSCF. La cabecera
"Service-Route" se inserta en el mensaje 200 OK
de aceptación del registro, en respuesta a la petición REGISTER
emitida por el proxy que ha registrado este terminal.
* El indicador de elusión "bypass" puede
estar presente en URIs que constituyen la cabecera "Route"
cuando estos últimos son predeterminados. Estos URIs son añadidos
por la entidad SIP emisora de la petición inicial. Por ejemplo, el
terminal A se puede configurar para insertar en la cabecera
"Route" URIs de entidades predeterminadas que se le han
comunicado previamente a la emisión del mensaje de petición
inicial.
* El URI de la entidad intermedia, completado
con el indicador de elusión "bypass", se inserta mediante dicha
entidad intermedia en la cabecera
"Record-Route" al paso de un mensaje de
petición inicial. Esta cabecera "Record-Route"
es recibida a continuación por la entidad emisora del mensaje de
petición inicial en un mensaje de respuesta a la petición inicial y
se vuelve a copiar mediante la entidad emisora en la cabecera
"Route" de un mensaje de petición subsiguiente.
* El indicador de elusión "bypass" se
inserta en la cabecera "Route" mediante una entidad intermedia,
distinta de la entidad intermedia en cuestión, al paso de un
mensaje de petición inicial.
Se apreciará que el parámetro "bypass" se
puede mejorar con otros valores que permiten tener en cuenta el
contexto en el cual se recibe el mensaje y el tipo de mensaje. Por
ejemplo:
- message Type: la entidad no se puede
eludir más que si se trata de un mensaje dado por este
parámetro,
- earlyDialog: la entidad no se puede
eludir más que si el mensaje en cuestión se recibe en un diálogo
SIP anticipado,
- confirmDialog: la entidad no se puede
eludir más que si el mensaje en cuestión se recibe en un diálogo
SIP confirmado.
\vskip1.000000\baselineskip
Las definiciones del diálogo SIP confirmado y
del diálogo SIP anticipado se ofrecen en la recomendación
RFC3261.
Durante la emisión de un mensaje SIP de
petición, si una entidad decide eludir una entidad intermedia cuyo
URI es el primero en la cabecera "Route", debe suprimir el URI
de esta entidad intermedia de la cabecera "Route". Ésta aplica
a continuación a la petición así modificada los procedimientos de
encaminamiento estándar definidos en el protocolo SIP. Esta
operación se puede repetir si el siguiente nodo en el camino de
señalización definido por la cabecera "Route" es también
inaccesible. De este modo, se pueden eludir diversos nodos a la
vez.
Igualmente, durante la emisión de un mensaje SIP
de respuesta, si una entidad decide eludir una entidad intermedia
cuyo URI es el primero en la cabecera "Vía", debe suprimir el
URI de esta entidad intermedia de la cabecera "Vía". Después
aplica a la respuesta así modificada los procedimientos de
encaminamiento estándar en el protocolo SIP. Esta operación se
puede repetir si el siguiente nodo en el camino de señalización
definido por la entidad "Vía" es también inaccesible. De este
modo se pueden eludir varios nodos a la vez.
A continuación se va a presentar una ilustración
de la invención en referencia a la figura 2, que realiza el
servicio de "transferencia de llamada" en el caso de una
arquitectura IMS. La transferencia de llamada se puede invocar en
cualquier momento de la llamada por el usuario abonado a este
servicio, en representación de la entidad emisora.
El mecanismo de invocación de los servidores de
aplicaciones AS, actualmente definido por el 3GPP, no permite la
invocación de un AS más que en la primera petición que inicia la
sesión o la llamada. De este modo, puesto que el servidor de
aplicaciones AS de transferencia de llamada debe poder intervenir en
cualquier momento de la llamada, este último ha de ser invocado e
insertado en el camino de señalización SIP para cualquier llamada
que implique un abonado al servicio de transferencia desde el inicio
de la llamada. Con el fin de permitir que las llamadas que pasan
por este servidor sigan siendo transmitidas normalmente en el caso
en el que ya no está disponible, este último añade el parámetro
"bypass = yes" en su URI antes de insertarlo en la cabecera
"Record-Route" de la petición inicial. De este
modo, si este servidor de aplicaciones AS se avería en el
transcurso del establecimiento de la llamada o una vez establecida
la llamada, el S-CSF S lo eludirá.
1.- A envía el mensaje de petición INVITE al
P-CSCF de A, PA, al cual está vinculado, para
iniciar una llamada hacia B. Este mensaje contiene en la cabecera
"Route" el URI del S-CSCF S encargado de
ejecutar los servicios de A así como el URI del proxy PA. La
entidad PA es la entidad intermedia que forma parte del camino de
señalización entre el terminal A y el S-CSCF S.
2.- El P-CSCF PA suprime su URI
de la cabecera "Route" y a continuación envía la petición al
S-CSCF S cuyo URI se ha convertido en el primero de
la cabecera después de haber añadido la cabecera
"Record-Route" que contiene su URI para que
pueda recibir las peticiones subsiguientes.
3.- El S-CSCF S determina que A
está abonado al servicio de transferencia de llamada y decide
invocar la entidad AS encargada de proporcionar este servicio. El
S-CSCF S añade el URI del AS "transfert"
seguido de su propio URI, con el fin de que la petición vuelva
hacia S después de su paso por el AS "transfert", en la
cabecera "Route" de la petición INVITE antes de transferirla
al AS "transfert".
4.- EL AS "transfert" añade su URI en la
cabecera "Record-Route" para permanecer en el
camino de señalización de esta llamada y poder proporcionar el
servicio de transferencia en el caso en que se invoca este último
por A, y reenvía la petición INVITE al S-CSCF S cuyo
URI es el siguiente en la cabecera "Route". El URI del AS
"transfert" contiene el parámetro "bypass = yes" con el
fin de indicar que este AS se puede eludir si se vuelve no
accesible.
5.- El S-CSCF S añade su URI en
la cabecera "Record-Route" antes de enviar el
mensaje de petición INVITE al P-CSCF de B, PB al
cual están vinculado B.
6.- El P-CSCF PB añade su URI en
la cabecera "Record-Route" antes de enviar la
petición INVITE a B.
7, 8, 9, 10, 11 y 12-. B acepta la llamada de A
enviando un mensaje de respuesta 200 OK. Esta respuesta se encamina
hasta A siguiendo el camino inverso atravesado por la petición
INVITE apilado en la cabecera "Vía" durante el paso de la
petición INVITE. Esta respuesta contiene la cabecera
"Record-Route" que ha recibido B en el mensaje
INVITE para de este modo indicar a A las entidades intermedias de la
llamada.
13, 14, 15, 16, 17, 18.- A acusa recibo de la
respuesta 200 OK enviando la petición ACK. Esta petición sigue el
camino apilado en la cabecera "Record-Route"
durante el paso de la petición INVITE inicial. A inserta la
cabecera "Route" en la petición ACK que contiene los URIs
recibidos en la cabecera "Record-Route" de la
respuesta SIP 200 OK a la petición INVITE. La respuesta 200 OK
puede ir precedida por otras respuestas provisionales,
especialmente la respuesta 180 "Ringing" que indica que se ha
avisado a B. Estas respuestas así como la cabecera "Route" de
la petición ACK y la cabecera "Vía" de la respuesta 200 OK no
se presentan en este diagrama con el fin de simplificarlo.
19.- B envía un mensaje de petición
re-INVITE con destino a A. Esta petición se puede
enviar para renegociar los parámetros de la sesión de medios, tales
como por ejemplo cambios de codecs, o para, por ejemplo, refrescar
la sesión establecida.
20.- El P-CSCF PB encamina la
petición re-INVITE hacia el S-CSCF S
basándose en la cabecera "Route".
21.- El S-CSCF S determina que
el AS "transfert" ya no es accesible y decide eludirlo ya que
el URI de este AS recibido en la cabecera "Route" contiene el
parámetro "bypass = yes". Por esto, suprime el URI del AS
"transfert" así como su URI de la cabecera "Route", y a
continuación vuelve a aplicar los procedimientos de encaminamiento
a esta petición re-INVITE así modificada: envía la
petición re-INVITE al P-CSCF PA cuyo
URI se encuentra el primero en la cabecera "Route".
22.- El P-CSCF PA prolonga la
petición re-INVITE a A.
23, 24, 25 y 26.- A acepta la petición
re-INVITE enviando la respuesta 200 OK. Esta
respuesta sigue el camino inverso atravesado por la petición
re-INVITE.
27, 28, 29, 30. B acusa recibo de esta respuesta
200 OK mediante la petición ACK. Esta petición se encamina del
mismo modo que la petición re-INVITE: se elude el AS
"transfert".
Claims (12)
1. Procedimiento de encaminamiento en una red de
telecomunicaciones de un mensaje SIP (Session Initiation Protocol)
destinado a encaminarse a través de entidades intermedias que
constituyen nodos de un camino de señalización,
caracterizado porque comprende una etapa de elusión de al
menos una entidad intermedia susceptible de ser eludida en caso de
no disponibilidad, realizándose dicha etapa de elusión por supresión
de la identidad URI (Uniform Resource Identifier) de dicha entidad
intermedia a eludir en una cabecera "Route" o "Vía" de un
mensaje SIP que contiene la lista de las identidades de las
entidades a atravesar.
2. Procedimiento según la reivindicación 1, que
comprende una etapa destinada a determinar si una entidad
intermedia es susceptible de ser eludida en caso de no
disponibilidad.
3. Procedimiento según la reivindicación 2, en
el cual dicha etapa de determinación se lleva a cabo por una
entidad por medio de un dato local que indica si dicha entidad
intermedia es susceptible de ser eludida.
4. Procedimiento según la reivindicación 2, en
el cual dicha etapa de determinación se lleva a cabo por una
entidad consultando una base de datos externa que indica si dicha
entidad intermedia es susceptible de ser eludida.
5. Procedimiento según la reivindicación 2, en
el cual dicha etapa de determinación se lleva a cabo por inserción
en una cabecera de encaminamiento de dicho mensaje SIP de un
indicador de elusión "bypass" de dicha entidad intermedia
susceptible de ser eludida.
6. Procedimiento según la reivindicación 5,
caracterizado porque dicho indicador de elusión de dicha
entidad intermedia se comunica a la entidad emisora de un mensaje
de petición inicial durante el registro de dicha entidad emisora en
la red de telecomunicaciones.
7. Procedimiento según la reivindicación 6,
caracterizado porque dicho indicador de elusión de dicha
entidad intermedia se comunica a la entidad emisora previamente a
la emisión de un mensaje de petición inicial.
8. Entidad intermedia que constituye un nodo de
un camino de señalización para el encaminamiento de un mensaje SIP
(Session Initiation Protocol) en una red de telecomunicaciones,
caracterizada porque dicha entidad intermedia es capaz de
insertar en una cabecera de encaminamiento de dicho mensaje SIP un
indicador de elusión cuando dicha entidad está en situación de no
disponibilidad.
9. Entidad que constituye un nodo de un camino
de señalización para el encaminamiento de un mensaje SIP (Session
Initiation Protocol) en una red de telecomunicaciones,
caracterizada porque dicha entidad comprende medios para
eludir una entidad intermedia en caso de no disponibilidad de dicha
entidad intermedia, capaces de suprimir la identidad URI (Uniform
Resource Identifier) de dicha entidad intermedia a eludir en una
cabecera "Route" o "Vía" de un mensaje SIP que contiene
la lista de las identidades de las entidades a atravesar.
10. Entidad según la reivindicación 9, que
comprende medios para determinar si una entidad intermedia es
susceptible de ser eludida en caso de no disponibilidad.
11. Programa de ordenador que comprende
instrucciones de programa para la aplicación del procedimiento según
una cualquiera de las reivindicaciones 1 a 7 cuando dicho programa
es ejecutado por un ordenador.
12. Señal que transporta un mensaje SIP (Session
Initiation Protocol) que comprende en una cabecera de encaminamiento
un indicador de elusión "bypass" de al menos una entidad
intermedia susceptible de ser eludida en caso de no disponibilidad
en un camino de señalización.
Applications Claiming Priority (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| FR0654297 | 2006-10-16 | ||
| FR0654297A FR2907294A1 (fr) | 2006-10-16 | 2006-10-16 | Procede de routage d'un message sip en cas d'indisponibilite de noeuds intermediaires |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| ES2345410T3 true ES2345410T3 (es) | 2010-09-22 |
Family
ID=38328581
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| ES07858586T Active ES2345410T3 (es) | 2006-10-16 | 2007-10-15 | Procedimiento de encaminamiento de un mensaje sip en caso de no disponibilidad de nodos intermedios. |
Country Status (9)
| Country | Link |
|---|---|
| US (1) | US8964524B2 (es) |
| EP (1) | EP2080339B1 (es) |
| JP (1) | JP5247709B2 (es) |
| CN (1) | CN101529851B (es) |
| AT (1) | ATE467300T1 (es) |
| DE (1) | DE602007006334D1 (es) |
| ES (1) | ES2345410T3 (es) |
| FR (1) | FR2907294A1 (es) |
| WO (1) | WO2008047037A1 (es) |
Families Citing this family (13)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| FR2907294A1 (fr) | 2006-10-16 | 2008-04-18 | France Telecom | Procede de routage d'un message sip en cas d'indisponibilite de noeuds intermediaires |
| IL189530A0 (en) | 2007-02-15 | 2009-02-11 | Marvell Software Solutions Isr | Method and apparatus for deep packet inspection for network intrusion detection |
| JP4924124B2 (ja) * | 2007-03-16 | 2012-04-25 | 富士通株式会社 | Ｓｉｐサーバ |
| US8392581B2 (en) * | 2009-06-09 | 2013-03-05 | Verizon Patent And Licensing Inc. | Intelligent IMS SIP session setup optimization |
| CN101651991B (zh) * | 2009-08-27 | 2012-04-04 | 华为技术有限公司 | 呼叫控制方法和呼叫控制装置 |
| EP2504966B1 (en) | 2009-11-26 | 2013-08-14 | Telefonaktiebolaget LM Ericsson (publ) | Method, system and network nodes for performing a sip transaction in a session initiation protocol based communications network |
| EP2622814B1 (en) * | 2010-10-01 | 2015-06-24 | Telefonaktiebolaget L M Ericsson (PUBL) | Service based release of a subscriber registrar server from a signalling path in an internet protocol communication network. |
| US10122735B1 (en) * | 2011-01-17 | 2018-11-06 | Marvell Israel (M.I.S.L) Ltd. | Switch having dynamic bypass per flow |
| CN103685234B (zh) * | 2013-11-14 | 2017-06-13 | 大唐移动通信设备有限公司 | Ims媒体业务数据处理的方法及装置 |
| KR102147246B1 (ko) * | 2014-05-26 | 2020-08-24 | 삼성전자 주식회사 | 통신 네트워크에서 성능 개선을 위한 방법 및 장치 |
| US10469538B2 (en) * | 2016-03-31 | 2019-11-05 | Avaya Inc. | Call preservation for multiple legs of a call when a primary session manager fails |
| US10193931B2 (en) | 2016-03-31 | 2019-01-29 | Avaya Inc. | Session initiation protocol call preservation based on a network failure |
| US20230130424A1 (en) * | 2021-10-22 | 2023-04-27 | Oracle International Corporation | Methods, systems, and computer readable media for triggering a session initiation protocol (sip) re-invite message |
Family Cites Families (21)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JPH03230643A (ja) * | 1990-02-05 | 1991-10-14 | Mitsubishi Electric Corp | パケット交換網におけるルーチング方式 |
| US6842430B1 (en) * | 1996-10-16 | 2005-01-11 | Koninklijke Philips Electronics N.V. | Method for configuring and routing data within a wireless multihop network and a wireless network for implementing the same |
| US6650644B1 (en) * | 1998-05-20 | 2003-11-18 | Nortel Networks Limited | Method and apparatus for quality of service translation |
| JP3196843B2 (ja) * | 1998-12-02 | 2001-08-06 | 日本電気株式会社 | ファイバ・チャネル仲裁型ループにおける障害ポートの検出／排除システム及びその検出／排除方法 |
| US6678264B1 (en) * | 1999-06-30 | 2004-01-13 | Nortel Networks Limited | Establishing connections with a pre-specified quality of service across a communication network |
| JP3356145B2 (ja) * | 1999-12-22 | 2002-12-09 | 日本電気株式会社 | 伝送路障害救済方法、伝送路障害救済システム、記憶媒体およびルータ |
| US6925645B2 (en) * | 2000-12-29 | 2005-08-02 | Webex Communications, Inc. | Fault tolerant server architecture for collaborative computing |
| CA2408766A1 (en) * | 2001-10-17 | 2003-04-17 | Telecommunications Research Laboratory | Content delivery network bypass system |
| US6718021B2 (en) * | 2002-02-19 | 2004-04-06 | Sbc Properties, L.P. | Method and system for presenting customized call alerts in a service for internet caller identification |
| JP2003249949A (ja) * | 2002-02-22 | 2003-09-05 | Nippon Telegr & Teleph Corp <Ntt> | ネットワーク経路選択方法、ルータ及びそのプログラム並びに情報記録媒体 |
| JP4406604B2 (ja) * | 2002-06-11 | 2010-02-03 | アシシュ エイ パンドヤ | Ｔｃｐ／ｉｐ、ｒｄｍａ、及びｉｐストレージアプリケーションのための高性能ｉｐプロセッサ |
| JP3761509B2 (ja) * | 2002-11-25 | 2006-03-29 | 日本電気通信システム株式会社 | Ｉｐ網におけるｓｉｐサーバ障害検出方式 |
| JP3990272B2 (ja) * | 2002-12-20 | 2007-10-10 | 富士通株式会社 | メーリングリスト管理システムおよび電子メール送受信装置 |
| US7355968B2 (en) * | 2003-09-30 | 2008-04-08 | International Business Machines Corporation | Method of stateless group communication and repair of data packets transmission to nodes in a distribution tree |
| US7694127B2 (en) * | 2003-12-11 | 2010-04-06 | Tandberg Telecom As | Communication systems for traversing firewalls and network address translation (NAT) installations |
| US7110780B2 (en) * | 2004-02-06 | 2006-09-19 | Tekelec | Methods and systems for automatically bypassing short message service center for short message service (SMS) messages destined for predetermined short message peer-to-peer (SMPP) destinations |
| WO2006021988A1 (ja) * | 2004-08-24 | 2006-03-02 | Mitsubishi Denki Kabushiki Kaisha | 中継装置及びネットワーク |
| JP4428184B2 (ja) * | 2004-10-04 | 2010-03-10 | 株式会社日立製作所 | 検索テーブル高速切替方式およびパケット転送装置 |
| JP2006215977A (ja) * | 2005-02-07 | 2006-08-17 | Sumitomo Electric Ind Ltd | 交通管制システム |
| FR2907294A1 (fr) | 2006-10-16 | 2008-04-18 | France Telecom | Procede de routage d'un message sip en cas d'indisponibilite de noeuds intermediaires |
| IL189530A0 (en) * | 2007-02-15 | 2009-02-11 | Marvell Software Solutions Isr | Method and apparatus for deep packet inspection for network intrusion detection |
-
2006
- 2006-10-16 FR FR0654297A patent/FR2907294A1/fr active Pending
-
2007
- 2007-10-15 CN CN200780038548.3A patent/CN101529851B/zh active Active
- 2007-10-15 EP EP07858586A patent/EP2080339B1/fr active Active
- 2007-10-15 AT AT07858586T patent/ATE467300T1/de not_active IP Right Cessation
- 2007-10-15 WO PCT/FR2007/052159 patent/WO2008047037A1/fr active Application Filing
- 2007-10-15 ES ES07858586T patent/ES2345410T3/es active Active
- 2007-10-15 JP JP2009531892A patent/JP5247709B2/ja not_active Expired - Fee Related
- 2007-10-15 US US12/445,895 patent/US8964524B2/en not_active Expired - Fee Related
- 2007-10-15 DE DE602007006334T patent/DE602007006334D1/de active Active
Also Published As
| Publication number | Publication date |
|---|---|
| WO2008047037A1 (fr) | 2008-04-24 |
| EP2080339A1 (fr) | 2009-07-22 |
| CN101529851A (zh) | 2009-09-09 |
| JP2010507269A (ja) | 2010-03-04 |
| DE602007006334D1 (de) | 2010-06-17 |
| ATE467300T1 (de) | 2010-05-15 |
| US8964524B2 (en) | 2015-02-24 |
| FR2907294A1 (fr) | 2008-04-18 |
| EP2080339B1 (fr) | 2010-05-05 |
| JP5247709B2 (ja) | 2013-07-24 |
| CN101529851B (zh) | 2013-01-02 |
| US20100238928A1 (en) | 2010-09-23 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| ES2345410T3 (es) | Procedimiento de encaminamiento de un mensaje sip en caso de no disponibilidad de nodos intermedios. | |
| ES2346563T3 (es) | Gestion de interfases de multiples usuarios en un subsistema de multimedios ip. | |
| JP4700105B2 (ja) | Ｉｐマルチメディアサブシステム（ｉｍｓ）おける呼転送 | |
| US9648048B2 (en) | Message handling in an IP multimedia subsystem | |
| US8325707B2 (en) | Session initiation from application servers in an IP multimedia subsystem | |
| ES2317341T3 (es) | Gestion de mensajes en un subsistema multimedia ip. | |
| WO2008049455A1 (en) | Methods and apparatuses for transporting signalling connectivity status information relating to the signalling connection between a terminal and p-cscf in ims | |
| US9420018B2 (en) | End-to-end address transfer | |
| JP2010535451A (ja) | Ｓｅｓｓｉｏｎｉｎｉｔｉａｔｉｏｎｐｒｏｔｏｃｏｌベースのネットワークでの複数のアプリケーション・サーバを用いる呼転送 | |
| EP3146691B1 (en) | Maintaining optimal media routing | |
| US9692835B2 (en) | Method and apparatuses for the provision of network services offered through a set of servers in an IMS network | |
| US20120202494A1 (en) | Method and Apparatus in a Telecommunications Network | |
| US20150326734A1 (en) | Sbc for cloud environment and method for operating sbc | |
| Jenkins et al. | IA for R4 ISC Interface | |
| Walker | Implementation Agreement for ISC Interface | |
| RU2417544C2 (ru) | Способы и устройства для передачи информации о состоянии сигнального соединения, относящейся к сигнальному соединению между терминалом и модулем посреднической функции управления сеансом/вызовом (p-cscf) в мультимедийной подсистеме интернет-протокола (ims) |