FR2930699A1 - Negociation optimisee de ressources de codage entre clients de communication - Google Patents

Negociation optimisee de ressources de codage entre clients de communication Download PDF

Info

Publication number
FR2930699A1
FR2930699A1 FR0852752A FR0852752A FR2930699A1 FR 2930699 A1 FR2930699 A1 FR 2930699A1 FR 0852752 A FR0852752 A FR 0852752A FR 0852752 A FR0852752 A FR 0852752A FR 2930699 A1 FR2930699 A1 FR 2930699A1
Authority
FR
France
Prior art keywords
client
message
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.)
Granted
Application number
FR0852752A
Other languages
English (en)
Other versions
FR2930699B1 (fr
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
Priority to FR0852752A priority Critical patent/FR2930699B1/fr
Priority to EP09742312A priority patent/EP2283631A1/fr
Priority to CN200980107397.1A priority patent/CN101960817B/zh
Priority to US12/736,286 priority patent/US20110016216A1/en
Priority to PCT/FR2009/050663 priority patent/WO2009136114A1/fr
Publication of FR2930699A1 publication Critical patent/FR2930699A1/fr
Application granted granted Critical
Publication of FR2930699B1 publication Critical patent/FR2930699B1/fr
Expired - Fee Related legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/10Architectures or entities
    • H04L65/1045Proxies, e.g. for session initiation protocol [SIP]
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/1066Session management
    • H04L65/1069Session establishment or de-establishment
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/1066Session management
    • H04L65/1101Session protocols
    • H04L65/1104Session initiation protocol [SIP]

Landscapes

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

Abstract

Equipement (S) de réseau (N), comportant des interfaces (ISA, ISB) 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 ces clients et destinées à l'établissement d'une session de communication entre lesdits clients. Il dispose de moyens (MT) pour supprimer les informations contenus dans un message d'invitation reçu du client 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 cet 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 clients de communication
La présente invention concerne la négociation de ressources de codage 5 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 Subsystem) et spécifiées par les organismes de standardisation 3GPP et 10 TISPAN. 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 15 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 20 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 25 existent. Certains de ces codages 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 30 de codage que l'on appelle communément Codec . II peut s'agir de 802974 P:\ppg - dossiers temps\802974\projetbr 802974.doc modules logiciels implémentant 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 5 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. 10 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 l'IETF. Le RFC 2543 intitulé An Offer/Answer Mode( with the Session Description Protocol (SDP) décrit plus particulièrement la négociation 15 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.
20 Il 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. 25 En outre, le choix de codec à 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. 30 802974 P:\ppg - dossiers temps\802974\projetbr 802974.doc 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 pour réseau de communication, comportant des interfaces de communication pour transmettre des messages de signalisation entre un client appelant et un client 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 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é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 client appelant, et au sein du message d'accord avant transmission au client appelé. 802974 P:\ppg - dossiers temps\802974\projetbr 802974.doc
Ces messages de signalisation peuvent être conformes au protocole SIP et les informations de ressources peuvent être conformes au protocole SDP. Selon une mise en oeuvre 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 25 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é, 802974 P:\ppg - dossiers temps\802974\projetbr 802974.doc 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 à utiliser, au sein d'un équipement du réseau de télécommunication, celle-ci devient indépendante des algorithmes qui sont implémentés dans les clients eux-mêmes. II devient aussi possible de tirer profit de données globales à disposition 15 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 20 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. 25 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. 802974 P:\ppg - dossiers temps\802974\projetbr 802974.doc 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 RA et RB et d'interfaces de communication, respectivement IA et IB.
Ces ressources de codage, ou Codec , permettent le codage et le décodage d'un flux audio ou vidéo vers ou depuis un support numérique. Des Codec différents peuvent être disponibles pour chaque type de média : audio, vidéo... Certains codecs sont mieux adaptés à certains types de contenu. Ainsi, si l'audio est de la voix (une conversation téléphonique, par exemple) ou 20 de la musique, le code à utiliser peut ne pas être le même. Comme exemples de codecs, on peut citer, pour l'audio : PCMU et PCMA spécifiés par la norme G.71 1 de l'ITU-T, la norme G.723 de l'ITU-T, iLBC, AMR, AMR-WB... Pour la vidéo, on peut citer : la norme H.261, MPV (partie vidéo du 25 format MPEG-1 ou MPEG-2)... Chaque codec peut être paramétré, formant ainsi autant de ressources de codage possibles.
Les clients de communication disposent en outre d'interfaces de 30 communication. Ces interfaces leur permettent d'envoyer des paquets de 802974 P:\ppg - dossiers temps\802974\projetbr 802974.doc 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 ( 1P Multimedia Subsystem ), ce proxy peut être une fonction CSCF ( Cali Session Control Function ). Il possède également des interfaces de communication ISA et ISB 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 ISA lui permettant de communiquer avec le client A et une interface ISB lui permettant de communiquer avec le client B.
Dans l'exemple illustré par la figure 1, on suppose que le client A est le client appelant et le client B est le client appelé. Le client A adresse donc un message d'invitation au client B. Ce message d'invitation peut être un message SIP INVITE , ainsi qu'illustré sur 20 le diagramme de la figure 2. De façon connue en soi, ce message INVITE contient des données conformes au 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 . 25 INVITE sip:olivier@172.27.204.168 SIP/2.0 CSeq: 1000 INVITE To: sip:olivier@live-ims.com Max-Forwards: 67 30 Content-Type: application/sdp 802974 P:\ppg - dossiers temps\802974\projetbr 802974.doc Cali-1D: 0017a4f4fabf-8248031671927676087 From: <sip:olivier.durecu@alcatel-Iucent.com>; tag=20017a4f4fabf-824803167-817-171438208 Contact: <sip:172.25.70.3:5660;transport=UDP> Content-Length: 319 v=0 o=null 1234567890 1234567891 IN IP4 172.27.204.168 s=conversation i=conversation c=IN IP4 172.27.204.168 t=0 0 m=audio 4760 RTP/AVP 97 98 0 8 a=rtpmap:97 AMR/16000 a=rtpmap:98 AMR-WB/8000 a = rtpmap:0 PCMU/8000 a = rtpma p:8 PCMA/8000 a=sendrecv
Les données au format SDP permettent de décrire la session demandée. 20 II 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 codecs audio : AMR, AMR-WB, PCMU et PCMA. 25 Ce message d'invitation INVITE est reçu par l'équipement S via son interface ISB. Elle est ensuite traitée par des moyens MT dont dispose cet équipement. 802974 P:\ppg - dossiers temps\802974\projetbr 802974.doc Selon l'invention, ces moyens MT suppriment au moins les informations de ressources contenues dans ce message d'invitation entrant, puis le transmettent au client B via l'interface de communication ISB. 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.
10 Un exemple de message d'invitation retransmis au client B est donné ci- dessous : INVITE sip:olivier@172.27.204.168 SIP/2.0 CSeq: 1000 INVITE To: sip:olivier@live-ims.com 15 Max-Forwards: 67 Content-Type: application/sdp Call-ID: 0017a4f4fabf-8248031671927676087 From: <sip:olivier.durecu@alcatel-lucent.com>; tag=20017a4f4fabf-824803167-817-171438208 20 Contact: <sip:172.25.70.3:5660;transport=UDP> Content-Length: 0
Le client B reçoit ce message d'invitation par son interface de communication IB. 25 Sa 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. 30 802974 P:\ppg - dossiers temps\802974\projetbr 802974.doc 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 Current Practices for Third Party Cali Control (3pcc) in the 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 : 10 SIP/2.0 200 0K To: <sip:olivier@live-ims.com>;tag=47fb1 a3f-1207645032125630-069 From: <sip:olivier.durecu@alcatel-lucent.com>;tag =20017a4f4fabf-15 824803167-817-171438208 Call-ID: 0017a4f4fabf-8248031671927676087 CSeq: 1000 INVITE Contact: olivier<sip:olivier@172.27.204.168> Content-Type: application/sdp 20 Content-Length: 178 v=0 o=LUSIPPhone 0 0 IN IP4 172.27.204.168 s=conversation i= conversation 25 c=IN IP4 172.27.204.168 t=0 0 m=audio 8552 RTP/AVP 0 b=AS:64 a=rtpmap:97 AMR/16000 30 a=rtpmap:0 PCMU/8000 802974 P:\ppg - dossiers temps\802974\projetbr 802974.doc a=rtpmap:8 PCMA/8000 a=sendrecv
Dans cet exemple, le client de communication B indique qu'il dispose de 5 trois ressources de codage RB audio : AMR, PCMU et PCMA. Ce message de réponse est transmis via l'interface de communication IB à l'équipement S. Celui-ci le reçoit sur son interface de communication ISB et le traite par ses moyens de traitement MT.
10 Les moyens de traitement disposent donc des informations de ressources relatives au client B, transmises par le message de réponse 200 Ok , et des informations de ressources relatives au client A, mémorisées dans la mémoire MEM.
15 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 codage communes aux clients A et B. 20 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 25 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é aux clients de communication A et B.
Cette sélection peut être effectuée par les moyens MT en fonction de 30 données disponibles au sein du réseau de communication N. 11 802974 P:\ppg - dossiers temps\802974\projetbr 802974.doc Ces données peuvent notamment concerner la 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 codec approprié. Ainsi, si un des clients est connecté via un réseau mobile 3G, les codecs vidéo et les codecs audio G.711 peuvent être éliminés au profit par exemple du codec 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 l'encombrement 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 codec parmi ceux disponibles.
Dans l'exemple, le codec sélectionné est le codec AMR car la bande-passante disponible est faible et le codec AMR est le moins coûteux en bande-20 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. 25 Un tel message de réponse peut être par exemple comme suit :
SIP/2.0 200 0K To: <sip:olivier@live-ims.com>;tag=47fbl a3f-1207645032125630- 069 802974 P:\ppg - dossiers temps\802974\projetbr 802974.doc From: <sip:olivier.durecu@alcatel-lucent.com>; tag=20017a4f4fabf-824803167-817-171438208 CaII-ID: 0017a4f4fabf-8248031671927676087 CSeq: 1000 INVITE Contact: olivier<sip:olivier@l 72.27.204.168> Content-Type: application/sdp Content-Length: 178 v=0 o=LUSIPPhone 0 0 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 a=rtpmap:97 AMR/16000 a =sendrecv
Le client de communication A reçoit ce message de réponse sur son 20 interface de communication et cela lui impose le codec à 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 25 ressources de codage. Un exemple d'un tel message est donné ci-dessous :
ACK sip:olivier@l 72.27.204.168 SIP/2.0 CSeq: 1000 ACK 802974 P:\ppg - dossiers temps\802974\projetbr 802974.doc To: <sip:olivier@live-ims.com>;tag =47fb1 a3f- 1207645032125630-069 Max-Forwards: 68 From: <sip:olivier.durecu@alcatel-lucent.com>;tag=20017a4f4fabf- 824803167-817-171438208 Call-ID: 0017a4f4fabf-8248031671927676087 Content-Length: 0
Ce message est reçu par l'équipement S sur son interface ISB. Les 10 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 : 15 ACK sip:olivier@172.27.204.168 SIP/2.0 CSeq: 1000 ACK To: <sip:olivier@live-ims.com>;tag=47fb1 a3f- 1207645032125630-069 20 Max-Forwards: 68 From: <sip:olivier.durecu@alcatel-lucent.com>; tag=20017a4f4fabf-824803167-817-171438208 Call-ID: 0017a4f4fabf-8248031671927676087 Content-Length: 178 25 v=0 o=LUSIPPhone 0 0 IN IP4 172.27.204.168 s=conversation i=conversation c=IN IP4 172.27.204.168 30 t=0 0 802974 P:\ppg - dossiers temps\802974\projetbr 802974.doc 5 m=audio 8552 RTP/AVP 0 b=AS:64 a=rtpmap:97 AMR/16000 a=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.
15 802974 P:\ppg - dossiers temps\802974\projetbr 802974.doc

Claims (10)

  1. Revendications1) Équipement (S) pour réseau de communication (N), comportant des interfaces de communication (ISA, ISB) 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 lesdits clients, lesdits messages de signalisation comprenant un message d'invitation émis par ledit client appelant vers ledit client appelé, un message de réponse, émis par ledit client appelé vers ledit client appelant, et un message d'accord émis par ledit client appelant vers ledit client 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 dudit message de réponse avant transmission audit client appelant, et au sein dudit message d'accord avant transmission audit client appelé.
  2. 2) Equipement selon la revendication précédente, dans lequel lesdits messages de signalisation sont conformes au protocole SIP, ledit message 25 d'invitation étant un message INVITE , ledit message de réponse étant un message 200 0K , ledit message d'accord étant un message ACK .
  3. 3) Equipement selon la revendication précédente, dans lequel lesdites informations de ressources sont conformes au protocole SDP. 30 802974 P:\ppg - dossiers temps\802974\projetbr 802974.doc
  4. 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. 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é. 10
  6. 6) Equipement selon la revendication précédente dans lequel lesdites données concernant la bande passante sont obtenus d'un système de localisation. 15
  7. 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. 8) Procédé de négociation pour l'établissement d'une session 20 multimédia entre un client appelant (A) et un client appelé (B) connectés à un 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 25 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é, 802974 P:\ppg - dossiers temps\802974\projetbr 802974.doc 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 dudit message de réponse avant transmission audit client appelant, et au sein dudit message d'accord avant transmission audit client appelé.
  9. 9) Réseau de communication (N) caractérisé en ce qu'il comporte un équipement selon l'une des revendications 1 à 7.
  10. 10) Programme d'ordinateur comportant un code programmé apte à mettre en oeuvre les étapes du procédé selon la revendication 8. 802974 P:\ppg - dossiers temps\802974\projetbr 802974.doc
FR0852752A 2008-04-24 2008-04-24 Negociation optimisee de ressources de codage entre clients de communication Expired - Fee Related FR2930699B1 (fr)

Priority Applications (5)

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
EP09742312A EP2283631A1 (fr) 2008-04-24 2009-04-10 Négociation optimisée de ressources de codage entre clients de communication
CN200980107397.1A CN101960817B (zh) 2008-04-24 2009-04-10 通信客户之间的优化编码资源协商
US12/736,286 US20110016216A1 (en) 2008-04-24 2009-04-10 Optimized negotiation of coding resources between communication clients
PCT/FR2009/050663 WO2009136114A1 (fr) 2008-04-24 2009-04-10 Négociation optimisée de ressources de codage entre clients de communication

Applications Claiming Priority (1)

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

Publications (2)

Publication Number Publication Date
FR2930699A1 true FR2930699A1 (fr) 2009-10-30
FR2930699B1 FR2930699B1 (fr) 2010-06-11

Family

ID=40327288

Family Applications (1)

Application Number Title Priority Date Filing Date
FR0852752A Expired - Fee Related FR2930699B1 (fr) 2008-04-24 2008-04-24 Negociation optimisee 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
WO2007146041A2 (fr) * 2006-06-14 2007-12-21 Cisco Technology, Inc. Amélioration du rafraîchissement dans un réseau sip
US20080086566A1 (en) * 2006-10-10 2008-04-10 Cisco Technology, Inc. Refreshing a session initiation protocol (SIP) session

Family Cites Families (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7151749B2 (en) * 2001-06-14 2006-12-19 Microsoft Corporation Method and System for providing adaptive bandwidth control for real-time communication
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 Ind 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)
US7907523B2 (en) * 2006-12-05 2011-03-15 Electronics And Telecommunications Research Institute Method and apparatus for controlling variable bit-rate voice codec
EP2092726B1 (fr) * 2006-12-08 2019-02-27 Telefonaktiebolaget LM Ericsson (publ) Gestion de multimédia d'annonce dans un environnement de réseau de communications
EP2007105A1 (fr) * 2007-06-22 2008-12-24 Accenture Global Services GmbH Adaptateur de protocole d'initiation de session

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2007146041A2 (fr) * 2006-06-14 2007-12-21 Cisco Technology, Inc. Amélioration du rafraîchissement dans un réseau sip
US20080086566A1 (en) * 2006-10-10 2008-04-10 Cisco Technology, Inc. Refreshing a session initiation protocol (SIP) session

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
MARJOU FRANCE TELECOM J LINDQUIST ERICSSON P RAJAGOPAL MOTOROLA M SAID FRANCE TELECOM S GANESAN MOTOROLA X: "Session Description Protocol (SDP) Offer/Answer Model For Media Control Protocol; draft-marjou-mmusic-sdp-rtsp-01.txt", IETF STANDARD-WORKING-DRAFT, INTERNET ENGINEERING TASK FORCE, IETF, CH, no. 1, 25 February 2008 (2008-02-25), XP015054297, ISSN: 0000-0004 *

Also Published As

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

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
EP1994724B1 (fr) Procede et systeme de caracterisation de noeuds de communication heterogenes
EP1911245A2 (fr) Dispositif de gestion de ressources de serveurs media pour l&#39;interfacage entre serveurs d&#39;applications et serveurs media au sein d&#39;un reseau de communication
EP1946523A1 (fr) Procédé et serveur d&#39;invocation des serveurs d&#39;application dans un réseau sip
EP2396950B1 (fr) Procede et systeme de gestion de la signalisation dans un reseau de telecommunications
EP1964363B1 (fr) Procédé de transfert de flux de communication
WO2005011245A1 (fr) Controle d&#39;admission de session multimedia sur critere de ressources reseau
FR2930699A1 (fr) Negociation optimisee de ressources de codage entre clients de communication
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
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
EP2079216B1 (fr) Mémorisation d&#39;informations contextuelles entre transmissions de messages de signalisation
EP3225006B1 (fr) Procédé de négociation de codecs dans les réseaux ip
EP3361746A1 (fr) Systeme de gestion de flux media
FR3073115A1 (fr) Procede et entite de gestion d&#39;une session multimedia entre un terminal appelant et au moins un terminal appele, terminal et 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
EP2801178B1 (fr) Procédé dynamique de détermination d&#39;une liste de services dans un réseau sip
EP2091201A1 (fr) Procédé et dispositif de transfert d&#39;un signal de flux média au cours d&#39;une session de communication
FR2979505A1 (fr) Procede d&#39;insertion d&#39;un equipement intermediaire permettant le controle a distance de la qualite d&#39;une communication
EP2252034A1 (fr) Refus d&#39;une demande de service contenu par un message de signalisation SIP &#34;UPDATE&#34;
WO2005062568A1 (fr) Procede et systeme de gestion dune session de transmission de donnees en flux continu et en temps reel
EP2051478A1 (fr) Procédé d&#39;envoi d&#39;un contenu
EP2403213A1 (fr) Methode et systeme pour l&#39;ajout d&#39;un record-route en-tete dans une requete de signalisation
EP3866432A1 (fr) Transmission de flux de données adaptable
EP2207325A1 (fr) Procédé de fourniture d&#39;informations de présence d&#39;un utilisateur dans un réseau
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

Legal Events

Date Code Title Description
GC Lien (pledge) constituted

Effective date: 20130923

RG Lien (pledge) cancelled

Effective date: 20141016

CA Change of address

Effective date: 20150521

CA Change of address

Effective date: 20150521

PLFP Fee payment

Year of fee payment: 9

ST Notification of lapse

Effective date: 20171229