Titre de l'invention : Procédés et serveurs de gestion des services d'un terminal additionnel dans un réseau de cœur SIP

Technique antérieure

La présente invention se situe dans le domaine des télécommunications et plus particulièrement dans le domaine des services VoIP (téléphonie, Visiophonie, RCS, SMSoIP,...) s'appuyant sur un cœur de réseau SIP (en anglais Session Initiation Protocol) fixe ou mobile, par exemple de type architecture standardisée 3GPP IMS (en anglais IP Multimedia Subsystem) ou bien encore d'architecture de type NGN (en anglais Next Génération Network).

Elle vise plus particulièrement des procédés et serveurs pour permettre à un terminal dit « additionnel » d'accéder à des services de voix sur IP dans de tels réseaux. Un terminal additionnel est par exemple un assistant vocal tel que les produits Alexa (marque déposée) et Google Home (marque déposée) proposés respectivement par les sociétés Amazon (marque déposée) et Google LLC (marque déposée).

Dans la présente demande, on appelle plus généralement « terminal additionnel » tout terminal qui partage son identité publique IMPU (en anglais IP Multimedia Public Identity) avec un terminal nominal et qui ne possède pas ou n'utilise pas de carte SIM (en anglais Subscriber Identity Module) ou eSIM (en anglais embedded SIM) pour s'enregistrer dans le réseau.

L'invention vise en particulier un mécanisme pour enregistrer un terminal additionnel dans le réseau, et lui permettre ensuite d'accéder à et/ou recevoir des services de voix sur IP.

On connaît principalement deux méthodes pour enregistrer et authentifier un terminal dans un réseau SIP.

Dans un réseau mobile, les identifiants SIP (en anglais credentials) sont stockés dans la carte SIM ou eSIM et le réseau cœur IMS mobile utilise un mode d'authentification EAP-AKA (en anglais Extensible Authentication Protocol - Authentification and Key Agreement) basé sur la dérivation des informations contenues dans la carte SIM/eSIM. Ce mécanisme est relativement simple.

En revanche, les terminaux fixes n'ont pas de carte SIM/eSIM. Ils ne peuvent donc pas s'enregistrer et s'authentifier selon le mécanisme EAP-AKA et doivent télécharger un fichier de configuration comportant notamment l'identité publique du terminal l'IMPU, l'identité privée du terminal IMPI (en anglais IP Multimedia Private Identity) et le mot de passe SIP pour permettre son authentification. L'authentification de ces terminaux est basée sur la méthode Digest RFC 2917. Ce mécanisme est plus compliqué, notamment parce qu'il nécessite le téléchargement du fichier de configuration.

L'intégration d'un terminal additionnel peut se faire en réseau fixe ou mobile. S'il est choisi d'intégrer le terminal additionnel dans un réseau mobile, le cœur IMS doit supporter à la fois l'authentification EAP-AKA pour l'enregistrement du terminal nominal mobile et le mode Digest pour l'assistant vocal qui ne comporte pas de carte SIM/eSIM.

Ce mécanisme d'enregistrement et la gestion de ces enregistrements dans le système d'information de l'opérateur sont complexes. Des informations d'enregistrement doivent être créées par le système d'information en temps réel pour chaque terminal additionnel détecté. Ces informations doivent être ajoutées au compte VoIP dans la base de données du cœur de réseau VoIP, puis être délivrées à la pile VoIP attachée au terminal additionnel, le tout de manière sécurisée... En outre, le cœur de réseau VoIP SIP doit être configuré pour autoriser l'enregistrement et traiter les services de communication de plusieurs terminaux partageant la même identité publique IMPU (activation du mode standardisée 3GPP Shared IMPU).

L'invention vise notamment à offrir un mécanisme simplifié d'enregistrement de ces terminaux additionnels, ce mécanisme étant sécurisé et facile à intégrer dans les réseaux fixes ou mobiles.

Exposé de l'invention

Plus précisément, et selon un premier aspect, l'invention concerne un procédé d'enregistrement d'un terminal additionnel mis en œuvre par un serveur d'enregistrement, ledit terminal additionnel étant un terminal qui partage son identité publique avec un terminal nominal, ce procédé comportant :

- une étape de réception d'une requête d'enregistrement d'en provenance d'un client SIP attaché au terminal additionnel et apte à s'enregistrer dans un réseau de cœur SIP d'un opérateur, pour activer au moins un service pour le terminal additionnel dans ce réseau ;

- une étape de recherche d'au moins une adresse IP connue de l'opérateur dans ladite requête d'enregistrement ;

- une étape de création d'un contexte comportant au moins une adresse de contact représentative de l'adresse du client SIP et au moins une identité publique associée à un compte dudit terminal nominal géré par l'opérateur dans ce réseau et associé à cette adresse IP, ce compte pouvant être utilisé pour fournir au moins un service audit terminal additionnel ;

- une étape de détermination d'au moins un service dont ledit terminal additionnel peut bénéficier ; et

- une étape d'envoi d'une réponse destinée audit client SIP et comportant des informations obtenues par le serveur d'enregistrement lors de ladite étape de détermination pour que ledit client SIP détermine les services dont le terminal additionnel peut bénéficier.

Corrélativement, l'invention concerne un serveur d'enregistrement comportant :

- un module de réception d'une requête d'enregistrement en provenance d'un client SIP apte à s'enregistrer dans un réseau de cœur SIP d'un opérateur, pour activer dans ledit réseau au moins un service pour un terminal additionnel auquel ledit client SIP est attaché, ledit terminal additionnel étant un terminal qui partage son identité publique avec un terminal nominal;

- un module de recherche d'au moins une adresse IP connue de l'opérateur dans ladite requête d'enregistrement ;

- un module de création d'un contexte comportant au moins une adresse de contact représentative de l'adresse du client SIP et au moins une identité publique associée à un compte dudit terminal nominal géré par l'opérateur dans ce réseau et associé à cette adresse IP, ce compte pouvant être utilisé pour fournir au moins un service audit terminal additionnel ;

- un module de détermination d'au moins un service dont ledit terminal additionnel peut bénéficier ;et

- un module d'envoi d'une réponse destinée audit client SIP et comportant des informations obtenues par le serveur d'enregistrement lors de ladite étape de détermination pour que ledit client SIP détermine les services dont le terminal additionnel peut bénéficier.

Ainsi, et de façon remarquable, l'invention propose un mécanisme d'enregistrement dans lequel le terminal additionnel n'est finalement pas techniquement enregistré dans le réseau de cœur SIP de l'opérateur mais dans le serveur d'enregistrement et bénéficie du compte de voix sur IP d'un terminal nominal enregistré dans le cœur SIP de l'opérateur auquel il est associé.

Dans un mode particulier de mise en œuvre de l'invention, le client SIP est un client de voix sur IP apte à activer au moins un service de voix sur IP pour le terminal additionnel et le compte géré par l'opérateur est un compte de voix sur IP du terminal nominal.

L'invention propose de découvrir l'identité publique IMPU de ce terminal nominal en analysant les adresses IP contenues dans les requêtes d'enregistrement émises pour enregistrer le terminal additionnel dans le serveur d'enregistrement SIP.

Dès lors que cet identifiant a été identifié, l'invention propose de ne pas poursuivre l'enregistrement du terminal additionnel dans le réseau de cœur SIP, de faire bénéficier au terminal additionnel de tout ou partie des services offerts par le compte de voix sur IP du terminal nominal et de répondre positivement à la requête d'enregistrement pour que le client SIP sur lequel s'appuie le terminal additionnel se considère dûment enregistré.

La gestion de l'enregistrement fictif du terminal additionnel et de tous les services s'appuie essentiellement sur le contexte créé par le serveur d'enregistrement.

L'invention est remarquable en ce que ce mécanisme d'enregistrement est totalement indépendant du réseau de cœur SIP.

Une difficulté résolue par l'invention est de découvrir l'identité publique IMPU du terminal nominal puis d'authentifier implicitement le terminal additionnel sur la base d'une adresse IP allouée par l'opérateur au point d'accès utilisé par le terminal additionnel. L'invention propose d'analyser toutes les adresses IP contenues dans la requête d'enregistrement et de vérifier si elles sont connues de l'opérateur et attachées à un compte de voix sur IP. Une telle adresse IP peut en particulier être une adresse attribuée à un point d'accès Internet qui fournit l'accès au terminal additionnel ou bien une adresse attribuée à un équipement réseau implémentant une fonction NAPT.

Dans un mode de réalisation, la requête d'enregistrement est une requête SIP REGISTER et les adresses IP sont recherchées dans les champs adresse IP source du paquet IP, ou Instance-ID, Via, ou Contact de cette requête.

Dans un mode de réalisation, ledit au moins un service utilisable par ledit terminal additionnel est explicitement enregistré dans ledit contexte et/ou précisé dans ladite réponse.

L'invention permet ainsi un mécanisme très fin de gestion des services offerts au terminal additionnel.

Dans un mode de réalisation, une durée d'utilisation du au moins un service par ledit terminal additionnel est explicitement enregistrée dans ledit contexte et/ou précisée dans ladite réponse. Cette durée peut par exemple être envoyée dans un paramètre Expires de la réponse pour inciter le client SIP à envoyer une nouvelle requête d'enregistrement avant l'expiration de cette durée. Il s'agit d'un mécanisme fictif puisque le terminal additionnel n'est pas enregistré en cœur de réseau SIP mais il permet avantageusement à l'opérateur de gérer dynamiquement les contextes utilisés par l'invention.

Dans un mode de réalisation de l'invention, la réponse à la requête d'enregistrement générée par le serveur d'enregistrement est négative si ce dernier détermine que la marque et/ou le type du terminal additionnel n'est pas autorisée. Ces informations de marque et/ou type de terminal additionnel peuvent être gérées directement par le serveur d'enregistrement ou être obtenues du serveur d'enregistrement à partir d'un serveur d'identités de l'opérateur.

Ces informations de marque et/ou type de terminal additionnel permettent au serveur d'enregistrement d'informer le terminal additionnel qu'il n'a pas l'autorisation d'accès aux services et donc qu'il ne doit pas re-solliciter le serveur d'enregistrement ce qui se traduit par une diminution de sa charge et potentiellement de celle du serveur d'identités de l'opérateur.

Ces informations de marque et/ou type de terminal additionnel préconfigurées dans ou obtenues par le serveur d'enregistrement permettent au serveur d'enregistrement de refuser la requête d'enregistrement par exemple sur la base d'un masque de l'adresse MAC de ces équipements et/ou sur la valeur du User Agent du terminal additionnel. Le serveur d'enregistrement peut ainsi refuser ou autoriser la requête d'enregistrement émise par un terminal additionnel en vérifiant si les informations contenues dans le champ Instance-ID et/ou User Agent de la requête d'enregistrement sont compatibles avec celles préconfigurées dans ou obtenues du serveur d'enregistrement.

Selon un deuxième aspect, l'invention concerne un procédé de gestion d'une demande émise par un terminal additionnel pour accéder à un service dans un réseau de cœur SIP, ledit terminal additionnel étant un terminal qui partage son identité publique avec un terminal nominal, ce procédé comportant :

- une étape de réception d'une requête d'accès à un service émise par un client SIP attaché audit terminal additionnel, ledit client SIP n'étant pas enregistré dans ledit réseau ;

- une étape pour vérifier si au moins une information contenue dans la requête d'accès à un service et représentative de l'adresse dudit client SIP est enregistrée dans un contexte en association avec une identité publique associée à un compte du dit terminal nominal géré par un opérateur dudit réseau ;

- une étape d'envoi d'une requête à une entité du réseau de cœur SIP pour établir ledit service pour le client SIP en utilisant un profil de service de ce compte.

Corrélativement, l'invention concerne un serveur de gestion d'au moins une demande émise par un terminal additionnel pour accéder à un service dans un réseau de cœur SIP, ledit terminal additionnel étant un terminal qui partage son identité publique avec un terminal nominal, ce serveur comportant :

- un module de réception d'une requête d'accès à un service émise par un client SIP attaché audit terminal additionnel, ledit client SIP n'étant pas enregistré dans ledit réseau ;

- un module pour vérifier si au moins une information contenue dans la requête et représentative de l'adresse dudit client SIP est enregistrée dans un contexte en association avec une identité publique associée à un compte dudit terminal nominal géré par un opérateur du réseau ;

- un module d'envoi d'une requête à une entité du réseau de cœur SIP pour établir le service pour le client de voix sur IP en utilisant un profil de service de ce compte.

Conformément à l'invention, le client SIP n'est pas techniquement enregistré dans le réseau. Il est enregistré dans le serveur d'enregistrement. On dit également qu'il est enregistré fictivement dans le réseau.

Dans un mode de réalisation, le contexte est destiné à être utilisé pour déclencher, dans le réseau de cœur SIP, l'établissement d'un appel entre le client SIP, ici un client de voix sur IP et un destinataire, la requête d'accès à un service étant une requête d'établissement d'appel SIP INVITE

La requête d'accès à un service peut aussi notamment être une requête SIP MESSAGE, SUBSCRIBE, OPTIONS, PUBLISH, REFER, ou INFO.

Ainsi et de façon très remarquable, la gestion de la demande d'accès à un service s'appuie sur le mode OOTB (en anglais (Out Of The Blue) standardisé du 3GPP. Ce mode de fonctionnement permet à un serveur certifié (en anglais « trusted ») par contrôle par exemple de son adresse IP d'accéder à un service pour le compte d'un utilisateur disposant d'une souscription VoIP sans être lui-même enregistré.

Par exemple, l'invention propose d'utiliser le mode OOTB pour la gestion des appels sortants notamment, pour permettre à un serveur certifié de passer des appels sortants pour le compte d'un utilisateur disposant d'une souscription VoIP sans être lui-même enregistré.

Ce mode de fonctionnement est par exemple utilisé par les serveurs de messagerie vocale pour offrir un service téléphonique de rappel du déposant ou pour un service téléphonique Click To Call. Comme décrit ultérieurement, l'information contenue dans la requête et recherchée dans le contexte est :

- une adresse IP ; et/ou

- une information contenue dans un champ FROM et/ou Preferred ID de la requête.

Dans un mode particulier de réalisation, le serveur de gestion des demandes d'accès à un service peut, comme le fait le serveur d'enregistrement, vérifier si les adresses IP contenues dans une requête d'accès à un service sont connues de l'opérateur et associées à un compte de voix sur IP dans le réseau, et lorsque c'est le cas, créer ou mettre à jour un contexte de sorte à gérer dynamiquement une nouvelle adresse IP qui vient tout juste d'être attribuée dynamiquement au point d'accès qui offre la connectivité au terminal additionnel.

Dans un mode de réalisation, le contexte comporte en outre l'adresse IP obtenue par le serveur d'enregistrement et utilisée pour identifier le compte et ce contexte est notamment destiné à être utilisé pour gérer les services entrants destinés au terminal additionnel.

Par conséquent, selon un troisième aspect, l'invention concerne un procédé de gestion d'un service entrant dirigé vers un terminal additionnel d'un terminal nominal, ledit terminal additionnel étant un terminal qui partage son identité publique avec ledit terminal nominal, ce procédé étant mis en œuvre par un serveur de gestion des services entrants et comportant :

- une étape préalable d'enregistrement d'une identité attribuée audit serveur en tant qu'identité appelée secondaire du terminal nominal dans un serveur d'application téléphonique pour déclencher un mécanisme de redirection d'un service dirigé vers ledit terminal nominal vers ledit serveur de gestion des services entrants ;

- une étape de réception d'une requête d'établissement de service en provenance dudit serveur d'application téléphonique ;

- une étape pour vérifier si ladite requête d'établissement de service comporte une identité publique IMPU comprise dans un de ses champs et associée dans un contexte à une adresse de contact représentative de l'adresse d'un client SIP attaché au terminal additionnel;

- une étape de transfert de ladite requête d'établissement de service vers l'adresse de contact pour qu'elle soit acheminée jusqu'au dit client SIP.

Corrélativement, l'invention concerne un serveur de gestion des services entrants dirigés vers au moins un terminal additionnel d'un terminal nominal, ledit terminal additionnel étant un terminal qui partage son identité publique avec ledit terminal nominal, ce serveur comportant :

- un module de réception d'une requête d'établissement de service en provenance d'un serveur d'application téléphonique, ce serveur téléphonique comportant au moins un enregistrement d'une identité attribuée audit serveur en tant qu'identité appelée secondaire du terminal nominal pour déclencher un mécanisme de redirection d'un service dirigé vers ledit terminal nominal vers ledit serveur de gestion des services entrants ;

- un module pour vérifier si ladite requête d'établissement de service comporte une identité publique IMPU comprise dans un de ses champs et associée dans un contexte à une adresse de contact représentative de l'adresse d'un client SIP attaché au terminal additionnel;

- un module de transfert de la requête d'établissement de service vers l'adresse de contact pour qu'elle soit acheminée jusqu'au dit client SIP .

Ainsi, et de façon remarquable, l'invention propose de s'appuyer sur les mécanismes de redirection connus de l'homme du métier pour gérer les services entrants, par exemple les appels entrants, dirigés vers le terminal additionnel.

Ces mécanismes de redirection peuvent par exemple être constitués par les services de renvoi simultanés ou séquentiels (en anglais « forking ») programmés dans les serveurs d'application téléphoniques pour gérer les services multi-terminaux.

Dans un mode de réalisation de l'invention, le contexte comporte en outre au moins une information de service définissant au moins un droit d'accès à un service pour au moins un type de terminal additionnel. Ces informations de service peuvent être gérées directement par le serveur d'enregistrement ou obtenues du serveur d'enregistrement à partir d'un serveur d'identités de l'opérateur.

Ces informations de service permettent au serveur de gestion des demandes d'accès à un service de ne pas solliciter le cœur de réseau VoIP pour un service non autorisé.

Ces informations de service obtenues par le serveur d'enregistrement et enregistrées dans le contexte comportent par exemple la marque ou le type des équipements autorisés à accéder à un service particulier, par exemple sur la base d'un masque de l'adresse MAC de ces équipements ou des informations du client SIP (User Agent) attaché au terminal additionnel. Le serveur de gestion des demandes d'accès à un service peut ainsi refuser ou autoriser l'accès à un service demandé par un terminal additionnel en vérifiant si les informations contenues dans le champ Instance-ID et/ou User Agent de la requête d'accès à un service sont compatibles avec celles enregistrées dans le contexte du terminal additionnel.

L'invention vise également un serveur proxy SIP comportant un serveur d'enregistrement, un serveur de gestion des demandes d'accès à un service et un serveur de gestion des services entrants tels que mentionnés ci-dessus.

Chacun des procédés mentionnés ci-dessus peut être mis en œuvre par un programme d'ordinateur.

Par conséquent, l'invention vise également un programme d'ordinateur sur un support d'enregistrement, ce programme étant susceptible d'être mis en œuvre dans un dispositif ou plus généralement dans un ordinateur. Ce programme comporte des instructions permettant la mise en œuvre d'au moins un procédé décrit ci-dessus. 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'information ou un support d'enregistrement lisibles par un ordinateur, et comportant des instructions d'un programme d'ordinateur tel que mentionné ci-dessus.

Le support d'information ou d'enregistrement peut être n'importe quelle entité ou dispositif capable de stocker les programmes. Par exemple, les supports peuvent comporter un moyen de stockage, tel qu'une ROM, par exemple un CD ROM ou une ROM de circuit microélectronique, ou encore un moyen d'enregistrement magnétique, par exemple une disquette (floppy dise) ou un disque dur, ou une mémoire flash.

D'autre part, le support d'information ou d'enregistrement peut être un support transmissible tel qu'un signal électrique ou optique, qui peut être acheminé via un câble électrique ou optique, par lien radio, par lien optique sans fil ou par d'autres moyens.

Le programme selon l'invention peut être en particulier téléchargé sur un réseau de type Internet.

Alternativement, le support d'informations ou d'enregistrement peut être un circuit intégré dans lequel un programme est incorporé, le circuit étant adapté pour exécuter ou pour être utilisé dans l'exécution de l'un des procédés tels que décrits précédemment.

Brève description des dessins

D'autres caractéristiques et avantages de la présente invention ressortiront de la description faite ci- dessous, en référence aux dessins annexés qui en illustrent un exemple de réalisation dépourvu de tout caractère limitatif. Sur les figures :

[Fig. 1] la figure 1 représente un serveur proxy conforme à l'invention dans son environnement.

[Fig. 2] la figure 2 représente le serveur proxy de la figure 1 ;

[Fig. 3] la figure 3 représente sous forme d'ordinogramme les principales étapes d'un procédé d'enregistrement conformément à un mode particulier de réalisation de l'invention ;

[Fig. 4] la figure 4 représente un contexte pouvant être utilisé dans un mode particulier de réalisation ;

[Fig. 5] la figure 5 représente sous forme d'ordinogramme les principales étapes de gestion d'une demande d'accès à un service conformément à un mode de réalisation de l'invention ;

[Fig. 6] la figure 6 représente sous forme d'ordinogramme les principales étapes de gestion d'un service entrant conformément à un mode de réalisation de l'invention ; [Fig. 7A] la figure 7A représente l'architecture fonctionnelle d'un serveur d'enregistrement conforme à un mode de réalisation de l'invention ;

[Fig. 7B] la figure 7B représente l'architecture fonctionnelle d'un serveur de gestion des demandes d'accès à un service conforme à un mode de réalisation de l'invention ;

[Fig. 7C] la figure 7C représente l'architecture fonctionnelle d'un serveur de gestion des services entrants conforme à un mode de réalisation de l'invention ; et

[Fig. 8] la figure 8 représente l'architecture matérielle de ces serveurs conformément à un mode de réalisation de l'invention.

Description détaillée de modes de réalisation particuliers

On considère par la suite le cas d'un utilisateur possédant un terminal nominal TN et au moins un terminal additionnel TA. Ce terminal additionnel TA ne comporte pas ou n'utilise pas de de carte SIM/eSIM.

La figure 1 représente un serveur proxy 100 conforme à l'invention dans son environnement.

On suppose que le terminal nominal TN est enregistré dans un réseau NCSOP de cœur SIP d'un opérateur OP et qu'il bénéficie de services de voix sur IP. On appelle NUMTN le numéro téléphonique de cette ligne VoIP.

Dans le mode de réalisation décrit ici, le réseau NCSOP de cœur SIP est un réseau IMS. En variante, ce réseau est un réseau NGN.

Dans le mode de réalisation décrit ici, le terminal additionnel TA est sous la couverture d'un point d'accès AP qui définit un réseau local sans fil WLAN.

Un dispositif de traduction d'adresses NAPT (en anglais Network Address Port Translation) connu de l'homme du métier, et intégré au point d'accès AP, établit une correspondance entre les adresses IPV4 privées du réseau WLAN et une adresse IPV4 publique attribué par le réseau à l'interface WAN (en anglais Wide Area Network) du point d'accès.

Dans le cas où le point d'accès qui fournit l'accès au terminal additionnel se fait attribuer une adresse IPV6 sur son interface WAN par l'opérateur, le point d'accès alloue aux terminaux connectés sur son LAN, une adresse IPV6 portant le même préfixe que celle de son interface WAN, les terminaux complétant la valeur de l'adresse IPV6 avec par exemple leur propre adresse MAC. Ces adresses IPV6 attribuées au point d'accès et aux terminaux connectés sur le LAN sont donc connues de l'opérateur.

Sur la figure 1, on a représenté un réseau NAMZ géré par une entité AMZ fournisseur du terminal additionnel TA. Ce réseau NAMZ est interconnecté par une liaison Internet à un réseau NOP géré par l'opérateur OP, lui-même interconnecté au réseau de cœur NCSOP de cœur SIP. Dans le mode de réalisation décrit ici, le réseau NAMZ comporte un serveur web SWAMZ interconnecté à une base de données BDAMZ, un client SIP (User Agent) VOIPAMZ et un contrôleur SBCAMZ (en anglais Session Border Controller). Le serveur web SWAMZ administré par l'entité AMZ gère une pluralité de terminaux additionnels, dont le terminal additionnel TA.

Ce client SIP VOIPAMZ est apte à s'enregistrer dans le réseau NCSOP de cœur SIP d'un opérateur pour activer au moins un service pour le terminal additionnel dans ledit réseau.

Dans le mode de réalisation décrit ici, le client SIP VOIPAMZ est un client de voix sur IP. Dans ce mode de réalisation, le client SIP VOIPAMZ est apte à s'enregistrer dans le réseau NCSOP pour activer le service de voix sur IP pour le terminal additionnel TA.

Dans le mode de réalisation décrit ici, le serveur web SWAMZ comporte une passerelle WebRTC configurée pour traiter les flux de signalisation et les flux média.

Dans le mode de réalisation décrit ici, le réseau NOP de l'opérateur comporte un contrôleur SBCOP configuré pour communiquer avec le contrôleur SBCAMZ du réseau NAMZ, le serveur proxy 100 conforme à l'invention et un gestionnaire d'identités GIOP (en anglais Enabler Identity). Les contrôleurs SBCAMZ et SBCOP sont configurés pour établir un tunnel sécurisé TLS.

On note ci-après :

- @SWAMZ l'adresse IP du serveur Web SWAMZ ; elle est enregistrée dans une mémoire du terminal additionnel TA

- @VOIPAMZ l'adresse du client SIP VOIPAMZ attaché au terminal additionnel TA;

- @SBCAMZ l'adresse du contrôleur SBCAMZ ;

- @SBCOP l'adresse du contrôleur SBCOP ; et

- @100, l'adresse du serveur proxy 100 conforme à l'invention.

La figure 2 représente le serveur proxy 100 dans un mode particulier de réalisation de l'invention. Dans le mode de réalisation décrit ici, le serveur proxy 100 comporte :

- un serveur SRVREG configuré pour créer un contexte CTX suite à une demande d'enregistrement dans le réseau NCSOP de cœur SIP émise par le client SIP VOIPAMZ attaché au terminal additionnel TA ;

- un serveur SRVAS configuré pour gérer les demandes d'accès à un service émises par le terminal additionnel TA en utilisant le contexte CTX ;

- un serveur SRVic configuré pour gérer les services entrants destinés au terminal additionnel TA en utilisant le contexte CTX ; et

- le contexte CTX.

Dans le mode de réalisation décrit ici, le serveur SRVREG joue le rôle d'un serveur SIP Registrar mais il n'enregistre pas le client SIP VOIPAMZ attaché au terminal additionnel TA dans le réseau NCSOP de cœur SIP. Dans le mode de réalisation décrit ici, le serveur SRVAS de gestion des demandes d'accès à un service est un serveur B2BUA (en anglais Back To Back User Agent) configuré pour émettre un appel en mode OOTB (en anglais Out Of The Blue) suite à une demande d'appel sortant émise par le terminal additionnel TA.

Dans le mode de réalisation décrit ici, le serveur SRVic de gestion des services entrants est un serveur B2BUA ou un serveur proxy apte à interroger la base de données du serveur d'enregistrement SRVREG.

La figure 3 représente sous forme d'ordinogramme les principales étapes d'un procédé d'enregistrement du terminal additionnel TA, conformément à un mode particulier de réalisation de l'invention.

Au cours d'une étape E05, le terminal additionnel TA envoie une requête d'activation HTTPS RACT au serveur Web SWAMZ pour s'enregistrer dans le réseau NCSOP de cœur SIP de sorte à pouvoir ultérieurement accéder à des services, notamment émettre et recevoir des appels de voix sur IP.

Cette requête comporte une adresse source @IPSOURŒ fournie par le dispositif de traduction d'adresses NAPT (IPV4) et l'identifiant unique IDTA du terminal additionnel TA. L'adresse source @IPSOURŒ est une adresse IPV4 publique correspondant à une adresse publique WAN du point d'accès AP.

Sur réception de cette requête, le serveur SWAMZ interroge (étape E10) la base de données BDAMZ pour vérifier que le terminal additionnel TA est un terminal connu de l'entité AMZ et autorisé par celle-ci à utiliser des services, par exemple de téléphonie.

Si tel est le cas, le serveur SWAMZ demande via une API Web, au cours d'une étape E15, l'activation d'un service, au niveau du client SIP VOIPAMZ. Dans le mode de réalisation décrit ici, on supposera que l'activation concerne l'activation d'un service de voix sur IP.

Cette demande d'activation comporte l'adresse source @IPSOURŒ.

Au cours d'une étape E20, le client SIP VOIPAMZ du réseau NAMZ envoie une requête SIP REGISTER (requête d'enregistrement au sens de l'invention) à l'entité de bordure SBCAMZ du réseau NAMZ. Cette requête comporte :

- des champs RURI, FROM et TO quelconques ;

- un champ Contact et un champ Via comportant l'adresse @VOIPAMZ du client SIP VOIPAMZ ; et

- un champ Instance-ID comportant l'adresse source @IPSOURŒ.

Dans le mode de réalisation décrit ici, le protocole de transport utilisé entre le client VOIPAMZ et le contrôleur SBCAMZ est le protocole UDP.

Au cours d'une étape E25, l'entité de bordure SBCAMZ du réseau NAMZ encapsule la requête SIP REGISTER dans le tunnel sécurisé TLS créé avec le contrôleur SBCOP du réseau opérateur NOP. Les champs Contact et Via sont modifiés pour comporter l'adresse @SBCAMZ du contrôleur SBCAMZ. Au cours d'une étape E30, le contrôleur SBCOP du réseau opérateur NOP déchiffre le message et transfert la requête SIP REGISTER au serveur d'enregistrement SRVREG du serveur proxy 100. Pour cela, le contrôleur SBCOP ajoute l'adresse @100 de ce serveur 100 dans l'entête Route du message. Les champs Contact et Via sont modifiés pour comporter l'adresse@ SBCNOP du contrôleur SBCOP.

Le protocole de transport utilisé entre le contrôleur SBCOP et le serveur proxy 100 peut par exemple être le protocole UDP, TCP, STCP ...

Au cours d'une étape E35, le serveur d'enregistrement SRVREG du dispositiflOO recherche dans le message SIP REGISTER l'adresse IP du point d'accès AP qui offre la connectivité au terminal additionnel TA.

Dans l'exemple décrit ici, cette adresse est l'adresse @IPSOURCE contenue dans le champ Instance-ID. Mais dans d'autres configurations cette adresse pourrait se trouver dans un autre champ du message SIP REGISTER, par exemple dans le champ SIP Via ou dans le champ SIP Contact. Cette adresse pourrait aussi être l'adresse IP source du paquet IP contenant le message SIP REGISTER, typiquement dans le cas où le client SIP VOIPAMZ attaché au terminal TA est directement intégré dans le terminal additionnel TA.

Par conséquent, au cours de l'étape E35, le serveur proxy Registrar 100 recherche toutes les adresses IP du message SIP REGISTER, et, pour chacune de ces adresses IP, le serveur proxy Registrar 100 interroge le gestionnaire d'identités GIOP pour obtenir les éventuelles informations concernant un service de voix sur IP, attaché à cette adresse IP.

C'est le cas si cette adresse IP (IPV4) ou si le préfixe de cette adresse IP (IPV6) a été attribué à un point d'accès et si ce service existe.

Dans le mode de réalisation décrit ici, le serveur proxy Registrar 100 interroge le gestionnaire d'identités GIOP via une API.

Plus précisément, dans le mode de réalisation décrit ici, lorsque le gestionnaire d'identités GIOP reçoit une adresse IP, il interroge sa base de données BDGI pour vérifier si cette adresse IP (ou préfixe en IPV6) a été attribuée par l'opérateur OP et si un service de voix sur IP géré par l'opérateur OP est attaché à cette adresse IP, et retourne dans sa réponse 200 OK, l'identité publique IMPU associée à ce compte de voix sur IP. En outre, le gestionnaire d'identités GIOP pourrait fournir des informations de service supplémentaires telles que par exemple un nombre maximal de terminaux additionnels autorisés, les marques et/ou type de terminaux additionnels autorisés et pouvant être retrouvés dans des champs du protocole SIP tel que le SIP User Agent, l'Instance-ID,..., des informations de service VoIP telles que l'autorisation des appels sortants et/ ou entrants exploitables, le nombre maximal d'appels simultanés autorisés pour les terminaux additionnels, l'autorisation d'accès aux services d'urgence, l'autorisation d'accès à des services à valeur ajoutée, l'autorisation d'accès à des correspondants fixe et/ou mobile nationaux et/ou internationaux, le support du service de visiophonie, le support des services de messagerie de type RCS (en anglais Rich Communication Suite), SMSoIP...ces informations pouvant être exploitées par le serveur Proxy 100 et limitant au strict minimum les interactions du serveur proxy 100 avec le cœur VoIP NCSOP.

Dans l'exemple de réalisation décrit ici, le terminal nominal TN bénéficie de services de voix sur IP, une de ces identités publiques IMPU est le numéro téléphonique NUMTN de la ligne VoIP associée. Il n'est pas nécessaire que le terminal nominal TN soit enregistré dans le réseau NCSOP. Il peut en particulier être éteint ou hors couverture radio.

Au cours d'une étape E40, le serveur d'enregistrement SRVREG du serveur proxy 100 crée un contexte CTX comportant :

- l'adresse comprise dans le champ Contact du message SIP REGISTER reçu à l'étape E30. Cette adresse est celle du contrôleur SBCOP, mais elle est représentative de l'adresse @VOIPAMZ du client SIP VOIPAMZ attaché au terminal TA;

- toutes les adresses IP du message SIP REGISTER et associées à un compte dans le gestionnaire d'identités GIOP et pour chacune d'elle la ou les identités publiques IMPU associées à ce compte de voix sur IP, dont nécessairement le numéro téléphonique NUMTN de la ligne VoIP du terminal nominal TN

- de manière optionnelle, les informations de services.

Un exemple de contexte CTX est représenté à la figure 4. Dans cet exemple on considère que la seule adresse IP du message SIP REGISTER et associée à un compte de voix sur IP est l'adresse @IPSOURŒ du point d'accès AP et que la seule identité publique IMPU associée à un compte de voix sur IP est le numéro téléphonique NUMTN de la ligne VoIP du terminal nominal TN.

Dans un mode de réalisation décrit ici, le serveur d'enregistrement SRVREG détermine de lui-même les services associés à ce compte de voix sur IP dont le terminal additionnel TA peut bénéficier, et il enregistre explicitement ces services dans le contexte CTX. Le serveur d'enregistrement SRVREG peut par exemple autoriser le terminal additionnel à émettre des appels et/ou à en recevoir.

Dans un autre mode de réalisation, le serveur d'enregistrement SRVREG détermine les services associés à ce compte de voix sur IP dont le terminal additionnel TA peut bénéficier sur la base des informations de services retournées par le gestionnaire d'identités GIOP.

Au cours d'une étape E45, le serveur d'enregistrement SRVREG du serveur proxy 100 envoie une réponse 200 OK au contrôleur SBCOP. Cette réponse est destinée au client SIP VOIPAMZ attaché au terminal additionnel TA et elle comporte des informations permettant au client SIP VOIPAMZ attaché au terminal additionnel TA de déterminer les services dont le terminal additionnel TA peut bénéficier. Dans le mode de réalisation décrit ici, par défaut, le terminal additionnel TA est autorisé à émettre et à recevoir des appels de voix sur IP.

Dans un mode de réalisation, les services utilisables par le terminal additionnel sont explicitement spécifiés dans la réponse SIP. Dans un mode de réalisation de l'invention, les services sont octroyés par le serveur d'enregistrement pour une durée déterminée, cette durée étant enregistrée dans le contexte CTX comme représenté à la figure 4.

Dans ce mode de réalisation, cette durée peut être envoyée dans un paramètre Expires de la réponse 200 OK pour inciter le client SIP VOIPAMZ attaché au terminal additionnel TA à envoyer une nouvelle requête d'enregistrement avant l'expiration de cette durée.

Dans le mode de réalisation décrit ici, la réponse 200 OK comporte également un champ P- Associated-URI comportant l'ensemble des identités publiques IMPU obtenues à l'étape E35. Ceci n'est pas obligatoire et il peut ne pas être interprétable par le client SIP VOIPAMZ attaché au terminal TA si celui-ci n'est pas conforme à l'IMS.

La réponse 200 OK est acheminée (étapes E50 et E55) jusqu'au client SIP VOIPAMZ attaché au terminal additionnel TA du réseau NAMZ via le tunnel TLS établi entre les contrôleurs SBCOP et SBCAMZ.

Le client SIP VOIPAMZ attaché au terminal additionnel TA est alors vu comme enregistré en cœur de réseau VoIP de l'opérateur OP mais il ne l'est pas d'un point de vue technique.

Le client SIP VOIPAMZ attaché au terminal additionnel TA enregistre dans la base de données BDAMZ le fait que le terminal additionnel TA est fictivement enregistré en cœur de réseau VoIP ainsi que la durée restante Expires de cet enregistrement fictif si celle-ci est présente dans la réponse 200 OK.

Si ce client SIP VOIPAMZ attaché au terminal additionnel TA est conforme à l'IMS, il peut aussi mémoriser les identités publiques IMPU du champ P-Associated-URI, dont le numéro de téléphone NUMTN si ce champ est présent dans la réponse 200 OK. Pour rappel, la première information présente dans ce champ P-Associated-URI est considérée comme étant l'identité publique par défaut. Cette information peut également lui permettre de sélectionner une identité publique préférée parmi la pluralité retournées lors des appels sortants en l'insérant dans le champ SIP FROM et/ou P- Preferred-Id. En outre, cette information peut être fournie au terminal additionnel TA si ce dernier peut restituer cette information à son utilisateur, le choix de l'identité publique IMPU utilisée pour l'appel étant alors effectué par l'utilisateur du terminal additionnel TA.

Sinon, le client SIP VOIPAMZ ignore l'entête P-Associated-URI du message SIP 200 OK.

Au cours d'une étape E60, le client SIP VOIPAMZ attaché au terminal additionnel TA confirme l'activation du service au serveur Web SWAMZ.

Au cours d'une étape E65, le serveur SWAMZ confirme l'activation du service au terminal additionnel TA. Il fournit éventuellement l'identité publique IMPU de la ligne VoIP.

La figure 5 représente sous forme d'ordinogramme les principales étapes de gestion d'une demande d'accès à un service émise par le terminal additionnel TA conformément à un mode de réalisation de l'invention.

Dans le mode de réalisation décrit ici, cette demande est une demande pour établir un appel sortant. Au cours d'une étape F05, un utilisateur du terminal additionnel TA demande, par une commande vocale, d'appeler le numéro appelé NUMCALLED. Une requête REA d'établissement d'appel est transmise en HTTPS POST au serveur Web SWAMZ. Elle comporte l'adresse source @IPSOURŒ du point d'accès AP et la commande vocale incluant le numéro NUMCALLED.

Au cours d'une étape F10, le serveur Web SWAMZ applique un algorithme de reconnaissance vocale pour reconnaître la commande d'appel du numéro NUMCALLED, et interroge la base de données BDAMZ pour déterminer si le terminal additionnel TA est fictivement enregistré dans le réseau de cœur SIP. Cette deuxième condition est vérifiée à partir de la valeur courante Expires enregistrée dans la base de données BDAMZ.

Si c'est le cas, au cours d'une étape F15, le serveur Web SWAMZ utilise une API du client SIP VOIPAMZ attaché au terminal additionnel TA pour demander l'établissement d'un appel sortant de voix sur IP vers le numéro NUMCALLED, en utilisant dans l'offre SDP (en anglais Session Description Protocol) les codées supportés par la passerelle WebRTC du serveur Web SWAMZ et une adresse IP d'écoute @IPWRTC.

Au cours d'une étape F20, le client SIP VOIPAMZ attaché au terminal additionnel TA génère un message SIP INVITE (requête d'établissement d'appel au sens de l'invention) comportant :

- dans les champs RURI et TO le numéro appelé NUMCALLED ;

- dans le champ FROM : i/ une valeur aléatoire « aléa » si le client SIP VOIPAMZ ne supporte pas l'entête SIP P- Associated-URI reçu dans la réponse 200 OK à l'étape E55 ; soit ii / le ou l'un des numéros de téléphone de la ligne VoIP du terminal nominal NUMTN, si le client SIP VOIPAMZ attaché au terminal additionnel TA supporte cet entête SIP P-Associated-URI ;

- dans les champs CONTACT, VIA, l'adresse @VOIPAMZ du client SIP VOIPAMZ attaché au terminal additionnel TA, le paramètre Instance-ID étant valorisé par l'adresse source @IPSOURŒ de la requête HTTPS d'établissement d'appel REA ;

- dans le champ SDP, les informations fournies par la passerelle WebRTC du serveur Web SWAMZ ; et

- dans le champ ROUTE, l'adresse @SBCAMZ du contrôleur SBCAMZ du réseau NAMZ.

De manière optionnelle, si le client SIP VOIPAMZ attaché au terminal additionnel TA supporte l'entête SIP P-Associated-URI et si l'utilisateur du terminal TA ne souhaite pas présenter l'identité publique IMPU par défaut à son correspondant appelé, le champ P-Preferred-ID peut être utilisé en le valorisant avec l'une des identités publiques IMPU présentes dans le champ P-Associated-URI reçue dans la réponse 200 OK REGISTER.

Dans le mode de réalisation décrit ici, le message SIP INVITE est routé jusqu'au contrôleur SBCAMZ selon un protocole de transport non sécurisé, par exemple UDP, TCP ou STCP.

Au cours d'une étape F25, le message SIP INVITE est modifié par le contrôleur SBCAMZ :

- l'adresse @IPSDP du SDP généré par la passerelle WebRTC est remplacée par l'adresse @SBCAMZ du contrôleur SBCAMZ ;

- dans les champs CONTACT, VIA, l'adresse @VOIPAMZ est remplacée par l'adresse @SBCAMZ du contrôleur SBCAMZ, le paramètre Instance-ID est inchangé ;

- dans le champ ROUTE, l'adresse @SBCAMZ est remplacée par l'adresse @SBCOP du contrôleur SBCOP du réseau NOP de l'opérateur OP.

Le message SIP INVITE est envoyé dans le tunnel TLS au contrôleur SBCOP.

Au cours d'une étape F30, le message SIP INVITE est modifié par le contrôleur SBCOP :

- l'adresse @SBCAMZ du contrôleur SBCAMZ est remplacée par l'adresse @SBCOP du contrôleur SBCOP au niveau du paramètre SDP;

- dans les champs CONTACT, VIA, l'adresse @SBCAMZ du contrôleur SBCAMZ est remplacée par l'adresse @SBCOP du contrôleur SBCOP, le paramètre Instance-ID est inchangé ;

- dans le champ ROUTE, l'adresse @SBCOP du contrôleur SBCOP est remplacée par l'adresse @100 du serveur SRVAS de gestion des demandes d'accès à un service compris dans le serveur proxy 100.

Le message SIP INVITE est routé jusqu'au serveur SRVAS de gestion des demandes d'accès à un service. Dans le mode de réalisation décrit ici, le message est transporté par un protocole de transport non sécurisé, par exemple UDP, TCP, STCP.

Au cours d'une étape F35, le serveur SRVAS de gestion des demandes d'accès à un service du serveur proxy 100 vérifie si une adresse IP contenue dans le message SIP INVITE est enregistrée dans un contexte CTX créé par le serveur SIP Registrar (étape E40). Cette adresse peut être par exemple l'adresse IP source du paquet IP contenant le message SIP INVITE, une adresse comprise dans le champ SIP Via ou dans le champ SIP Contact ou dans le paramètre Instance-Id. Si le serveur SRVAS trouve un contexte CTX comportant une adresse IP dans le message SIP INVITE, il autorise l'appel sortant. Sinon, il renvoie une réponse SIP 403 Forbidden ou 480 Calling Party not Registered au client SIP VOIPAMZ.

De manière alternative ou complémentaire, le serveur SRVAS du serveur proxy 100 vérifie si une identité publique IMPU contenue dans le message SIP INVITE au niveau des champs SIP FROM et/ou P-Preferred-ID est enregistrée dans un contexte CTX créé par le serveur SIP Registrar (étape E40).

Si le serveur SRVAS de gestion des demandes d'accès à un service intégré au serveur proxy 100 autorise l'appel sortant, au cours d'une étape F40 il modifie le message SIP INVITE :

- si le champ FROM comporte une valeur aléatoire (c'est le cas si le client SIP VOIPAMZ n'a pas interprété l'entête SIP P-Associated-URI reçu à l'étape E55), cette valeur est remplacée par le numéro de téléphone NUMTN associé à la ligne VoIP attribué au terminal nominal TN et mémorisé dans le contexte CTX ;

- au moins une identité appelante certifiée PAI (P-Asserted-ID) est ajoutée, correspondant à l'identité publique IMPU contenue dans le champ FROM et certifiée ;

- dans le champ CONTACT, l'adresse @SBCOP du contrôleur SBCOP est remplacée par l'adresse @100 du serveur proxy 100 ;

- dans le champ ROUTE, l'adresse @100 du serveur proxy est remplacée par l'adresse IP de l'entité I- CSCF (Interrogating Call Session Control Function) du réseau NCSOP et le paramètre « orig » est ajouté pour que l'appel entrant soit traité en mode OOTB comme s'il s'agissait d'un appel sortant émis par le terminal nominal TN.

Le message SIP INVITE est acheminé vers l'entité I-CSCF du réseau NCSOP.

De façon connue, lorsque l'I-CSCF détecte la présence du paramètre « orig » dans le champ ROUTE du message SIP INVITE, après avoir vérifié que le serveur proxy 100 est un équipement autorisé, il comprend qu'il doit traiter l'appel en mode OOTB. Il doit donc retrouver le profil de service VoIP du compte associé à l'identité publique IMPU certifiée présente dans l'identité appelante certifiée PAI du message SIP INVITE, c'est-à-dire au terminal nominal TN et non pas à celui du numéro appelé NUMCALLED du champ RURI ou TO.

Ce traitement est connu de l'homme du métier. Le I-CSCF consulte la base de données HSS via le protocole DIAMETER en lui envoyant un message LIR (Location Information Request) avec pour paramètre le numéro de téléphone NUMTN compris dans le paramètre PAI (P-Asserted-ID) du message SIP INVITE.

La base de données HSS retourne au I-CSCF l'adresse du S-CSCF prenant en charge cet abonné IMS.

L'entité S-CSCF dispose du profil du compte de service associé à l'identité publique NUMTN, autrement dit au terminal nominal TN.

Le S-CSCF modifie le message SIP INVITE. En particulier :

- un entête P-Served-User est ajouté et valorisé avec l'identité publique NUMTN avec le paramètre Session = Orig ;

- un champ ROUTE est ajouté et valorisé par l'adresse @TAS du serveur TAS

Le S-CSCF envoie le message SIP INVITE au serveur d'application téléphonique TAS (en anglais Telephony Application Server), le paramètre P-Served-User de ce message étant valorisé avec le numéro NUMTN et le paramètre Session=Orig pour que celui-ci exécute les services Originating.

Si le numéro appelé NUMCALLED n'est pas barré via le service Originating, le message SIP INVITE est routé de manière classique jusqu'au destinataire NUMCALLED.

Le client VOIPAMZ de voix sur IP attaché au terminal additionnel TA reçoit un code SIP provisoire 180 Ringing. Il notifie le serveur Web SWAMZ qui notifie à son tour le terminal additionnel TA et celui-ci génère un retour de sonnerie.

Le flux média est transmis en mode sécurisé via le protocole SRTP lorsque ce trafic emprunte le réseau IP Internet public puis en mode non sécurisé via le protocole RTP lorsque ce trafic emprunte le réseau NAMZ. Dans le mode de réalisation décrit précédemment le service accédé par le terminal additionnel TA est une demande d'appel en voix sur IP et la requête est une requête INVITE.

L'invention s'applique de la même façon pour accéder à d'autres services. Il suffit de rechercher l'information (adresse IP et/ou information contenue dans un champ FROM et/ou P-Preferred-ID) dans la requête MESSAGE, INFO, SUBSCRIBE, OPTIONS, REFER, PUBLISH émise par le client SIP pour demander l'accès à ce service.

La figure 6 représente sous forme d'ordinogramme les principales étapes de gestion d'un service entrant dirigé vers un terminal additionnel TA conformément à un mode de réalisation de l'invention.

Dans le mode de réalisation décrit ici, ce procédé est mis en œuvre par le serveur SRVic de gestion des services entrants compris dans le dispositif proxy 100.

On suppose qu'une identité NUMioo attribuée au serveur SRVic de gestion des services entrants a été préalablement enregistrée en tant que numéro appelé secondaire du terminal TN dans le serveur d'application téléphonique TAS du réseau NCSOP de cœur SIP de manière à ce que le serveur d'application téléphonique TAS déclenche, lorsqu'il détecte un service entrant dirigé vers le terminal nominal TN, un mécanisme de redirection de ce service, vers le serveur SRVic de gestion des services entrants.

Dans le mode de réalisation décrit ici, le service entrant est un appel en voix sur IP et le mécanisme de redirection est un renvoi d'appel simultané ou séquentiel de cet appel vers le serveur SRVic.

Cet enregistrement peut être fait pour tous les terminaux nominaux TN ou n'être fait que pour les terminaux nominaux TN associés à une identité publique IMPU enregistrée dans un contexte CTX. Par exemple, cet enregistrement peut être effectué par le serveur d'enregistrement SRVREG.

Ainsi, en reprenant l'exemple décrit à la figure 3 de l'enregistrement fictif du terminal additionnel TA, lorsqu'à l'étape E35, le serveur d'enregistrement SRVREG obtient, de la base de données BDGI du gestionnaire d'identités GIOP le numéro téléphonique NUMTN de la ligne VoIP associée au terminal nominal TN, il enregistre l'identité NUMioo du serveur SRVic de gestion des services entrants en tant que numéro appelé secondaire du terminal TN dans le serveur d'application téléphonique TAS.

Ainsi, et de façon connue, quand un appel entrant destiné à l'identité publique IMPU du terminal nominal TN contenue dans les header SIP RURI et TO d'un message SIP INVITE est présenté à un réseau NCSOP de cœur SIP, le serveur d'application téléphonique TAS dirige cet appel vers le terminal nominal TN, puis simultanément ou séquentiellement vers le serveur SRVic de gestion des services entrants. Un tel mécanisme est connu de l'homme du métier sous le nom de « forking ».

Plus précisément, et de façon connue de l'homme du métier, le serveur d'application téléphonique TAS génère un appel sortant de type renvoi d'appel avec :

- l'exécution des services Originating. Le serveur TAS vérifie en particulier que l'identité NUMioo du serveur SRVic est bien autorisée par le service Outgoing Call Barring : - génération d'un message SIP INVITE sortant dans lequel:

- les champs RURI et TO comportent l'identité NUMioo du serveur SRVic de gestion des services entrants ;

- les champs FROM et PAI comportent les informations FROM & PAI du message SIP INVITE reçu par le TAS ;

- le champ CONTACT comporte l'adresse @TAS du serveur d'application téléphonique TAS ;

- un champ de redirection DIVERSION et/ou HISTORY INFO comporte l'identité publique IMPU NUMTN de la ligne VoIP appelée, le paramètre cause de renvoi étant valorisé à FollowMe, et le compteur de renvoi étant valorisé à 1.

Ce message INVITE est reçu par le serveur SRVic de gestion des services entrants compris dans le dispositif proxy 100 au cours d'une étape G05.

Au cours d'une étape G10, le serveur SRVic de gestion des services entrants recherche :

- si le message SIP INVITE comporte un entête SIP de redirection DIVERSION ou HISTORY INFO ; et lorsque c'est le cas

- si un contexte CTX créé par le serveur d'enregistrement SRVREG (comme décrit en référence à la figure 3) comporte l'identité publique IMPU comprise dans ce champ de redirection DIVERSION ou HISTORY INFO, en l'espèce l'identité publique NUMTN.

Si cette double condition n'est pas satisfaite, le serveur SRVic répond un code erreur SIP, par exemple 404 Not Found ou 480 Temporarily Unavailable ou 403 Forbidden.

Si aucun contexte n'est trouvé, le serveur SRVic répond un code erreur SIP, par exemple 404 Not Found ou 480 Temporarily Unavailable ou 403 Forbidden.

Si un contexte CTX est trouvé, au cours d'une étape G15, le serveur SRVic modifie le message INVITE :

- dans le champ RURI, l'identité NUMioo du serveur SRVic est remplacée par l'adresse @SBCOP de Contact comprise dans le contexte CTX, représentative de l'adresse @VOIPAMZ du client SIP VOIPAMZ attaché au terminal additionnel TA ; et

- dans le champ TO, l'identité NUMioo du serveur SRVic est remplacée par l'identité publique IMPU NUMTN contenue dans le champ SIP de redirection DIVERSION ou HISTORY-INFO. Il s'agit d'une identité publique IMPU du champ P-Associated-URI du message SIP 200 OK généré par le serveur d'enregistrement SRVREG à l'étape E45.

Le champ SIP de redirection DIVERSION et/ou HISTORY INFO peut être supprimé.

Le message SIP modifié est routé vers le client SIP VOIPAMZ attaché au terminal additionnel TA via le contrôleur SBCOP de l'opérateur, le tunnel TLS et le contrôleur SBCAMZ du réseau NAMZ.

Ce dernier notifie le serveur Web SWAMZ de l'appel entrant. Le serveur SBCAMZ recherche dans la base de données BDAMZ, l'identifiant unique IDTA de terminal additionnel TA associé à l'identité publique IMPU NUMTN contenue dans le TO du message SIP INVITE, puis notifie l'appel entrant au terminal additionnel TA.

Dans le mode de réalisation décrit précédemment, le serveur SRVREG, le serveur SRVAS de gestion des demandes d'accès à un service et le serveur SRVic de gestion des appels entrants sont intégrés dans un serveur proxy 100.

En variante, le serveur SRVREG, le serveur SRVAS de gestion des demandes d'accès à un service et le serveur SRVic de gestion des appels entrants peuvent être des équipements distincts qui partagent le contexte CTX.

La figure 7A représente l'architecture fonctionnelle du serveur d'enregistrement SRVREG dans un mode particulier de réalisation. Il comporte :

- un module ME30 de réception d'une requête d'enregistrement en provenance d'un client SIP apte à s'enregistrer dans un réseau de cœur SIP d'un opérateur pour activer au moins un service pour un terminal additionnel ;

- un module ME35 de recherche d'au moins une adresse IP connue de l'opérateur dans cette requête d'enregistrement ;

- un module ME40 de création d'un contexte comportant au moins une adresse de contact représentative de l'adresse du client SIP attaché au terminal additionnel TA et au moins une identité publique associée à un compte géré par l'opérateur dans ledit réseau, ce compte pouvant être utilisé pour fournir au moins un service au terminal additionnel et

- un module ME45 d'envoi d'une réponse destinée audit client SIP attaché au terminal additionnel TA pour que celui-ci détermine les services dont le terminal additionnel peut bénéficier.

La figure 7B représente l'architecture fonctionnelle du serveur SRVAS de gestion d'au moins une demande d'accès à un service émise par un terminal additionnel TA pour accéder à un service dans un réseau de cœur SIP, dans un mode particulier de réalisation. Ce serveur comportant :

- un module MF30 de réception d'une requête d'accès à un service émise par un client SIP et considérant à tort être enregistré dans ce réseau;

- un module MF35 pour vérifier si au moins une information contenue dans la requête est enregistrée dans un contexte en association avec une identité publique associée à un compte géré par cet opérateur dans le réseau, cette information pouvant être une adresse IP et/ou une information contenue dans un champ FROM et/ou P-Preferred-ID de la requête ;

- un module MF40 d'envoi d'une requête à une entité du réseau de cœur SIP pour établir ledit service pour le client SIP attaché au terminal additionnel TA en utilisant un profil de service de ce compte.

La figure 7C représente l'architecture fonctionnelle du serveur SRVic de gestion des services entrants destinés dirigés vers un terminal additionnel d'un terminal nominal dans un mode particulier de réalisation. Ce serveur comporte :

- un module MG05 de réception d'une requête d'établissement de service en provenance d'un serveur d'application téléphonique, ce serveur téléphonique comportant au moins un enregistrement d'une identité attribuée audit serveur en tant que numéro appelé secondaire du terminal nominal pour déclencher un mécanisme de redirection d'un service destiné audit terminal nominal vers ledit serveur de gestion des services entrants ;

- un module MG10 pour vérifier si ladite requête d'établissement de service comporte une identité publique IMPU comprise dans un de ses champs et associée dans un contexte à une adresse de contact représentative de l'adresse d'un client SIP ;

- un module MG15 de transfert de la requête d'établissement de service vers l'adresse de contact pour qu'elle soit acheminée jusqu'au dit client SIP attaché au terminal additionnel TA.

Chacun de ces serveurs peut avoir l'architecture matérielle d'un ordinateur tel que représenté à la figure 8.

Cet ordinateur ORD comporte notamment un processeur 10, une mémoire vive de type RAM 11, une mémoire morte de type ROM 12, une mémoire non volatile réinscriptible de type Flash 14 et des moyens de communication 13.

La mémoire morte 12 constitue un support conforme à un mode particulier de réalisation de l'invention. Cette mémoire comporte un programme d'ordinateur PG conforme à un mode particulier de réalisation de l'invention, qui lorsqu'il est exécuté par le processeur 10, met en œuvre un ou plusieurs des procédés d'enregistrement, de gestion des appels sortants ou de gestion des appels entrants conformes à l'invention et décrits précédemment en référence aux figures 3, 5 et 6.

Dans le mode de réalisation décrit ici, la mémoire 14 de l'ordinateur ORD comporte un contexte CTX tel que décrit précédemment, notamment en référence à la figure 4.

Dans l’exemple de la figure 1 , le dispositif de traduction d'adresses NAPT est intégré dans le module AP : il établit une correspondance entre les adresses IPV4 privées du réseau WLAN et une adresse IPV4 publique attribué par le réseau à l'interface WAN. La fonction de traduction d’adresses peut aussi être mise en œuvre dans un équipement réseau de type CGN (Carrier Grade NAT).