ES2958755T3 - Método de control de una comunicación que comprende múltiples transacciones - Google Patents
Método de control de una comunicación que comprende múltiples transacciones Download PDFInfo
- Publication number
- ES2958755T3 ES2958755T3 ES18736975T ES18736975T ES2958755T3 ES 2958755 T3 ES2958755 T3 ES 2958755T3 ES 18736975 T ES18736975 T ES 18736975T ES 18736975 T ES18736975 T ES 18736975T ES 2958755 T3 ES2958755 T3 ES 2958755T3
- Authority
- ES
- Spain
- Prior art keywords
- transaction
- communication
- called
- sip
- message
- 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
- 238000004891 communication Methods 0.000 title claims abstract description 56
- 238000000034 method Methods 0.000 title claims abstract description 49
- 238000004590 computer program Methods 0.000 claims description 11
- 230000000977 initiatory effect Effects 0.000 claims description 3
- 238000013500 data storage Methods 0.000 claims 1
- 230000004044 response Effects 0.000 description 10
- 230000008901 benefit Effects 0.000 description 6
- 230000011664 signaling Effects 0.000 description 6
- 230000006870 function Effects 0.000 description 5
- 230000007246 mechanism Effects 0.000 description 5
- 230000009471 action Effects 0.000 description 4
- 230000004913 activation Effects 0.000 description 4
- 230000003287 optical effect Effects 0.000 description 2
- 230000001755 vocal effect Effects 0.000 description 2
- 230000005540 biological transmission Effects 0.000 description 1
- 238000004364 calculation method Methods 0.000 description 1
- 230000008859 change Effects 0.000 description 1
- 230000000694 effects Effects 0.000 description 1
- 230000003993 interaction Effects 0.000 description 1
- 230000014759 maintenance of location Effects 0.000 description 1
- 230000007257 malfunction Effects 0.000 description 1
- 238000007726 management method Methods 0.000 description 1
- 238000004377 microelectronic Methods 0.000 description 1
- 230000004048 modification Effects 0.000 description 1
- 238000012986 modification Methods 0.000 description 1
- 230000006855 networking Effects 0.000 description 1
- 238000012545 processing Methods 0.000 description 1
- 238000013468 resource allocation Methods 0.000 description 1
- 238000012546 transfer Methods 0.000 description 1
Classifications
-
- 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]
-
- 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/1106—Call signalling protocols; H.323 and related
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L43/00—Arrangements for monitoring or testing data switching networks
- H04L43/08—Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters
- H04L43/0852—Delays
- H04L43/0864—Round trip delays
-
- 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]
-
- 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/1069—Session establishment or de-establishment
-
- 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/1073—Registration or de-registration
Landscapes
- Engineering & Computer Science (AREA)
- Multimedia (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Business, Economics & Management (AREA)
- General Business, Economics & Management (AREA)
- Environmental & Geological Engineering (AREA)
- Telephonic Communication Services (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
- Communication Control (AREA)
Abstract
La invención se refiere a un método de control de una comunicación entre dos dispositivos, donde el protocolo de dicha comunicación comprende al menos una transacción, denominada primera transacción, y al menos una transacción posterior, denominada segunda transacción. Dicho método comprende los siguientes pasos: uno de dichos dispositivos, denominado primer dispositivo, transmite, durante dicha primera transacción, al otro dispositivo, denominado segundo dispositivo, un retraso máximo aceptable entre el final de la primera transacción y el comienzo de dicha segunda transacción, así como una indicación explícita del tipo de mensaje que caracteriza dicho inicio de la segunda transacción; y dicho segundo dispositivo activa un temporizador para dicho retraso. La invención es aplicable a redes IMS. (Traducción automática con Google Translate, sin valor legal)
Description
DESCRIPCIÓN
Método de control de una comunicación que comprende múltiples transacciones
La presente invención hace referencia a las redes de comunicaciones de tipo IP ("Internet Protocol") y, en particular, a las redes IP capaces de aplicar protocolos de control de sesión avanzados. Las redes IP permiten la difusión de datos conversacionales como parte de servicios tales como "Voz sobre IP" (VoIP), "Uso compartido de contenidos" o "Mensajería instantánea".
Más concretamente, la presente invención hace referencia a los medios implementados en una red IP para aplicar una temporización a un conjunto de transacciones entre dos dispositivos cliente, o entre un dispositivo cliente y un servidor o incluso entre dos servidores, cuando estas transacciones están lógicamente vinculadas entre sí.
Estos "dispositivos cliente" pueden ser, por ejemplo, un terminal fijo o móvil, o una pasarela tanto residencial ("Residential Gatewayen inglés) como situada en una empresa. En aras de la brevedad, a continuación, se utilizará con frecuencia el término genérico "terminal de usuario", o "terminal" para abreviar, para referirse a estos diversos equipos.
Los protocolos avanzados de control de sesión convencionales, tales como el SIP (iniciales de las palabras inglesas"Session Initiation Protocol"que significan "Protocolo de Iniciación de Sesión"), utilizan los llamados mensajes de "señalización", que son mensajes que permiten a un terminal solicitar una conexión con otro terminal, o también mensajes que señalan que una línea telefónica está ocupada, o que el teléfono al que se llama está sonando, o incluso que un teléfono concreto está conectado a la red y puede ser localizado de una forma determinada.
El protocolo SIP fue definido por el IETF (InternetEngineering TaskForce)en el documento RFC 3261. Este protocolo permite el establecimiento, la modificación y la finalización de sesiones multimedia en una red utilizando el protocolo IP. El protocolo SIP fue ampliado posteriormente, en particular en el documento RFC 3265. Esta extensión define procedimientos de notificación de eventos.
El protocolo SIP se utiliza sobre todo en infraestructuras de tipo IMS (iniciales de las palabras inglesas"IP Multimedia Subsystem"que significan "Subsistema multimedia sobre IP"). IMS fue definido por los organismos de normalización 3GPP ("Third Generation Partnership Project')y TISPAN ("Telecommunications and Internet Converged Services and Protocols for Advanced Networking'). Se trata de una arquitectura de red introducida por el 3GPP para las redes móviles y, a continuación, adoptada por TISPAN para las redes fijas. Esta arquitectura permite el establecimiento y control dinámicos de sesiones multimedia entre dos clientes, así como la reserva de recursos a nivel de red para el transporte de flujos multimedia. Gracias a esta arquitectura, los operadores de red pueden aplicar fácilmente una política de gestión, ofrecer una calidad de servicio predeterminada y calcular los importes que se deben facturar a los clientes. Actualmente, el IMS permite acceder a los servicios de tipo telefonía, videotelefonía, presencia y mensajería instantánea, y también gestiona su interacción.
Por lo tanto, cuando un usuario quiere aprovechar los servicios que ofrece una red IMS, envía mensajes de señalización a la red, que pueden incluir, en particular, varios tipos de solicitudes.
En primer lugar, el dispositivo cliente del usuario debe, salvo excepciones (tales como determinadas llamadas de emergencia), registrarse en la red. Si la red es incapaz de establecer el vínculo entre este registro y un registro anterior (por ejemplo, tras un fallo de la red, o después de que el dispositivo cliente haya estado apagado durante más de un periodo de tiempo predeterminado), el registro se considera un registro inicial. Tras un registro inicial, el dispositivo cliente del usuario debe enviar periódicamente una solicitud a la red para confirmar que desea mantener su registro.
Para poder registrar los dispositivos cliente, las redes IMS incluyen uno o más servidores de registro, denominados "S-CSCF" (iniciales de las palabras inglesas"Serving-Call Server Control Function"que significan "Función de control del servidor de llamadas de servicio"), capaces (entre otras funciones) de gestionar el procedimiento de registro de los dispositivos conectados a la red.
Las redes IMS también comprenden uno o más servidores de interrogación, denominados "I-CSCF" (iniciales de las palabras inglesas" Interrogating-Call Server Control Function"que significan "Función de control de la sesión de llamada de interrogación"), que se suelen combinar físicamente con los servidores de registro S-CSCF para formar servidores de llamada llamados "I/S-CSCF" que, cuando se registra un dispositivo cliente, interrogan a un servidor de datos de abonado llamado "HSS" (iniciales de las palabras inglesas"Home SubscriberServer'que significan "Servidor de suscriptor doméstico"), con el fin de poder seleccionar un servidor S-CSCF con las características que se requieren obligatoriamente (y, en su caso, opcionalmente) para alcanzar el nivel de servicio suscrito por el usuario. Los servidores HSS contienen cada uno una base de datos de clientes, y por tanto son el equivalente en las redes IP de los servidores "HLR" ((iniciales de las palabras inglesas"Home Location Register"que significan "Registro de suscriptor doméstico") utilizados en las redes GSM. Cada servidor HSS contiene el "perfil" de un determinado número de dispositivos cliente de la red, comprendiendo este perfil su estado de registro, datos de autentificación y localización, y los servicios a los que tienen derecho.
En efecto, una vez que a un usuario se le ha asignado de este modo un servidor S-CSCF, puede utilizar un determinado número de servicios durante la sesión en curso. Puede tratarse, por ejemplo, de servicios ofrecidos automáticamente a todos los usuarios de la red IMS. También pueden ser servicios a los que este usuario se ha suscrito con el operador de red y que se ponen automáticamente a su disposición. Por último, pueden ser servicios que el usuario puede utilizar tras realizar una solicitud adecuada (SIP SUBSCRIBE).
Estos servicios incluyen aplicaciones audiovisuales como las mencionadas anteriormente. También puede consistir en suscribirse al estado de un recurso de la red, en cuyo caso se envían notificaciones de eventos (SIP NOTIFY) al dispositivo cliente en cuanto cambia el estado del recurso; por ejemplo, cuando el usuario de un dispositivo cliente tiene un buzón de voz en la red, se le puede informar cada vez que se ha grabado un mensaje en este buzón de voz; un usuario puede, del mismo modo, pedir que se le notifique el estado de grabación de su propio dispositivo cliente.
Las redes IMS también comprenden uno o más servidores denominados "P-CSCF" (iniciales de las palabras inglesas"Proxy-Call Server Control Function"que significa "Punto de entrada al subsistema IMS"). Para cada dispositivo cliente conectado a una red IMS, existe un servidor P-CSCF que actúa como entidad de conexión entre el núcleo de la red IMS y la red de acceso utilizada por este dispositivo cliente; de este modo, toda la señalización SIP intercambiada entre el dispositivo cliente por una parte y el servidor de interrogación I-CSCF o el servidor de registro S-CSCF por otra parte, pasa a través del servidor P-CSCF.
La presente invención hace referencia a situaciones en las que normalmente se espera una determinada transacción T2 tras una primera transacción T1. Una "transacción" se define por un conjunto de mensajes intercambiados entre un primer dispositivo de comunicación dado y un segundo dispositivo de comunicación dado, siendo el primer mensaje de dicho conjunto de un tipo dado. En muchos casos (pero no en todos los casos a los que se aplica la invención), estas transacciones lógicamente vinculadas comparten la misma referencia de llamada (el mismo "Call-Id" en el protocolo SIP).
Dichos "tipos" de mensajes pueden ser muy variados, por ejemplo una solicitud de registro (método "REGISTER" en SIP), una solicitud de suscripción (método "SUBSCRIBE" en SIP), una solicitud de notificación de evento (método "NOTIFY" en SIP), una solicitud para establecer una sesión (método "INVITE" en SIP), una solicitud para cancelar el establecimiento de una sesión (método "CANCEL" en SIP), una solicitud para modificar el estado de una sesión (método "UPDATE" en SIP), o una solicitud para finalizar una sesión (método "BYE" en SIP).
Aunque existen mecanismos de temporización normalizados específicos para una transacción determinada, no existe ningún mecanismo de control que permita aplicar una temporización a un conjunto de transacciones. Esto puede ser muy útil en diferentes casos de utilización, con el fin de evitar un mal funcionamiento, en cuyo caso podemos, por ejemplo, liberar recursos innecesarios, renovar una solicitud o activar acciones adicionales adecuadas.
A continuación, vamos a presentar sobre la base de varios ejemplos, la utilidad de un mecanismo de control de este tipo.
Consideraremos, de acuerdo con un primer ejemplo, ilustrado en lafigura 1, los intercambios de mensajes durante un procedimiento de registro.
En este ejemplo, la transacción T1 está representada por los intercambios F1/F2, la transacción T2 por los intercambios F3/F4. De acuerdo con el protocolo SIP, la transacción T2 debe permitir a Bob proporcionar el resultado del cálculo de autentificación utilizando los datos proporcionados por el servidor SIP en la etapa F2.
Sin embargo, una vez finalizada la transacción T1, el servidor SIP espera la transacción T2 durante cierto tiempo, pero no más; en efecto, el servidor SIP no conserva indefinidamente los datos temporales necesarios para la autentificación. Por lo tanto, existe un tiempo máximo de espera para la transacción T2, más allá del cual el servidor SIP no podrá tener en cuenta la solicitud de la etapa F3 porque los datos temporales se habrán borrado. Por lo tanto, las transacciones T1 y T2 están vinculadas por una temporización multitransacción gestionada por el servidor SIP.
Si Bob conociera el tiempo máximo de retención de los datos temporales en el servidor SIP, sabría que después de la expiración de esta temporización ya no debería enviar la solicitud de la etapa F3, sino repetir la etapa F1. Si, por el contrario, Bob no es consciente de este límite de tiempo y transmite la solicitud de la etapa F3 fuera de plazo, el servidor SIP responderá mediante un mensaje de error; a la inversa, si Bob, tras un cambio en el tipo de acceso, reinicia un procedimiento de registro completo transmitiendo la solicitud de la etapa F1 mientras el servidor espera la solicitud de la etapa F3, Bob corre el riesgo de que este intento de nuevo registro sea rechazado; en ambos casos, se pueden producir efectos secundarios más o menos controlados para Bob, como un retraso general en el registro, dificultades en la asignación de recursos IPsec (Internet Protocol Security) o TLS (Transport Layer Security), o incluso un bucle perpetuo.
Pueden surgir problemas similares en el caso de un procedimiento de autentificación con un servidor proxy (proxy SIP), en el que los mensajes de las etapas F1 y F3 son peticiones INVITE, y la respuesta de la etapa F2 es una solicitud de autentificación 407. Del mismo modo, el proxy SIP almacena temporalmente los datos suministrados en la respuesta de la etapa F2; transcurrido un cierto tiempo, la solicitud de la etapa F3 será rechazada por el proxy SIP.
De acuerdo con un segundo ejemplo ilustrado en lafigura2,se consideran los intercambios de mensajes durante un procedimiento de suscripción.
En este ejemplo, la transacción T1 (F1/F2, donde F1 es una etapa de transmisión de una solicitud SUBSCRIBE) conduce a una transacción T2 (F3/F4), que da el estado actual de la suscripción. Si el abonado no recibe la notificación de la etapa F3 al cabo de un cierto tiempo, sin duda se ha producido una incidencia; entonces hay que repetir el intento liberando la transacción T1 y lanzando una nueva solicitud SUBSCRIBE. Sin embargo, el notificador podría proporcionar esta indicación de límite de tiempo en la respuesta de la etapa F2.
De acuerdo con un tercer ejemplo ilustrado en lafigura 3, consideramos una secuencia de condiciones previas de acuerdo con el documento RFC 3312 (estas condiciones previas requieren de la parte de un participante en una comunicación que lleve a cabo, antes de entrar en sesión, uno de los mecanismos normalizados de reserva de recursos antes de iniciar una sesión). Los agentes SIP designados por A y B en esta figura pueden ser cada uno un terminal o un servidor.
En esta secuencia, varias transacciones dependen unas de otras:
- la transacción T1 está representada por los mensajes F1, F2, F7 y F10,
- la transacción T2 (F3/F4) se activa mediante la recepción de F2,
- la transacción T3 (F5/F6) se activa mediante la recepción de F2 y la reserva satisfactoria de recursos de red.
Se recuerda que de acuerdo con los estándares SIP, un mensaje PRACK es un acuse de recibo enviado en respuesta a una respuesta provisional. En este caso, este es el caso de los mensajes F3, F4, F8 y F9.
La ausencia de transacciones T2 o T3 equivale a un fallo en la reserva de recursos y, por tanto, a un fallo de la llamada. Sin embargo, en las normas actuales, no existe ninguna temporización que indique a B, por ejemplo, un tiempo máximo de espera para la etapa F5, más allá del cual B tiene derecho a abandonar el procedimiento y liberar recursos. Por ejemplo, si este procedimiento se utiliza para una llamada de voz sobre IP, la recepción por parte de A de este error señalado por B podría permitir a A cambiar inmediatamente la comunicación hacia el dominio del circuito.
De acuerdo con un cuarto ejemplo, ilustrado en lafigura 4,se considera el establecimiento de una comunicación multimedia utilizando el protocolo de transporte en tiempo real (RTP) (que permite el transporte de datos sujetos a restricciones de tiempo real, tales como flujos de medios de audio o vídeo) entre dos agentes SIP A y B.
La secuencia ilustrada en la figura 4 es la secuencia clásica para establecer una comunicación de este tipo. Puede ser deseable que la red no deje recursos disponibles indefinidamente para esta comunicación. Si, en la respuesta "200 OK" de la etapa F3, el agente B pudiera indicar un tiempo máximo del diálogo, el agente A podría finalizar la sesión con un BYE para liberar los recursos. Esta situación es probable que se produzca, por ejemplo, si falla el procedimiento de liberación de recursos a través de la red (debido a una pérdida de contexto, por ejemplo).
De acuerdo con un quinto ejemplo, ilustrado en lafigura5,se considera un servicio de anuncios de voz.
La secuencia ilustrada en la figura 5 es la secuencia clásica durante la cual un servidor SIP (por ejemplo, del tipo "Application Server", identificado como AS en la figura) ordena a un equipo especializado ("Media Resource Function", identificado como MRF en la figura) la difusión de un anuncio vocal hacia un cliente tercero (no representado). En este caso de utilización, suele ser conveniente limitar el tiempo de difusión del anuncio. Las transacciones iniciadas en las etapas F1 (INVITE) y F6 (BYE) están entonces vinculadas por este tiempo máximo de difusión.
En el caso general, es el servidor SIP el que controla este temporización, en relación con el estado de la sesión con el cliente tercero. Sin embargo, puede ser ventajoso difundir el valor de la temporización a la máquina de voz en la solicitud INVITE (F1). De este modo, si por cualquier motivo (por ejemplo, se reinicia el servidor o se produce un fallo en la red), la máquina vocal no recibe el BYE de la etapa F6, ésta podrá tomar las medidas oportunas (liberar recursos o transmitir un<b>Y<e>por iniciativa propia).
De acuerdo con un sexto ejemplo ilustrado en lafigura 6, se considera la activación de un servicio de reenvío sin respuesta entre dos agentes SIP A y B (donde, por ejemplo, el agente A es el servidor de aplicaciones telefónicas que está a cargo de un terminal B).
De la forma habitual, el agente A gestiona una temporización que le permite esperar a la posible desconexión del agente B antes de proceder al reenvío hacia un nuevo destino.
Normalmente, es el agente A el que emite la solicitud CANCEL (etapa F3) activando el fin del tono de llamada cuando expira el tiempo de espera. Sin embargo, puede resultar ventajoso difundir el valor de la temporización al agente B en la solicitud INVITE (etapa F1). De esta manera, si la llamada no resulta con la desconexión de la persona que llama y si, por cualquier razón (por ejemplo, el reinicio del servidor, o un fallo de red), la solicitud CANCEL (etapa F3) no es recibida por el agente B, este último puede tomar las medidas adecuadas (por ejemplo, detener el tono de llamada, o la transmisión de una respuesta negativa a la solicitud INVITE).
De acuerdo con un séptimo ejemplo, ilustrado en lafigura7,se considera una comunicación entre dos agentes SIP A y B, y una secuencia para poner la comunicación en espera.
Cuando se pone una llamada en espera, es aconsejable limitar el tiempo de puesta en espera. En este caso, las transacciones iniciadas en las etapas F1 y F3 están vinculadas.
Puede ser ventajoso difundir el valor de la temporización al agente B puesto en espera en el re-INVITE de la etapa F1. De esta manera, si no se libera el diálogo, ni se levanta la guardia después de un cierto límite de tiempo, es decir, no hay re-INVITE de acuerdo con la etapa F3 (ni BYE), el agente B podrá tomar las medidas apropiadas (por ejemplo, transmitir un BYE, o liberar recursos).
El documento WO 2016/185118 describe un método de control de una sesión relativa a un servicio.
El documento US 2003/0212912 describe un método para seleccionar un duración de tiempo en una asociación de seguridad entre un equipo de usuario y una entidad de control en un sistema de comunicación.
De acuerdo con un primer aspecto, la presente invención hace referencia por tanto a un método de control relativo a una comunicación entre dos dispositivos, en el que el protocolo de dicha comunicación comprende al menos una transacción, denominada primera transacción, y al menos una transacción posterior, denominada segunda transacción. Dicho método comprende las siguientes etapas:
- uno de dichos dispositivos, denominado primer dispositivo, transmite durante dicha primera transacción al otro dispositivo, denominado segundo dispositivo, un tiempo máximo aceptable entre el final de la primera transacción y el inicio de dicha segunda transacción, así como una indicación explícita del tipo de mensaje que caracteriza dicho inicio de la segunda transacción, y
- dicho segundo dispositivo activa un temporizador para dicho límite de tiempo.
- Téngase en cuenta (según se ilustra en los ejemplos anteriores) que, en funcionamiento normal, dependiendo de la aplicación prevista:
- el mensaje que caracteriza el inicio de la primera transacción y el mensaje que caracteriza el inicio de la segunda transacción pueden ser del mismo tipo o de tipos diferentes, y
- se supondrá que el mensaje que caracteriza el inicio de la segunda transacción ha sido enviado por dicho primer dispositivo o por dicho segundo dispositivo.
Gracias a estas disposiciones, si, por una razón u otra, el mensaje que caracteriza el inicio de la segunda transacción no se transmite dentro de dicho límite de tiempo, el segundo dispositivo podrá aplicar eventualmente un tratamiento adecuado sin esperar. Este tratamiento que debe aplicar el segundo dispositivo al expirar el límite de tiempo puede ser de naturaleza muy variada en función del contexto de utilización. Puede consistir, por ejemplo, en la transmisión de una nueva solicitud de registro o de suscripción inicial, o en la detención de un anuncio vocal o de un tono de llamada, o en la liberación de recursos implicados en la comunicación.
Cabe señalar que, para cada aplicación de la invención, la invención prevé transmitir una indicación explícita del tipo de mensaje que caracteriza el inicio de la segunda transacción, además de un tiempo de temporización. De forma ventajosa, la invención propone de este modo un mecanismo genérico que permita evitar tener que establecer una norma internacional para cada aplicación prevista (sobre la base de la cual podría bastar una indicación implícita del tipo de mensaje que caracteriza el inicio de la segunda transacción).
De acuerdo con características particulares, cuando dicha comunicación se asocia al menos a un diálogo, dicho segundo dispositivo ya no tiene en cuenta dicho límite de tiempo si dicho diálogo es liberado por dicho primer dispositivo (por ejemplo por medio de una solicitud BYE o CANCEL en el caso de un diálogo iniciado por una solicitud INVITE) antes de la expiración de dicho límite de tiempo.
Conviene recordar a este respecto que una comunicación entre un primer y un segundo dispositivo está generalmente asociada a varios diálogos, por ejemplo un primer diálogo entre el primer dispositivo y un servidor P-CSCF de la red de origen, un segundo diálogo entre este servidor P-CSCF de la red de origen y un Servidor de Aplicaciones de la red de origen, un tercer diálogo entre este Servidor de Aplicaciones de la red de origen y un Servidor de Aplicaciones de la red de destino, un cuarto diálogo entre este Servidor de Aplicaciones de la red de destino y un servidor P-CSCF de la red de destino y finalmente un quinto diálogo entre este servidor P-CSCF de la red de destino y el segundo dispositivo.
Gracias a estas disposiciones, dicho tratamiento se cancelará automáticamente. De este modo, se evita que el segundo dispositivo realice cualquier acción innecesaria, o incluso contraria a la liberación de dicho diálogo.
De acuerdo con otras características particulares, dicho primer dispositivo y dicho segundo dispositivo comprenden agentes SIP, y dicho tipo de mensaje que caracteriza el inicio de la segunda transacción es un método SIP.
Gracias a estas disposiciones, nos beneficiamos de las ventajas de un protocolo de control de sesión avanzado.
De acuerdo con un segundo aspecto, la invención hace referencia a diversos dispositivos.
Hace referencia, por tanto, en primer lugar, a un dispositivo de comunicación, denominado primer dispositivo, que comprende medios para, cuando está en comunicación con otro dispositivo de comunicación, denominado segundo dispositivo, el protocolo de dicha comunicación comprenda al menos una transacción, denominada primera transacción, y al menos una transacción posterior, denominada segunda transacción, transmitir durante dicha primera transacción a dicho segundo dispositivo un tiempo máximo aceptable entre el final de la primera transacción y el inicio de dicha segunda transacción, así como una indicación explícita del tipo de mensaje que caracteriza dicho inicio de la segunda transacción.
La invención también hace referencia, en segundo lugar, a un dispositivo de comunicación, denominado segundo dispositivo, que comprende medios para, cuando está en comunicación con otro dispositivo de comunicación, denominado primer dispositivo, el protocolo de dicha comunicación comprenda al menos una transacción, denominada primera transacción, y al menos una transacción posterior, denominada segunda transacción:
- recibir durante dicha primera transacción de la parte de dicho primer dispositivo un tiempo máximo aceptable entre el final de la primera transacción y el inicio de dicha segunda transacción, así como una indicación explícita del tipo de mensaje que caracteriza dicho inicio de la segunda transacción, y
- activar un temporizador para este límite de tiempo.
De acuerdo con características particulares, dicho segundo dispositivo comprende medios para, cuando dicha comunicación se asocia con al menos un diálogo, no tener en cuenta dicho límite de tiempo si dicho diálogo es liberado por dicho primer dispositivo antes de la expiración de dicho límite de tiempo.
De acuerdo con otras características particulares, dicho primer dispositivo o dicho segundo dispositivo comprende un agente SIP, y dicho tipo de mensaje es un método SIP.
De acuerdo con otras características particulares, dicho primer dispositivo o dicho segundo dispositivo se aloja en un dispositivo cliente, o en un servidor.
Ni que decir tiene que un mismo dispositivo cliente, o un mismo servidor, puede alojar tanto un primer dispositivo como un segundo dispositivo, tales como los descritos de forma breve anteriormente.
Las ventajas que ofrecen estos dispositivos son, en esencia, las mismas que las de los métodos correlativos descritos brevemente anteriormente.
Cabe señalar que es posible implementar estos dispositivos en el contexto de instrucciones de software y/o en el contexto de circuitos electrónicos.
De acuerdo con un tercer aspecto, la invención hace referencia a un sistema de comunicación que comprende al menos un primer dispositivo y al menos un segundo dispositivo tal como se describió brevemente anteriormente.
La invención también hace referencia a un programa informático que se pueda descargar de una red de comunicaciones y/o almacenarse en un soporte legible por ordenador y/o ejecutarse mediante un microprocesador. Este programa informático destaca por que comprende instrucciones para la ejecución de las etapas del método de control descrito de forma breve anteriormente implementado por el primer dispositivo cuando estas etapas se ejecutan en un ordenador, o para la ejecución de las etapas del método de control descrito de forma breve anteriormente implementado por el segundo dispositivo cuando estos pasos se ejecutan en un ordenador.
Las ventajas que ofrece este programa informático son, en esencia, las mismas que las que ofrece dicho método.
Otros aspectos y ventajas de la invención se pondrán de manifiesto con la lectura de la descripción detallada a continuación de formas de realización particulares, dadas a modo de ejemplos no restrictivos. La descripción hace referencia a las figuras adjuntas, en las que:
- la figura 1 muestra un procedimiento de registro,
- la figura 2 muestra un procedimiento de suscripción,
- la figura 3 muestra una reserva de recursos,
- la figura 4 muestra el establecimiento de una comunicación multimedia utilizando el protocolo RTP, - la figura 5 muestra la activación de un servicio de anuncios vocales,
- la figura 6 muestra la activación de un servicio de reenvío sin respuesta,
- la figura 7 muestra la activación de la puesta en espera de una llamada, y
- la figura 8 muestra esquemáticamente un sistema de prestación de servicios multimedia adecuado para poner en práctica la invención.
Aunque la presente invención hace referencia a las redes IP en general, se considerará ahora, a modo de ejemplo de forma de realización, una arquitectura de red de tipo IMS, tal como se presentó brevemente anteriormente. Esta arquitectura se ilustra en lafigura 8.
Los servicios multimedia ofrecidos por esta red IMS 1 pueden comprender telefonía, videotelefonía, uso compartido de contenidos ("content-sharing"en inglés), de presencia, de mensajería instantánea o de servicios de televisión. Estos servicios están a disposición del usuario de un dispositivo cliente ("User Equipment" o UE en inglés) 10 perteneciente a la red 1, que permite al dispositivo cliente 10 intercambiar flujos multimedia y señales de control de sesión conformes al protocolo SIP, por ejemplo, con el dispositivo cliente (no representado) de un usuario perteneciente a una red SIP (no representada) conectada a la red 1.
El dispositivo cliente 10 puede ser un terminal fijo o móvil, o una pasarela doméstica o empresarial, que disponga de medios de señalización SIP y que pueda comprender medios para reproducir contenidos audiovisuales.
Como se muestra en la figura 8, esta red IMS 1 comprende, además de una infraestructura de transporte IP (no mostrada):
- al menos un servidor S-CSCF; el servidor S-CSCF 27 gestiona en particular el procedimiento de registro de los dispositivos conectados a la red 1; el servidor S-CSCF 27 gestiona también el enrutamiento de la señalización entre el dispositivo cliente 10 y los servidores de mensajería vocal VM 25, mensajería instantánea 26 y telefonía TAS 29;
- al menos un servidor I-CSCF; el servidor I-CSCF 22 gestiona en particular el enrutamiento hacia otros terminales gestionados por la misma red IMS 1 y el enrutamiento de la señalización entre esta red IMS 1 y otras redes (no mostradas);
- al menos un servidor P-CSCF; el servidor P-CSCF 21 actúa como entidad de conexión entre la red central IMS y la red de acceso utilizada por el dispositivo cliente 10;
- al menos un servidor de base de datos, del tipo HSS; el servidor HSS 24 contiene el perfil del usuario del dispositivo cliente 10 en términos de autentificación y localización y servicios suscritos;
- al menos un servidor VM 25 de resumen de mensajería vocal ("message-summary"en inglés); el servidor VM 25 gestiona la suscripción del dispositivo cliente 10 a eventos de depósito/recuperación de mensajes para el dispositivo cliente 10, y notifica al dispositivo cliente 10 cuando se producen estos eventos;
- al menos un servidor de mensajería instantánea IM 26; si el usuario del UE 10 se suscribe al servicio de mensajería instantánea, este usuario puede chatear "instantáneamente" en línea con otros suscriptores de este servicio; y
- al menos un servidor de telefonía TAS 29; el servidor TAS gestiona los servicios telefónicos a los que el usuario del terminal 10 se ha suscrito con su operador, tales como la presentación de números o el desvío de llamadas.
Ejemplos de servidores de aplicaciones (AS) son el servidor de mensajería vocal VM 25, el servidor de mensajería instantánea IM 26 y el servidor de telefonía TAS 29.
Algunos servicios, como los del Servidor VM 25 y del Servidor de Mensajería Instantánea IM 26, dependen de que el terminal 10 se suscriba a eventos predeterminados, como se explicó anteriormente.
La presente invención hace referencia a una comunicación entre dos dispositivos, en la que el protocolo de dicha comunicación comprende al menos una transacción, denominada primera transacción, y al menos una transacción posterior, denominada segunda transacción.
De acuerdo con una forma de realización de la invención, se llevan a cabo los siguientes etapas:
- uno de dichos dispositivos, denominado primer dispositivo, transmite durante dicha primera transacción al otro dispositivo, denominado segundo dispositivo, un tiempo máximo aceptable entre el final de la primera transacción y el inicio de dicha segunda transacción, así como una indicación explícita del tipo de mensaje que caracteriza dicho inicio de la segunda transacción, y
- dicho segundo dispositivo activa un temporizador para dicho límite de tiempo.
De acuerdo con una aplicación particular, el "primer dispositivo" y el "segundo dispositivo" comprenden agentes SIP. En este caso, de acuerdo con una variante, el primer dispositivo puede utilizar convenientemente una nueva cabecera SIP, que indica el tiempo máximo de espera para una nueva transacción para el misma referencia de llamada (Call-Id). Esta cabecera podría, por ejemplo, ser de la forma: Next-Transaction-Limit: method; delay
En este caso, el parámetro "method" indica el método SIP que caracteriza el inicio de la futura transacción, y el parámetro "delay" indica el tiempo de temporización.
De este modo, en el primer ejemplo, en la etapa F2, el servidor SIP puede introducir la información: Next-Transaction-Limit: REGISTER; 60 para indicar a Bob que los datos de autentificación temporales sólo son válidos únicamente en los próximos 60 segundos. Después de eso, Bob tendrá que volver a emitir una solicitud de registro inicial. Del mismo modo, en caso de movilidad entre dos redes de acceso, el terminal de Bob sabrá que sólo puede enviar el REGISTER inicial en el nuevo acceso después de esperar 60 segundos.
En el segundo ejemplo, en la etapa F2, el notificador puede introducir la información: Next-Transaction-Limit: NOTIFY; 140 para indicar al abonado que si no recibe una notificación (etapa F3) en un límite de tiempo de 140 segundos, tendrá que borrar la suscripción actual y renovarla.
En el tercer ejemplo, en la etapa F3, el agente SIP A puede introducir la información: Next-Transaction-Limit: UPDATE; 10 en el mensaje PRACK de la etapa F3 con el fin de indicar al agente SIP B que si este último no recibe una solicitud UPDATE (etapa F5) en los 10 segundos siguientes a la recepción del mensaje PRACK, el agente B tendrá que liberar los recursos mediante un código apropiado (lo que permitirá al agente SIP A transferir la comunicación hacia el dominio del circuito). Este comportamiento también se podría aplicar para limitar el límite de tiempo de recepción del mensaje PRACK en las etapas F3 y F8.
En el cuarto ejemplo, en la etapa F3, el agente B puede introducir la información: Next-Transaction-Limit: BYE; 43200 con el fin de indicar al agente A que si el diálogo no ha sido liberado después de 12 horas, el agente A debe liberar el recurso con un código apropiado. En el mismo ejemplo, el agente A puede proporcionar la misma información al agente B en la etapa F4.
En el quinto ejemplo, en la etapa F4, el servidor SIP puede introducir la información: Next-Transaction-Limit: BYE; 300 con el fin de indicar a la máquina vocal que el anuncio se debe reproducir durante un máximo de 5 minutos.
En el sexto ejemplo, en la etapa F1, el agente A puede introducir la información: Next-Transaction-Limit: CANCEL; 30 con el fin de indicar al agente B que el tiempo de espera para la solicitud CANCEL es como máximo de 30 segundos.
En el séptimo ejemplo, en la etapa F1, el agente A puede introducir la información: Next-Transaction-Limit: INVITE; 300 con el fin de indicar al agente B que el tiempo de espera es como máximo de 5 minutos.
Cabe señalar que, en los ejemplos descritos anteriormente, la información de temporización se ha transmitido en una cabecera específica. Sin embargo, evidentemente otros formatos son posibles para transmitir esta información. De este modo, como alternativa, esta información se puede transmitir en el cuerpo del mensaje ("body xml" en inglés) de una solicitud y/o en la respuesta a una solicitud.
En términos generales, la presente invención se puede poner en práctica dentro de los nodos de una red IP, por ejemplo dispositivos cliente o servidores, por medio de componentes de software y/o hardware.
Los componentes de software se pueden integrar en un programa informático convencional para gestionar un nodo de red. Por lo tanto, como se indicó anteriormente, la presente invención también hace referencia a un sistema informático. Este sistema informático tiene convencionalmente una unidad central de procesamiento que controla una memoria por medio de señales, así como una unidad de entrada y una unidad de salida. Además, este sistema informático se puede utilizar para ejecutar un programa informático que comprende instrucciones para la implementación de etapas de uno cualquiera de los métodos de control de acuerdo con la invención.
En efecto, la invención también hace referencia a un programa informático que se puede descargar de una red de comunicación y que comprende instrucciones para la ejecución de etapas de un método de control de acuerdo con la invención, cuando se ejecuta en un ordenador. Este programa informático se puede almacenar en un medio legible por ordenador y se puede ejecutar mediante un microprocesador.
Este programa puede utilizar cualquier lenguaje de programación, y presentarse en forma de código fuente, código objeto, o código intermedio entre el código fuente y el código objeto, tal como en una forma parcialmente compilada o en cualquier otra forma deseable.
La invención también hace referencia a un medio de información no extraíble o parcial o totalmente extraíble que se puede leer mediante un ordenador y que tiene instrucciones para un programa informático tal como el mencionado anteriormente.
El medio de almacenamiento puede ser cualquier entidad o dispositivo capaz de almacenar el programa. Por ejemplo, el soporte puede comprender un medio de almacenamiento, tal como una ROM, por ejemplo, un CD ROM o una ROM de circuito microelectrónica, o un medio de registro magnético, tal como un disco duro, o incluso una unidad USB ("USB flash drive"en inglés).
Por otro lado, el soporte de informaciones puede ser un soporte transmisible tal como una señal eléctrica u óptica, que puede transmitirse a través de un cable eléctrico u óptico, por radio o por otros medios. En particular, el programa informático de acuerdo con la invención se puede descargar de una red de tipo Internet.
Como variante, el soporte de información puede ser un circuito integrado en el que se incorpora el programa, estando adaptado el circuito para ejecutar etapas o para ser utilizado en la ejecución de etapas de cualquiera de los métodos de control de acuerdo con la invención.
Claims (12)
1. Método de control relativo a una comunicación entre dos dispositivos, en el que el protocolo de dicha comunicación comprende al menos una transacción, denominada primera transacción, y al menos una transacción posterior, denominada segunda transacción, comprendiendo dicho método las siguientes etapas:
- uno de dichos dispositivos, denominado primer dispositivo, transmite durante dicha primera transacción al otro dispositivo, denominado segundo dispositivo, un tiempo máximo aceptable entre el final de la primera transacción y el inicio de dicha segunda transacción, y
- dicho segundo dispositivo activa un temporizador para dicho límite de tiempo,
caracterizado por que,durante dicha primera transacción, dicho primer dispositivo también transmite al segundo dispositivo una indicación explícita del tipo de mensaje que caracteriza dicho inicio de la segunda transacción.
2. Método de control de acuerdo con la reivindicación 1,caracterizado por que, cuando dicha comunicación está asociada con al menos un diálogo, dicho segundo dispositivo ya no tiene en cuenta dicho límite de tiempo si dicho diálogo es liberado por dicho primer dispositivo antes de la expiración de dicho límite de tiempo.
3. Método de control de acuerdo con la reivindicación 1 o la reivindicación 2,caracterizado por quedicho primer dispositivo y dicho segundo dispositivo comprenden agentes SIP (Session Initiation Protocol), ypor quedicho tipo de mensaje que caracteriza el inicio de la segunda transacción es un método SIP.
4. Un dispositivo de comunicación, denominado primer dispositivo, que comprende medios para, cuando está en comunicación con otro dispositivo de comunicación, denominado segundo dispositivo, cuyo protocolo de comunicación comprende al menos una transacción, denominada primera transacción, y al menos una transacción posterior, denominada segunda transacción, transmitir durante dicha primera transacción a dicho segundo dispositivo un tiempo máximo aceptable entre el final de la primera transacción y el inicio de dicha segunda transacción,caracterizado por quedicho primer dispositivo comprende además medios para transmitir durante dicha primera transacción al segundo dispositivo una indicación explícita del tipo de mensaje que caracteriza dicho inicio de la segunda transacción.
5. Dispositivo de comunicación, denominado segundo dispositivo, que comprende medios para, cuando está en comunicación con otro dispositivo de comunicación, denominado primer dispositivo, el protocolo de dicha comunicación comprenda al menos una transacción, denominada primera transacción, y al menos una transacción posterior, denominada segunda transacción:
- recibir durante dicha primera transacción de la parte de dicho primer dispositivo un tiempo máximo aceptable entre el final de la primera transacción y el comienzo de dicha segunda transacción, y
- activar un temporizador para dicho límite de tiempo,
caracterizado por quedicho segundo dispositivo comprende además medios para recibir durante dicha primera transacción de parte de dicho primer dispositivo una indicación explícita del tipo de mensaje que caracteriza dicho inicio de la segunda transacción.
6. Dispositivo de comunicación de acuerdo con la reivindicación 5,caracterizado por quecomprende medios para, cuando dicha comunicación está asociada con al menos un diálogo, dejar de tener en cuenta dicho límite de tiempo si dicho diálogo es liberado por dicho primer dispositivo antes de la expiración de este límite de tiempo.
7. Dispositivo de comunicación de acuerdo con una cualquiera de las reivindicaciones 4 a 6,caracterizado por quecomprende un agente SIP (Session Initiation Protocol), ypor quedicho tipo de mensaje es un método SIP.
8. Dispositivo de comunicación de acuerdo con una cualquiera de las reivindicaciones 4 a 7,caracterizado por quese aloja en un dispositivo cliente.
9. Dispositivo de comunicación de acuerdo con una cualquiera de las reivindicaciones 4 a 7,caracterizado por quese aloja en un servidor.
10. Sistema de comunicación, que comprende al menos un primer dispositivo de comunicación de acuerdo con la reivindicación 4, y al menos un segundo dispositivo de comunicación de acuerdo con la reivindicación 5 o la reivindicación 6.
11. Medios de almacenamiento de datos no extraíbles o parcial o totalmente extraíbles que comprenden instrucciones de código de programa informático para la ejecución de las etapas de un método de control de acuerdo con cualquiera de las reivindicaciones 1 a 3 implementado por el primer dispositivo, o para la ejecución de las etapas de un método de control de acuerdo con cualquiera de las reivindicaciones 1 a 3 implementado por el segundo dispositivo.
12. Programa informático descargable desde una red de comunicaciones y/o almacenado en un soporte legible por ordenador y/o ejecutable por un microprocesador,caracterizado por quecomprende instrucciones para la ejecución de las etapas de un método de control de acuerdo con cualquiera de las reivindicaciones 1 a 3 implementado por el primer dispositivo cuando estas etapas se ejecutan en un ordenador, o para la ejecución de las etapas de un método de control de acuerdo con cualquiera de las reivindicaciones 1 a 3 implementado por el segundo dispositivo cuando estas etapas se ejecutan en un ordenador.
Applications Claiming Priority (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
FR1754569A FR3066872A1 (fr) | 2017-05-23 | 2017-05-23 | Procede de controle d' une communication comprenant des transactions multiples |
PCT/FR2018/051209 WO2018215719A1 (fr) | 2017-05-23 | 2018-05-18 | Procédé de contrôle d'une communication comprenant des transactions multiples |
Publications (1)
Publication Number | Publication Date |
---|---|
ES2958755T3 true ES2958755T3 (es) | 2024-02-14 |
Family
ID=59699832
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
ES18736975T Active ES2958755T3 (es) | 2017-05-23 | 2018-05-18 | Método de control de una comunicación que comprende múltiples transacciones |
Country Status (5)
Country | Link |
---|---|
US (1) | US11283842B2 (es) |
EP (1) | EP3632078B1 (es) |
ES (1) | ES2958755T3 (es) |
FR (1) | FR3066872A1 (es) |
WO (1) | WO2018215719A1 (es) |
Family Cites Families (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US7434258B2 (en) * | 2002-05-07 | 2008-10-07 | Nokia Corporation | Method and communication system for controlling security association lifetime |
US8213295B2 (en) * | 2006-09-12 | 2012-07-03 | Qualcomm Incorporated | Transaction timeout handling in communication session management |
US7978599B2 (en) * | 2006-11-17 | 2011-07-12 | Cisco Technology, Inc. | Method and system to identify and alleviate remote overload |
FR3036567A1 (fr) * | 2015-05-18 | 2016-11-25 | Orange | Procede de controle d'une session relative a un service |
-
2017
- 2017-05-23 FR FR1754569A patent/FR3066872A1/fr not_active Withdrawn
-
2018
- 2018-05-18 US US16/615,764 patent/US11283842B2/en active Active
- 2018-05-18 EP EP18736975.6A patent/EP3632078B1/fr active Active
- 2018-05-18 WO PCT/FR2018/051209 patent/WO2018215719A1/fr unknown
- 2018-05-18 ES ES18736975T patent/ES2958755T3/es active Active
Also Published As
Publication number | Publication date |
---|---|
WO2018215719A1 (fr) | 2018-11-29 |
US11283842B2 (en) | 2022-03-22 |
EP3632078B1 (fr) | 2023-07-12 |
US20200162518A1 (en) | 2020-05-21 |
EP3632078A1 (fr) | 2020-04-08 |
FR3066872A1 (fr) | 2018-11-30 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US8718238B2 (en) | Method and a system for implementing a multimedia ring back tone service | |
US8325707B2 (en) | Session initiation from application servers in an IP multimedia subsystem | |
WO2014044224A1 (zh) | 接入协商、释放中服务质量承载资源控制的方法及系统 | |
US20150334241A1 (en) | Real-Time Monitoring/Interrupting of Voicemail Message Recording | |
US11411899B2 (en) | Routing parent and child device calls through a parent telephony application server | |
ES2672644T3 (es) | Facilitación de medios anticipados en un sistema de comunicaciones | |
ES2958755T3 (es) | Método de control de una comunicación que comprende múltiples transacciones | |
US11418635B2 (en) | Method of dynamic selection, by a caller, from a plurality of terminals of a callee | |
WO2020128258A1 (fr) | Procédé de basculement d'une communication de tcp sur udp | |
EP2274922A1 (en) | A system and method for alerting a party in a call of a call disconnection of another party | |
WO2017168084A1 (fr) | Procédé de transfert de réseau d'accès pour un terminal mobile en itinérance | |
EP3583757B1 (fr) | Procédé de changement de réseau mobile | |
KR20220018761A (ko) | 얼리 세션 모델 기반 비디오 cat을 제공하기 위한 통신 프로토콜 | |
US20180375901A1 (en) | Method of communication between a calling terminal and a plurality of called terminals | |
WO2007109970A1 (fr) | Procédé, système et dispositif pour commander un temporisateur de session | |
ES2366655T3 (es) | Equipo de usuario, método y sistema para el control de sesiones simultáneas. | |
JP6549523B2 (ja) | 要求先端末のオプション機能の非使用を整合する網間制御方法、sipサーバ及びプログラム | |
JP2015162827A (ja) | アーリーメディアの送信タイミングを制御するセッション制御方法、sipサーバ及びプログラム | |
FR2977433A1 (fr) | Procede de filtrage de flux early media dans un reseau ims et serveur mettant en œuvre ce procede | |
WO2018121590A1 (zh) | Sip终端呼叫转接方法及系统 | |
WO2013102716A1 (fr) | Procede dynamique de determination d'une liste de services dans un reseau sip | |
FR2905816A1 (fr) | Procede et serveur de notification d'un appel dans un reseau |