Brevet FR2930699A1 — publié le 20091030

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: ; tag=20017a4f4fabf-824803167-817-171438208 Contact: 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: ; tag=20017a4f4fabf-824803167-817-171438208 20 Contact: 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: ;tag=47fb1 a3f-1207645032125630-069 From: ;tag =20017a4f4fabf-15 824803167-817-171438208 Call-ID: 0017a4f4fabf-8248031671927676087 CSeq: 1000 INVITE Contact: olivier 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: ;tag=47fbl a3f-1207645032125630- 069 802974 P:\ppg - dossiers temps\802974\projetbr 802974.doc From: ; tag=20017a4f4fabf-824803167-817-171438208 CaII-ID: 0017a4f4fabf-8248031671927676087 CSeq: 1000 INVITE Contact: olivier 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: ;tag =47fb1 a3f- 1207645032125630-069 Max-Forwards: 68 From: ;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: ;tag=47fb1 a3f- 1207645032125630-069 20 Max-Forwards: 68 From: ; 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 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) 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) 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) 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é. 10 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) 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 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) 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. 802974 P:\ppg - dossiers temps\802974\projetbr 802974.doc