WO2020128258A1 - Procédé de basculement d'une communication de tcp sur udp - Google Patents

Procédé de basculement d'une communication de tcp sur udp Download PDF

Info

Publication number
WO2020128258A1
WO2020128258A1 PCT/FR2019/053066 FR2019053066W WO2020128258A1 WO 2020128258 A1 WO2020128258 A1 WO 2020128258A1 FR 2019053066 W FR2019053066 W FR 2019053066W WO 2020128258 A1 WO2020128258 A1 WO 2020128258A1
Authority
WO
WIPO (PCT)
Prior art keywords
sip
response
udp
tcp
network
Prior art date
Application number
PCT/FR2019/053066
Other languages
English (en)
Inventor
José DORÉE
Jean-Claude Le Rouzic
Original Assignee
Orange
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Orange filed Critical Orange
Publication of WO2020128258A1 publication Critical patent/WO2020128258A1/fr

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/1066—Session management
    • H04L65/1069—Session establishment or de-establishment
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/1066—Session management
    • H04L65/1101—Session protocols
    • H04L65/1104—Session initiation protocol [SIP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/16—Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/16—Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
    • H04L69/165—Combined use of TCP and UDP protocols; selection criteria therefor
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/18—Multiprotocol handlers, e.g. single devices capable of handling multiple protocols
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/10—Flow control; Congestion control
    • H04L47/19—Flow control; Congestion control at layers above the network layer
    • H04L47/196—Integration of transport layer protocols, e.g. TCP and UDP

Definitions

  • the present invention relates to IP (Internet Protocol) type communication networks, and in particular those among IP networks which are capable of implementing advanced session control protocols.
  • IP networks allow the transmission of conversational data, as part of services such as "Voice over IP” (VoIP), "Content Sharing", or "Instant Messaging”.
  • the present invention relates to the means implemented in an IP network to apply a time delay on a set of transactions between two client devices, or between a client device and a server, or even between two servers, when these transactions are logically related.
  • client devices can be, for example, a fixed or mobile terminal, or a Residential Gateway, either domestic or located in a business.
  • client devices can be, for example, a fixed or mobile terminal, or a Residential Gateway, either domestic or located in a business.
  • client devices can be, for example, a fixed or mobile terminal, or a Residential Gateway, either domestic or located in a business.
  • user terminal or simply “terminal” will frequently be used below to designate these various pieces of equipment.
  • the SIP protocol was defined by the Internet Engineering Task Force (IETF) in document RFC 3261. This protocol allows the establishment, modification and termination of multimedia sessions in a network using the IP protocol. The SIP protocol was then extended in particular in document RFC 3265. This extension defines procedures for event notification.
  • the SIP protocol is used in particular in IMS type infrastructures (initials of the English words "IP Multimedia Subsystem” meaning “Multimedia Subsystem over IP”).
  • the IMS was defined by the standardization body 3GPP ("Third Generation Partnership Project") and TISPAN ("Telecommunications and Internet Converged Services and Protocols for
  • IMS International Mobile Subscriber Identity
  • 3GPP 3rd Generation Partnership Project
  • TISPAN 3rd Generation Partnership Project
  • This architecture allows the dynamic establishment and control of multimedia sessions between two clients as well as the reservation of resources at the level of the transport network for multimedia flows. Thanks to this architecture, network operators can conveniently implement a management policy, provide a predetermined Quality of Service, and calculate the amounts to be billed to customers.
  • IMS currently provides access to telephony, videophone, presence and instant messaging services, the interaction of which it also manages.
  • the client device of the user must, with exceptions (such as certain emergency calls), register with the network.
  • exceptions such as certain emergency calls
  • the network is unable to make the link between this recording and a previous recording (for example following a network failure, or following a shutdown of the client device for a duration greater than a predetermined value)
  • the recording is considered as being an initial recording.
  • the user's client device must periodically send the network a request to confirm that it wishes to maintain its registration.
  • IMS networks include one or more recording servers, called “S-CSCF” (initials of the English words “Serving-Call Server Control Function” meaning “Serving Call Session Control Function »), Able (among other functions) to manage the registration procedure for devices connected to the network.
  • S-CSCF recording servers
  • IMS networks also include one or more interrogation servers, called “l-CSCF” (initials of the English words “Interrogating- Call Server Control Function” meaning “Interrogating Call Session Control Function”) - moreover often physically combined with S-CSCF recording servers to form call servers denoted "l / S-CSCF” - which, when registering a client device, interrogate a data server subscriber called “HSS” (initials of the English words “Home Subscriber Server” meaning “Attached Subscriber Server”), in order to be able to select an S-CSCF server having the characteristics which are obligatorily (and, where appropriate, optionally) required to reach the level of service subscribed by the user.
  • HSS data server subscriber
  • the HSS servers each contain a client database, and are therefore the equivalent in IP networks of the “HLR” servers (initials of the English words “Home Location Register” meaning “Home Location Register”) used in the networks. GSM.
  • Each HSS server contains the “profile” of a certain number of client devices on the network, this profile comprising their registration status, authentication and location data, and the services to which it is entitled.
  • each user can make use of a certain number of services during the current session.
  • This can for example be services offered automatically to all users of the IMS network. It can also be services to which this user has subscribed to the network operator, and which are automatically made available to him. Finally, these may be services which the user can make use of after having made an appropriate request (SIP SUBSCRIBE).
  • These services include audiovisual applications as mentioned above. It may also be a subscription to the state of a network resource, in which case event notifications (SIP NOTIFY) are sent to the client device as soon as the state of the resource changes; for example, when the user of a client device has a mailbox on the network, he may be informed each time a message has been recorded on this mailbox; a user can, likewise, request to be notified of the registration status of his own client device.
  • SIP NOTIFY event notifications
  • the IMS networks also include one or more servers called “P-CSCF” (initials of the English words “Proxy-Call Server Control Function” meaning “Mandatory Call Session Control Function”).
  • P-CSCF Internet Services Management Function
  • the transport protocols mainly used by software applications to communicate on the Internet are TCP (initials of the English words “Transmission Control Protocol” meaning “Transmission Control Protocol”) and UDP (initials of the English words “User Datagram Protocol” meaning “Protocol User Datagram ”).
  • TCP transmission Control Protocol
  • UDP User Datagram Protocol
  • the technical means enabling a client device (“User Equipment”, or UE in English) to optimize the use of available network resources according to the needs and constraints of applications based on TCP or UDP are likely to significantly improve the level of quality associated with the use of such applications.
  • some Internet players are experimenting on a large scale with alternative solutions to TCP based on UDP (and, more precisely, on an encapsulation scheme). From this point of view, service providers and IP network operators are committed to providing a comparable level of quality of use between applications based on TCP and those based on UDP.
  • TCP transport mode implements queues, retransmission algorithms, anticipation windows, timers, and so on for each connection.
  • processor CPU
  • memory operations which are limited resources in any system. computer science.
  • the shortage of TCP resources can prevent client devices from connecting to the IMS network, or even establish new calls via this transport mode, requests for new TCP connections being refused due to lack of resources.
  • UDP does not manage any timers, has no memory of received packets (no retransmission, anticipation window, or sequencing control ).
  • the present invention therefore relates, according to a first aspect, to a failover method in a network implementing the SIP session control protocol.
  • Said method comprises the following steps:
  • a device of said network transmits a SIP request to the core network using the TCP transport protocol
  • the backbone sends a response to the device requesting it, by means of a dedicated flag, to use the UDP transport protocol instead of the TCP transport protocol if it issues a future SIP request, and
  • the invention proposes an evolution of the SIP standard to introduce a mechanism for switching over to the UDP transport mode. This can be particularly useful in the event of TCP congestion, but this switchover could be generalized to other use cases, for example when it is the TCP transport mode itself which is problematic.
  • the network equipment concerned such as a P-CSCF server, an S-CSCF server, or an Application Server (AS), will be able to regulate the use of TCP resources, and will be able to set up different policies for managing a shortage of resources, depending on the degree of use of TCP resources.
  • This network equipment could, for example:
  • said response also includes a dedicated code for requesting said device to retransmit said SIP request using UDP instead of TCP.
  • said response also includes a dedicated header for asking said device to use UDP if it sends at least one new SIP request.
  • said response also specifies at least one type of SIP method concerned by this request.
  • said response also specifies a duration of application.
  • the invention relates to a network server comprising a SIP agent, as well as means for:
  • said response also includes a dedicated code for requesting said device to retransmit said SIP request using UDP instead of TCP.
  • said response also includes a dedicated header for asking said device to use UDP if it sends at least one new SIP request.
  • said response also specifies at least one type of SIP method concerned by this request.
  • said response also specifies a duration of application.
  • the invention relates to a device comprising an SIP agent, as well as means for:
  • this device may, for example, be hosted by a client device or by a residential gateway.
  • said device also comprises means for including a dedicated label in said SIP request.
  • the device informs the network of its compatibility with the present invention.
  • the invention also relates to a computer program downloadable from a communication network and or stored on a medium readable by computer and / or executable by a microprocessor.
  • This computer program is remarkable in that it includes instructions for the execution of the steps of the switching process succinctly described above implemented by the first device when these steps are executed on a computer, or for the execution of the steps of the switching process succinctly described above implemented by the second device when these steps are executed on a computer.
  • FIG. 1 which accompanies it, and which schematically represents a system for the supply of multimedia services capable of implementing the invention.
  • the multimedia services offered by this IMS 1 network may include telephony, video-telephony, content sharing services
  • Presence Presence
  • Instant Messaging television.
  • These services are available to the user of a client device 10 belonging to the network 1, which allows the client device 10 to exchange multimedia streams and session control signals conforming to the SIP protocol, for example with the client device (not shown) of a user belonging to a SIP network (not shown) connected to network 1.
  • the client device 10 may be a fixed or mobile terminal, or a domestic or corporate gateway, having SIP signaling means and which may include means for restoring audiovisual content.
  • this IMS network 1 includes, in addition to an IP transport infrastructure (not shown):
  • the server S-CSCF 27 manages in particular the procedure for registering the devices connected to the network 1; the server S-CSCF 27 also manages the routing of the signaling between the client device 10 and the voice messaging servers VM 25, Instant Messaging 26, and telephony TAS 29;
  • the l-CSCF 22 server notably manages the routing towards other terminals managed by the same IMS 1 network and the routing of the signaling between this IMS 1 network and other networks (not shown);
  • At least one P-CSCF server serves as a connection entity between the IMS core network and the access network used by the client device 10;
  • the HSS server 24 contains the profile of the user of the client device 10 in terms of authentication and location data, and of subscribed services;
  • VM 25 voice mail server (“message-summary” in English); the VM server 25 manages the subscription of the client device 10 to the events for depositing / consulting messages intended for the client device 10, and notifies the client device 10 when these events occur;
  • At least one TAS 29 telephony server the TAS server manages the telephone services to which the user of the terminal 10 has subscribed to his operator, such as the presentation of the number or the call forwarding.
  • Examples of Application Servers (AS) are VM 25 Voicemail, IM Instant Messaging 26, and Telephony TAS 29 servers.
  • Certain services such as those of the VM server 25 and of the IM instant messaging server 26, rely on the subscription of the terminal 10 to predetermined events, as explained above.
  • a device such as a terminal or a residential gateway, compatible with the present invention, sends a SIP request over TCP to the core network.
  • said device informs the network of its compatibility with the invention by including in its request a dedicated label ("optiontag” in English), which we will call “UDPfalIback", for example in the header "Supported” ( known per se).
  • the network responds to the device by asking it, by means of a dedicated flag, to use the UDP transport protocol instead of the TCP transport protocol if it issues a future request .
  • This dedicated indicator could for example take the form of a valuation, which we will also call “UDPfalIback", from the header "Require” (known per se).
  • said response also includes a dedicated code, for example “543”, to request the device to re-transmit said SIP request using UDP instead of TCP, even if, if necessary, this request has a size greater than 1300 bytes.
  • a dedicated code for example “543”
  • a terminal issues the following registration request:
  • the core network responds to the terminal as follows:
  • the device On receipt of this response, the device re-issues the same REGISTER request, but this time on UDP.
  • the core network response includes a dedicated header, which we will also call "UDPfallback", to ask said device to use UDP if it sends at least one new SIP request.
  • this dedicated header can also specify the duration of application of this policy.
  • a terminal issues the following session establishment request:
  • INVITE sip alice @ ims. mnc001.mcc208.3gppnetwork.org SI P / 2.0
  • the core network requests the terminal, using the code 543, to re-issue its request on UDP.
  • the backbone also requests the terminal to use UDP for all new requests, for a period of 24 hours (86,400 seconds):
  • the terminal On receipt of this response, the terminal re-issues the same INVITE request, but this time on UDP. In addition, for any new request issued (if any) during 24 hours, the terminal will use UDP.
  • the response of the core network specifies to the device the, or the type (s) of SIP method (s) that it will henceforth have to transmit over UDP.
  • the core network specifies a period of application of this policy.
  • a terminal issues the following session establishment request:
  • INVITE sip alice @ ims. mnc001.mcc208.3gppnetwork.org SI P / 2.0
  • the core network requests the terminal, using the code 543, to re-issue its request on UDP.
  • the backbone also specifies that the SIP REGISTER and SIP OPTIONS methods must be sent over UDP, and that this policy applies for a period of 2 hours (7200 seconds):
  • the terminal On receipt of this response, the terminal re-issues the same INVITE request, but this time on UDP. In addition, for any new REGISTER or OPTIONS request issued (if applicable) for 2 hours, the terminal will use UDP.
  • the response sent by the backbone does not require a re-transmission on UDP of said request, which will be processed normally.
  • the core network requests the device to use UDP for all new requests, for a period of time indicated in the "UDPfalIback" header.
  • UDPfalIback a period of time indicated in the "UDPfalIback" header.
  • a terminal issues the following session establishment request:
  • INVITE sip alice @ ims. mnc001.mcc208.3gppnetwork.org SI P / 2.0
  • the core network classically processes this request, and in response requests the terminal to no longer use TCP for all new requests for a period of 24 hours (86,400 seconds):
  • the core network response may require an additional action to be performed by the device (for example re-registration of the device, this time using the UDP transport mode), either immediately or following the expiration of a duration indicated in the “UDPfallback” header.
  • the present invention can be implemented within nodes of an IP network, for example client devices, residential gateways or servers, by means of software and / or hardware components.
  • the software components can be integrated into a conventional computer program for managing a network node. This is why, as indicated above, the present invention also relates to a computer system.
  • This computer system conventionally comprises a central processing unit controlling by signals a memory, as well as an input unit and an output unit.
  • this computer system can be used to execute a computer program comprising instructions for the implementation of steps of any of the failover methods according to the invention.
  • the invention also relates to a computer program downloadable from a communication network comprising instructions for the execution of steps of a failover method according to the invention, when it is running on a computer.
  • This computer program can be stored on a computer readable medium and can be executable by a microprocessor.
  • This program can use any programming language, and be in the form of source code, object code, or intermediate code between source code and object code, such as in a partially compiled form, or in any other desirable form.
  • the invention also relates to an irremovable, or partially or completely removable, information medium, readable by a computer, and comprising instructions of a computer program as mentioned above.
  • the information medium can be any entity or device capable of storing the program.
  • the support may include a storage means, such as a ROM, for example a CD ROM or a microelectronic circuit ROM, or a magnetic recording means, such as a hard disk, or even a USB key. (“USB flash drive" in English).
  • the information medium can be a transmissible medium such as an electrical or optical signal, which can be routed via an electrical or optical cable, by radio or by other means.
  • the computer program according to the invention can in particular be downloaded from a network of the Internet type.
  • the information medium may be an integrated circuit in which the program is incorporated, the circuit being adapted to execute steps or to be used in the execution of steps of any of the failover methods according to the invention. 'invention.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Security & Cryptography (AREA)
  • Business, Economics & Management (AREA)
  • General Business, Economics & Management (AREA)
  • Multimedia (AREA)
  • Mobile Radio Communication Systems (AREA)
  • Telephonic Communication Services (AREA)
  • Communication Control (AREA)

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.

Description

PROCEDE DE BASCULEMENT D’UNE COMMUNICATION
DE TCP SUR UDP
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 ».
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.
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.
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.
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 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. 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 Génération Partnership Project ») et TISPAN (« Télécommunications 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 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.
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 (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.
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-Call 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 d’interrogation, appelés « l-CSCF » (initiales des mots anglais « Interrogating- Call 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 « l/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 S-CSCF 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.
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).
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 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.
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 cœur 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 l-CSCF ou le serveur d’enregistrement S-CSCF d’autre part, passe par le serveur P-CSCF.
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 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’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.
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.
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 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.
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).
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.
La présente invention concerne donc, selon un premier aspect, un procédé de basculement 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 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 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 lui-mê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.
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 troisième aspect, l'invention concerne un dispositif comprenant un agent SIP, ainsi que des moyens pour :
- é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.
On notera que ce dispositif pourra, par exemple, être hébergé par un dispositif-client ou par une passerelle résidentielle.
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.
Grâce à ces dispositions, le dispositif informe le réseau de sa compatibilité avec la présente invention.
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. 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.
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.
Les avantages offerts par ce programme d'ordinateur sont essentiellement les mêmes que ceux offerts par ledit procédé.
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 à 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.
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.
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 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 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 contenu audiovisuel.
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 l-CSCF ; le serveur l-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 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 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 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 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 « UDPfalIback », par exemple dans l’en-tête « Supported » (connu en soi).
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 « UDPfalIback », de l’en-tête « Require » (connu en soi).
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.
Un terminal émet la requête d’enregistrement suivante :
REGISTER sip:ims. mnc001.mcc208.3gppnetwork.org SIP/2.0
Via: SIP/2.0/TCP 10.10.1.2:6100;branch=z9hG4bK-524287-l—
f9el3c5732becd59;rport;keep;transport=TCP
Max-Forwards: 70
Contact: <sip: 0149145215(g) 10.10.1.2:6100>;+sip.instance="<urn:gsma:imei: 0149145215-180-
02>";q=1.0;+g.3gpp.icsi-ref="urn%3Aurn-7%3A3gpp-service.ims.icsi.mmtel";audio
To: <sip:0149145215@ ims.mnc001.mcc208.3gppnetwork.org>
From: <sip: 0149145215(g) ims.mnc001.mcc208.3gppnetwork.org>;tag=e9471567 Call-ID: TdTltDznlGj7GDzk9y2Z6w@ 10.10.1.2
CSeq: 2 REGISTER
Expires: 600000
Allow: I NVITE, ACK, OPTIONS, CANCEL, BYE, UPDATE, I N FO, REFER, NOTIFY, M ESSAGE, PRACK Supported: path, sec-agree, UDPfallback
P-Access-Network-lnfo: 3GPP-E-UTRAN-FDD;utran-cell-id-3gpp=1234
Content-Length: 0
Le cœur de réseau répond au terminal de la façon suivante :
SI P/2.0 543 Use U DP
Via: SIP/2.0/TCP 10.10.1.2:6100;branch=z9hG4bK-524287-l—
f9el3c5732becd59;rport;keep;transport=TCP;received=10.10.1.2;rport=6101
From: <sip: 0149145215@ims.mnc001.mcc208.3gppnetwork.org>;tag=e9471567
To: <sip: 0149145215@ims.mnc001.mcc208.3gppnetwork.org>;tag=zlDLflkeEU
Call-ID: TdTltDznlGj7GDzk9y2Z6w..@ 10.10.1.2
CSeq: 2 REGISTER
Require: UDPfallback
Content-Length: 0
Sur réception de cette réponse, le dispositif réémet la même requête REGISTER, mais cette fois sur UDP.
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.
Un terminal émet la requête d’établissement de session suivante :
INVITE sip:alice@ims. mnc001.mcc208.3gppnetwork.org SI P/2.0
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(g) 10.10.1.2:6100>;+sip.instance="<urn:gsma:imei: 0149145215-180-
02>";q=1.0;+g.3gpp.icsi-ref="urn%3Aurn-7%3A3gpp-service.ims.icsi.mmtel";audio
To: <sip:al ice@ims.mnc001.mcc208.3gppnetwork.org> From: <sip: 0149145215(g) ims.mnc001.mcc208.3gppnetwork.org>;tag=e9471567
Call-ID: srvtl5s6s8ftlg78jhljk8u@ 10.10.1.2
CSeq: 1 INVITE
Expires: 600000
Allow: I NVITE, AC K, OPTIONS, CANCEL, BYE, UPDATE, I N FO, REFER, NOTIFY, M ESSAGE, PRACK Supported: path, sec-agree, UDPfalIback
P-Access-Network-Info: 3GPP-E-UTRAN-FDD;utran-cell-id-3gpp=1234
Content-Length: 0
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) :
SI P/2.0 543 Use U DP
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(g) 10.10.1.2:6100>;+sip.instance="<urn:gsma:imei: 0149145215-180- 02>";q=1.0;+g.3gpp.icsi-ref="urn%3Aurn-7%3A3gpp-service.ims.icsi.mmtel";audio
To: sip:alice(5>ims.mnc001.mcc208.3gppnetwork.org;tag=45dr685s8rgh4h459d
From: <sip: 0149145215@ims.mnc001.mcc208.3gppnetwork.org>;tag=e9471567
Call-ID: srvtl5s6s8ftlg78jhljk8u@ 10.10.1.2
CSeq: 1 INVITE
Require: UDPfalIback
UDPfalIback: *=86400
Content-Length: 0
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.
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. Un terminal émet la requête d’établissement de session suivante :
INVITE sip:alice@ims. mnc001.mcc208.3gppnetwork.org SI P/2.0
Via: SIP/2. O/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="<urn:gsma:imei: 0149145215-180-
02>";q=1.0;+g.3gpp.icsi-ref="urn%3Aurn-7%3A3gpp-service.ims.icsi.mmtel";audio
To: <sip:al ice@ims.mnc001.mcc208.3gppnetwork.org>
From: <sip: 0149145215@ims.mnc001.mcc208.3gppnetwork.org>;tag=e9471567
Call-ID: srvtl5s6s8ftlg78jhljk8u@ 10.10.1.2
CSeq: 1 INVITE
Expires: 600000
Allow: I NVITE, AC K, OPTIONS, CANCEL, BYE, UPDATE, I N FO, REFER, NOTIFY, M ESSAGE, PRACK Supported: path, sec-agree, UDPfalIback
P-Access-Network-Info: 3GPP-E-UTRAN-FDD;utran-cell-id-3gpp=1234
Content-Length: 0
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) :
SI P/2.0 543 Use U DP
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="<urn:gsma:imei: 0149145215-180- 02>";q=1.0;+g.3gpp.icsi-ref="urn%3Aurn-7%3A3gpp-service.ims.icsi.mmtel";audio
To: sip:aliçe@i s.mnç001.mçç208.3gppngtwork.org;tag=45dr685s8rgh4h459d
From: <sip: 0149145215@ims.mnc001.mcc208.3gppnetwork.org>;tag=e9471567
Call-ID: srvtl5s6s8ftlg78jhljk8u@ 10.10.1.2
CSeq: 1 INVITE
Require: UDPfalIback
UDPfalIback: REGISTER =7200, OPTIONS =7200 Content-Length: 0
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.
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 « UDPfalIback ». Voici un exemple de mise en œuvre de ce quatrième mode de réalisation.
Un terminal émet la requête d’établissement de session suivante :
INVITE sip:alice@ims. mnc001.mcc208.3gppnetwork.org SI P/2.0
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(g) 10.10.1.2:6100>;+sip.instance="<urn:gsma:imei: 0149145215-180-
02>";q=1.0;+g.3gpp.icsi-ref="urn%3Aurn-7%3A3gpp-service.ims.icsi.mmtel";audio
To: <sip:al ice@ims.mnc001.mcc208.3gppnetwork.org>
From: <sip: 0149145215@ims.mnc001.mcc208.3gppnetwork.org>;tag=e9471567
Call-ID: srvtl5s6s8ftlg78jhljk8u@ 10.10.1.2
CSeq: 1 INVITE
Allow: INVITE, AC K, OPTIONS, CANCEL, BYE, UPDATE, I N FO, REFER, NOTIFY, M ESSAGE, PRACK Supported: 100rel,path, sec-agree, UDPfalIback
P-Access-Network-Info: 3GPP-E-UTRAN-FDD;utran-cell-id-3gpp=1234
Content-Length: 2568
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) :
SIP/2.0 183 Session Progress
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(g) 10.10.1.2:6100>;+sip.instance="<urn:gsma:imei: 0149145215-180- 02>";q=1.0;+g.3gpp.icsi-ref="urn%3Aurn-7%3A3gpp-service.ims.icsi.mmtel";audio
To: sip:alice(5>ims.mnc001.mcc208.3gppnetwork.org;tag=45dr685s8rgh4h459d
From: <sip: 0149145215@ims.mnc001.mcc208.3gppnetwork.org>;tag=e9471567
Call-ID: srvtl5s6s8ftlg78jhljk8u@10.10.1.2
CSeq: 1 INVITE
Require: lOOrel, UDPfallback
UDPfallback : *=86400
Content-Length: 0
Sur réception de cette réponse, pour toute nouvelle requête émise (le cas échéant) pendant 24 heures, le terminal utilisera UDP.
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 ».
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.
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.
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.
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.
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.
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).
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.
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

R E V E N D I C A T I O N S
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
1 1. 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.
12. Dispositif selon la revendication 1 1 , caractérisé en ce qu’il comprend en outre des moyens pour inclure une étiquette dédiée dans ladite requête SIP.
13. Dispositif-client, caractérisé en ce qu’il comprend un dispositif selon la revendication 1 1 ou la revendication 12.
14. Passerelle résidentielle caractérisé en ce qu’elle comprend un dispositif selon revendication 1 1 ou la revendication 12.
15. Moyen de stockage de données inamovible, ou partiellement ou totalement amovible, comportant des instructions de code de programme informatique pour l'exécution des étapes d'un procédé de basculement selon l’une quelconque des revendications 1 à 5.
16. Programme d'ordinateur téléchargeable depuis un réseau de communications et/ou stocké sur un support lisible par ordinateur et/ou 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 basculement selon l’une quelconque des revendications 1 à 5, lorsque ces étapes sont exécutées sur un ordinateur.
PCT/FR2019/053066 2018-12-17 2019-12-13 Procédé de basculement d'une communication de tcp sur udp WO2020128258A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR1873056A FR3090252B1 (fr) 2018-12-17 2018-12-17 Procédé de basculement d’une communication de TCP sur UDP
FR1873056 2018-12-17

Publications (1)

Publication Number Publication Date
WO2020128258A1 true WO2020128258A1 (fr) 2020-06-25

Family

ID=66676674

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/FR2019/053066 WO2020128258A1 (fr) 2018-12-17 2019-12-13 Procédé de basculement d'une communication de tcp sur udp

Country Status (2)

Country Link
FR (1) FR3090252B1 (fr)
WO (1) WO2020128258A1 (fr)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN112601122A (zh) * 2020-12-14 2021-04-02 福建福讯人才服务有限公司 一种基于udp的屏幕广播方法及系统
EP4247060A4 (fr) * 2020-11-10 2024-05-01 Vivo Mobile Communication Co., Ltd. Procédé et appareil de configuration de communication

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20050262251A1 (en) * 2004-05-03 2005-11-24 Microsoft Corporation Fast startup for streaming media
US20100241754A1 (en) * 2009-03-18 2010-09-23 Norimasa Niiya Telephone System, Server, and Terminal Device
US20150016446A1 (en) * 2013-04-30 2015-01-15 Metaswitch Networks Limited Sip signalling

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20050262251A1 (en) * 2004-05-03 2005-11-24 Microsoft Corporation Fast startup for streaming media
US20100241754A1 (en) * 2009-03-18 2010-09-23 Norimasa Niiya Telephone System, Server, and Terminal Device
US20150016446A1 (en) * 2013-04-30 2015-01-15 Metaswitch Networks Limited Sip signalling

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP4247060A4 (fr) * 2020-11-10 2024-05-01 Vivo Mobile Communication Co., Ltd. Procédé et appareil de configuration de communication
CN112601122A (zh) * 2020-12-14 2021-04-02 福建福讯人才服务有限公司 一种基于udp的屏幕广播方法及系统

Also Published As

Publication number Publication date
FR3090252A1 (fr) 2020-06-19
FR3090252B1 (fr) 2021-08-20

Similar Documents

Publication Publication Date Title
WO2010109125A1 (fr) Procede et dispositif de traitement d&#39;une information indicatrice d&#39;un souhait d&#39;implication dans au moins une session applicative d&#39;un utilisateur
EP2366238B1 (fr) Procede et systeme de regulation du trafic de redemarrage dans un reseau de telecommunications
FR3015838A1 (fr) Procede de mise a jour dynamique d&#39;informations obtenues de la part d&#39;un serveur dns
WO2011064492A1 (fr) Procede de basculement d&#39;un hss primaire sur un hss de secours dans un reseau ip
WO2020128258A1 (fr) Procédé de basculement d&#39;une communication de tcp sur udp
EP2396950B1 (fr) Procede et systeme de gestion de la signalisation dans un reseau de telecommunications
EP2926524B1 (fr) Routage d&#39;une requête de service visant un abonné ims
EP3158709A1 (fr) Procédé de sélection dynamique par un appelant parmi une pluralité de terminaux d&#39;un appelé
WO2017168084A1 (fr) Procédé de transfert de réseau d&#39;accès pour un terminal mobile en itinérance
EP3472993B1 (fr) Procédé de détermination d&#39;un ensemble de formats de codage pour établir une communication
EP3391615B1 (fr) Procédé de communication entre un terminal appelant et une pluralité de terminaux appelés
EP3632078B1 (fr) Procédé de contrôle d&#39;une communication comprenant des transactions multiples
EP3646578B1 (fr) Procédé de synchronisation d&#39;état média
WO2015181505A1 (fr) Procédé pour informer une entité d&#39;un réseau ip du type de réseau d&#39;accès utilisé par un terminal
EP2801178B1 (fr) Procédé dynamique de détermination d&#39;une liste de services dans un réseau sip
WO2014170582A1 (fr) Procede de restauration de service dans un reseau ims
WO2011117513A1 (fr) Procedes et dispositifs de contrôle de passerelles media
WO2012049404A1 (fr) Procede de traitement des flux de presence dans un reseau sip
WO2007148015A2 (fr) Systeme de declenchement d&#39;un comptage dans un reseau de transport a travers un reseau a architecture de type ims

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 19845589

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 19845589

Country of ref document: EP

Kind code of ref document: A1