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.