FR 3090252 A1 20200619 FR 1873056 A 20181217 Description Titre de l'invention: Procédé de basculement d'une communication de TCP sur UDP Technique antérieure [0001] 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 » (VoIP), « Partage de Contenu », ou « Messagerie Instantanée ». [0002] Plus particulièrement, la présente invention concerne les moyens mis en place dans un réseau IP pour appliquer une temporisation sur un ensemble de transactions entre deux dispositifs-clients, ou entre un dispositif-client et un serveur, ou encore entre deux serveurs, lorsque ces transactions sont logiquement liées entrent-elles. [0003] Ces « dispositifs-clients » peuvent être, par exemple, un terminal fixe ou mobile, ou une passerelle résidentielle (« Residential Gateway » en anglais) soit domestique ou 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. [0004] 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 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. 100051 Le protocole SIP a été défini par l' IETF (Internet Engineering Task 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 W. 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. 100061 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 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 2 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 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. [0007] 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. [0008] Tout d'abord, le dispositif-client de l'usager doit, sauf exceptions (telles que certains appels d'urgence), s'enregistrer sur le réseau. Lorsque 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 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. [0009] Pour pouvoir enregistrer les dispositifs-clients, les réseaux IMS comprennent un ou plusieurs serveurs d'enregistrement, appelés « S-CSCF » (initiales des mots anglais « Serving-Cali Server Con trol 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. [0010] Les réseaux IMS comprennent en outre un ou plusieurs serveurs d'interrogation, appelés « I-CSCF » (initiales des mots anglais « Interrogating-Call Server Con trol 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 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 SCSCF possédant les caractéristiques qui sont obligatoirement (et, le cas échéant, 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 GSM. Chaque serveur HSS contient le « profil » d'un certain 3 nombre de dispositifs-clients du réseau, ce profil comprenant leur état d'enregistrement, des données d'authentification et de localisation, et les services auxquels il a droit. [0011] En effet, après qu'un serveur S-CSCF lui a été ainsi attribué, chaque utilisateur peut faire usage d'un certain nombre de services pendant la session en cours. Il peut par exemple s'agir de services offerts automatiquement à tous les utilisateurs du réseau IMS. Il peut aussi s'agir de services auxquels cet utilisateur a souscrit auprès de l'opérateur du réseau, et qui sont mis automatiquement à sa disposition. Enfin, il peut s'agir de services dont l'utilisateur peut faire usage après avoir émis une requête appropriée (SIP SUBSCRIBE). [0012] Ces services comprennent des applications audiovisuelles telles que mentionnées ci- dessus. Il peut s'agir également d'une souscription à l'état d'une ressource réseau, auquel cas des notifications d'évènement (SIP NOTIFY) sont envoyées au dispositif-client dès lors que l'état de la ressource change ; par exemple, lorsque l'utilisateur d'un dispositif-client dispose dune boîte vocale sur le réseau, il pourra être informé chaque fois qu'un message a été enregistré sur cette boîte vocale ; un utilisateur peut, de même, demander à être notifié de l'état d'enregistrement de son propre dispositif-client. [0013] 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 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'inten-ogation I-CSCF ou le serveur d'enregistrement S-CSCF d'autre part, passe par le serveur P-CSCF. [0014] Les protocoles de transport majoritairement utilisés par les applications logicielles pour communiquer sur Internet sont TCP (initiales des mots anglais « Transmission Con trol Protocol » signifiant « Protocole de Contrôle de Transmission ») et UDP (initiales des mots anglais « User Data grain Protocol » signifiant « Protocole de Datagramme Utilisateur »). A ce titre, les moyens techniques permettant à un dispositif-client (« User Equipment », ou UE en anglais) d'optimiser l'usage des ressources réseaux disponibles en fonction des besoins et des contraintes des applications reposant sur TCP ou UDP, sont de nature à apporter une amélioration significative du niveau de qualité associé à l'utilisation de telles applications. De plus, certains acteurs de l'Intemet sont en train d'expérimenter à grande échelle des solutions alternatives à TCP qui reposent sur UDP (et, plus précisément, sur un schéma d'encapsulation). De ce point de vue, les fournisseurs de service et opérateurs de réseaux IP ont à coeur de fournir un niveau de qualité d'utilisation comparable entre des applications reposant sur TCP et celles reposant sur UDP. [0015] Or les opérateurs rencontrent un problème récurrent de congestion des ressources TCP sur les équipements réseau lorsque ce protocole de transport est utilisé par le protocole SIP (transport imposé en particulier lorsque les messages à émettre ont une taille supérieure à 1300 octets). En effet, le mode de transport TCP met en oeuvre pour chaque connexion des files d'attentes, des algorithmes de retransmissions, des fenêtres d'anticipation, des temporisateurs, et ainsi de suite. Par suite, il est un fort consommateur d'opérations processeur (CPU) et de mémoire, qui sont des ressources limitées dans tout système informatique. La pénurie de ressources TCP peut empêcher les dispositifs-clients de se connecter au réseau IMS, voire d'établir de nouveaux appels via ce mode de transport, les demandes de nouvelles connexions TCP étant refusées par manque de ressources. [0016] Ce problème est particulièrement gênant dans le cas où une fonction NAT (initiales des mots anglais « Network Address Translation » signifiant « traduction d'adresse réseau ») est mise en oeuvre dans le réseau d'accès, car dans cc cas les connexions TCP doivent persister tant que l'utilisateur est enregistré ! Pour ce type de configuration, particulièrement consommateur en ressources, il n'existe actuellement aucun moyen pour forcer une libération « propre » des connexions. [0017] Cette situation est absurde car le trafic venant des terminaux pourrait être écoulé en utilisant UDP plutôt que TCP puisque le protocole SIP est compatible avec ces deux modes de transport. Contrairement à TCP, le protocole UDP est très peu consommateur de ressources mémoire et CPU : en effet, UDP ne gère aucun temporisateur, n'a aucune mémoire des paquets reçus (pas de retransmission, de fenêtre d'anticipation, ou de contrôle de séquencement). [0018] Malheureusement, si les normes en vigueur imposent un basculement d'UDP vers TCP en certaines circonstances (lorsque les messages à émettre ont une taille supérieure à 1300 octets), ce qui peut conduire à une situation de pénurie de ressources TCP, elles ne permettent pas de forcer les terminaux à basculer (ou revenir) sur UDP en cas de dépassement d'un seuil de congestion en TCP. Exposé de l'invention [0019] La présente invention concerne donc, selon un premier aspect, un procédé de bas- culement dans un réseau mettant en oeuvre le protocole de contrôle de session SIP. Ledit procédé comprend les étapes suivantes : un dispositif dudit réseau émet une requête SIP vers le coeur de réseau en utilisant le protocole de transport TCP, le coeur de réseau envoie une réponse au dispositif lui demandant, au moyen d'un indicateur dédié, d'utiliser le protocole de transport UDP au lieu du protocole de transport TCP s'il émet une future requête SIP, et suite à la réception de cette réponse, si le dispositif émet une future requête SIP, il utilise pour ce faire le protocole de transport UDP. [0020] Ainsi, r invention propose une évolution de la norme SIP pour introduire un mécanisme de basculement vers le mode de transport UDP. Cela peut être particulièrement utile en cas de congestion TCP, mais ce basculement pourrait être généralisé à d'autres cas d'utilisation, par exemple lorsque c'est le mode de transport TCP lui-même qui pose problème. [0021] Grâce à ces dispositions, l'équipement réseau concerné, tel qu'un serveur P-CSCF, un serveur S-CSCF, ou un Serveur d'Applications (AS), sera capable de réguler l'usage des ressources TCP, et pourra implanter différentes politiques de gestion d'une pénurie de ressources, en fonction du degré d'utilisation des ressources TCP. Cet équipement réseau pourra, par exemple : à un premier niveau de congestion, demander la réémission sur UDP d'un appel émis sur TCP par un client résidentiel sans privilèges, à un deuxième niveau, généraliser cette procédure à tous les types d'appels et de messages, et à un troisième niveau, demander en outre le récnregistrement en UDP et la suppression de toutes les connexions TCP établies par le client, y compris le cas échéant une connexion associée à une fonction NAT telle que mentionnée ci-dessus. [0022] Selon des caractéristiques particulières, ladite réponse comprend également un code dédié pour demander audit dispositif de réémettre ladite requête SIP en utilisant UDP au lieu de TCP. [0023] Selon d'autres caractéristiques particulières, ladite réponse comprend également un en-tête dédié pour demander audit dispositif d'utiliser UDP s'il émet au moins une nouvelle requête SIP. [0024] Selon des caractéristiques encore plus particulières, ladite réponse précise également au moins un type de méthode SIP concerné par cette demande. [0025] Selon d'autres caractéristiques encore plus particulières, ladite réponse précise également une durée d'application. [0026] Selon un deuxième aspect, l'invention concerne un serveur réseau comprenant un agent SIP, ainsi que des moyens pour : recevoir de la part d'un dispositif dudit réseau une requête SIP émise en utilisant le protocole de transport TCP, envoyer audit dispositif une réponse lui demandant, au moyen d'un indicateur dédié, d'utiliser le protocole de transport UDP au lieu du protocole de transport TCP s'il émet une future requête SIP. 6 [0027] Selon des caractéristiques particulières, ladite réponse comprend également un code dédié pour demander audit dispositif de réémettre ladite requête SIP en utilisant UDP au lieu de TCP. [0028] Selon d'autres caractéristiques particulières, ladite réponse comprend également un en-tête dédié pour demander audit dispositif d'utiliser UDP s'il émet au moins une nouvelle requête SIP. [0029] Selon des caractéristiques encore plus particulières, ladite réponse précise également au moins un type de méthode SIP concerné par cette demande. [0030] Selon d'autres caractéristiques encore plus particulières, ladite réponse précise également une durée d'application. [0031] Selon un troisième aspect, l'invention concerne un dispositif comprenant un agent SIP, ainsi que des moyens pour : [0032] - émettre une requête SIP vers un coeur de réseau en utilisant le protocole de transport TCP, recevoir dudit coeur de réseau une réponse lui demandant, au moyen d'un indicateur dédié, d'utiliser le protocole de transport UDP au lieu du protocole de transport TCP s'il émet une future requête SIP, et suite à la réception de cette réponse, utiliser le protocole de transport UDP s'il émet une future requête SIP. [0033] On notera que cc dispositif pourra, par exemple, être hébergé par un dispositif-client ou par une passerelle résidentielle. [0034] Selon des caractéristiques particulières, ledit dispositif comprend en outre des moyens pour inclure une étiquette dédiée dans ladite requête SEP. [0035] Grâce à ces dispositions, le dispositif informe le réseau de sa compatibilité avec la présente invention. [0036] Les avantages offerts par ces serveurs et ces dispositifs sont essentiellement les mêmes que ceux offerts par les procédés corrélatifs succinctement exposés ci-dessus. [0037] On notera qu'il est possible de réaliser ces serveurs et ces dispositifs dans le contexte d'instructions logicielles et/ou dans le contexte de circuits électroniques. [0038] 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 instructions pour l'exécution des étapes du procédé de basculement succinctement exposé ci-dessus mises en oeuvre par le premier dispositif lorsque ces étapes sont exécutées sur un ordinateur, ou pour l'exécution des étapes du procédé de basculement succinctement exposé ci-dessus mises en oeuvre par le second dispositif lorsque ces étapes sont exécutées sur un ordinateur. [0039] Les avantages offerts par ce programme d'ordinateur sont essentiellement les mêmes 7 que ceux offerts par ledit procédé. Brève description des dessins [0040] 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 à : [0041] [fie.11 la figure 1 qui l'accompagne, et qui représente schématiquement un système pour la fourniture de services multimédia apte à mettre en oeuvre l'invention. [0042] Description de modes de réalisation [0043] Bien que la présente invention concerne les réseaux IP en général, 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 I. [0044] 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, dc partage 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 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 protocole S1P, par exemple avec le dispositif-client (non représenté) d'un usager appartenant à un réseau S1P (non représenté) relié au réseau 1. [0045] Le dispositif-client 10 peut être un terminal fixe ou mobile, ou une passerelle do- mestique ou d'entreprise, disposant de moyens de signalisation SI P et pouvant comprendre des moyens dc restitution d'un contenu audiovisuel. [0046] Comme le montre la figure 1, cc 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 1-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 8 contient le profil de l'utilisateur du dispositif-client 10 en termes de données d'authentification et de localisation, et de services souscrits ; au moins un serveur VM 25 de messagerie vocale (« message-sumtnary » 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 dc Messagerie Instantanée IM 26 ; en cas de souscription de l'utilisateur de ruE 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 dc téléphonie TAS 29 ; le serveur TAS gère les services téléphoniques auxquels l'utilisateur du terminal 10 a souscrits auprès de son opérateur, tels que la présentation du numéro ou le renvoi d'appel. [0047] Les serveurs de messagerie vocale VM 25, de Messagerie Instantanée IM 26, et de téléphonie TAS 29 sont des exemples dc Serveurs d'Applications (AS). [0048] Certains services, comme ceux du serveur VM 25 et du serveur de Messagerie Ins- tantanée IM 26, s'appuient sur la souscription du terminal 10 à des événements prédéterminés, comme expliqué ci-dessus. [0049] On va décrire à présent plusieurs modes de réalisation de l'invention, dans lesquels un dispositif, tel qu'un terminal ou une passerelle résidentielle, compatible avec la présente invention, émet une requête SIP sur TCP vers le coeur de réseau. De préférence, ledit dispositif informe le réseau de sa compatibilité avec l'invention en incluant dans sa requête une étiquette (« optiontag » en anglais) dédiée, que nous appellerons « UDPfallback », par exemple dans l'en-tête « Supported » (connu en soi). [0050] Si par exemple le réseau est en situation de congestion TCP, il répond au dispositif en lui demandant, au moyen d'un indicateur dédié, d'utiliser le protocole de transport UDP au lieu du protocole de transport TCP s'il émet une future requête. Cet indicateur dédié pourra par exemple prendre la forme d'une valorisation, que nous appellerons également « UDPfallback », de l'en-tête « Require » (connu en soi). [0051] Selon un premier mode de réalisation, ladite réponse comprend également un code dédié, par exemple « 543 », pour demander au dispositif de réémettre ladite requête SIP en utilisant UDP au lieu de TCP, et cela, même si, le cas échéant, cette requête a une taille supérieure à 1300 octets. Voici un exemple de mise en oeuvre de ce premier mode de réalisation. [0052] Un terminal émet la requête d'enregistrement suivante : [0053] 9 REG1STER sip; iiins.mric001.mcc208.3gppnetwork ore S1P12 0 Via: SIR2.0/TCP 10.10.1.2:6100;branch=z9hG4bK-524287-1---feel3c5732becd59; rportikeepitranspo =TCP Max-Forwards: 70 Contact: ;+sip.instancee'Aurn:gsma:intei: 0149145215-180- 02>";q=1.0;t-g.3gppicsi-ref="u rn'tit3Au rn-7%3A3gpp-service ims.iosi.mmtDnaudio Te: csip:0149/45215girns.rnnc001.mcc208.3opianetwork.org, From: qatiezIDL.fl keEU Tc11111DzniGj7GDzk9y2Z6w @ 10 10 1 2 CSeq: 2 REGISTER Require: UDIRM1Ittack Content-Length: 0 [0056] Sur réception de cette réponse, le dispositif réémet la même requête REGISTER, mais cette fois sur UDP. [0057] Selon un deuxième mode de réalisation, la réponse du coeur de réseau comprend un en-tête dédié, que nous appellerons également « UDPfallback », pour demander audit dispositif d'utiliser UDP s'il émet au moins une nouvelle requête SIP. Optionnellement, cet en-tête dédié peut préciser en outre une durée d'application de cette politique. Voici un exemple de mise en oeuvre de ce deuxième mode de réalisation. [0058] Un terminal émet la requête d'établissement de session suivante : [0059] NVITE si p:a iice©irris inric001 mcc208 3p,ppnotififork org S1P/2 0 Via: SIR2.01TCP 10 10 1 2:6100; branch=z9hG4bK-52,1287-2-bod23658dz5118sd:rporhkeeparansport=TCP Max-Forwards. 70 Contact: From: :tagee9471567 Call-ID: srvtl 5ses6ftlg78thtik3ue.10.10.1.2 CSeq: 1 INVITE Expires: 600000 Allow: iNV1TE, ACK OPT1ONS, CANC EL, 6YE UPDATE, INFO, REFER, NOTi FY, MESSAGE, PRACK Su pported: path sec-agree, UDPialtback P-Access-Network-info: 3GPP-E-UTRAN-FDD:utran-weil-id-3gpp=1234 Content-Length: 0 [0060] En réponse à cette requête, le coeur de réseau demande au terminal, au moyen du code 543, de réémettre sa requête sur UDP. Le coeur de réseau demande en outre au terminal d'utiliser UDP pour l'ensemble des nouvelles requêtes, et cc, pendant une durée de 24 heures (86400 secondes) : [0061] SiPt2 0 543 Use UDP Via: SIP/2.0ITOP 1 0 10 1 2:5100;branoh=z9hG4bK-524287-2-bod23658dz f8scl;rport,keeparansporti=TCP Max-Forwards 70 Contact: csio 0149145215@.10,10.1.2:6100>;+sip.instance=" ,tag=e9471567 - srrti 5s6s5fI1g78p1ik8u©10 10 1.2 CSea 1 INVITE Require, UDPfallback UDPfallback: '1=86400 Content-Length: 0 100621 Sur réception de cette réponse, le terminal réémet la même requête INVITE, mais cette fois sur UDP. De plus, pour toute nouvelle requête émise (le cas échéant) pendant 24 heures, le terminal utilisera UDP. 100631 Selon un troisième mode de réalisation, la réponse du coeur de réseau précise au dispositif le, ou les type(s) de méthode(s) SIP qu'il lui faudra dorénavant émettre sur UDP. Optionnellement, le coeur de réseau précise une durée d'application de cette politique. Voici un exemple de mise en oeuvre de ce troisième mode de réalisation. 100641 Un terminal émet la requête d'établissement de session suivante : 100651 NvlrE s3p-a hceeirns rrinc001 mcc208 3pppnetwork orgSIF/2 G Via 31P/2.0/TOPIC 10 1.2:6100;brarie=z9h(84bK-524287-2-bod23658dz5f8sd;rport;keep;transpoCaTOP Max-Forward s. 70 Contact csip 0149145215@1 0 10 1 2.6100>; +sip in stance=" ":G=1.0:+a3g pp.1csi-ref="urn%3Aum-7/03A3gpp-service.ims.ics1.maltenaud10 - csip:alice@imsfrine001 mcc208.3gpprieM,ork.ory> From esia, 0149145215©1Êns mnc001 mec205 3gpprieb/ork org>;tag=e9471567 - srvU5s6s8F11978ffi1jk8u@l0 10 I 2 CSeri: 1 ENVITE Expires: 600000 Alow:iNVITE, ACK, OP7ONS CANCEL. BYE, UPDATE, INFO, REFER, NOT1FY, MESSAGE. PRACK Su pported. path. see-agree.UDPfallback P-Access-Network-Infa 3GPP-E-1JTRAN-FDD,ratran-ce11-1d-3gpp=1234 Content-Length: 0 100661 En réponse à cette requête, le coeur de réseau demande au terminal, au moyen du code 543, de réémettre sa requête sur UDP. Le coeur de réseau précise en outre que les méthodes SIP REG1STER et SIP OPTIONS devront être émises sur UDP, et que cette politique s'applique pour une durée de 2 heures (7200 secondes) : 100671 11 SIR/2.0 543 Use UDP Via: SIR12.01TCP 10.10.1.2:5100;branch=z9hG4bK-524287-2-bcd23658dz5f8s ,rportkeep;transport=TCP Max-Forwerds170 Contact ;+ep.instance="cum:gsmatirnei: 0149145215-1 80 02>";q=1 .0;+g.3gpp.icsi-ret="u rn%3Auin-7%3A3gpp-seni ice iros.icsi.nwrifensudio Ta: potaiiicictO1cpy:i From t ;tag=e9471567 Call-ID: srvtl5s6s8ft1g78jhlkeu ©10.10.1.2 Oriel: INVITE Requ ire: UDPfallback UDPfallback: REGISTER =7200,OPTIONS =7200 Content-Lenoth: 0 100681 Sur réception de cette réponse, le terminal réémet la même requête INVITE, mais cette fois sur UDP. De plus, pour toute nouvelle requête REGISTER ou OPTIONS émise (le cas échéant) pendant 2 heures, le terminal utilisera UDP. 100691 Selon un quatrième mode de réalisation, la réponse émise par le coeur de réseau ne requiert pas une réémission sur UDP de ladite requête, qui sera traitée normalement. En revanche, le coeur de réseau demande au dispositif d'utiliser UDP pour l'ensemble des nouvelles requêtes, et ce, pendant une durée indiquée dans l'en-tête « UDPfallback ». Voici un exemple de mise en oeuvre de ce quatrième mode de réalisation. 100701 Un terminal émet la requête d'établissement de session suivante : 100711 INVITE si po lice@irns ninc001 mcc,208 3gppnetwork org SIP/2 0 SIP?2.0)TCP 10 10 1.2:6100;branch=s9hG4bK-524287-2-bcd23658ds5 sclaportUceep;transpori=TCP Max-Fon/yards:70 Contact: ;+sip.instance=" ;+sip.instance--"cumi gsmaiirineii 0149145215-180- 02>";q=1 .0;+g.3gpp. icsi-ref="u rn°X,3Aum-7%3Pagpp-seni ice icsi.nwrifens Lidio Toi From i-esip: 0149145215@ims.mnc001.mcc208.3gppnetwork.org>itag=e9471567 srvt15s6s8ft1g78jh1jkeuta10.10.1.2 CSeq: INVITE Regulus: 100rel, UDPfallback UDPfailback : *=88400 Content-Lenoth: 0 100741 Sur réception de cette réponse, pour toute nouvelle requête émise (le cas échéant) pendant 24 heures, le terminal utilisera UDP. 100751 D'autres modes de réalisation de l'invention sont naturellement envisageables. Par exemple, la réponse du coeur de réseau peut requérir une action supplémentaire à effectuer par le dispositif (par exemple le réenregistrement du dispositif, cette fois en utilisant le mode de transport UDP), soit immédiatement, soit suite à l'expiration d'une durée indiquée dans l'en-tête « UDPfallback ». 100761 De manière générale, la présente invention peut être mise en oeuvre au sein des noeuds d'un réseau W, par exemple des dispositifs-clients, des passerelles résidentielles ou des serveurs, au moyen de composants logiciels et/ou matériels. 100771 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 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 d'étapes de l'un quelconque des procédés de basculement selon l'invention. 100781 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 d'étapes d'un procédé de basculement selon l'invention, lorsqu'il est exécuté sur un ordinateur. Cc programme d'ordinateur peut être stocké sur un support lisible par ordinateur et peut être exécutable par un microprocesseur. [0079] 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 une forme partiellement compilée, ou dans n'importe quelle autre forme souhaitable. [0080] L'invention vise aussi un support d'informations, inamovible, ou partiellement ou to- talement amovible, lisible par un ordinateur, et comportant des instructions d'un 13 programme d'ordinateur tel que mentionné ci-dessus. [0081] 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 d'enregistrement magnétique, tel qu'un disque dur, ou encore une clé USB (« USB flash drive » en anglais). [0082] D'autre part, le support d'informations peut être un support transmissible tel qu'un signal électrique ou optique, qui peut être acheminé via un câble électrique ou optique, par radio ou par d'autres moyens. Le programme d'ordinateur selon l'invention peut être en particulier téléchargé sur un réseau de type Internet. [0083] 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 des étapes ou pour être utilisé dans l'exécution d'étapes de l'un quelconque des procédés de basculement selon l'invention. 14 [Revendication 1]