FR 3111496 A1 20211217 FR 2006511 A 20200622 Procédés et serveurs de gestion des services d’un terminal additionnel dans un réseau de cœur SIP Un procédé d’enregistrement d’un terminal additionnel comporte une étape (E30) de réception d’une requête d’enregistrement en provenance d’un client de voix sur IP. Il recherche (E35) une adresse IP connue de l’opérateur dans cette requête et crée (E40) un contexte (CTX) comportant une adresse représentative de l’adresse du client de voix sur IP et au moins une identité publique associée à un compte de voix sur IP dans un réseau de cœur SIP. Ce contexte (CTX) est utilisé par un procédé de gestion des appels sortants pour accéder à un service en utilisant un profil de service d’un compte associé à ladite identité publique. Il est aussi utilisé par un procédé de gestion des services entrants pour rediriger jusqu’au client de voix sur IP, un service entrant émis vers ladite identité publique dans ledit réseau. Fig. 3 Procédés et serveurs de gestion des services d’un terminal additionnel dans un réseau de cœur SIP 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 Generation 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 de carte SIM (en anglais Subscriber Identity Module) ou eSIM (en anglais embedded SIM). 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 connait 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. 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, ce procédé comportant : - une étape de réception d’une requête d’enregistrement d'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 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 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 et - une étape d’envoi d’une réponse destinée audit client SIP pour que celui-ci 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 au moins un service pour un terminal additionnel dans ce réseau; - 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 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 et - un module d’envoi d’une réponse destinée audit client SIP pour que celui-ci 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, ce procédé comportant : - une étape de réception d’une requête d’accès à un service émise par un client SIP considérant à tort être 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 est enregistrée dans un contexte en association avec une identité publique associée à un compte de voix sur IP 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, ce serveur comportant : - un module de réception d’une requête d’accès à un service émise par un client SIP considérant à tort être enregistré dans ledit réseau ; - un module 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 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, 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; - 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, 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 ; - 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 disc) 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. 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 : la figure 1 représente un serveur proxy conforme à l’invention dans son environnement. la figure 2 représente le serveur proxy de la figure 1 ; 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 ; la figure 4 représente un contexte pouvant être utilisé dans un mode particulier de réalisation ; 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 ; 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 ; la figure 7A représente l’architecture fonctionnelle d’un serveur d’enregistrement conforme à un mode de réalisation de l’invention ; 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 ; 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 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 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 NCS OP de cœur SIP d’un opérateur OP et qu’il bénéficie de services de voix sur IP. On appelle NUM TN le numéro téléphonique de cette ligne VoIP. Dans le mode de réalisation décrit ici, le réseau NCS OP 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 N AMZ géré par une entité AMZ fournisseur du terminal additionnel TA. Ce réseau N AMZ est interconnecté par une liaison Internet à un réseau N OP géré par l’opérateur OP, lui-même interconnecté au réseau de cœur NCS OP de cœur SIP. Dans le mode de réalisation décrit ici, le réseau N AMZ comporte un serveur web SW AMZ interconnecté à une base de données BD AMZ , un client SIP (User Agent) VoIP AMZ et un contrôleur SBC AMZ (en anglais Session Border Controller). Le serveur web SW AMZ administré par l’entité AMZ gère une pluralité de terminaux additionnels, dont le terminal additionnel TA. Dans le mode de réalisation décrit ici, le client SIP VoIP AMZ est un client de voix sur IP. Dans le mode de réalisation décrit ici, le serveur web SW AMZ 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 N OP de l’opérateur comporte un contrôleur SBC OP configuré pour communiquer avec le contrôleur SBC AMZ du réseau N AMZ , le serveur proxy 100 conforme à l’invention et un gestionnaire d’identités GI OP (en anglais Enabler Identity). Les contrôleurs SBC AMZ et SBC OP sont configurés pour établir un tunnel sécurisé TLS. On note ci-après : - @SW AMZ l’adresse IP du serveur Web SW AMZ ; elle est enregistrée dans une mémoire du terminal additionnel TA - @VoIPAMZ l’adresse du client SIP VoIP AMZ attaché au terminal additionnel TA; - @SBC AMZ l’adresse du contrôleur SBC AMZ ; - @SBC OP l’adresse du contrôleur SBC OP ; et - @100, l’adresse du serveur proxy 100 conforme à l’invention . On remarque que cette architecture est indépendante du réseau NCS OP de cœur SIP auquel est raccordé le terminal nominal TN de voix sur IP de l’utilisateur. 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 SRV REG configuré pour créer un contexte CTX suite à une demande d’enregistrement dans le réseau NCS OP de cœur SIP émise par le client SIP VoIP AMZ attaché au terminal additionnel TA ; - un serveur SRV AS configuré pour gérer les demandes d’accès à un service émises par le terminal additionnel TA en utilisant le contexte CTX ; - un serveur SRV IC 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 SRV REG joue le rôle d’un serveur SIP Registrar mais il n’enregistre pas le client SIP VoIP AMZ attaché au terminal additionnel TA dans le réseau NCS OP de cœur SIP. Dans le mode de réalisation décrit ici, le serveur SRV AS 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 SRV IC de gestion des services entrants est un serveur B2BUA ou un serveur proxy apte à interroger la base de données du serveur d’enregistrement SRV REG . 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 SW AMZ pour s’enregistrer dans le réseau NCS OP 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 @IP SOURCE fournie par le dispositif de traduction d’adresses NAPT (IPV4) et l’identifiant unique ID TA du terminal additionnel TA. L’adresse source @IP SOURCE 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 SW AMZ interroge (étape E10) la base de données BD AMZ 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 SW AMZ demande via une API Web, au cours d’une étape E15, l’activation d’un service, au niveau du client SIP VoIP AMZ . 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 @IP SOURCE . Au cours d’une étape E20, le client SIP VoIP AMZ du réseau N AMZ envoie une requête SIP REGISTER (requête d’enregistrement au sens de l’invention) à l’entité de bordure SBC AMZ du réseau N AMZ . Cette requête comporte : - des champs RURI, FROM et TO quelconques ; - un champ Contact et un champ Via comportant l’adresse @VoIP AMZ du client SIP VoIP AMZ ; et - un champ Instance-ID comportant l’adresse source @IP SOURCE . Dans le mode de réalisation décrit ici, le protocole de transport utilisé entre le client VoIP AMZ et le contrôleur SBC AMZ est le protocole UDP. Au cours d’une étape E25, l’entité de bordure SBC AMZ du réseau NAMZ encapsule la requête SIP REGISTER dans le tunnel sécurisé TLS créé avec le contrôleur SBC OP du réseau opérateur N OP . Les champs Contact et Via sont modifiés pour comporter l’adresse @SBC AMZ du contrôleur SBC AMZ . Au cours d’une étape E30, le contrôleur SBC OP du réseau opérateur N OP déchiffre le message et transfert la requête SIP REGISTER au serveur d’enregistrement SRV REG du serveur proxy 100. Pour cela, le contrôleur SBC OP 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@ SBC NOP du contrôleur SBC OP . Le protocole de transport utilisé entre le contrôleur SBC OP et le serveur proxy 100 peut par exemple être le protocole UDP, TCP, STCP … Au cours d’une étape E35, le serveur d’enregistrement SRV REG du dispositif100 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 @IP SOURCE 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 VoIP AMZ 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 GI OP 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 GI OP via une API. Plus précisément, dans le mode de réalisation décrit ici, lorsque le gestionnaire d’identités GI OP reçoit une adresse IP, il interroge sa base de données BD GI 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 GI OP 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 NCS OP . 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 NUM TN de la ligne VoIP associée. Il n’est pas nécessaire que le terminal nominal TN soit enregistré dans le réseau NCS OP . Il peut en particulier être éteint ou hors couverture radio. Au cours d’une étape E40, le serveur d’enregistrement SRV REG 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 SBC OP , mais elle est représentative de l’adresse @VoIP AMZ du client SIP VoIP AMZ attaché au terminal TA; - toutes les adresses IP du message SIP REGISTER et associées à un compte dans le gestionnaire d’identités GI OP 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 NUM TN 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 @IP SOURCE 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 NUM TN de la ligne VoIP du terminal nominal TN. Dans un mode de réalisation décrit ici, le serveur d’enregistrement SRV REG 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 SRV REG 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 SRV REG 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 GI OP. Au cours d’une étape E45, le serveur d’enregistrement SRV REG du serveur proxy 100 envoie une réponse 200 OK au contrôleur SBC OP . Cette réponse est destinée au client SIP VoIP AMZ attaché au terminal additionnel TA et elle comporte des informations permettant au client SIP VoIP AMZ 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 VoIP AMZ 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 VoIP AMZ 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 VoIP AMZ attaché au terminal additionnel TA du réseau N AMZ via le tunnel TLS établi entre les contrôleurs SBC OP et SBC AMZ . Le client SIP VoIP AMZ 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 VoIP AMZ attaché au terminal additionnel TA enregistre dans la base de données BD AMZ 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 VoIP AMZ 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 NUM TN 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 VoIP AMZ ignore l’entête P-Associated-URI du message SIP 200 OK. Au cours d’une étape E60, le client SIP VoIP AMZ attaché au terminal additionnel TA confirme l’activation du service au serveur Web SW AMZ . Au cours d’une étape E65, le serveur SW AMZ 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é NUM CALLED . Une requête REA d’établissement d’appel est transmise en HTTPS POST au serveur Web SW AMZ . Elle comporte l’adresse source @IP SOURCE du point d’accès AP et la commande vocale incluant le numéro NUM CALLED . Au cours d’une étape F10, le serveur Web SW AMZ applique un algorithme de reconnaissance vocale pour reconnaître la commande d’appel du numéro NUM CALLED , et interroge la base de données BD AMZ 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 BD AMZ . Si c’est le cas, au cours d’une étape F15, le serveur Web SW AMZ utilise une API du client SIP VoIP AMZ attaché au terminal additionnel TA pour demander l’établissement d’un appel sortant de voix sur IP vers le numéro NUM CALLED , en utilisant dans l’offre SDP (en anglais Session Description Protocol) les codecs supportés par la passerelle WebRTC du serveur Web SW AMZ et une adresse IP d’écoute @IP WRTC . Au cours d’une étape F20, le client SIP VoIP AMZ 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é NUM CALLED ; - dans le champ FROM : i/ une valeur aléatoire « aléa » si le client SIP VoIP AMZ 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 NUM TN , si le client SIP VoIP AMZ attaché au terminal additionnel TA supporte cet entête SIP P-Associated-URI ; - dans les champs CONTACT, VIA, l’adresse @VoIP AMZ du client SIP VoIP AMZ attaché au terminal additionnel TA, le paramètre Instance-ID étant valorisé par l’adresse source @IP SOURCE de la requête HTTPS d’établissement d’appel REA ; - dans le champ SDP, les informations fournies par la passerelle WebRTC du serveur Web SW AMZ ; et - dans le champ ROUTE, l’adresse @SBC AMZ du contrôleur SBC AMZ du réseau N AMZ . De manière optionnelle, si le client SIP VoIP AMZ 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 SBC AMZ 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 SBC AMZ : - l’adresse @IP SDP du SDP généré par la passerelle WebRTC est remplacée par l’adresse @SBC AMZ du contrôleur SBC AMZ ; - dans les champs CONTACT, VIA, l’adresse @VoIP AMZ est remplacée par l’adresse @SBC AMZ du contrôleur SBC AMZ , le paramètre Instance-ID est inchangé ; - dans le champ ROUTE, l’adresse @SBC AMZ est remplacée par l’adresse @SBC OP du contrôleur SBC OP du réseau N OP de l’opérateur OP. Le message SIP INVITE est envoyé dans le tunnel TLS au contrôleur SBC OP . Au cours d’une étape F30, le message SIP INVITE est modifié par le contrôleur SBC OP : - l’adresse @SBC AMZ du contrôleur SBC AMZ est remplacée par l’adresse @SBC OP du contrôleur SBC OP au niveau du paramètre SDP; - dans les champs CONTACT, VIA, l’adresse @SBC AMZ du contrôleur SBC AMZ est remplacée par l’adresse @SBC OP du contrôleur SBC OP , le paramètre Instance-ID est inchangé ; - dans le champ ROUTE, l’adresse @SBC OP du contrôleur SBC OP est remplacée par l’adresse @100 du serveur SRV AS de gestion des demandes d’accès à un service compris dans le serveur proxy 100. Le message SIP INVITE est routé jusqu’au serveur SRV AS 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 SRV AS 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 SRV AS 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 VoIP AMZ . De manière alternative ou complémentaire, le serveur SRV AS 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 SRV AS 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 VoIP AMZ 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 NUM TN 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 @SBC OP du contrôleur SBC OP 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 NCS OP 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 NCS OP . 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é NUM CALLED 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 NUM TN 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 NUM TN , 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 NUM TN 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 NUM TN et le paramètre Session=Orig pour que celui-ci exécute les services Originating. Si le numéro appelé NUM CALLED n’est pas barré via le service Originating, le message SIP INVITE est routé de manière classique jusqu’au destinataire NUM CALLED . Le client VoIP AMZ de voix sur IP attaché au terminal additionnel TA reçoit un code SIP provisoire 180 Ringing. Il notifie le serveur Web SW AMZ 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 N AMZ . 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 SRV IC de gestion des services entrants compris dans le dispositif proxy 100. On suppose qu’une identité NUM 100 attribuée au serveur SRV IC 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 NCS OP 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 SRV IC 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 SRV IC . 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 SRV REG . 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 SRV REG obtient, de la base de données BD GI du gestionnaire d’identités GI OP le numéro téléphonique NUM TN de la ligne VoIP associée au terminal nominal TN, il enregistre l’identité NUM 100 du serveur SRV IC 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 NCS OP 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 SRV IC 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é NUM 100 du serveur SRV IC 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é NUM 100 du serveur SRV IC 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 NUM TN 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 SRV IC 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 SRV IC 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 SRV REG (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 NUM TN . Si cette double condition n’est pas satisfaite, le serveur SRV IC 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 SRV IC 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 SRV IC modifie le message INVITE : - dans le champ RURI, l’identité NUM 100 du serveur SRV IC est remplacée par l’adresse @SBC OP de Contact comprise dans le contexte CTX, représentative de l’adresse @VoIP AMZ du client SIP VoIP AMZ attaché au terminal additionnel TA ; et - dans le champ TO, l’identité NUM 100 du serveur SRV IC est remplacée par l’identité publique IMPU NUM TN 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 SRV REG à 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 VoIP AMZ attaché au terminal additionnel TA via le contrôleur SBC OP de l’opérateur, le tunnel TLS et le contrôleur SBC AMZ du réseau N AMZ . Ce dernier notifie le serveur Web SW AMZ de l’appel entrant. Le serveur SBC AMZ recherche dans la base de données BD AMZ , l’identifiant unique ID TA de terminal additionnel TA associé à l’identité publique IMPU NUM TN 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 SRV REG , le serveur SRV AS de gestion des demandes d’accès à un service et le serveur SRV IC de gestion des appels entrants sont intégrés dans un serveur proxy 100. En variante, le serveur SRV REG , le serveur SRV AS de gestion des demandes d’accès à un service et le serveur SRV IC 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 SRV REG 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 SRV AS 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 SRV IC 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). Procédé d’enregistrement d’un terminal additionnel (TA) mis en œuvre par un serveur d’enregistrement (SRV REG ), ce procédé comportant : - une étape (E30) de réception d’une requête d’enregistrement en provenance d’un client SIP (VoIP AMZ ) apte à s’enregistrer dans un réseau (NCS OP ) de cœur SIP d’un opérateur (OP), pour activer au moins un service pour le terminal additionnel (TA) dans ledit réseau; - une étape (E35) de recherche d’au moins une adresse IP connue de l’opérateur (OP) dans ladite requête d’enregistrement ; - une étape (E40) de création d’un contexte (CTX) comportant au moins une adresse de contact (@SBC OP ) représentative de l’adresse (@VoIP AMZ ) du client SIP (VoIP AMZ ) et au moins une identité publique (NUM TN ) associée à un compte géré par l’opérateur dans ledit réseau (NCS OP ) et associé à ladite adresse IP, ce compte pouvant être utilisé pour fournir au moins un service audit terminal additionnel (TA) et - une étape (E45) d’envoi d’une réponse destinée audit client SIP (VoIP AMZ ) pour que celui-ci détermine les services dont le terminal additionnel (TA) peut bénéficier. Procédé d’enregistrement selon la revendication 1 dans lequel ledit contexte (CTX) comporte en outre ladite adresse obtenue au cours de ladite étape (E35) de recherche et associée audit compte. Procédé d’enregistrement selon la revendication 1 ou 2 dans lequel ledit contexte (CTX) 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 (TA). Procédé d’enregistrement selon l’une quelconque des revendications 1 à 3 dans lequel ledit contexte (CTX) est destiné à être utilisé pour : - déclencher (F40), dans ledit réseau (NCS OP ) de cœur SIP, l’établissement d’un service pour le client SIP (VoIP AMZ ) en utilisant un profil de service d’un compte associé à ladite identité publique (NUM TN ) et/ou pour - rediriger (G15) jusqu’au dit client SIP (VoIP AMZ ), un service dirigé vers ladite identité publique (NUM TN ) dans ledit réseau (NCS OP ) de cœur SIP. Procédé d’enregistrement selon l’une quelconque des revendications 1 à 4 dans lequel ladite requête d’enregistrement est une requête SIP REGISTER et en ce que ladite au moins adresse IP recherchée (E35) dans ladite requête d’enregistrement est comprise dans un champ IP source du paquet IP ou Instance-ID, Via, ou Contact de ladite requête. Procédé d’enregistrement selon l’une quelconque des revendications 1 à 5 dans lequel ledit au moins un service utilisable par ledit terminal additionnel (TA) est explicitement enregistré dans ledit contexte (CTX) et/ou précisé dans ladite réponse. Procédé d’enregistrement selon l’une quelconque des revendications 1 à 6 dans lequel une durée d’utilisation dudit au moins un service par ledit terminal additionnel (TA) est explicitement enregistrée dans ledit contexte (CTX) et/ou précisée dans ladite réponse. Procédé de gestion d’une demande (REA) émise par un terminal additionnel (TA) pour accéder à un service dans un réseau (NCS OP ) de cœur SIP, ce procédé comportant : - une étape (F30) de réception d’une requête d’accès à un service émise par un client SIP (VoIP AMZ ) considérant à tort être enregistré dans ledit réseau (NCS OP ) ; - une étape (F35) pour vérifier si au moins une information contenue dans la requête d’accès à un service est enregistrée dans un contexte (CTX) en association avec une identité publique (NUM TN ) associée à un compte géré par un opérateur dudit réseau (NCS OP ) ; - une étape (F40) d’envoi d’une requête à une entité du réseau (NCS OP ) de cœur SIP pour établir ledit service pour ledit client SIP (VoIP AMZ )en utilisant un profil de service dudit compte. Procédé de gestion selon la revendication 8 dans lequel ladite au moins une information est : - une adresse IP ; et/ou - une information contenue dans un champ FROM et/ou P-Preferred-ID de ladite requête. Procédé de gestion d’un service entrant dirigé vers un terminal additionnel (TA) d’un terminal nominal (TN), ce procédé étant mis en œuvre par un serveur (SRV IC ) de gestion des services entrants et comportant : - une étape préalable d’enregistrement d’une identité (NUM 100 ) attribuée audit serveur (SRV IC ) en tant qu’identité appelée secondaire du terminal nominal (TN) dans un serveur d’application téléphonique (TAS) pour déclencher un mécanisme de redirection d’un service dirigé vers ledit terminal nominal (TN) vers ledit serveur (SRV IC ) de gestion des services entrants ; - une étape (G05) de réception d’une requête d’établissement de service en provenance dudit serveur d’application téléphonique (TAS) ; - une étape (G10) pour vérifier si ladite requête d’établissement de service comporte une identité publique IMPU (NUM TN ) comprise dans un de ses champs et associée dans un contexte (CTX) à une adresse de contact (@SBC OP ) représentative de l’adresse (@VoIP AMZ ) d’un client SIP (VoIP AMZ ) ; - une étape (G15) 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 (VoIP AMZ ). Serveur d’enregistrement (SRV REG ) comportant : - un module (ME30) de réception d’une requête d’enregistrement en provenance d’un client SIP (VoIP AMZ ) apte à s’enregistrer dans un réseau (NCS OP ) de cœur SIP d’un opérateur (OP), pour activer au moins un service pour un terminal additionnel (TA) dans ledit réseau ; - un module (ME35) de recherche d’au moins une adresse IP connue de l’opérateur (OP) dans ladite requête d’enregistrement ; - un module (ME40) de création d’un contexte (CTX) comportant au moins une adresse de contact (@SBC OP ) représentative de l’adresse (@VoIP AMZ ) du client SIP (VoIP AMZ ) et au moins une identité publique (NUM TN ) associée à un compte géré par l’opérateur dans ledit réseau (NCS OP ) et associé à ladite adresse IP, ce compte pouvant être utilisé pour fournir au moins un service audit terminal additionnel (TA) et - un module (ME45) d’envoi d’une réponse destinée audit client SIP (VoIP AMZ ) pour que celui-ci détermine les services dont le terminal additionnel (TA) peut bénéficier. Serveur (SRV AS ) de gestion d’au moins une demande émise par un terminal additionnel (TA) pour accéder à un service dans un réseau (NCS OP ) de cœur SIP, ce serveur comportant : - un module (M30) de réception d’une requête d’accès à un service émise par un client SIP (VoIP AMZ ) considérant à tort être enregistré dans ledit réseau (NCS OP ) ; - un module (MF35) pour vérifier si au moins une information contenue dans ladite requête est enregistrée dans un contexte (CTX) en association avec une identité publique (NUM TN ) associée à un compte géré par un opérateur (OP) dudit réseau (NCS OP ) ; - un module (MF40) d’envoi d’une requête à une entité du réseau (NCS OP ) de cœur SIP pour établir ledit service pour ledit client SIP (VoIP AMZ ) en utilisant un profil de service dudit compte. Serveur (SRV IC ) de gestion des services entrants dirigés vers au moins un terminal additionnel (TA) d’un terminal nominal (TN), ce serveur comportant : - un module (MG05) de réception d’une requête d’établissement de service en provenance d’un serveur d’application téléphonique (TAS), ledit serveur téléphonique (TAS) comportant au moins un enregistrement d’une identité (NUM 100 ) attribuée audit serveur (SRV IC ) en tant qu’identité appelée secondaire du terminal nominal (TN) pour déclencher un mécanisme de redirection d’un service dirigé vers ledit terminal nominal (TN) vers ledit serveur (SRV IC ) de gestion des services entrants ; - un module (G10) pour vérifier si ladite requête d’établissement de service comporte une identité publique IMPU (NUM TN ) comprise dans un de ses champs et associée dans un contexte (CTX) à une adresse de contact (@SBC OP ) représentative de l’adresse (@VoIP AMZ ) d’un client SIP (VoIP AMZ ) ; - 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 (VoIP AMZ ). Serveur proxy SIP (100) comportant un serveur d’enregistrement (SRV REG ) selon la revendication 11, un serveur (SRV AS ) de gestion d’une demande d’accès à un service selon la revendication 12 et un serveur (SRV IC ) de gestion des services entrants selon la revendication 13. Programme d’ordinateur (PG) comportant des instructions configurées pour mettre en œuvre les étapes d’un procédé selon l’une quelconque des revendications 1 à 10 lorsqu’elles sont exécutées par un ordinateur (ORD).