Brevet FR3022717A1 — publié le 20151225

PROCEDE DE SELECTION DYNAMIQUE PAR UN APPELANT PARMI UNE PLURALITE DE TERMINAUX D'UN APPELE La présente invention concerne les réseaux de communications de type IP (« Internet Protocol »), et notamment ceux parmi les réseaux IP qui sont aptes à mettre en oeuvre des protocoles de contrôle de session évolués. Les réseaux IP permettent la diffusion de données conversationnelles, dans le cadre de services tels que « Voix sur IP » (VolP), « Partage de Contenu », ou « Messagerie Instantanée ». Plus particulièrement, la présente invention concerne les moyens mis en place dans un réseau IP pour permettre à l'émetteur d'une requête d'obtenir les capacités techniques des dispositifs-clients du destinataire de la requête connectés audit réseau IP, de manière à pouvoir sélectionner, parmi ces dispositifs-clients, celui qui paraît le plus apte à satisfaire cette requête. Ces « dispositifs-clients » peuvent être, par exemple, un terminal fixe ou mobile, ou une passerelle soit domestique (« Residential Gateway» en anglais) soit située dans une entreprise. Par souci de brièveté, on utilisera fréquemment ci-dessous le terme générique de « terminal d'utilisateur », ou de « terminal » tout court, pour désigner ces divers équipements. Les services de communication sur réseau IP peuvent identifier des ressources physiques ou virtuelles au moyen de chaînes de caractères telles qu'une « URI » (initiales des mots anglais « Uniform Resource Identifier » signifiant « Identifiant Uniforme de Ressource »). La syntaxe des URIs est définie dans le document RFC 3986 de l'IETF ; la connaissance de l'URI d'une ressource permet d'obtenir l'adresse IP d'un équipement du réseau de l'opérateur gérant cette ressource. Dans la présente description, nous appellerons « URI » tout type d'identifiant de ressource applicative physique ou virtuelle accessible sur un réseau. 3022717 2 Les protocoles de contrôle de session évolués classiques, tels que le protocole SIP (initiales des mots anglais « Session Initiation Protocol » signifiant « Protocole d'Initiation de Session »), utilisent des messages dits de « signalisation », qui sont des messages permettant à un terminal de 5 demander une connexion avec un autre terminal, ou également des messages signalant qu'une ligne téléphonique est occupée, ou signalant que le téléphone appelé sonne, ou encore signalant que tel téléphone est connecté au réseau et peut être joint de telle ou telle manière. Le protocole SIP a été défini par l'IETF (Internet Engineering Task 10 Force) dans le document RFC 3261. Ce protocole permet l'établissement, la modification et la terminaison de sessions multimédia dans un réseau utilisant le protocole IP. Le protocole SIP a ensuite été étendu notamment dans le document RFC 3265. Cette extension définit des procédures de notification d'événements. 15 Le protocole SIP est utilisé en particulier dans les infrastructures de type IMS (initiales des mots anglais « IP Multimedia Subsystem » signifiant « Sous-système Multimédia sur IP »). L'IMS a été défini par l'organisme de normalisation 3GPP (« Third Generation Partnership Project ») et TISPAN (« Telecommunications and Internet Converged 20 Services and Protocols for Advanced Networking »). C'est une architecture de réseau introduite par le 3GPP pour les réseaux mobiles, puis reprise par TISPAN pour les réseaux fixes. Cette architecture permet l'établissement dynamique et le contrôle de sessions multimédia entre deux clients ainsi que la réservation des ressources au niveau du réseau 25 de transport des flux multimédias. Grâce à cette architecture, les opérateurs réseau peuvent commodément mettre en oeuvre une politique de gestion, fournir une Qualité de Service prédéterminée, et calculer les montants à facturer aux clients. L'IMS permet actuellement d'accéder à des services de type téléphonie, visiophonie, Présence et Messagerie Instantanée, dont elle gère aussi l'interaction. 3022717 3 Chaque usager d'un réseau IMS peut y être identifié au moyen de diverses identités, dont notamment l'IMPI (initiales des mots anglais « IP Multimedia Private Identity » signifiant « Identité Privée pour IP Multimédia ») et l'IMPU (initiales des mots anglais « IP Multimedia PUblic 5 identity » signifiant « Identité Publique pour IP Multimédia »). L'IMPI est défini dans la spécification TS 23.228 du 3GPP. L'IMPI est une identité affectée de manière permanente par l'opérateur d'un réseau à une souscription auprès de cet opérateur, et est utilisé, par exemple, pour l'enregistrement, l'autorisation d'accès, l'administration des 10 services offerts à l'usager, et la facturation (on notera qu'un usager peut avoir plusieurs IMPI au sein de la même souscription ; on peut ainsi associer chaque IMPI à un dispositif-client différent). L'IMPI a la forme d'un NAI (initiales des mots anglais « Network Access Identifier » signifiant « Identifiant d'Accès Réseau »), tel que défini dans le document RFC 15 4282 de l'IETF. Un usager se sert de son IMPU pour communiquer avec d'autres usagers. L'IMPU se présente sous la forme d'une URI ou d'un numéro court, ou encore d'un alias quelconque. Pour un IMPI donné, il peut y avoir plusieurs IMPU (souvent, une tel-URI et une SIP-URI). Un IMPU 20 peut être partagé avec un autre téléphone, de manière à ce que ces téléphones puissent être tous les deux joints avec la même identité (par exemple, un numéro de téléphone unique pour toute une famille d'usagers). Ces identités sont configurées par l'opérateur lors de la création par un usager d'un compte auprès de cet opérateur, et exploitées 25 lors de l'enregistrement d'un dispositif-client de l'usager sur le réseau. Lorsque donc un usager souhaite bénéficier des services offerts par un réseau IMS, il émet vers le réseau des messages de signalisation pouvant inclure notamment divers types de requêtes. Tout d'abord, le dispositif-client de l'usager doit, sauf exceptions 30 (telles que certains appels d'urgence), s'enregistrer sur le réseau. Lorsque 3022717 4 le réseau est incapable de faire le lien entre cet enregistrement et un enregistrement précédent (par exemple suite à une panne réseau, ou suite à un arrêt du dispositif-client pendant une durée supérieure à une valeur prédéterminée), l'enregistrement est considéré comme étant un 5 enregistrement initial. Après un enregistrement initial, le dispositif-client de l'usager doit envoyer périodiquement au réseau une requête pour confirmer qu'il souhaite maintenir son enregistrement. Pour pouvoir enregistrer les dispositifs-clients, les réseaux IMS comprennent un ou plusieurs serveurs d'enregistrement, appelés « S- 10 CSCF » (initiales des mots anglais « Serving-Gall Server Control Function » signifiant « Fonction de Commande de Session d'Appel Serveuse »), aptes (entre autres fonctions) à gérer la procédure d'enregistrement des dispositifs connectés au réseau. Les réseaux IMS comprennent en outre un ou plusieurs serveurs 15 d'interrogation, appelés « I-CSCF » (initiales des mots anglais « Interrogating-Cali Server Control Function » signifiant « Fonction de Commande de Session d'Appel Interrogatrice ») - d'ailleurs souvent combinés physiquement avec les serveurs d'enregistrement S-CSCF pour constituer des serveurs d'appel dénotés « I/S-CSCF » - qui, au moment 20 de l'enregistrement d'un dispositif-client, interrogent un serveur de données d'abonné appelé « HSS » (initiales des mots anglais « Home Subscriber Server » signifiant « Serveur d'Abonné de Rattachement »), afin de pouvoir sélectionner un serveur S-CSCF possédant les caractéristiques qui sont obligatoirement (et, le cas échéant, 25 optionnellement) requises pour atteindre le niveau de service souscrit par l'usager. Les serveurs HSS contiennent chacun une base de données-clients, et sont donc l'équivalent dans les réseaux IP des serveurs « HLR » (initiales des mots anglais « Home Location Register » signifiant « Registre de Localisation de Rattachement ») utilisés dans les réseaux 30 GSM. Chaque serveur HSS contient le « profil » d'un certain nombre de 3022717 5 dispositifs-clients du réseau, ce profil comprenant leur état d'enregistrement, des données d'authentification et de localisation, et les services souscrits. Dans le processus de création d'un compte d'usager sur un réseau 5 IMS, l'opérateur du réseau crée d'abord dans le HSS une souscription IMS, qui servira de fondement à la facturation. L'opérateur note ensuite, en référence à cette souscription, les identités privées IMPI et publiques IMPU des usagers partageant cette souscription, déclare leurs profils de services et les IFC (initiales des mots anglais « Initial Filter Criteria » 10 signifiant Critères de Filtrage Initiaux) associés, ainsi que de nombreuses autres informations relatives aux usagers. Les réseaux IMS comprennent en outre un ou plusieurs serveurs appelés « P-CSCF » (initiales des mots anglais « Proxy-Call Server Control Function » signifiant « Fonction de Commande de Session d'Appel 15 Mandataire »). Pour chaque dispositif-client connecté à un réseau IMS, il existe un serveur P-CSCF servant d'entité de raccordement entre le coeur de réseau IMS et le réseau d'accès utilisé par ce dispositif-client ; ainsi, toute la signalisation SIP échangée entre le dispositif-client d'une part, et le serveur d'interrogation I-CSCF ou le serveur d'enregistrement S-CSCF 20 d'autre part, passe par le serveur P-CSCF. Lorsqu'un premier usager (dit « appelant ») émet une requête à destination d'un second usager (dit « appelé »), l'appelant ne connaît pas (en général) les capacités du terminal de l'appelé, ou les capacités des terminaux de l'appelé lorsque ce dernier possède plusieurs terminaux 25 (typiquement, associés chacun à un IMPI respectif mais à un unique IMPU commun). Par « capacités d'un terminal », on entend, dans le cadre de la présente invention, la capacité technique de ce terminal à participer à la fourniture d'un service particulier, par exemple un service téléphonique, ou un service de Voix Haute Définition (HD), ou un service vidéo, ou encore 30 un service de messagerie instantanée. Or la connaissance de ces 3022717 6 capacités techniques serait fort utile à l'appelant, car cela lui permettrait de savoir - 1) si l'un des terminaux de l'appelé possède des capacités suffisantes pour le service souhaité par l'appelant, et 5 2) s'il existe un tel terminal, l'identité de ce terminal ou comment le joindre. On connaît dans l'état de l'art diverses propositions visant à résoudre ce problème. On connaît en particulier des solutions réseaux à base de 10 « serveurs d'applications » agrégeant les capacités de chacun des terminaux connectés d'un usager. Mais ces solutions ne reflètent pas les capacités de chacun des terminaux connectés à un instant donné, car c'est l'agrégation des capacités de l'ensemble des terminaux qui est présentée, et non les capacités individuelles de chacun des terminaux. 15 D'autres solutions, à base de « forking » (c'est-à-dire de transmission d'un signal de contrôle à une pluralité de destinataires), permettent d'explorer les capacités d'une partie (et non nécessairement de la totalité) des terminaux connectés, en leur envoyant une requête dédiée. Ce parcours peut en outre prendre un temps important en fonction 20 du nombre de terminaux connectés. Par exemple, dans le cas d'un forking « séquentiel », dans lequel l'appel est présenté séquentiellement à l'ensemble des terminaux jusqu'à l'expiration d'un temporisateur ou le décrochage éventuel d'un des terminaux apte à répondre à la requête de capacités, ce parcours pourra prendre beaucoup de temps, et l'on n'est 25 jamais certain que l'ensemble des terminaux a été parcouru. En résumé, aucune des solutions actuelles ne permet à un appelant de garantir la sélection du terminal appelé le plus apte à rendre correctement un service requis par l'appelant. La présente invention concerne donc un procédé de sélection, par 30 un premier usager d'un réseau IP, d'un dispositif-client parmi une pluralité 3022717 7 de dispositifs-client d'un second usager connectés audit réseau IP. Ledit procédé comprend les étapes suivantes : a) le dispositif-client dudit premier usager émet une requête à destination dudit second usager, ladite requête comprenant un indicateur 5 requérant la fourniture, par tout dispositif-client du second usager recevant cette requête, des capacités techniques de ce dispositif-client, et b) au moins un des dispositifs-client du second usager ayant reçu ladite requête contenant ledit indicateur répond au premier usager au moyen d'une requête indiquant les capacités techniques de ce dispositif- 10 client du second usager. Grâce à ces dispositions, un premier usager peut, par exemple lors de l'établissement d'une session, obtenir les capacités de chacun des terminaux appartenant à un certain second usager et connectés au réseau IP. 15 Selon des caractéristiques particulières, ledit procédé comprend en outre les étapes suivantes : c) après réception desdites requêtes envoyés par des dispositifs-client du second usager, le dispositif-client du premier usager sélectionne l'un de ces dispositifs-client du second usager sur la base au moins des 20 informations de capacités techniques contenues dans ces requêtes, d) le dispositif-client du premier usager émet, à destination du dispositif-client sélectionné, une réponse favorable à la requête émise lors de ladite étape b) par ce dispositif-client sélectionné, et e) le dispositif-client du premier usager et le dispositif-client 25 sélectionné entrent en session. Grâce à ces dispositions, le premier usager peut, sur la base des informations de capacité reçues, sélectionner le terminal du second usager le plus approprié pour rendre un service souhaité par le premier usager. 30 Selon des caractéristiques encore plus particulières : 3022717 8 - la requête émise par chaque dispositif-client respectif du second usager lors de ladite étape b) comprend un identifiant respectif de ce dispositif-client, et - le dispositif-client du premier usager insère l'identifiant dudit 5 dispositif-client sélectionné dans la réponse émise lors de ladite étape d) à destination de ce dispositif-client sélectionné. Grâce à ces dispositions, le premier usager peut connaître les capacités techniques de tous les dispositifs-clients du second usager présentement connectés au réseau IP, avant même de tenter 10 (éventuellement) d'établir une session avec ce second usager. Si par exemple aucun dispositif-client du second usager ne lui convient, le premier usager peut décider de ne pas tenter d'établir une session avec le second usager. Selon d'autres caractéristiques encore plus particulières : 15 - ladite requête émise par le dispositif-client du premier usager lors de ladite étape a) mentionne un service que le premier usager souhaite obtenir au cours de la session en cours d'établissement, et - lors de ladite étape d), le dispositif-client du premier usager émet une réponse défavorable aux requêtes envoyées lors de ladite étape b) 20 par les dispositifs-clients du second usager non sélectionnés. Grâce à ces dispositions, le premier usager peut rapidement, au moyen de l'indicateur selon l'invention, obtenir les informations nécessaires pour pouvoir choisir parmi les dispositifs-clients du second usager présentement connectés au réseau IP, le dispositif-client optimal 25 avec qui établir une session. Ce mode de réalisation est bien adapté au cas où le premier usager sait que le second usager possède plusieurs dispositifs-clients présentement connectés au réseau IP. Selon encore d'autres caractéristiques encore plus particulières : - préalablement à ladite étape a), le dispositif-client du premier 30 usager émet, à destination dudit second usager, une requête mentionnant 3022717 9 un service que le premier usager souhaite obtenir au cours de la session en cours d'établissement, et - lors de ladite étape d), le dispositif-client du premier usager émet une réponse défavorable aux requêtes envoyées lors de ladite étape b) 5 par les dispositifs-clients du second usager non sélectionnés. Grâce à ces dispositions, une première requête permet au premier usager d'obtenir une liste de dispositifs-clients appartenant au second usager et aptes à fournir le service souhaité, puis une deuxième requête permet au premier usager, au moyen de l'indicateur selon l'invention ou 10 d'une requête d'un type spécifique à l'invention, d'obtenir les informations nécessaires pour pouvoir choisir dans cette liste le dispositif-client optimal avec qui établir une session. Ce mode de réalisation est bien adapté au cas où le premier usager n'est pas sûr à l'avance si le second usager possède ou non une pluralité de dispositifs-clients présentement 15 connectés au réseau IP. Selon encore d'autres caractéristiques encore plus particulières, si aucun dispositif-client du second usager ayant émis lors de ladite étape b) une requête indiquant ses capacités techniques n'est techniquement apte à fournir un service souhaité par le premier usager, le dispositif-client du 20 premier usager sélectionne parmi ces dispositifs-clients du second usager, lors de ladite étape c), celui qui est le plus apte à fournir au premier usager un service de qualité réduite. Grâce à ces dispositions, le premier usager peut établir une session avec le second usager dans les meilleures conditions possibles en 25 pratique, compte tenu du service initialement souhaité. Corrélativement, l'invention concerne divers dispositifs. Elle concerne ainsi, premièrement, un dispositif-client, possédant des moyens pour : - émettre dans un réseau IP une requête à destination d'un usager, 30 dit second usager, dudit réseau IP, ladite requête comprenant un 3022717 10 indicateur requérant la fourniture, par tout dispositif-client dudit second usager recevant cette requête, des capacités techniques de ce dispositif-client du second usager, et - recevoir en réponse, de la part d'au moins un dispositif-client du 5 second usager ayant reçu la requête contenant ledit indicateur, une requête indiquant les capacités techniques de ce dispositif-client du second usager. Selon des caractéristiques particulières, ledit dispositif-client possède en outre des moyens pour, sur la base au moins des 10 informations de capacités techniques contenues dans lesdites requêtes reçues de la part de dispositifs-client du second usager, sélectionner l'un de ces dispositifs-client du second usager. L'invention concerne aussi, deuxièmement, un dispositif-client possédant des moyens pour : 15 - recevoir dans un réseau IP une requête comprenant un indicateur requérant la fourniture par ledit dispositif-client de ses capacités techniques, et - émettre en réponse une requête indiquant ses capacités techniques. 20 Les avantages offerts par ces dispositifs sont essentiellement les mêmes que ceux offerts par les procédés corrélatifs succinctement exposés ci-dessus. On notera qu'il est possible de réaliser ces dispositifs dans le contexte d'instructions logicielles et/ou dans le contexte de circuits 25 électroniques. L'invention vise également un programme d'ordinateur téléchargeable depuis un réseau de communication et/ou stocké sur un support lisible par ordinateur et/ou exécutable par un microprocesseur. Ce programme d'ordinateur est remarquable en ce qu'il comprend des 3022717 11 instructions pour l'exécution des étapes du procédé de sélection succinctement exposé ci-dessus, lorsqu'il est exécuté sur un ordinateur. Les avantages offerts par ce programme d'ordinateur sont essentiellement les mêmes que ceux offerts par ledit procédé. 5 D'autres aspects et avantages de l'invention apparaîtront à la lecture de la description détaillée ci-dessous de modes de réalisation particuliers, donnés à titre d'exemples non limitatifs. La description se réfère aux figures qui l'accompagnent, dans lesquelles : - la figure 1 représente schématiquement un système pour la 10 fourniture de services multimédia apte à mettre en oeuvre l'invention, et - la figure 2 représente schématiquement un mode de réalisation de l'invention dans lequel un usager A d'un réseau IMS souhaite placer un appel audio et vidéo vers un autre usager B du même réseau IMS. Bien que la présente invention concerne les réseaux IP en général, 15 on va considérer à présent, à titre d'exemple de réalisation, une architecture de réseau de type IMS, telle que présentée succinctement ci-dessus. Cette architecture est illustrée sur la figure 1. Les services multimédia offerts par ce réseau IMS 1 peuvent comprendre des services de téléphonie, de vidéo-téléphonie, de partage 20 de contenu (« content-sharing » en anglais), de Présence, de Messagerie Instantanée, ou de télévision. Ces services sont à la disposition de l'utilisateur d'un dispositif-client (« User Equipment », ou UE en anglais) 10 appartenant au réseau 1, qui permet au dispositif-client 10 d'échanger des flux multimédias et des signaux de contrôle de session conformes au 25 protocole SIP, par exemple avec le dispositif-client (non représenté) d'un usager appartenant à un réseau SIP (non représenté) relié au réseau 1. Le dispositif-client 10 peut être un terminal fixe ou mobile, ou une passerelle domestique ou d'entreprise, disposant de moyens de signalisation SIP et pouvant comprendre des moyens de restitution d'un 30 contenu audiovisuel. 3022717 12 Comme le montre la figure 1, ce réseau IMS 1 comprend, outre une infrastructure de transport IP (non représentée) : - au moins un serveur S-CSCF ; le serveur S-CSCF 27 gère notamment la procédure d'enregistrement des dispositifs connectés au réseau 1 ; le serveur S-CSCF 27 gère également le routage de la signalisation entre le dispositif-client 10 et les serveurs de messagerie vocale VM 25, de Messagerie Instantanée 26, et de téléphonie TAS 29 ; au moins un serveur I-CSCF ; le serveur I-CSCF 22 gère notamment le routage en direction d'autres terminaux gérés par le même réseau IMS 1 et le routage de la signalisation entre ce réseau IMS 1 et d'autres réseaux (non représentés) ; au moins un serveur P-CSCF ; le serveur P-CSCF 21 sert d'entité de raccordement entre le coeur de réseau IMS et le réseau d'accès utilisé par le dispositif-client 10 ; au moins un serveur de base de données, de type HSS ; le serveur HSS 24 contient le profil de l'utilisateur du dispositif-client 10 en termes de données d'authentification, de localisation et de services souscrits ; au moins un serveur VM 25 de messagerie vocale (« messagesummary » en anglais) ; le serveur VM 25 gère la souscription du dispositif-client 10 aux événements de dépôt/consultation des messages à l'intention du dispositif-client 10, et notifie le dispositif-client 10 lors de l'occurrence de ces événements ; au moins un serveur de Messagerie Instantanée IM 26 ; en cas de souscription de l'utilisateur de l'UE 10 au service de Messagerie Instantanée, cet utilisateur peut dialoguer « instantanément » en ligne avec d'autres abonnés à ce service ; et au moins un serveur de téléphonie TAS 29 ; le serveur TAS gère les services téléphoniques auxquels l'utilisateur du terminal 10 a 5 - 10 - 15 - 20 - 25 - - 30 3022717 13 souscrits auprès de son opérateur, tels que la présentation du numéro ou le renvoi d'appel. Les serveurs de messagerie vocale VM 25, de Messagerie Instantanée IM 26, et de téléphonie TAS 29 sont des exemples de 5 Serveurs d'Applications (AS). Certains services, comme ceux du serveur VM 25 et du serveur de Messagerie Instantanée IM 26, s'appuient sur la souscription du terminal 10 à des événements prédéterminés, comme expliqué ci-dessus. On va décrire à présent, en référence à la figure 2, plusieurs 10 modes de réalisation de l'invention, dans lesquels on suppose qu'un usager A d'un réseau IMS souhaite placer, par exemple, un appel audio et vidéo vers un autre usager B du même réseau IMS. Selon un premier mode de réalisation, on met en oeuvre les étapes suivantes. 15 Lors d'une étape E1, le terminal du premier usager A émet une requête SIP de type OPTIONS à destination du second usager B. Cette requête contient un indicateur selon l'invention (que l'on appellera « reversecap ») requérant la fourniture, par tout terminal du second usager B recevant cette requête, des capacités techniques de ce 20 terminal ; cet indicateur peut, par exemple, être inséré dans un en-tête (« header » en anglais) « Require » de la requête. Lors d'une étape E2, chaque terminal respectif du second usager B (c'est-à-dire, de 131 à B4) répond à la requête OPTIONS émise par le premier usager A en émettant à son tour à destination du premier usager 25 A une requête OPTIONS comprenant notamment un identifiant respectif du terminal émetteur, par exemple la mention (« featuretag » en anglais) classique « +sip.instance ». En outre, du fait de la présence dans la requête émise par le premier usager A de l'indicateur « reversecap », chaque requête OPTIONS émise par un terminal respectif du second 30 usager B contient les capacités techniques respectives de ce terminal ; la 3022717 14 présente invention propose ainsi une application nouvelle de la possibilité (prévue au Chapitre 11 du document RFC 3261 de l'IETF) pour deux terminaux d'échanger leurs capacités techniques respectives au moyen de requêtes OPTIONS. 5 Lors d'une étape E3, le terminal du premier usager A analyse les informations de capacités techniques contenues dans ces requêtes OPTIONS, et sélectionne l'un d'eux sur la base de ces informations et, optionnellement, de critères prédéterminés. De préférence, le terminal du premier usager A sélectionne le terminal du second usager B apte à 10 rendre un service optimal selon des critères prédéterminés ; ainsi, dans le présent exemple, le terminal du premier usager A pourrait sélectionner le terminal B3, car ce terminal (et lui seul) est compatible avec une session audio HD et vidéo HD, dans le cas où ces caractéristiques seraient souhaitables pour le premier usager A par rapport à une session audio ou 15 vidéo de définition standard ou faible. Lors d'une étape E4, le terminal du premier usager A envoie une requête INVITE au terminal sélectionné (dans le présent exemple, le terminal B3), en utilisant, dans cette requête INVITE, le featuretag +sip.instance de manière classique pour viser le terminal sélectionné. 20 Enfin, lors d'une étape E5, le terminal du premier usager A et le terminal B3 entrent en session audio-vidéo HD. Selon un deuxième mode de réalisation, on met en oeuvre les étapes suivantes. Lors d'une étape E'1, le terminal du premier usager A émet une 25 requête SIP de type INVITE vers le second usager B. Cette requête contient l'indicateur « reversecap » selon l'invention. Cette requête mentionne en outre un service (dans le présent exemple, une session audio et vidéo) que l'usager A souhaite obtenir au cours de la session en cours d'établissement. Pour ce faire, comme défini 30 dans les documents RFC 3840 et RFC 3841 de l'IETF, le terminal du 3022717 15 premier usager A insère par exemple, dans les en-têtes « Contact » et « Accept-contact » de sa requête, le featuretag « audio » et le featuretag « video » désignant les services souhaités. De même, le cas échéant, le featuretag « mmtel » désignerait un service téléphonique, le featuretag 5 « sip-im » désignerait un service de messagerie instantanée, et ainsi de suite. Comme expliqué ci-dessus en référence à la figure 1, la requête INVITE émise par le terminal de A est transmise au serveur S-CSCF (appelé S-CSCFA sur la figure 2) en charge de l'usager A, puis au serveur 10 I-CSCF aux fins de routage vers le serveur S-CSCF (appelé S-CSCFB sur la figure 2) en charge de l'usager B. Lors d'une étape E'2, conformément aux spécifications du document RFC 3841 de l'IETF, le serveur S-CSCFB transmet la requête (mécanisme de forking) à l'ensemble des terminaux techniquement aptes 15 pour une session audio et vidéo ; ainsi, les terminaux B2, B3 et B4 reçoivent la requête, mais le terminal B1 ne la reçoit pas car ce terminal est techniquement apte pour une session audio, mais pas pour une session vidéo. Lors d'une étape E'3, chacun des terminaux du second usager B 20 ayant reçu la requête émise par le premier usager A (en l'occurrence, les terminaux B2, B3 et B4) répond au premier usager A au moyen d'une requête de type OPTIONS indiquant ses capacités techniques, du fait de la présence, dans la requête émise par le premier usager A, de l'indicateur « reversecap ». 25 L'étape E'4 est analogue à l'étape E3 décrite ci-dessus en référence au premier mode de réalisation. Lors d'une étape E'5, le terminal du premier usager A répond : - favorablement (réponse SIP 200 OK) à la requête OPTIONS envoyée par le terminal sélectionné (B3 dans le présent exemple), qui va 30 continuer à présenter l'appel (par exemple, sonnerie d'appel), et 3022717 16 - défavorablement (par exemple, au moyen d'un code d'erreur spécifique à la présente invention) aux requêtes OPTIONS envoyées par les autres terminaux du second usager B (B2 et B4 dans le présent exemple), qui répondent alors à la requête INVITE reçue lors de l'étape 5 E'2 en indiquant (par exemple, au moyen d'un code SIP 487) qu'ils mettent fin à l'appel en cours. On peut prévoir que, pendant la phase de sélection d'un terminal du second usager B, les terminaux du second usager B ayant reçu la requête INVITE lors de l'étape E'2 sonnent, ou prévoir au contraire qu'ils ne 10 sonnent pas (par exemple sur détection de la présence du paramètre « reversecap » dans l'en-tête « Require ») de sorte que seul le terminal sélectionné se mettra à sonner (après réception de la réponse 200 OK envoyée par le premier usager A). Enfin, lors d'une étape E'6, le terminal du premier usager A et le 15 terminal B3 entrent en session audio-vidéo HD. Selon un troisième mode de réalisation, on met en oeuvre les étapes suivantes. Lors d'une étape E"1, le terminal du premier usager A émet une requête SIP de type INVITE à destination du second usager B. Cette 20 requête mentionne un service (dans le présent exemple, une session audio et vidéo) que l'usager A souhaite obtenir au cours de la session en cours d'établissement, en insérant par exemple le featuretag « audio » et le featuretag « video » dans les en-têtes « Contact » et « Accept-contact » de sa requête. 25 Mais, contrairement au premier et au deuxième mode de réalisation, cette première requête émise par le premier usager A ne contient pas d'indicateur requérant la fourniture, par tout terminal du second usager B recevant cette requête, des capacités techniques de ce terminal. 3022717 17 Lors d'une étape E"2, conformément aux spécifications du document RFC 3841 de l'IETF, le serveur S-CSCFB transmet la requête à l'ensemble des terminaux techniquement aptes pour une session audio et vidéo, c'est-à-dire, dans le présent exemple, aux terminaux B2, B3 et B4, 5 mais pas au terminal B1. Lors d'une étape E"3, le premier usager A reçoit des réponses de type « provisoire » (codes SIP 100 à 199) de la part de chacun des terminaux du second usager B ayant reçu la requête émise par le premier usager A (en l'occurrence, les terminaux B2, B3 et B4). 10 Lors d'une étape E"4, le premier usager A émet une deuxième requête SIP, par exemple une requête de type UPDATE contenant l'indicateur « reversecap » selon l'invention ou d'un type (que l'on appellera « REVOPTIONS ») spécifique à la présente invention, à destination des terminaux qui lui ont répondu (en l'occurrence, les 15 terminaux B2, B3 et B4), de manière à indiquer à ces terminaux du second usager B que le premier usager A souhaite connaître leurs capacités techniques. On met ensuite en oeuvre des étapes E"5 à E"8, qui sont respectivement analogues aux étapes E'3 à E'6 décrites ci-dessus en 20 référence au deuxième mode de réalisation. Dans l'exemple que l'on vient de décrire selon trois modes de réalisation, on a supposé que, non seulement plusieurs terminaux du second usager B étaient aptes à rendre le service souhaité par le premier usager A, mais que de surcroît l'un de ces terminaux (à savoir B3) était 25 apte à rendre un service de qualité optimale (audio HD et vidéo HD). Mais dans un autre cas de figure, il pourrait naturellement se produire qu'aucun des terminaux du second usager B ne soit apte à rendre le service souhaité par le premier usager A. On peut prévoir que, dans un tel cas, le terminal du premier usager A sélectionnera le terminal 30 de B le plus apte à fournir au premier usager A un service de qualité 3022717 18 réduite, selon des critères prédéterminés. Le terminal du premier usager A est en effet apte à opérer cette sélection suite à la réception des capacités des terminaux B comme décrit ci-dessus. De manière générale, la présente invention peut être mise en 5 oeuvre au sein des noeuds d'un réseau IP, par exemple des dispositifs- client, au moyen de composants logiciels et/ou matériels. Les composants logiciels pourront être intégrés à un programme d'ordinateur classique de gestion de noeud de réseau. C'est pourquoi, comme indiqué ci-dessus, la présente invention concerne également un 10 système informatique. Ce système informatique comporte de manière classique une unité centrale de traitement commandant par des signaux une mémoire, ainsi qu'une unité d'entrée et une unité de sortie. De plus, ce système informatique peut être utilisé pour exécuter un programme d'ordinateur comportant des instructions pour la mise en oeuvre de l'un 15 quelconque des procédés de sélection selon l'invention. En effet, l'invention vise aussi un programme d'ordinateur téléchargeable depuis un réseau de communication comprenant des instructions pour l'exécution des étapes d'un procédé de sélection selon l'invention, lorsqu'il est exécuté sur un ordinateur. Ce programme 20 d'ordinateur peut être stocké sur un support lisible par ordinateur et peut être exécutable par un microprocesseur. Ce programme peut utiliser n'importe quel langage de programmation, et se présenter sous la forme de code source, code objet, ou de code intermédiaire entre code source et code objet, tel que dans 25 une forme partiellement compilée, ou dans n'importe quelle autre forme souhaitable. L'invention vise aussi un support d'informations, inamovible, ou partiellement ou totalement amovible, lisible par un ordinateur, et comportant des instructions d'un programme d'ordinateur tel que 30 mentionné ci-dessus. 3022717 19 Le support d'informations peut être n'importe quelle entité ou dispositif capable de stocker le programme. Par exemple, le support peut comprendre un moyen de stockage, tel qu'une ROM, par exemple un CD ROM ou une ROM de circuit microélectronique, ou un moyen 5 d'enregistrement magnétique, tel qu'un disque dur, ou encore une clé USB (« USB flash drive » en anglais). D'autre part, le support d'informations peut être un support transmissible tel qu'un signal électrique ou optique, qui peut être acheminé via un câble électrique ou optique, par radio ou par d'autres moyens. Le 10 programme d'ordinateur selon l'invention peut être en particulier téléchargé sur un réseau de type Internet. En variante, le support d'informations peut être un circuit intégré dans lequel le programme est incorporé, le circuit étant adapté pour exécuter ou pour être utilisé dans l'exécution de l'un quelconque des 15 procédés de sélection selon l'invention. REVENDICATIONS1. Procédé de sélection, par un premier usager d'un réseau IP, d'un dispositif-client parmi une pluralité de dispositifs-client d'un second usager connectés audit réseau IP, ledit procédé comprenant les étapes suivantes : a) le dispositif-client dudit premier usager émet (E1, El , E"4) une requête (INVITE, UPDATE, REVOPTIONS, OPTIONS) à destination dudit second usager, ladite requête comprenant un indicateur (reversecap, REVOPTIONS) requérant la fourniture, par tout dispositif-client du second usager recevant cette requête, des capacités techniques de ce dispositif- client, et b) au moins un des dispositifs-client du second usager ayant reçu ladite requête contenant ledit indicateur (reversecap, REVOPTIONS) répond (E2, E'3, E"5) au premier usager au moyen d'une requête (OPTIONS) indiquant les capacités techniques de ce dispositif-client du second usager. 2. Procédé de sélection selon la revendication 1, caractérisé en ce qu'il comprend en outre les étapes suivantes : c) après réception desdites requêtes (OPTIONS) envoyés par des dispositifs-clients du second usager, le dispositif-client du premier usager sélectionne (E'4, E"6, E3) l'un de ces dispositifs-clients du second usager sur la base au moins des informations de capacités techniques contenues dans ces requêtes (OPTIONS), d) le dispositif-client du premier usager émet (E4, E'5, E"7), à destination du dispositif-client sélectionné, une réponse favorable (200 OK, INVITE) à la requête (OPTIONS) émise lors de ladite étape b) par ce dispositif-client sélectionné, et e) le dispositif-client du premier usager et le dispositif-client sélectionné entrent (E5, E'6, E"8) en session. 3022717 21 3. Procédé de sélection selon la revendication 2, caractérisé en ce que : - la requête (OPTIONS) émise (E2) par chaque dispositif-client respectif du second usager lors de ladite étape b) comprend un identifiant 5 respectif de ce dispositif-client, et - le dispositif-client du premier usager insère (E4) l'identifiant dudit dispositif-client sélectionné dans la réponse (INVITE) émise lors de ladite étape d) à destination de ce dispositif-client sélectionné. 4. Procédé de sélection selon la revendication 2, caractérisé en ce 10 que : - ladite requête (INVITE) émise par le dispositif-client du premier usager lors de ladite étape a) mentionne (E'1) un service que le premier usager souhaite obtenir au cours de la session en cours d'établissement, et 15 - lors de ladite étape d), le dispositif-client du premier usager émet (E'5) une réponse défavorable aux requêtes (OPTIONS) envoyées lors de ladite étape b) par les dispositifs-clients du second usager non sélectionnés. 5. Procédé de sélection selon la revendication 2, caractérisé en ce 20 que : - préalablement à ladite étape a), le dispositif-client du premier usager émet (E"1), à destination dudit second usager, une requête (INVITE) mentionnant un service que le premier usager souhaite obtenir au cours de la session en cours d'établissement, et 25 - lors de ladite étape d), le dispositif-client du premier usager émet (E"7) une réponse défavorable aux requêtes (OPTIONS) envoyées lors de ladite étape b) par les dispositifs-clients du second usager non sélectionnés. 3022717 22 6. Procédé de sélection selon la revendication 2, caractérisé en ce que, si aucun dispositif-client du second usager ayant émis lors de ladite étape b) une requête (OPTIONS) indiquant ses capacités techniques n'est techniquement apte à fournir un service souhaité par le premier usager, le 5 dispositif-client du premier usager sélectionne parmi ces dispositifs-clients du second usager, lors de ladite étape c), celui qui est le plus apte à fournir au premier usager un service de qualité réduite. 7. Dispositif-client, possédant des moyens pour : - émettre dans un réseau IP une requête (INVITE, UPDATE, 10 REVOPTIONS, OPTIONS) à destination d'un usager, dit second usager, dudit réseau IP, ladite requête comprenant un indicateur (reversecap, REVOPTIONS) requérant la fourniture, par tout dispositif-client dudit second usager recevant cette requête, des capacités techniques de ce dispositif-client du second usager, et 15 - recevoir en réponse, de la part d'au moins un dispositif-client du second usager ayant reçu la requête contenant ledit indicateur (reversecap, REVOPTIONS), une requête (OPTIONS) indiquant les capacités techniques de ce dispositif-client du second usager. 20 8. Dispositif-client selon la revendication 7, caractérisé en ce qu'il possède en outre des moyens pour, sur la base au moins des informations de capacités techniques contenues dans lesdites requêtes (OPTIONS) reçues de la part de dispositifs-client du second usager, sélectionner l'un de ces dispositifs-client du second usager. 25 9. Dispositif-client, possédant des moyens pour : - recevoir dans un réseau IP une requête (INVITE, UPDATE, REVOPTIONS, OPTIONS) comprenant un indicateur (reversecap, REVOPTIONS) requérant la fourniture par ledit dispositif-client de ses capacités techniques, et 3022717 23 - émettre en réponse une requête (OPTIONS) indiquant ses capacités techniques. 10. Moyen de stockage de données inamovible, ou partiellement 5 ou totalement amovible, comportant des instructions de code de programme informatique pour l'exécution des étapes d'un procédé de sélection selon l'une quelconque des revendications 1 à 6. 11. Programme d'ordinateur téléchargeable depuis un réseau de communications et/ou stocké sur un support lisible par ordinateur et/ou 10 exécutable par un microprocesseur, caractérisé en ce qu'il comprend des instructions pour l'exécution des étapes d'un procédé de sélection selon l'une quelconque des revendications 1 à 6, lorsqu'il est exécuté sur un ordinateur.