FR3090252A1

FR3090252A1 - Procédé de basculement d’une communication de TCP sur UDP

Info

Publication number: FR3090252A1
Application number: FR1873056A
Authority: FR
Inventors: José Doree; Jean-Claude Le Rouzic
Original assignee: Orange SA
Current assignee: Orange SA
Priority date: 2018-12-17
Filing date: 2018-12-17
Publication date: 2020-06-19
Anticipated expiration: 2038-12-17
Also published as: FR3090252B1; WO2020128258A1

Abstract

Procédé de basculement d’une communication de TCP sur UDP L’invention concerne un procédé de basculement dans un réseau mettant en œuvre le protocole de contrôle de session SIP (Session Initiation Protocol), ledit procédé comprenant les étapes suivantes : un dispositif dudit réseau émet une requête SIP vers le cœur de réseau en utilisant le protocole de transport TCP en utilisant le protocole de transport TCP (Transmission Control Protocol) ; le cœur 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 (User Datagram Protocol) 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. Application aux réseaux IMS. Figure pour l'abrégé : Fig. 1

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 œuvre 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.

[0005] Le protocole SIP a été défini par ΓΙΕΤΡ (Internet Engineering Task Force) dans le document RLC 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 RLC 3265. Cette extension définit des procédures de notification d’événements.

[0006] 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

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 œuvre 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-CSCL » (initiales des mots anglais « Serving-Call Server Control Function » signifiant « Ponction 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-CSCP » (initiales des mots anglais « Interrogating-Call Server Control Function » signifiant « Ponction de Commande de Session d'Appel Interrogatrice ») — d'ailleurs souvent combinés physiquement avec les serveurs d’enregistrement S-CSCP pour constituer des serveurs d’appel dénotés « I/S-CSCP » — 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 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 cidessus. 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 dispositifclient dès lors que l’état de la ressource change ; par exemple, lorsque l'utilisateur d'un dispositif-client dispose d'une 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 dispositifclient connecté à un réseau IMS, il existe un serveur P-CSCF servant d’entité de raccordement entre le cœur de réseau IMS et le réseau d’accès utilisé par ce dispositifclient ; 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 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 Control Protocol » signifiant « Protocole de Contrôle de Transmission ») et UDP (initiales des mots anglais « User Datagram Protocol » signifiant « Protocole de Datagramme Utilisateur »). A ce titre, les moyens techniques permettant à un dispositifclient (« 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’Internet 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 à cœur 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 œuvre 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 œuvre dans le réseau d’accès, car dans ce 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 basculement dans un réseau mettant en œuvre 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 cœur de réseau en utilisant le protocole de transport TCP,

- le cœur 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

[0020]

[0021]

[0022]

[0023]

[0024]

[0025]

[0026] 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.

Ainsi, l’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 luimême qui pose problème.

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éenregistrement 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.

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.

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.

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.

Selon d’autres caractéristiques encore plus particulières, ladite réponse précise également une durée d’application.

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.

[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 cœur de réseau en utilisant le protocole de transport

TCP,

- recevoir dudit cœur 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 ce 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 SIP.

[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 œuvre 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 œuvre 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 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] [fig-1] 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 œuvre 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 1.

[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, de 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 rutilisateur 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 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.

[0045] 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 contenu audiovisuel.

[0046] 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 dispositifclient 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 cœur 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 et de localisation, et de services souscrits ;

• au moins un serveur VM 25 de messagerie vocale (« message-summary » 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 dispositifclient 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 rutilisateur 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 rutilisateur 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 de Serveurs d'Applications (AS).

[0048] 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.

[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 cœur 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 œuvre de ce premier mode de réalisation.

[0052] Un terminal émet la requête d’enregistrement suivante : [0053]

REGISTER sip:ims.mncOO1 .mcc208.3gppnetwork.org SIP/2.0

Via: SIP/2.0/TCP 10.10.1.2:6100;branch=z9hG4bK-524287-1—f9e13c5732beod59;rport;keep;transport=TCP Max-Forwards: 70

Contact <sip: 0149145215@10.10.1.2:6100>;+sip.instance=<urn:gsma:imei: 0149145215-18002>;q=1.0;+g.3gpp.icsi-ref=”um%3Aurn-7%3A3gpp-service.ims.icsi.mrritel;audio

To: <sip:0149145215@ims.mno001.mcc208.3gppnetwork.otg>

From: <sip: 0149145215@ims.mnc001.mcc208.3gppnetwork.org>;tag=e9471567

Call-ID: TdTitDzniGj7GDzk9y2Z6w@10.10.1.2

CSeq: 2 REGISTER

Expires: 600000

Allow: INVITE, ACK, OPTIONS, CANCEL, BYE, UPDATE, INFO, REFER, NOTIFY, MESSAGE, PRACK Supported: path, sec-agree, UDPfallback

P-Access-Network-Info: 3GPP-E-UTRAN-FDD;utran-cei!-id-3gpp=1234 Content-Length: 0

[0054] Le cœur de réseau répond au terminal de la façon suivante :

[0055] SIP/2.0 543 Use UDP

Via: SIP/2.0/TCP10.10.1.2:6100;branch=z9hG4bK-524287-1 — f9e13c5732becd59;rport;keep;transport=TCP;received=10.10.1.2;rport=6101

From: <sip: 0149145215@ims.mnc001.mcc208.3gpprietwork.org>;tag=e9471567

To: <sip:0149145215@ims.mnc001.mcc208.3gppnetwork.org>;tag=zlDLf1keEU

Call-ÎD: TdTitDznlGj7GDzk9y2Z6w..@ 10.10.1.2

CSeq: 2 REGISTER Require: UDPfallback 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 cœur 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 œuvre de ce deuxième mode de réalisation.

[0058] Un terminal émet la requête d’établissement de session suivante :

[0059] INVITE sip:aiice@ims.mnc001. mcc208.3gppnetwork.org SIP/2.0

Via: SIP/2.0/TCP10.10.1.2:6100:branch=z9hG4bK-524287-2-bcd23658dz5f8sd;rport,keep;transport=TCP Max-Forwards: 70

Contact: <sip: 0149145215@10.10.1.2:6100>;+sip.instance=<urn:gsma:imei:0149145215-18002>;q=1.0;+g.3gpp.icsi-ref=‘\im%3Aurn-7%3A3gpp-service.ims.icsi.rnmtel”;audio

To: <sip:aJice@ims. mnc001.mcc208.3gppnetwork.org>

From: <sip: 0149145215@ims.mnc001.mcc208.3gppnetwork.org>;tag=e9471567

Call-ID: srvtl 5s6s8ft1 g78jh 1 jk8u@ 10.10.1.2

CSeq: 1 INVITE

Expires: 600000

Allow: INVITE, ACK, OPTIONS, CANCEL, BYE, UPDATE, INFO, REFER, NOTIFY, MESSAGE. PRACK Supported: path, sec-agree, UDPfallback

P-Access-Network-Info: 3GPP-E-UTRAN-FDD;utran-cell-id-3gpp=1234 Content-Length: 0

[0060] En réponse à cette requête, le cœur de réseau demande au terminal, au moyen du code 543, de réémettre sa requête sur UDP. Le cœur de réseau demande en outre au terminal d’utiliser UDP pour l’ensemble des nouvelles requêtes, et ce, pendant une durée de 24 heures (86400 secondes) :

[0061] SIP/2.0 543 Use UDP

Via: S1P/2.0/TCP 10.10.1.2:6100;branch=z9hG4bK-524287-2-bed23658dz5f8sd;rport;keep;transport=TCP

Max-Forwards: 70

Contact: <sip: 0'49145215@10.10.1 .2:6100>;+sip.instance=<urn:gsma:imei: 0149145215-18002>;q=1.0:+g.3gpp.icsi-ref=um%3Aurn-7%3A3gpp-service.ims.icsi.mmtel”;audio

From:<s;p: 0149145215@ims.mnc001.mcc208.3gppnetwork.org>;tag=e9471567

Call-iD: snrtl 5s6s8ft1 g78jh1 jk8u@10.10.1.2

CSeq: 1 INVITE

Require: UDPfalIback

UDPfalIback: *=86400

Content-Length: 0

[0062] 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.

[0063] Selon un troisième mode de réalisation, la réponse du cœur 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 cœur de réseau précise une durée d’application de cette politique. Voici un exemple de mise en œuvre de ce troisième mode de réalisation.

[0064] Un terminal émet la requête d’établissement de session suivante :

[0065] INVITE sip:aiice@ims.mnc001. mcc208.3gppnetwork.org SIP'2.0

Via: SIP/2.0/TCP 10.10.1.2:6100;branch=z9hG4bK-524287-2-bcd23658dz5Ssd:rport;keep;transport=TCP Max-Forwards: 70

Contact: <stp: 0149145215@10.10.1.2:6100>;+sip.instance=<urn:gsma:imei: 0149145215-18002>:q=1.0:+g.3gpp.Îcsi-ref=um%3Aurn-7%3A3gpp-service.ims.icsÎ.mmter^,;audÎo

To: <sip:aiiœ@:ms.mni;001.mcc208.3gppnetwork.org>

From: «sip: 0149145215@ims.mnc001.mcc208.3gppnetwork.org>;tag=e9471567

Call-ID: srvtl 5s6s8ft1 g78jh1 jk8u@ 10.10.1.2

CSeq: 1 INVITE

Expires: 600000

Allow: INVITE, ACK, OPTIONS, CANCEL, BYE, UPDATE, INFO, REFER, NOTIFY, MESSAGE, PRACK Supported: path, sec-agree, UDPfalIback

P-Access-Network-Info: 3GPP-E-UTRAN-FDD;utran-cell-id-3gpp=1234

Content-Length: 0

[0066] En réponse à cette requête, le cœur de réseau demande au terminal, au moyen du code 543, de réémettre sa requête sur UDP. Le cœur de réseau précise en outre que les méthodes SIP REGISTER et SIP OPTIONS devront être émises sur UDP, et que cette politique s’applique pour une durée de 2 heures (7200 secondes) :

[0067]

SIP/2.0 543 Use UDP

Via: SIP/2.0/TCP 10.10.1.2:6100;branch=z9hG4bK-524287-2-bcd23658dz5f8sd,rport;keep;transport=TCP Max-Forwards: 70

Contact <sip: 0149145215@10.10.1.2:6100>;+sip.instance-'<um:gsma:imei: 0149145215-18002>’^,;q=1.0;+g.3gpp.ics!-ref=urn%3Aum-7%3A3gpp-seivice.!ms.icsi.mmtel;audio To: / ' ,1ag=45dr685s8rgh4h459d

From: <sip: 0149145215@ims.mnc001.mcc208.3gppnetwork.org>;tag=e9471567 Call-ID:srvt15s6s8ft1g78jh1jk8u@10.10.1.2

CSeq: 1 INVITE

Require: UDPfallback

UDPfallback: REGISTER =7200,OPTIONS =7200

Content-Length: 0

[0068] 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.

[0069] Selon un quatrième mode de réalisation, la réponse émise par le cœur de réseau ne requiert pas une réémission sur UDP de ladite requête, qui sera traitée normalement. En revanche, le cœur 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 œuvre de ce quatrième mode de réalisation.

[0070] Un terminal émet la requête d’établissement de session suivante :

[0071] INVITE sip:alice@ims.mnc001.mcc208.3gppnetwork.org SIP/2.0

Via: SIP/2.0/TCP10.10.1.2:6100;branch=z9hG4bK-524287-2-bcd23658dz518sd;rport;keep;transport=TCP Max-Foiwards: 70

Contact: <sip: 0149145215@10.10.1.2:6100>;+sip.instance=<urn:gsma:imei: 0149145215-18002>;q=1.0;+g.3gppdcsi-ref=um%3Aiim-7%3A3gpp-seMce.ims.icsi.mmtel'';audio

To: <sip:alice@ims.mnc001 . mcc208.3gppnetwork.org>

From: <sip: 0149145215@ims.mnc001.mcc208.3gppnetwork.org>;tag=e9471567

Call-ÎD: srvtl 5s6s8ft1 g78jh1 jk8u@10.10.1.2

CSeq: 1 INVITE

Allow: INVITE, ACK, OPTIONS, CANCEL, BYE, UPDATE, INFO, REFER, NOTIFY, MESSAGE, PRACK Supported: 100rel,path, sec-agree, UDPfallback

P-Access-Network-Info: 3GPP-E-UTRAN-FDD;utran-cell-id-3gpp=1234 Content-Length: 2568

[0072] Le cœur de réseau traite classiquement cette requête, et en réponse demande au terminal de ne plus utiliser TCP pour l’ensemble des nouvelles requêtes pendant une durée de 24 heures (86400 secondes) :

[0073]

SIP/2.0 183 Session Progress

Via: SIP/2.0/TCP 10.10.1.2:6100;branch=z9hG4bK-524287-2-bcd23658dz5f8sd;rportkeep;transport=TCP Max-Forwards: 70

Contact <sip: 0149145215@10.10.1.2:6100>;+sip.instance-'<um:gsma:iniei: 0149145215-18002>”;q=1.0;+g.3gpp.ics!-ref=um%3Atjm-7%3A3gpp-seivice.!ms.icsi.rTimtei;audio

To: / ' , ,1ag=45dr685s8rgh4h459d

From: <sip: 0149145215@ims.mnc001.mcc208.3gppnetwork.org>;tag=e9471567

Call-ID:srvt15s6s8ft1g78jh1jk8u@10.10.1.2

CSeq: 1 INVITE

Require: 100rel, UDPfallback

UDPfallback : *=86400

Content-Length: 0

[0074] Sur réception de cette réponse, pour toute nouvelle requête émise (le cas échéant) pendant 24 heures, le terminal utilisera UDP.

[0075] D’autres modes de réalisation de l’invention sont naturellement envisageables. Par exemple, la réponse du cœur 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 ».

[0076] De manière générale, la présente invention peut être mise en œuvre au sein des nœuds d’un réseau IP, par exemple des dispositifs-clients, des passerelles résidentielles ou des serveurs, au moyen de composants logiciels et/ou matériels.

[0077] Les composants logiciels pourront être intégrés à un programme d'ordinateur classique de gestion de nœud 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 œuvre d’étapes de l'un quelconque des procédés de basculement selon l’invention.

[0078] 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. Ce 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 totalement amovible, lisible par un ordinateur, et comportant des instructions d'un 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.

Claims

Revendications [Revendication 1] Procédé de basculement dans un réseau mettant en œuvre le protocole de contrôle de session SIP (Session Initiation Protocol), ledit procédé comprenant les étapes suivantes : - un dispositif dudit réseau émet une requête SIP vers le cœur de réseau en utilisant le protocole de transport TCP (Transmission Control Protocol), - le cœur 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 (User Datagram Protocol) 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. [Revendication 2] Procédé de basculement selon la revendication 1, caractérisé en ce que 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. [Revendication 3] Procédé de basculement selon la revendication 1 ou la revendication 2, caractérisé en ce que 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. [Revendication 4] Procédé de basculement selon la revendication 3, caractérisé en ce que ladite réponse précise également au moins un type de méthode SIP concerné par cette demande. [Revendication 5] Procédé de basculement selon la revendication 3 ou la revendication 4, caractérisé en ce que ladite réponse précise également une durée d’application. [Revendication 6] Serveur réseau comprenant un agent SIP (Session Initiation Protocol), 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 (Transmission Control Protocol), - envoyer audit dispositif une réponse lui demandant, au moyen

d’un indicateur dédié, d’utiliser le protocole de transport UDP (User Datagram Protocol) au lieu du protocole de transport TCP s’il émet une future requête SIP. [Revendication 7] Serveur réseau selon la revendication 6, caractérisé en ce 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. [Revendication 8] Serveur réseau selon la revendication 6 ou la revendication 7, caractérisé en ce que 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. [Revendication 9] Serveur réseau selon la revendication 8, caractérisé en ce que ladite réponse précise également au moins un type de méthode SIP concerné par cette demande. [Revendication 10] Serveur réseau selon la revendication 8 ou la revendication 9, caractérisé en ce que ladite réponse précise également une durée d’application. [Revendication 11] Dispositif comprenant un agent SIP (Session Initiation Protocol), ainsi que des moyens pour : - émettre une requête SIP vers un cœur de réseau en utilisant le protocole de transport TCP (Transmission Control Protocol), - recevoir dudit cœur de réseau une réponse lui demandant, au moyen d’un indicateur dédié, d’utiliser le protocole de transport UDP (User Datagram Protocol) 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. [Revendication 12] Dispositif selon la revendication 11, caractérisé en ce qu’il comprend en outre des moyens pour inclure une étiquette dédiée dans ladite requête SIP. [Revendication 13] Dispositif-client, caractérisé en ce qu’il comprend un dispositif selon la revendication 11 ou la revendication 12. [Revendication 14] Passerelle résidentielle caractérisé en ce qu’elle comprend un dispositif selon revendication 11 ou la revendication 12.

1/1