FR2974964A1 - Continuite de service inter-terminal dans un reseau de telecommunications - Google Patents

Abstract

L'invention concerne un procédé d'établissement d'un canal de signalisation d'accès pour une continuité de services entre un premier (UE1) et un second (UE2) terminal utilisateur dans un réseau de télécommunications, caractérisé en ce qu'il comporte les étapes suivantes, effectuées dans un serveur d'application de continuité de service (AS1) : - création d'une requête initiale à destination du second terminal utilisateur, la requête contenant un en-tête de type « Route », - insertion dans l'en-tête de type « Route » d'une information pour inhiber la vérification de critères de filtre initial dans un serveur de fonction de contrôle de session d'appel (S-CSCF).

Description

Continuité de service inter-terminal dans un réseau de télécommunications

1 o Le domaine de l'invention est celui des télécommunications. La présente invention vise plus particulièrement un traitement de données pour la communication de données sur un réseau informatique. L'expression réseau informatique doit être comprise avec un sens large et le réseau informatique peut notamment être un réseau de téléphonie mobile, par exemple 15 celui dit de troisième génération (3GPP). Le développement des télécommunications a permis à un nombre croissant d'utilisateurs de disposer d'un ou plusieurs terminaux média, tels que des téléphones mobiles, des ordinateurs ou des assistants personnels numériques, via lesquels ils peuvent établir des sessions multimédia. 20 Pour permettre la communication entre des réseaux informatiques opérant sous différents protocoles, une architecture standardisée dite IMS (pour Internet Protocol Multimedia Subsystem) a été développée. L'architecture IMS est une architecture multimédia ouverte qui utilise le protocole SIP (Session Initiation Protocol). L'invention concerne donc plus particulièrement un réseau informatique opérant 25 sous le protocole de signalisation SIP (Session Initiation Protocol). Le protocole SIP est un protocole normalisé qui permet d'établir, de modifier et de terminer des sessions multimédia. Le protocole SIP est un protocole du type requête/réponse dans le sens où, pour chaque message émis par une source, il y a au moins une réponse associée du destinataire confirmant la réception du message envoyé. 30 Dans la norme 3GPP, l'utilisateur peut utiliser plusieurs terminaux pour une même souscription. Dans la terminologie 3GPP, un terminal est appelé UE (User Equipement). Un utilisateur peut également posséder plusieurs identités publiques c'est-à-dire des identités sur lesquelles il peut être joignable par d'autres utilisateurs. L'utilisateur peut associer une même identité publique à plusieurs de ses terminaux. 15

Un utilisateur a par ailleurs la possibilité de souscrire à un service de transfert inter-terminal permettant, lors d'une session multimédia, de réaliser des opérations de transfert ou de réplication d'un flux média vers d'autres terminaux. Lors de l'établissement d'une session multimedia entre un terminal d'un utilisateur ayant souscrit au service de transfert inter-terminal et un correspondant, un serveur d'application de continuité de service dit SCC AS (Service Centralization and Continuity Application Server) fait l'intermédiaire entre le terminal et le correspondant, de façon à permettre par la suite les opérations de transfert, c'est-à-dire de remplacement du terminal par un autre terminal, et de réplication, c'est-à-dire de copie d'un flux média envoyé au terminal vers un autre terminal. Il est à noter que le transfert inter-terminal peut exister entre terminaux correspondant à une même souscription IMS, ou entre terminaux correspondants à des souscriptions IMS distinctes. Ainsi, lorsque l'utilisateur est en communication en utilisant un de ses terminaux, il peut transférer sa communication ou un ou plusieurs flux de sa communication (lorsque celle-ci comporte plusieurs flux, un flux audio et un flux vidéo par exemple) sur un autre terminal. Par exemple, l'utilisateur ayant commencé un appel sur son téléphone mobile et qui arrive à son bureau, peut transférer le flux audio sur son téléphone fixe, de façon transparente pour son correspondant c'est-à-dire sans interruption.

Pour permettre à l'utilisateur de transférer ou répliquer ses flux de ses sessions multimédias entre les différents terminaux dont il dispose, la norme 3GPP a introduit une nouvelle fonctionnalité dans le serveur d'application de continuité de service SCC AS. Cette nouvelle fonctionnalité consiste à orchestrer les opérations de transfert/réplication des flux médias ainsi que de transfert du contrôle de la session entre les terminaux de l'utilisateur. Le serveur d'application de continuité de service SCC AS est par conséquent en charge de deux types de continuité de service : - Continuité de service lorsqu'un terminal change de réseau d'attachement (dite continuité inter-système) ; par exemple lorsqu'un terminal quitte une couverture Wi-Fi et se connecte à un réseau 3G, la continuité inter-système permet le maintien sans coupure des services en cours ; cette fonctionnalité existe depuis la Release 8 de la norme.

- Continuité de service entre différents terminaux (dite continuité inter-terminal), ci-dessus évoquée ; cette fonctionnalité a été introduite en Release 9 de la norme.

Dans la présente demande on s'intéresse plus particulièrement à la continuité de service inter-terminal. Par ailleurs, d'autres serveurs d'application peuvent être invoqués en plus du serveur d'application de continuité de service SCC AS au sein d'une même session 1 o pour rendre d'autres services. Il s'agit par exemple des services supplémentaires de la téléphonie. Afin d'assurer un rendu du service cohérent à l'utilisateur, il est nécessaire de respecter un certain ordre de déclenchement des serveurs d'application dans une même session. Notamment, le serveur d'application de continuité de service SCC AS 15 doit être, dans la chaîne des serveurs d'application invoqués, celui qui est le plus proche du terminal servi. Ainsi, le serveur d'application de continuité de service SCC AS peut exercer les contrôles nécessaires sur les échanges SIP et assurer le bon déroulement des procédures de continuité inter-système et de transfert/réplication des flux entre les terminaux de l'utilisateur. 20 Pour cela, il est prévu dans la spécification TS 23.237 (cf. sections 6.2.1.1 et 6.2.2.1), que le serveur d'application de continuité de service SCC AS doit être invoqué en premier pour une session initiée par le terminal (appel émis), et en dernier pour une session destinée au terminal (appel reçu). Ainsi, on appelle « Access Leg » le canal de signalisation d'accès entre le terminal utilisateur UE et le serveur d'application de 25 continuité de service SCC AS, et « Remote Leg » le canal de signalisation entre le serveur d'application de continuité de service SCC AS et le terminal correspondant. Cette caractéristique est nécessaire car le serveur d'application de continuité de service SCC AS joue le rôle de point d'ancrage de la signalisation pour la mobilité inter-système. Lorsque le terminal utilisateur UE change de réseau d'accès, il établit un 30 nouveau canal de signalisation d'accès « Access Leg » via le nouveau réseau d'accès en envoyant une requête SIP INVITE au serveur d'application de continuité de service SCC AS, et le serveur d'application de continuité de service SCC AS se charge de faire la corrélation avec le canal de signalisation « Remote Leg », de telle sorte que la

mobilité du terminal utilisateur UE est transparente pour le correspondant et les autres serveurs d'application qui peuvent se trouver sur le canal de signalisation « Remote Leg ».

Afin de s'assurer que le serveur d'application de continuité de service SCC AS soit et demeure, dans la chaîne des serveur d'application invoqués, celui qui est le plus proche du terminal servi, il est prévu que des critères de filtre initial iFC (initial Filter Criteria) soient configurés dans le serveur de fonction de contrôle de session d'appel S-CSCF de telle sorte que le serveur d'application de continuité de service SCC AS soit invoqué en premier pour les sessions « originating » (INVITE envoyé par le terminal servi vers un correspondant), et en dernier pour les sessions « terminating » (INVITE reçu d'un correspondant à destination du terminal servi). Le nouveau canal de signalisation d'accès « Access Leg » est établi à l'initiative du terminal, en envoyant une requête INVITE. Le serveur de fonction de contrôle de session d'appel S-CSCF se comporte alors en mode « originating », ce qui est suffisant pour s'assurer qu'aucun autre serveur d'application AS ne soit inséré entre le terminal utilisateur et le serveur d'application de continuité de service SCC AS, puisque le serveur d'application de continuité de service SCC AS est invoqué en premier. Toutefois, dans le cas de la continuité de service inter-terminal, il est spécifié par le 3GPP qu'une fois qu'un premier terminal utilisateur a une session en cours ancrée par le serveur d'application de continuité de service SCC AS, ce serveur d'application de continuité de service SCC AS peut : - établir un nouveau canal de signalisation d'accès « Access Leg » vers un deuxième terminal de l'utilisateur, et corréler ces deux canaux de signalisation d'accès « Access Legs » de façon combinée avec un seul canal de signalisation « Remote Leg » - établir un nouveau canal de signalisation d'accès « Access Leg » vers un deuxième terminal de l'utilisateur, et transférer la session sur ce deuxième terminal. Une différence importante par rapport à la continuité de service inter-système est que dans ce cas, c'est le serveur d'application de continuité de service SCC AS qui30

est à l'initiative de l'établissement d'un nouveau canal de signalisation d'accès « Access Leg », en envoyant une requête INVITE vers le deuxième terminal. Le problème qui se pose alors est que le serveur de fonction de contrôle de session d'appel S-CSCF traite la requête INVITE envoyée par le serveur d'application de continuité de service SCC AS vers le deuxième terminal en mode « terminating », c'est-à-dire qu'il passe en revue les critères de filtre initial iFC présents dans le profil de service du deuxième terminal pour les sessions destinées à ce deuxième terminal, et, pour chaque critère de filtre initial iFC dont l'évaluation est positive, invoque le serveur d'application prévu par ce critère iFC. Par conséquent, dans le cas où le profil de 1 o service du deuxième terminal prévoit que des serveurs d'application doivent être invoqués pour les sessions destinées au deuxième terminal, le serveur de fonction de contrôle de session d'appel S-CSCF déclenche ces serveurs d'application pour le nouveau canal de signalisation d'accès Access Leg. Cela conduit à que le serveur d'application de continuité de service SCC AS 15 n'est pas obligatoirement le plus proche du terminal utilisateur. Le bon fonctionnement des services n'est pas garanti pour l'utilisateur. La présente invention a pour but de résoudre les inconvénients de la technique antérieure en fournissant un procédé d'établissement d'un canal de signalisation 20 d'accès pour une continuité de services entre un premier et un second terminal utilisateur dans un réseau de télécommunications, caractérisé en ce qu'il comporte les étapes suivantes, effectuées dans un serveur d'application de continuité de service : - création d'une requête initiale à destination du second terminal utilisateur, la 25 requête contenant un en-tête de type « Route », - insertion dans l'en-tête de type « Route » d'une information pour inhiber la vérification de critères de filtre initial dans un serveur de fonction de contrôle de session d'appel. Grâce à l'invention, le bon enchaînement des déclenchements de serveurs 30 d'application est assuré. Cela permet de garantir le bon fonctionnement des services rendus à l'utilisateur.

Selon une caractéristique préférée, l'étape d'insertion comporte l'ajout d'un identifiant uniforme de ressource de proxy P-CSCF et d'une adresse de contact du terminal utilisateur destinataire de la requête.

Selon une caractéristique préférée alternative, l'étape d'insertion comporte l'ajout d'un paramètre spécifique d'identifiant uniforme de ressource à l'identifiant uniforme de ressource du S-CSCF, le paramètre spécifique indiquant au serveur de fonction de contrôle de session d'appel S-CSCF de ne pas exécuter de critères de filtre initial.

L'invention concerne aussi un serveur d'application de continuité de service caractérisé en ce que, pour établir un canal de signalisation d'accès pour une continuité de services entre un premier et un second terminal utilisateur dans un réseau de télécommunications, il comporte : - des moyens de création d'une requête initiale à destination du second terminal utilisateur, la requête contenant un en-tête de type « Route », - des moyens d'insertion dans l'en-tête de type « Route » d'une information pour inhiber la vérification de critères de filtre initial dans un serveur de fonction de contrôle de session d'appel.

L'invention concerne aussi un signal de données portant une requête émise par un serveur d'application de continuité de service pour établir un canal de signalisation d'accès pour une continuité de services entre un premier et un second terminal utilisateur dans un réseau de télécommunications, à destination du second terminal utilisateur, caractérisé en ce qu'il comporte un en-tête de type « Route » comportant une information pour inhiber la vérification de critères de filtre initial dans un serveur de fonction de contrôle de session d'appel.

L'invention concerne aussi un serveur de fonction de contrôle de session d'appel adapté pour inhiber la vérification de critères de filtre initial lorsqu'il reçoit une requête émise par un serveur d'application de continuité de service pour établir un canal de signalisation d'accès pour une continuité de services entre un premier et un second terminal utilisateur dans un réseau de télécommunications, à destination du second terminal utilisateur, ladite requête comportant un en-tête de type « Route » comportant une information pour inhiber la vérification de critères de filtre initial.

Ce signal et ces dispositifs présentent des avantages analogues à ceux du procédé précédemment présenté. Dans un mode particulier de réalisation, les différentes étapes du procédé selon l'invention sont déterminées par des instructions de programmes d'ordinateurs. En conséquence, l'invention vise aussi un programme d'ordinateur sur un support d'informations, ce programme étant susceptible d'être mis en oeuvre dans un ordinateur, ce programme comportant des instructions adaptées à la mise en oeuvre des étapes d'un procédé tel que décrit ci-dessus. 1 o Ce programme peut utiliser n'importe quel langage de programmation, et être sous la forme de code source, code objet, ou de code intermédiaire entre code source et code objet, tel que dans une forme partiellement compilée, ou dans n'importe quelle autre forme souhaitable. L'invention vise aussi un support d'informations lisible par un ordinateur, et 15 comportant des instructions des programmes d'ordinateur tels que mentionnés ci-dessus. Le support d'informations peut être n'importe quelle entité ou dispositif capable de stocker le programme. Par exemple, le support peut comporter un moyen de stockage, tel qu'une ROM, par exemple un CD ROM ou une ROM de circuit 20 microélectronique, ou encore un moyen d'enregistrement magnétique, par exemple une disquette (floppy disc) ou un disque dur. D'autre part, le support d'informations peut être un support transmissible tel qu'un signal électrique ou optique, qui peut être acheminé via un câble électrique ou optique, par radio ou par d'autres moyens. Le programme selon l'invention peut être en 25 particulier téléchargé sur un réseau de type Internet. Alternativement, le support d'informations peut être un circuit intégré dans lequel le programme est incorporé, le circuit étant adapté pour exécuter ou pour être utilisé dans l'exécution du procédé en question. 30 D'autres caractéristiques et avantages apparaîtront à la lecture de modes de réalisation préférés décrits en référence aux figures dans lesquelles : - la figure 1 représente de façon schématique un réseau informatique selon un mode de réalisation de l'invention,

- la figure 2 représente un schéma fonctionnel d'un premier terminal utilisateur du réseau informatique de la figure 1, - la figure 3 représente un schéma fonctionnel d'un serveur d'application de continuité de service du réseau informatique de la figure 1, - la figure 4 représente un schéma fonctionnel d'un serveur de fonction de contrôle de session d'appel du réseau informatique de la figure 1, - la figure 5 représente un premier mode de réalisation de procédé selon l'invention, - la figure 6 représente un second mode de réalisation de procédé selon l'invention,

Selon un mode de réalisation préférée représenté à la figure 1, un réseau informatique comporte un coeur de réseau de type IMS (Internet Protocol Multimedia Subsystem). On appelle « coeur de réseau » la partie principale d'un réseau informatique, qui concentre et transporte les flux de données entre des réseaux affluents. L'architecture IMS est une architecture multimédia ouverte qui utilise le protocole SIP (Session Initiation Protocol). Le protocole SIP permet d'établir, de modifier et de terminer des sessions multimédia. Par rapport aux autres protocoles de signalisation, le protocole SIP se caractérise par sa capacité de véhiculer les informations de routage dans les messages SIP. En effet, la première requête initiant une session peut contenir les adresses des entités qu'elle doit traverser. Ces données sont renseignées par l'entité initiant la session qu'elle a elle-même récupérées au moment de son enregistrement au réseau ou via d'autres mécanismes.

Le chemin de signalisation correspondant à la session est établi au moment du passage de la requête initiale en fonction de la destination de l'appel, de l'architecture du réseau et des services nécessaires pour cette session. Ainsi, les requêtes subséquentes et les réponses SIP contiennent toutes les données nécessaires pour leur routage.

Les messages SIP sont de deux types : les requêtes et leurs réponses. Les réponses suivent le même chemin que la requête à laquelle elles sont associées. Il y a deux types de requêtes : les requêtes initiales et les requêtes subséquentes. Les requêtes subséquentes sont les requêtes appartenant à un dialogue SIP créé par une requête initiale. Seules certaines requêtes initiales peuvent créer un dialogue SIP (par exemple la requête INVITE). Le chemin des requêtes subséquentes, c'est-à-dire la

succession d'éléments SIP du réseau, que doivent traverser toutes les requêtes appartenant à ce dialogue est déterminé lors du passage de la requête initiale créant ce dialogue. L'en-tête SIP "Request-URI" de la requête SIP véhicule la destination de la requête. Une requête SIP peut optionnellement contenir un en-tête particulier nommé Route qui contient par ordre décroissant (c'est-à-dire l'ordre des entités sur le chemin), la liste des identités, sous forme d'URIs (Uniform Resource Identifier), des entités à traverser avant d'atteindre la destination. Il s'agit des entités intermédiaires par lesquelles la requête doit passer.

Une entité SIP intermédiaire (typiquement un proxy SIP) recevant une requête SIP initiale analyse celle-ci. Si cette requête contient un en-tête Route alors elle considère la première entité SIP présente dans cet en-tête comme l'entité à laquelle elle doit faire suivre la requête. Sinon elle détermine l'entité suivante à laquelle la requête doit être envoyée à partir de l'en-tête Request-URI en utilisant des mécanismes spécifiques de routage. Toute entité SIP (intermédiaire ou non) a la possibilité d'ajouter un en-tête Route ou d'ajouter l'identité d'entités additionnelles (URIs) dans un en-tête Route existant. Les usages de cette fonctionnalité sont très nombreux. Elle permet par exemple à la première entité contactée du réseau d'ajouter dans l'en-tête Route l'identité de l'entité responsable de la gestion des services alloués à l'usager émetteur de la requête afin de garantir que la requête passe par cette entité. Elle permet également pour les requêtes subséquentes envoyées dans le cadre d'un dialogue SIP déjà établi de spécifier dans l'en-tête Route la liste des entités ayant demandé, lors de l'établissement du dialogue SIP, à recevoir ces requêtes subséquentes. Le réseau informatique comporte un premier terminal utilisateur UE1, un deuxième terminal utilisateur UE2, un premier serveur d'application AS1, dit serveur SCC AS (Service Centralization and Continuity Application Server), un serveur de fonction de contrôle de session d'appel S-CSCF et deux autres serveurs d'application AS2 et AS3. Seules les entités directement impliquées dans l'invention sont représentées et décrites. Le premier terminal utilisateur UE1 peut être, par exemple, un terminal de téléphonie mobile, un ordinateur portable, un assistant personnel numérique, ou autre.

Par exemple, le premier terminal utilisateur UE1 est un terminal de téléphonie mobile appartenant à un utilisateur ayant souscrit à un service de transfert inter-terminal. Comme représenté sur la figure 2, le premier terminal utilisateur UE1 comporte un module d'émission-réception 10 configuré pour émettre une requête de transfert ou de réplication, vers un autre terminal, d'un flux média reçu par le terminal UE1. La requête comprend des informations relatives au terminal destinataire du transfert ou de la réplication, par exemple le deuxième terminal utilisateur UE2. La requête comprend également des informations relatives au flux média à transférer ou à répliquer. Le premier terminal utilisateur UE1 comporte également un module SIP 11 configuré pour gérer les requêtes SIP, et un module multimédia 12 configuré pour permettre la lecture d'un flux média, par exemple d'une vidéo. De manière similaire, le deuxième terminal utilisateur UE2 peut être un terminal de téléphonie mobile, un ordinateur portable, un assistant personnel numérique, ou autre. Par exemple, le deuxième terminal utilisateur UE2 est un ordinateur portable, qui peut appartenir au même utilisateur ou à un utilisateur différent. En effet, l'invention s'applique aussi bien au cas où le premier et le second terminal correspondent à une même souscription IMS, qu'au cas où ils correspondent à des souscriptions IMS distinctes. Le deuxième terminal utilisateur UE2 comprend par exemple des modules similaires aux modules du premier terminal utilisateur UE1.

Le serveur d'application de continuité de service AS1 a pour fonction de servir d'intermédiaire lors de l'établissement d'une session multimédia entre un terminal d'un utilisateur ayant souscrit au service de transfert inter-terminal, par exemple le premier terminal utilisateur UE1, et un correspondant distant, non représenté. Le serveur d'application de continuité de service AS1 permet ainsi par la suite de réaliser des opérations de transfert et de réplication. On appelle opération de transfert une opération de remplacement du terminal UE1 par un autre terminal pour la réception d'un flux média. On appelle opération de réplication une opération de copie d'un flux média envoyé au terminal UE1 vers un autre terminal. Comme représenté sur la figure 3, le serveur d'application de continuité de service AS1 comporte un module d'émission-réception 30 configuré pour recevoir une requête de transfert ou de réplication émise par un terminal d'un utilisateur ayant souscrit au service de transfert inter-terminal, par exemple le terminal UE1. Le module 30 permet également d'émettre des requêtes formées selon l'invention, comme il sera détaillé dans la suite.

Le serveur d'application de continuité de service AS1 comporte un module de mémoire 31 configuré pour mémoriser des éléments d'information reçus. Le serveur d'application de continuité de service AS1 comporte également un module de traitement 32 configuré pour créer une requête initiale à destination du second terminal utilisateur, la requête contenant un en-tête de type « Route », et pour insérer dans l'en-tête de type « Route » une information pour inhiber la vérification de critères de filtre initial iFC dans le serveur de fonction de contrôle de session d'appel S-CSCF. Le serveur d'application de continuité de service AS1 comporte également un module d'émission-réception 33 configuré pour émettre la requête initiale ainsi formée. 1 o Les serveurs d'application AS2 et AS3 comportent respectivement un module d'émission-réception 40, 50 configuré pour communiquer notamment avec le serveur de fonction de contrôle de session d'appel S-CSCF. Les serveurs d'application AS2 et AS3 comportent en outre un module respectif de service 41, 51 hébergeant une logique de service, par exemple un service de 15 fourniture de vidéo et/ou de musique. Comme représenté sur la figure 4, le serveur de fonction de contrôle de session d'appel S-CSCF comporte un module d'émission-réception 60 configuré pour recevoir une requête initiale envoyée par le serveur d'application de continuité de service. 20 Le serveur de fonction de contrôle de session d'appel S-CSCF comporte également un module 61 de traitement pour interpréter les informations contenues dans un en-tête « Route » de la requête initiale. En particulier, le module de traitement est adapté pour inhiber la vérification de critères de filtre initial (iFC) lorsqu'il reçoit une requête émise par un serveur 25 d'application de continuité de service pour établir un canal de signalisation d'accès pour une continuité de services entre un premier et un second terminal utilisateur dans un réseau de télécommunications, à destination du second terminal utilisateur, ladite requête comportant un en-tête de type « Route » comportant une information pour inhiber la vérification de critères de filtre initial iFC. Cette caractéristique correspond 30 plus particulièrement au second mode de réalisation détaillé dans la suite. Selon un premier mode de réalisation de l'invention représenté à la figure 5, le procédé selon l'invention comporte des étapes El à E3.

Dans ce mode de réalisation, le serveur d'application de continuité de service SCC AS connait les adresses de contact enregistrées par les terminaux de l'utilisateur, ainsi que l'identifiant uniforme de ressource URI du proxy P-CSCF associé. Ce besoin peut être satisfait par l'utilisation de la fonctionnalité « Third Party Register » qui permet au serveur d'application de continuité de service SCC AS de recevoir toutes les informations liées à l'enregistrement des terminaux utilisateur. Le serveur d'application de continuité de service SCC AS mémorise ces informations. Lorsque le serveur d'application de continuité de service SCC AS décide d'envoyer une requête initiale de type INVITE à un terminal utilisateur donné, par exemple le terminal UE2, il crée à l'étape El une requête initiale à destination du terminal utilisateur UE2. La requête contient un en-tête de type « Route ». A l'étape E2, le serveur d'application de continuité de service insère dans l'en-tête Route l'identifiant uniforme de ressource URI du proxy P-CSCF et l'adresse de contact enregistrée par ce terminal utilisateur UE2 destinataire de la requête. A l'étape suivante E3, le serveur d'application de continuité de service émet la requête ainsi formée. Lorsque le serveur de fonction de contrôle de session d'appel S-CSCF reçoit la requête INVITE, il constate qu'elle contient un en-tête ROUTE. Dans ce cas, le serveur S-CSCF utilise cet en-tête pour acheminer la requête initiale, selon les procédures de la RFC 3261 et TS 24.229, sans analyser les critères de filtre initial iFC. En d'autres termes, le serveur S-CSCF ne vérifie pas les critères de filtre initial lorsqu'il reçoit l'en-tête Route formé selon l'invention. Un exemple de requête INVITE envoyée par le serveur d'application de continuité de service SCC AS selon ce premier mode de réalisation est le suivant. Les éléments spécifiques à ce mode de réalisation sont indiqués en gras : INVITE sip:userl_public2@homel.net;gr=urn:uuid: f8ld4fae-7dec-lldO-a765-00a0c9le6bf6 SIP/2.0 Via: To: sip:userl_public2@homel.net; From: sip:interUEtransfer@sccasl.homel.net; tag=27365 Call-ID: cb03a0s09a2sdfglkj22222 CSeq: Max-Forwards: Route: <sip:scscf2.homel.net;lr>,<sip:pcscf2.homel.net;lr>,<sip: 2a01:c001::c0a8:0121:5060> P-Asserted-Identity: Require: Referred-By: sip:userl publicl@homel.net Contact: Allow: Content-Type: application/sdp Content-Length: G.)

v=0 o=- 1027933615 1027933615 IN 132.54.76.98 s=- c=IN IP4 132.54.76.98 t=0 0 m=audio 0 RTP/AVP 97 m=video 3002 RTP/AVP 98 99 b=AS:75 a=rtpmap:98 H263 a=fmtp:98 profile-level-id=0 a=rtpmap:99 MP4V-ES a=sendonly Selon un second mode de réalisation de l'invention représenté à la figure 6, le 35 procédé d'établissement d'un canal de signalisation d'accès pour une continuité de 10 15 20 25 30

services entre deux terminaux utilisateurs dans un réseau de télécommunications comporte des étapes E10 à E30. Lorsque le serveur d'application de continuité de service SCC AS décide d'envoyer une requête initiale à un terminal utilisateur donné, il crée à l'étape E10 une requête initiale à destination du terminal utilisateur. La requête contient un en-tête de type « Route ». Cette étape est identique à l'étape El précédemment décrite. A l'étape E20, le serveur d'application de continuité de service SCC AS insère dans l'en-tête Route un paramètre spécifique d'URI à l'URI du serveur S-CSCF. Le paramètre spécifique est noté no-iFC et indique au serveur S-CSCF de ne pas 1 o exécuter de vérification de critères de filtre initial. A l'étape suivante E30, le serveur d'application de continuité de service émet la requête ainsi formée. Lorsque le serveur S-CSCF reçoit la requête et interprète le paramètre no-iFC, il route la requête selon les procédures de la RFC 3261. En d'autres termes, le serveur 15 S-CSCF ne vérifie pas les critères de filtre initial. Un exemple de requête INVITE envoyée par le serveur d'application de continuité de service SCC AS selon ce deuxième mode de réalisation est le suivant. Les éléments ajoutés sont indiqués en gras : 20 5 15 20 25 30 INVITE sip:userl_public2@homel.net;gr=urn:uuid: f8ld4fae-7dec-lldO-a765-00a0c9le6bf6 SIP/2.0 Via: To: sip:userl_public2@homel.net; From: sip:interUEtransfer@sccasl.homel.net; tag=27365 Call-ID: cb03a0s09a2sdfglkj22222 CSeq: Max-Forwards: Route: <sip:scscf2.homel.net;lr;no-iFC> P-Asserted-Identity: Require: Referred-By: sip:userl publicl@nomel.net Contact: Allow: Content-Type: application/sdp Content-Length : G.)

v=0 o=- 1027933615 1027933615 IN 132.54.76.98 s=- c=IN IP4 132.54.76.98 t=0 0 m=audio 0 RTP/AVP 97 m=video 3002 RTP/AVP 98 99 b=AS:75 a=rtpmap:98 H263 a=fmtp:98 profile-level-id=0 a=rtpmap:99 MP4V-ES a=sendonly En référence à nouveau à la figure 1, le canal de signalisation d'accès avant transfert entre le terminal UE1 et le terminal UE2 est noté Cl et le canal de signalisation d'accès après transfert est noté C2. Grâce à l'invention, le serveur d'application de continuité de service demeure le plus proche du terminal utilisateur. 35

Claims (8)

1. REVENDICATIONS1. Procédé d'établissement d'un canal de signalisation d'accès pour une continuité de services entre un premier (UE1)et un second (UE2) terminal utilisateur dans un réseau de télécommunications, caractérisé en ce qu'il comporte les étapes suivantes, effectuées dans un serveur d'application de continuité de service (AS1) : - création (El, E10) d'une requête initiale à destination du second terminal utilisateur, la requête contenant un en-tête de type « Route », - insertion (E2, E20) dans l'en-tête de type « Route » d'une information pour inhiber la vérification de critères de filtre initial dans un serveur de fonction de contrôle de session d'appel (S-CSCF).
2. 2. Procédé selon la revendication 1, caractérisé en ce que l'étape d'insertion (E2) comporte l'ajout d'un identifiant uniforme de ressource de proxy P-CSCF et d'une adresse de contact du terminal utilisateur destinataire de la requête.
3. 3. Procédé selon la revendication 1, caractérisé en ce que l'étape d'insertion comporte (E20) l'ajout d'un paramètre spécifique d'identifiant uniforme de ressource à l'identifiant uniforme de ressource du serveur de fonction de contrôle de session d'appel (S-CSCF), le paramètre spécifique indiquant au serveur de fonction de contrôle de session d'appel (S-CSCF) de ne pas exécuter de critères de filtre initial.
4. 4. Serveur d'application de continuité de service (AS1) caractérisé en ce que, pour établir un canal de signalisation d'accès pour une continuité de services entre un premier et un second terminal utilisateur dans un réseau de télécommunications, il comporte : - des moyens de création (32) d'une requête initiale à destination du second terminal utilisateur, la requête contenant un en-tête de type « Route », - des moyens d'insertion (32) dans l'en-tête de type « Route » d'une information pour inhiber la vérification de critères de filtre initial dans un serveur de fonction de contrôle de session d'appel (S-CSCF).35
5. 5. Signal de données portant une requête émise par un serveur d'application de continuité de service (AS1) pour établir un canal de signalisation d'accès pour une continuité de services entre un premier et un second terminal utilisateur dans un réseau de télécommunications, à destination du second terminal utilisateur, caractérisé en ce qu'il comporte un en-tête de type « Route » comportant une information pour inhiber la vérification de critères de filtre initial dans un serveur de fonction de contrôle de session d'appel (S-CSCF).
6. 6. Serveur de fonction de contrôle de session d'appel (S-CSCF) adapté pour 1 o inhiber la vérification de critères de filtre initial lorsqu'il reçoit une requête émise par un serveur d'application de continuité de service (AS1) pour établir un canal de signalisation d'accès pour une continuité de services entre un premier et un second terminal utilisateur dans un réseau de télécommunications, à destination du second terminal utilisateur, ladite requête comportant un en-tête de type « Route » comportant 15 une information pour inhiber la vérification de critères de filtre initial.
7. 7. Programme d'ordinateur comportant des instructions pour l'exécution des étapes du procédé selon l'une quelconque des revendications 1 à 3 lorsque ledit programme est exécuté par un ordinateur.
8. 8. Support d'enregistrement lisible par un ordinateur sur lequel est enregistré un programme d'ordinateur comprenant des instructions pour l'exécution des étapes du procédé selon I l'une quelconque des revendications 1 à 3. 20 25