EP2283631A1 - Négociation optimisée de ressources de codage entre clients de communication - Google Patents

Négociation optimisée de ressources de codage entre clients de communication

Info

Publication number
EP2283631A1
EP2283631A1 EP09742312A EP09742312A EP2283631A1 EP 2283631 A1 EP2283631 A1 EP 2283631A1 EP 09742312 A EP09742312 A EP 09742312A EP 09742312 A EP09742312 A EP 09742312A EP 2283631 A1 EP2283631 A1 EP 2283631A1
Authority
EP
European Patent Office
Prior art keywords
message
client
called
calling
resource
Prior art date
Legal status (The legal status 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 status listed.)
Withdrawn
Application number
EP09742312A
Other languages
German (de)
English (en)
Inventor
Olivier Durecu
Bruno Legat
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Alcatel Lucent SAS
Original Assignee
Alcatel Lucent SAS
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 Alcatel Lucent SAS filed Critical Alcatel Lucent SAS
Publication of EP2283631A1 publication Critical patent/EP2283631A1/fr
Withdrawn legal-status Critical Current

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/10—Architectures or entities
    • H04L65/1045—Proxies, e.g. for session initiation protocol [SIP]
    • 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]

Definitions

  • the present invention relates to the negotiation of coding resources between two communication clients for the transmission of a multimedia session.
  • IMS IP Multimedia S ⁇ bsystem
  • any communication system based on signaling protocols for negotiation between customers who are on the call, coding resources they will use to transmit a multimedia session.
  • a signaling protocol may in particular be the SIP protocol specified by RFC 3261 of the IETF.
  • This SIP protocol (for Session Initiation Protocol) allows two parties to exchange the information necessary for the establishment of a multimedia session through a communication network.
  • This session can be a typical "voice” session but can also include data, video, and so on.
  • the information must be encoded in a digital format.
  • formats exist.
  • codoges may be better suited to certain situations. Thus, depending on whether we want to optimize the quality or the bandwidth used, we will not choose the same coding format.
  • Communication clients have one or more coding resources commonly referred to as "coded”. It may be software modules implement ⁇ t the coding algorithm, or specific or programmable electronic circuits.
  • SDP Session Description Protocol
  • RFC 2327 of NETF RFC 2543 titled "An Offer / Answer Mode / with Session Description Protocol (SDP)" more particularly describes the negotiation of coding resources to be used for setting up the multimedia session. This negotiation is based on the offer of one or more clients of available coding resources and the choice of a common resource among the "offered" coding resources common to both parties.
  • the invention has for its first object, a communication network device, comprising communication interfaces for transmitting signaling messages between a calling party and a called party.
  • These signaling messages may contain resource information about the encoding resources available to clients for establishing a communication session between those clients.
  • These signaling messages include - an invitation message sent by the calling customer to the called customer, - a response message, sent by the called client to the calling customer, and - a message of agreement sent by the calling customer to the called customer.
  • This equipment is innovative in particular that it also has the means to - delete the resource information contained in the invitation message before transmission to the called client,
  • the equipment may further comprise a memory provided for storing the resource information contained in the invitation message received from the calling client.
  • the means are provided for selecting the resource based on data concerning the bandwidth between the calling client and the called customer.
  • This data can for example be obtained from a location system or a network management system.
  • the invention also relates to a negotiation method for establishing a multimedia session between a calling client and a called client connected to a communication network, by exchanging signaling messages.
  • This signaling message exchange includes:
  • the method according to the invention is characterized in that the signaling messages are transmitted via an equipment of the communication network and in that this equipment: - deletes the resource information contained in the invitation message before transmission to the called customer, determines a set of usable resources from the resource information contained in the invitation message and the response message, and selects, where appropriate, one of the encoding resources from the set and inserts relative resource information to the resource as unique resource information within the response message before transmission to the calling client, and within the agreement message before transmission to the called client.
  • Figure 1 schematically shows a communication network comprising an equipment according to the invention.
  • FIG. 2 illustrates an exchange of signaling messages according to the invention.
  • the invention is also likely to apply to multimedia sessions involving more than two clients.
  • per communication client it must be not only understood a communication terminal, but also a content server or an application server, for example.
  • the invention can quite apply to the negotiation of coding resources to be used between a communication terminal and a video-on-demand server.
  • the communication terminals can be mobile telecommunication terminals, computers equipped with telecommunication interface, televisions also equipped, digital personal digital assistants (or PDAs for "Personal Digital Assistant"), etc.
  • FIG. 1 shows two communication clients A and B connected to a communication network N.
  • the communication clients have coding resources, R 1 and R respectively, and communication interfaces, I A and I respectively.
  • These coding resources, or “coded”, allow the encoding and decoding of an audio or video stream to or from a digital medium. Different codes may be available for each type of media: audio, video ... Some coded are better suited to certain types of content. Thus, if the audio is voice (for example, a telephone conversation) or music, the code to use may not be the same.
  • codecs for audio: PCMU and PCMA specified by the 1TU-T G.711 standard, ITU-T standard G.723, ILBC, AMR, AMR- WB ...
  • Each codec can be parameterized, thus forming as many coding resources as possible.
  • Communication clients also have communication interfaces. These interfaces allow them to send packets of data on the communication network N. This data can transport the multimedia sessions but also signaling messages, in particular compliant with the SIP protocol.
  • the communication network N comprises an equipment S.
  • This equipment can be a "SIP proxy".
  • SIP proxy In the context of an IMS ("IP Multiplia S ⁇ bsystem") type architecture, this proxy can be a CSCF ("CaII Session Control F ⁇ nction") function.
  • client A is the calling client and client B is the oppe client.
  • client A therefore sends an invitation message to the client B.
  • This invitation message may be a message S) P "INVITE", as illustrated in the diagram of FIG. 2.
  • this "INVITE" message contains data complying with the SDP protocol.
  • a simplified example of such an "INVITE” message is given below.
  • SOP data is used to describe the requested session.
  • the SDP data further contains resource information.
  • This information describes the encoding resources available to the communication client A. In this example, it has four audio codecs: AMR, AMR-WB, PCMU and PCAAA.
  • This invitation message "INVITE" is received by the equipment S via its interface I 9 . It is then processed by MT means available to this equipment. According to the invention, these means MT suppress less resource information contained in this incoming invitation message, and then transmit it to the B via the communication interface 1 SB .
  • the equipment S stores the deleted resource information for later use. This information can be stored in a MEM memory.
  • INVITE sip olivi ⁇ r @ l 72.27.204.168 SIP / 2.0
  • CaII-ID 0017a4f4fabf-8248031671927676087
  • Client B receives this invitation message via its communication interface I ,. So answer can depend on a decision of the user of the customer, and in particular of his acceptance or not of the call. It is assumed that the call is accepted by the communication client B and then responds with a "200 OK" response message in accordance with the IETF SIP protocol and RFC 2543. Since this invitation message does not include resource information, the "200 Ok” response message must include an "offer” of resources in the sense of RFC 3264. Such behavior is usual and illustrated notably by RFC 3725 entitled " Best Courtesy Pracfic ⁇ s for Third Party
  • the response message "200 Ok” therefore contains resource information relating to the coding resources available to the communication client B.
  • An example of a "200 Ok” response message is given below:
  • CaII-ID 0017a4f4fabf-8248031671927676087
  • the communication sink B indicates that it has three R encoding resources, audio: AMR, PCMU, and PCMA.
  • This response message is transmitted via the communication interface I 8
  • equipment S This receives it on its communication interface I SB and processes it by its processing means MT.
  • the processing means therefore have the resource information relating to the host B, transmitted by the response message "200 Ok", and resource information relating to the transceiver A, stored in the memory MEM.
  • the processing means MT are provided to determine a set of resources that can be used from the resource information from the two communication clients A and B.
  • This set of usable resources can be formed by all codoge resources common to clients A and B.
  • This set can be empty and in which case no session can be established. The request must then be rejected.
  • the set can also be reduced to a singleton.
  • the processing means MT can be made by the processing means MT in order to determine a single coding resource.
  • a coding resource is selected by the equipment S and this choice is imposed with communication clients A and B.
  • This selection can be made by the means MT as a function of data available at the end of the communication network N.
  • This data may relate in particular to the bandwidth on the links used for the transmission of the multimedia session between the clients A and B.
  • This data can for example be obtained from a location system which can identify the type of access network by which the clients are connected. This identification can be used as a limiting factor for choosing an appropriate code.
  • video codecs and codecs a ⁇ dio G.71 1 can be eliminated for the benefit of eg the AMR codec.
  • the data can also be obtained from a network management system that can access (and thus provide) information on network congestion and time and available bandwidth. Other devices may also be used to provide bandwidth data.
  • the equipment S can also use other criteria than the delay or the bandwidth to select one of the available codes.
  • the selected codec is the AMR codec because the available bandwidth is low and the AMR codec is the least expensive in bandwidth among available coding resources, AMR, PCMU, and PCMA.
  • the equipment S transmits the response message "200 Ok" to the calling client A, by first inserting information relating to the selected coding resource.
  • Such a response message can be for example as follows:
  • the communication client A receives this response message on its communication interface and this imposes on it the codec to be used for the transmission of the multimedia session.
  • This chord message does not normally contain information about the encoding resources.
  • This message is received by the equipment S on its interface I 38 .
  • the processing means MT insert in this received message the information relating to the chosen coding resource before transmitting it to the called communication client, B.
  • An example of an ACK agreement message forwarded to client B can be as follows:
  • the communication clients A and B are informed of the coding resource chosen by the equipment S and to be used for the establishment and transmission of the negotiated multimedia session.

Landscapes

  • Engineering & Computer Science (AREA)
  • Multimedia (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Business, Economics & Management (AREA)
  • General Business, Economics & Management (AREA)
  • Telephonic Communication Services (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Mobile Radio Communication Systems (AREA)

Abstract

Équipement (S) de réseau (N), comportant des interfaces (ISA, ISB) pour transmettre des messages de sîgnaiisation entre un client appelant (A) et un client appelé (B), pouvant contenir des informations de ressources relatives aux ressources de codage dont disposent ces clients et destinées à l'établissement d'une session de communication entre iesdifs clients, lî dispose de moyens (MT) pour supprimer Ses informations contenus dans un message d'invitation reçu du ciient appelant avant transmission au client appelé, pour déterminer un ensemble de ressources utilisables à partir des informations de ressources contenus dans ce message d'invitation et dans le message de réponse reçu du client appelé, et pour sélectionner, le cas échéant, une ressource de codage parmi ce! ensemble et insérer des informations relatives à cette ressource comme uniques informations au sein du message de réponse reçu du client appelé avant transmission au client appelant, et au sein du message d'accord reçu du client appelant avant transmission au client appelé.

Description

Négociation optimisée de ressources de codage entre cliente de communication
La présente invention concerne la négociation de ressources de codage entre deux clients de communication pour la transmission d'une session multimédia.
Elle s'applique particulièrement, mais pas exclusivement, aux architectures de communication appelées « IMS » (pour « IP Multimedia Sυbsystem) et spécifiées par les organismes de standardisation 3GPP et TlSPAN.
Elle s'applique toutefois également à tout système de communication basé sur des protocoles de signalisation permettant la négociation entre les clients partis à l'appel, des ressources de codage qu'ils vont utiliser pour transmettre une session multimédia. Un tel protocole de signalisation peut notamment être le protocole SIP spécifié par le RFC 3261 de l'IETF.
Ce protocole SIP (pour « Session Initiation Protocol ») permet à deux parties d'échanger les informations nécessaires à l'établissement d'une session multimédia au travers d'un réseau de communication. Cette session peut être une session « voix » classique mais peut également comporter des données, de la vidéo, etc.
Pour transmettre certains média, comme de l'audio ou de la vidéo, les informations doivent être codés sous un format numérique. Plusieurs formats existent.
Certains de ces codoges peuvent être mieux adaptés à certaines situations. Ainsi, selon que l'on veut optimiser la qualité ou la bande-passante utilisée, on ne choisira pas le même format de codage.
Les clients de communication disposent d'un ou de plusieurs ressources de codage que l'on appelle communément « Codée ». Il peut s'agir de modules logiciels implémentαπt l'algorithme du codage, ou bien de circuits électroniques spécifiques ou programmables.
Pour qu'une session multimédia puisse être transmise entre deux clients de communication, il est bien entendu nécessaire que ceux-ci partagent au moins une ressource de codage commune.
Préalablement à l'établissement de la session multimédia, les clients négocient le ou les ressources de codage à utiliser, par l'échange de messages de signalisation appropriés. Certains messages de signalisation SIP contiennent des données conformes au protocole SDP permettant de décrire la session multimédia à établir. Ce protocole SDP (« Session Description Protocol ») est spécifié par le RFC 2327 de NETF. Le RFC 2543 intitulé « An Offer/Answer Mode/ with fhe Session Description Protocol (SDP) » décrit plus particulièrement la négociation des ressources de codage à utiliser pour l'établissement de la session multimédia. Cette négociation se base sur l'offre d'un ou des clients des ressources de codage disponibles et du choix d'une ressource commune parmi les ressources de codage « offertes » commune aux deux parties.
II apparaît toutefois que la façon dont s'opère ce choix n'est pas spécifiée de façon précise, de sorte que chaque fabriquant de client de communication peut implémenter un algorithme différent de négociation des ressources de codage, tout en restant comptable avec les spécifications de l'IETF. En outre, le choix de codée à utiliser se fait de façon locale par les clients de communication. Par définition, ceux-ci n'ont pas une vision globale du réseau de communication et ne peuvent donc pas baser leur sélection sur des caractéristiques du réseau comme la bande passante disponible, un profil d'utilisateurs mémorisé dans une base de profils, etc. Le problème technique qui se pose est d'améliorer la situation en optimisant la négociation entre les clients de communication. Il s'agit notamment de rendre la négociation indépendante de l'algorithme de sélection implémenté par les clients de communication.
Pour ce faire l'invention a pour premier objet, un équipement pouf réseau de communication, comportant des interfaces de communication pour transmettre des messages de signalisation entre un dient appelant et un citent appelé. Ces messages de signalisation peuvent contenir des informations de ressources relatives aux ressources de codage dont disposent les clients et destinées à l'établissement d'une session de communication entre ces clients.
Ces messages de signalisation comprennent - un message d'invitation émis par le client appelant vers le client appelé, - un message de réponse, émis par le client appelé vers le client appelant, et - un message d'accord émis par le client appelant vers le client appelé. Cet équipement est novateur notamment en ce qu'il dispose en outre de moyens pour - supprimer les informations de ressources contenues dans le message d'invitation avant transmission au client appelé,
• déterminer υn ensemble de ressources utilisables à partir des informations de ressources contenus dans le message d'invitation et dans le message de réponse, et - sélectionner, le cas échéant (c'est-à-dire si l'ensemble déterminé comporte plus d'une ressource), une ressource de codage parmi cet ensemble et insérer des informations de ressources relatives à la ressource sélectionnée comme uniques informations de ressources au sein du message de réponse avant transmission au dient appelant, et au sein du message d'accord avant transmission au client appelé. Ces messages de signalisation peuvent être conformes au protocole SIP et les informations de ressources peuvent être conformes au protocole SOP.
Selon une mise en couvre de l'invention, l'équipement peut comporter en outre une mémoire prévue pour mémoriser les informations de ressources contenues dans le message d'invitation reçu du client appelant.
Selon un mode de réalisation de l'invention, les moyens sont prévus pour sélectionner la ressource en fonction de données concernant la bande- passante entre le client appelant et le client appelé. Ces données peuvent par exemple être obtenues d'un système de localisation ou d'un système de gestion de réseau.
L'invention a également pour objet un procédé de négociation pour l'établissement d'une session multimédia entre un client appelant et un client appelé connectés à un réseau de communication, par échange de messages de signalisation. Cet échange de message de signalisation comprend :
• l'émission d'un message d'invitation par le client appelant vers le client appelé, - l'émission d'un message de réponse par le client appelé vers le client appelant, et - l'émission d'un message d'accord par le client appelant vers le client appelé,
Le procédé selon l'invention se caractérise en ce les messages de signalisation sont transmis par l'intermédiaire d'un équipement du réseau de communication et en ce que cet équipement : - supprime les informations de ressources contenues dans le message d'invitation avant transmission au client appelé, - détermine un ensemble de ressources utilisables à partir des informations de ressources contenus dans le message d'invitation et dans le message de réponse, et - sélectionne, le cas échéant, une ressource de codage parmi l'ensemble et insère des informations de ressources relatives à la ressource comme uniques informations de ressources au sein du message de réponse avant transmission au client appelant, et au sein du message d'accord avant transmission au client appelé.
Ainsi, en déportant la sélection des ressources de codage à υtHiser, au sein d'un équipement du réseau de télécommunication, celle-ci devient indépendante des algorithmes qui sont impiémentéβ dans les clients eux- mêmes.
Il devient aussi possible de tirer profit de données globales à disposition de cet équipement pour sélectionner les ressources de codage à utiliser parmi celles possibles.
L'invention, ses caractéristiques, ses avantages apparaîtront de façon plus claire dans la description qui va suivre en liaison avec les figures annexées.
La figure 1 représente de façon schématique un réseau de communication comportant un équipement conforme à l'invention.
La figure 2 illustre un échange de messages de signalisation conforme à l'invention.
Afin de faciliter la description, nous ne nous intéresserons qu'à la situation où deux clients de communication négocient une session multimédia. Toutefois, l'invention est également susceptible de s'appliquer à des sessions multimédia impliquant plus de deux clients. De même, par client de communication, il doit être non seulement compris un terminal de communication, mais également un serveur de contenu ou un serveur applicatif, par exemple. Ainsi, l'invention peut tout à fait s'appliquer à la négociation des ressources de codage à utiliser entre un terminal de communication et un serveur de vidéo à la demande.
Les terminaux de communication peuvent être des terminaux mobiles de télécommunication, des ordinateurs équipés d'interface de télécommunication, des téléviseurs également équipés, des assistants personnels numériques (ou PDA pour « Personal Digital Assistant »), etc.
La figure 1 représente deux clients de communication A et B connectés à un réseau de communication N. Les clients de communication disposent de ressources de codage, respectivement R^ et R, et d'interfaces de communication, respectivement IA et I». Ces ressources de codage, ou « Codée », permettent le codage et le décodage d'un flux audio ou vidéo vers ou depuis un support numérique. Des Codée différents peuvent être disponibles pour chaque type de média : audio, vidéo... Certains codées sont mieux adaptés à certains types de contenu. Ainsi, si l'audio est de la voix (une conversation téléphonique, par exemple) ou de la musique, le code à utiliser peut ne pas être le même.
Comme exemples de codées, on peut citer, pour l'audio : PCMU et PCMA spécifié* par la norme G.711 de l'1TU-T, la norme G.723 de l'ITU-T, ÎLBC, AMR, AMR-WB...
Pour la vidéo, on peut citer : la norme H.261 , MPV (partie vidéo du format MPB3-1 ou MPEG-2)...
Chaque codée peut être paramétré, formant ainsi autant de ressources de codage possibles.
Les clients de communication disposent en outre d'interfaces de communication. Ces interfaces leur permettent d'envoyer des paquets de données sur le réseau de communication N. Ces données peuvent transporter les sessions multimédias mais également des messages de signalisation, notamment conformes au protocole SIP.
Le réseau de communication N comporte un équipement S. Cet équipement peut être un « proxy SIP ». Dans le cadre d'une architecture de type IMS (« IP Multimédia Sυbsystem »), ce proxy peut être une fonction CSCF (« CaII Session Control Fυnction »).
Il possède également des interfaces de communication lu et IM qui lui permettent d'émettre et recevoir des paquets de données transportant des sessions multimédia et des messages de signalisation. Dans l'exemple simplifié de la figure 1 , seules ont été représentées une interface I^ lui
permettant de communiquer avec le client A et une interface lu lui permettant de communiquer avec le client B.
Dans l'exemple illustré par la figure 1 , on suppose que le client A est le dient appelant et le client B est le client oppeié. le client A adresse donc un message d'invitation au client B. Ce message d'invitation peut être un message S)P « INVITE », ainsi qu'illustré sur le diagramme de la figure 2.
De façon connue en soi, ce message « INVITE » contient des données conformes av protocole SDP. Un exemple simplifié d'un tel message « INVITE » est donné ci-dessous. Les données SDP débutent par la ligne « v=0 ».
INVITE sip:olivier@l 72.27.204.168 SlP/2.0
CSeq: 1000 INVITE
To: sip;olivier@iive-irns.corn
Max-Forwards: 67 Content-Type: αppiicσtton/sdp
Cαll-ID: 0017α4f4fαbf-8248031671927676087
From: <»ip:olivier.clurβcu@αlcαtβl-lυœnt.conn>/-tαg=20017α4f4fαbf- 824803167-817-171438208 Contact: <sip:172.25.70.3:5660;trαnsport=UDP>
Content-Length: 319 v=O o=nυll 1234567890 1234567891 IN IP4 172.27.204.168 s=conversαfion i «conversation c»IN IP4 172.27.204.168 t-0 0 m=audio 4760 RTP/AVP 97 980 8 a*rtpmap:97 AMR/16000 a=rtpmap:98 AMR-WB/8000 σ»rtpmap:0 PCMU/8000 a=rtpmaρ:8 PCMA/8000 a=sendrecv
Les données au format SOP permettent de décrire la session demandée.
Il s'agit dans cet exemple d'une session audio.
Les données SDP contiennent en outre des informations de ressources. Ces informations décrivent les ressources de codage dont dispose le client de communication A. Dans cet exemple, il dispose donc de quatre codées audio : AMR, AMR-WB, PCMU et PCAAA.
Ce message d'invitation « INVITE » est reçu par l'équipement S via son interface I9. Elle est ensuite traitée par des moyens MT dont dispose cet équipement. Selon l'invention, ces moyens MT suppriment αυ moins les informations de ressources contenues dons ce message d'invitation entrant, puis le transmettent au dient B via l'interface de communication 1SB.
L'ensemble des données SDP peut être supprimé.
L'équipement S mémorise toutefois les informations de ressources supprimées afin de pouvoir ultérieurement les utiliser. Ces informations peuvent être mémorisées dans une mémoire MEM.
Un exemple de message d'invitation retransmis au client B est donné ci- dessous :
INVITE sip:oliviβr@l 72.27.204.168 SIP/2.0
CSeq: 1000 INVITE
To: sip:olivier@live-ims.com Max-Forwards: 67
Content-Type: application/sdp
CaII-ID: 0017a4f4fabf-8248031671927676087
From: <sip:olivïer.durecu®olcatβl-lucβnt.com>;tag=20017a4f4fabf- 824803167-817-171438208 Contact: <sip:172.25.70.3:5660,iransport=UDP>
Contβnt-Lβngth: 0
Le client B reçoit ce message d'invitation par son interface de communication I,. So réponse peut dépendre d'une décision de l'utilisateur du client, et notamment de son acceptation ou non de l'appel. On suppose que l'appel est accepté par le client de communication B et il répond alors par un message de réponse « 200 OK » conformément au protocole SIP et au RFC 2543 de l'IETF. Ce message d'invitation ne comportant pas d'informations de ressources, le message de réponse « 200 Ok » doit comporter une « offre » de ressources au sens du RFC 3264. Un tel comportement est habituel et illustré notamment par le RFC 3725 intitulé « Best Cυrrent Pracficβs for Third Party
Ca// Cόπfro/ (3pcc) m thβ Session Initiation Protocol ».
Le message de réponse « 200 Ok » contient donc des informations de ressources, relatives aux ressources de codage dont dispose le client de communication B. Un exemple de message de réponse « 200 Ok » est donné ci-dessous :
SIP/2.0 200 OK
To: <sip:divfβr@Hvβ-ims.com>;tog=47fbl a3f-l 207645032125630- 069 From: <$ip:olivier.durecu@alcatθl-lυcβnt.com>;tag=20017a4f4fabf-
824803167-817-171438208
CaII-ID: 0017a4f4fabf-8248031671927676087
CSβq: 1000 JNVITE
Contact: ol ivier<sip: olivier® 172.27.204.168> Content-Type: application/sdp
Content-Length: 178 v=0 o=LUSJPPhonβ 0 0 IN IP4 172.27.204.168 s » conversation («conversation c=IN HM 172.27.204.168 t=0 0 m=audio 8552 RTP/AVP 0 b=AS:64 a =rtρmap:97 AMR/16000 α=rtpmop:0 PCMU/8000 α=rtρmαp:8 PCMA/8000 α=sβndrβcv
Dans cet exemple, le dient de communication B indique qu'il dispose de trois ressources de codage R, audio : AMR, PCMU et PCMA.
Ce message de réponse est transmis via l'interface de communication I8
à l'équipement S. Celui-ci le reçoit sur son interface de communication ISB et le traite par ses moyens de traitement MT.
Les moyens de traitement disposent donc des informations de ressources relatives au dient B, transmises par le message de réponse « 200 Ok », et des informations de ressources relatives au dient A, mémorisées dans la mémoire MEM.
Les moyens de traitement MT sont prévus pour déterminer un ensemble de ressources utilisables à partir des informations de ressources provenant des deux clients de communication A et B.
Cet ensemble de ressources utilisables peut être formé par l'ensemble des ressources de codoge communes aux clients A et B.
Cet ensemble peut être vide et auquel cas aucune session ne peut être établie. La demande doit alors être rejetée.
L'ensemble peut également être réduit à un singleton.
Si l'ensemble des ressources utilisables comporte plus d'une ressource de codage, une sélection peut être opérée par les moyens de traitement MT afin de déterminer une unique ressource de codage.
De cette façon, une ressource de codage est sélectionnée par l'équipement S et ce choix est imposé avx clients de communication A et B. Cette sélection peut être effectuée par les moyens MT en fonction de données disponibles au seîn du réseau de communication N.
Ces données peuvent notamment concerner \a bande-passante sur les liens utilisés pour la transmission de la session multimédia entre les clients A et B.
Ces données peuvent par exemple être obtenues d'un système de localisation qui peut identifier le type de réseau d'accès par lequel les clients sont connectés. Cette identification peut être utilisée comme facteur limitant pour choisir un codée approprié. Ainsi, si un des clients est connecté via un réseau mobile 3G, les codées vidéo et les codées aυdio G.71 1 peuvent être éliminés au profit par exemple du codée AMR.
Les données peuvent aussi être obtenues d'un système de gestion de réseau qui peut avoir accès (et donc fournir) des informations sur Pencombrement du réseau et sur les délais et la bande-passante disponible. D'autres dispositifs peuvent également être utilisés pour fournir des données sur la bande-passante. L'équipement S peut en outre utiliser d'autres critères que le délai ou la bande-passante pour sélectionner un codée parmi ceux disponibles.
Dans l'exemple, le codée sélectionné est le codée AMR car la bande- passante disponible est faible et le codée AMR est le moins coûteux en bande- passante parmi les ressources de codage disponibles, AMR, PCMU et PCMA.
Après cette sélection, l'équipement S transmet le message de réponse « 200 Ok » vers le client appelant A, en insérant au préalable des informations relatives à la ressource de codage sélectionnée.
Un tel message de réponse peut être par exemple comme suit :
SIP/2.0 200 OK To: <sip:oliviβr@live-ims.com>;tαg=47fbla3f-1207Q45032125630- 069
From: <sip:olivier.dυrocυ@alcatel-lυcent.com>;tαg=20017α4f4fabf- 824803107-817-171438208 Call-ID: 0017α4f4fabf-8248031671927676087
CSeq: 1000 INVITE
Contact: olivier<sip;ofiviβr@172.27.204.1ό8> Content-Type: application/sdp Content-Length: 178 v=0 o=LUSIPPhonβ 00 IN IP4 172.27.204.168 s=conversation i=conversation c=IN IP4 172.27.204.168 t=0 0 m=audio 8552 RTP/AVP 0 b=AS:64 o=rtpmap:97 AMR/16000 a=sendrecv
Le client de communication A reçoit ce message de réponse sur son interface de communication et cela lui impose le codée à utiliser pour la transmission de la session multimédia.
Selon le RFC 3261, il répond alors par un message d'accord « ACK ».
Ce message d'accord ne contient normalement pas d'informations sur les ressources de codage.
Un exemple d'un tel message est donné ci-dessous :
ACK siρ:oliviβr@1 72.27.204.168 SIP/2.0 CSβq: 1000 ACK
To: <3ip:ofrvier@lrve-ims.com>,1cιg=47fblα3f- 1207645032125630.069
Mαx-Forwαrds: 68 From: <5ip:olîviβr.durβcυ@αlcαtβl-lυcβnt.com>,-tαg»20017o4f4fαbf-
824803167-817-171438208
Cαll-ID: 0017α4f4fabf-8248031671927676087
Content-Length: 0
Ce message est reçu par l'équipement S sur son interface I38. Les moyens de traitement MT Insèrent dans ce message reçu les informations relatives à la ressource de codage choisie avant de le transmettre au client de communication appelé, B.
Un exemple de message d'accord ACK retransmis au client B peut être comme suit :
ACK sip:olivîer@l 72.27.204.168 SIP/2.0
CSβq: 1000 ACK
To: <sip:oliviβr@livβ-»rns.com>;tag=47fbl a3f- 1207645032125630-069
Max-Forwards: 68
From: <sip:oliviβr.dυrβcu®aJaj1el-lucerrt.com>,iag=20017a4f4fabf- 824803167-817-171438208
CaII-ID: 0017a4f4fabf-8248031671927676087 Contβnt-Lβngth: 178 v=O o=LUSIPPhone 0 0 IN IP4 172.27.204.168
«^conversation i= conversation c=IN IP4 172.27.204.168 t=O O m=αυdio 8552 RTP/AVP 0 b=AS:64 α=rtpmαp:97 AMR/16000 α=sendrecv
De cette façon, les clients de communication A et B sont informés de la ressource de codage choisie par l'équipement S et à utiliser pour l'établissement et la transmission de la session multimédia négociée.

Claims

Revendications
1 ) Équipement (S) pour réseau de communication (N), comportant des interfaces de communication (I^ I*) pour transmettre des messages de signalisation entre un client appelant (A) et un client appelé (B), pouvant contenir des informations de ressources relatives aux ressources de codage dont disposent lesdits clients, destinées à l'établissement d'une session de communication entre lesdHs clients, lesdits messages de signalisation comprenant un message d'invitation émis par ledit client appelant vers ledit dient appelé, un message de réponse, émis par ledit client appelé vers ledit dient appelant, et un message d'accord émis par ledit dient appelant vers ledit dient appelé, caractérisé en ce qu'il dispose en outre de moyens (MT) pour supprimer les informations de ressources contenus dans ledit message d'invitation avant transmission audit client appelé, pour déterminer un ensemble de ressources utilisables à partir des informations de ressources contenus dans lesdits message d'invitation et message de réponse, et pour sélectionner, le cas échéant, une ressource de codage parmi ledit ensemble et insérer des informations de ressources relatives à ladite ressource comme uniques informations de ressources au sein dυdit message de réponse avant transmission audit dient appelant, et au sein dud'rt message d'accord avant transmission audit dient appelé.
2) Equipement selon la revendication précédente, dans lequel lesdits messages de signalisation sont conformes au protocole SIP, ledit message d'invitation étant un message « INVITE », ledit message de réponse étant un message « 200 OK », ledit message d'accord étant un message « ACK ».
3) Equipement selon la revendication précédente, dans lequel lesdites informations de ressources sont conformes aυ protocole SDP. 4) Equipement selon l'une des revendications précédentes, comportant en outre une mémoire (MEM) prévue pour mémoriser les informations de ressources contenues dans ledit message d'invitation reçu dudit client appelant.
5) Équipement selon l'une des revendications précédentes, dans lequel lesdits moyens (MT) sont prévus pour sélectionner ladite ressource parmi ledit ensemble de ressources disponibles en fonction de données concernant la bande-passante entre ledit client appelant et ledit client appelé.
6) Equipement selon la revendication précédente dans lequel IβsdHes données concernant la bande passante sont obtenus d'un système de localisation.
7) Equipement selon la revendication 5, dans lequel lesdites données concernant la bande-passante sont obtenus d'un système de gestion de réseau.
8) Procédé de négociation pour l'établissement d'une session multimédia entre un client appelant (A) et un client appelé (B) connectés à υr\ réseau de communication (N), par échange de messages de signalisation, ledit échange comprenant l'émission d'un message d'invitation par ledit client appelant vers ledit client appelé, l'émission d'un message de réponse par ledit client appelé vers ledit client appelant, et l'émission d'un message d'accord par ledit client appelant vers ledit client appelé, ledit procédé étant caractérisé en ce lesdits messages de signalisation sont transmis par l'intermédiaire d'un équipement (S) dudit réseau de communication et en ce que ledit équipement - supprime les informations de ressources contenues dans ledit message d'invitation avant transmission audit client appelé, - détermine un ensemble de ressources utilisables à partir des informations de ressources contenus dans lesdits message d'invitation et message de réponse, et - sélectionne, le cas échéant, une ressource de codage parmi ledit ensemble et insère des informations de ressources relatives à ladite ressource comme uniques informations de ressources au sein dudrt message de réponse avant transmission audit client appelant, et au sein dudit message d'accord avant transmission audit client appelé.
9) Réseau de communication (N) caractérisé en ce qu'il comporte un équipement selon l'une des revendications 1 à 7.
10) Programme d'ordinateur comportant un code programmé apte à mettre en oeuvre les étapes du procédé selon la revendication 8.
EP09742312A 2008-04-24 2009-04-10 Négociation optimisée de ressources de codage entre clients de communication Withdrawn EP2283631A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR0852752A FR2930699B1 (fr) 2008-04-24 2008-04-24 Negociation optimisee de ressources de codage entre clients de communication
PCT/FR2009/050663 WO2009136114A1 (fr) 2008-04-24 2009-04-10 Négociation optimisée de ressources de codage entre clients de communication

Publications (1)

Publication Number Publication Date
EP2283631A1 true EP2283631A1 (fr) 2011-02-16

Family

ID=40327288

Family Applications (1)

Application Number Title Priority Date Filing Date
EP09742312A Withdrawn EP2283631A1 (fr) 2008-04-24 2009-04-10 Négociation optimisée de ressources de codage entre clients de communication

Country Status (5)

Country Link
US (1) US20110016216A1 (fr)
EP (1) EP2283631A1 (fr)
CN (1) CN101960817B (fr)
FR (1) FR2930699B1 (fr)
WO (1) WO2009136114A1 (fr)

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN102811336A (zh) * 2011-06-03 2012-12-05 中兴通讯股份有限公司 多媒体能力协商方法及装置

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20030016630A1 (en) * 2001-06-14 2003-01-23 Microsoft Corporation Method and system for providing adaptive bandwidth control for real-time communication
EP2007105A1 (fr) * 2007-06-22 2008-12-24 Accenture Global Services GmbH Adaptateur de protocole d'initiation de session

Family Cites Families (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20100305943A1 (en) * 2001-08-27 2010-12-02 Andreas Witzel Method and node for the control of a connection in a communication network
US20040032860A1 (en) * 2002-08-19 2004-02-19 Satish Mundra Quality of voice calls through voice over IP gateways
GB2406022A (en) * 2003-09-15 2005-03-16 Matsushita Electric Industrial Co Ltd Method for releasing resources at SIP handover
WO2007028122A2 (fr) * 2005-09-02 2007-03-08 Nortel Networks Limited Reduction d'en-tete de protocole de lancement de session (sip)
US8223748B2 (en) * 2006-06-14 2012-07-17 Cisco Technology, Inc. Enhanced refresh in SIP network
US8036215B2 (en) * 2006-10-10 2011-10-11 Cisco Technology, Inc. Refreshing a session initiation protocol (SIP) session
US7907523B2 (en) * 2006-12-05 2011-03-15 Electronics And Telecommunications Research Institute Method and apparatus for controlling variable bit-rate voice codec
CN101601269B (zh) * 2006-12-08 2015-11-25 艾利森电话股份有限公司 用户媒体与通告媒体之间切换的方法，系统及通告服务器

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20030016630A1 (en) * 2001-06-14 2003-01-23 Microsoft Corporation Method and system for providing adaptive bandwidth control for real-time communication
EP2007105A1 (fr) * 2007-06-22 2008-12-24 Accenture Global Services GmbH Adaptateur de protocole d'initiation de session

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
See also references of WO2009136114A1 *

Also Published As

Publication number Publication date
WO2009136114A1 (fr) 2009-11-12
FR2930699A1 (fr) 2009-10-30
CN101960817A (zh) 2011-01-26
US20110016216A1 (en) 2011-01-20
FR2930699B1 (fr) 2010-06-11
CN101960817B (zh) 2015-08-05

Similar Documents

Publication Publication Date Title
EP2025181B1 (fr) Systeme d&#39;acces a un service de television sur ip dans un reseau a architecture ims
WO2009077683A1 (fr) Contrôle de l&#39;interface d&#39;émission d&#39;un message de réponse sip
EP1994724B1 (fr) Procede et systeme de caracterisation de noeuds de communication heterogenes
CN102025718A (zh) Sip端点增强器
EP2396950B1 (fr) Procede et systeme de gestion de la signalisation dans un reseau de telecommunications
EP2283631A1 (fr) Négociation optimisée de ressources de codage entre clients de communication
EP1647133A1 (fr) Controle d admission de session multimedia sur critere de re ssources reseau
EP3361746B1 (fr) Systeme de gestion de flux media
WO2020128258A1 (fr) Procédé de basculement d&#39;une communication de tcp sur udp
KR20100069419A (ko) 접속 설정 프로토콜 기반의 브이오 아이피 네트워크에서 미디어 코덱 결정 방법 및 장치
WO2008046697A1 (fr) Enrichissement de la signalisation dans une session de communication de type &#39; push to talk &#39; par insertion d&#39;une carte de visite
EP3701697A1 (fr) Procédé et entité de gestion d&#39;une session multimédia entre un terminal appelant et au moins un terminal appelé, terminal et programme d&#39;ordinateur correspondants
EP2079216B1 (fr) Mémorisation d&#39;informations contextuelles entre transmissions de messages de signalisation
FR2888698A1 (fr) Dispositif de communication, procede de formation d&#39;un message de protocole de transfort et procede de traitement d&#39;un message de protocole de transport
EP1964363A1 (fr) Procede de transfert de flux de communication
EP2801178B1 (fr) Procédé dynamique de détermination d&#39;une liste de services dans un réseau sip
EP2073493A1 (fr) Procédé de communication multimédia, serveur et produit programme d&#39;ordinateur correspondants
EP4366243A1 (fr) Procédé de traitement de flux de données d&#39;une session de conférence par un serveur de session
EP3225006A1 (fr) Procédé de négociation de codecs dans les réseaux ip
EP2252034A1 (fr) Refus d&#39;une demande de service contenu par un message de signalisation SIP &#34;UPDATE&#34;
Högberg Video telephony in an IP-based set-top box environment
Wu MMUSIC WG R. Even Internet-Draft Huawei Technologies Intended status: Informational J. Lennox Expires: December 30, 2013 Vidyo
FR2886797A1 (fr) Procede de communication entre un point de commande de services d&#39;un reseau intelligent et un serveur externe, point de commande, serveur externe, systeme et programmes d&#39;ordinateur associes
EP2403213A1 (fr) Methode et systeme pour l&#39;ajout d&#39;un record-route en-tete dans une requete de signalisation
EP2207325A1 (fr) Procédé de fourniture d&#39;informations de présence d&#39;un utilisateur dans un réseau

Legal Events

Date Code Title Description
PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

17P Request for examination filed

Effective date: 20101124

AK Designated contracting states

Kind code of ref document: A1

Designated state(s): AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HR HU IE IS IT LI LT LU LV MC MK MT NL NO PL PT RO SE SI SK TR

AX Request for extension of the european patent

Extension state: AL BA RS

DAX Request for extension of the european patent (deleted)
111Z Information provided on other rights and legal means of execution

Free format text: AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HR HU IE IS IT LI LT LU LV MC MK MT NL NO PL PT RO SE SI SK TR

Effective date: 20130410

RAP1 Party data changed (applicant data changed or rights of an application transferred)

Owner name: ALCATEL LUCENT

D11X Information provided on other rights and legal means of execution (deleted)
STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: EXAMINATION IS IN PROGRESS

17Q First examination report despatched

Effective date: 20161118

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE APPLICATION IS DEEMED TO BE WITHDRAWN

18D Application deemed to be withdrawn

Effective date: 20170329