Visioconfrence et tlphonie sur IP : mise en uvre de H323 et SIP

Ludovic FONTAINE
mise en place dune confrence audio point point, puis dune confrence audio/vido. Ensuite, la mise en place dun pont de confrence (MCU) permettra ltude dune confrence plus de 2 participants. Enfin, linclusion dun garde-barrire (gatekeeper) lensemble du systme de confrences permettra notamment ltude de lauthentification des participants se joignant la confrence. A. Conversation audio H323 point point Le logiciel NetMeeting de Microsoft est excut et configur sur chaque participant. Ce logiciel permet non seulement deffectuer des confrences audio et vido H323, mais aussi des discussions crites en direct (chat), de partager un tableau blanc, ou encore, de transfrer des fichiers entre les participants. Aprs avoir parcouru les fonctionnalits de NetMeeting et les options de configuration notamment audio et vido, lenvoi et la rception de vido sont dsactivs puisque seule la conversation audio est tudie pour le moment. La commande netstat an ou le logiciel TCPview [4] permet tout moment de connatre les ports et protocoles de transport en coute ou en connexion. Une fois NetMeeting excut, le port TCP 1720 est en coute, il correspond au protocole Q931 de configuration dappel H323. Le port TCP 1503 est aussi en coute, correspondant au protocole dapplication de donnes temps rel T120.
Participant 1 Participant 2 Participant 3 Participant 4

Rsum Cet article prsente ltude de confrences audio et vido selon la suite de protocoles H323 et selon le protocole SIP. Diverses conversations point point entre 2 participants sont tudies laide danalyseurs de trames permettant ltablissement de diagrammes de communication, en vue de comprendre le fonctionnement de ces conversations audio et vido. Des confrences plus de 2 participants faisant intervenir un pont de confrence sont tudies dans les mmes conditions o sont mises en vidence des liaisons unicast avec le pont de confrence.

I. INTRODUCTION

ANS le cadre du module complmentaire de tlphonie et visioconfrence sur IP, sadressant plus particulirement aux parcours de renforcement de comptences professionnelles et dapprofondissement technologique, lobjectif de cet article est de mettre en uvre des solutions gratuites de visioconfrence et tlphonie sur IP, sous Windows, en point point et multipoints, afin dtudier et comprendre le fonctionnement de la voix et de la vido sur IP. La premire solution est oriente visioconfrence laide de lensemble de protocoles H323, la seconde est oriente tlphonie via le protocole SIP. Lanalyse des trames changes entre les participants et les autres quipements entrant dans le fonctionnement de la visioconfrence et de la tlphonie sur IP, permettra de comparer laspect pratique laspect thorique des protocoles en jeu. Enfin, plusieurs perspectives dtudes seront ensuite proposes pour approfondir les connaissances en visioconfrence et VoIP, comme le multicast IP lors de confrences multipoints ou encore les dbits audio et vido utiliss en fonction des codecs. II. PREAMBULE Chaque participant a sa disposition un ordinateur sous Windows XP Pro, muni dune carte rseau, dune carte son, dun casque, dun micro, dune webcam et dun analyseur de trames (Wireshark [1] ou ClearSight Analyzer [2]), tous correctement installs et configurs. Les ordinateurs sont interconnects en rseau via un switch (Fig. 1). III. VISIOCONFERENCE PAR H323 Cette premire solution concerne ltude de confrences audio et vido laide de lensemble de protocoles H323. Le logiciel NetMeeting [3] sera utilis en premier lieu pour la
Manuscript reu le 15 octobre 2007. Ce travail est support par le dpartement Rseaux et Tlcommunications (R&T) de lIUT de Blois. L. Fontaine est matre de confrences dans le dpartement Rseaux et Tlcommunications de lIUT de Blois, France (e-mail: ludovic.fontaine@univ-tours.fr).

Participants quips de : Webcam cran Carte son Micro Haut-parleurs

switch

Tous ordinateurs quips de : Windows XP Pro Carte rseau Adressage IP 10.0.0.x Analyseur rseau

Autres ordinateurs sans participant pour implmentation de diverses fonctionnalits

Fig. 1. Architecture du rseau incluant les quipements, les participants, et leurs configurations.

Un analyseur de trames permettant la capture et lanalyse des trames entrantes et sortantes est en service sur chaque ordinateur. Un participant effectue un appel vers un autre participant. Lanalyse des trames changes entre les 2 participants permet dtablir le diagramme douverture de session, de transfert de flux audio et de fermeture de session (Fig. 2). Chacune des phases de ce diagramme, les

protocoles mis en jeu et les codecs utiliss sont alors identifis.

Participant 1 Participant 2 O uv e rture conn exion TC P, pro to c ole Q9 31 TCP 1720 Q 931 H 22 5.0 CS set up TCP 1720 TCP 1720 Q9 31 H 22 5.0 CS alerting Le correspondant dcroche i 1 049 TCP 1720 Q 931 H 22 5.0 CS co nnect, p ort ngo c O uv erture conn exion TC P, pro to c ole H2 45 TCP 1049 decs s up por ts H 24 5 Te rminalC a pabilityS e t, liste co H 2 45 Termi n alC apabilityS et, li ste codecs s up por t s H2 45 M a s ter Slave D etermin a tio n

H 2 45 M asterS lave D etermination H2 45 Term in alCapab ilityS etA c k onA ck H 245 M as terS lav eD eter minati H 24 5 Mas terS laveD eter minationA ck
H 24 5 Op enLog ical C hann el dem ande ou verture canal flux aud io por

UDP 4 960 0

t ng oci H 245 O p en Log ical C hann el uver tu re can al flu x audio po rt ngoci demand e o H 24 5 O penLo gicalChan nelA ck 0 2, R TCP port 50 03 ac q o uver tu re canal R TP p ort 50 H 2 45 O penLo gicalCh an nelA c k acq ouv erture canal RT P p ort 49 6 00, RTC P po rt 496 01 TCP 1049

1,) F lu x RTP audio G 72 3 (ou autre G 71 F lux RTP audio G 72 3 (ou autr e G 71 1,)

Le correspondant raccroche H 2 45 End Ses sio nCo mmand ,

D isco nnect Q9 31 H 22 5. 0 CS r ele as e co mpl ete ct H 24 5 End Ses sio nCo mmand , D isco nne R initialis ati o n conn exion TC P, proto cole H 2 45

TCP 1049 TCP 1720 TCP 1049 TCP 1049 TCP 1720 TCP 1720

UDP 50 02

TC P 1 049

H2 45 Termin alC apabilityS etAck

B. Confrence audio/vido H323 Aprs avoir activs lenvoi et la rception de vido dans les options de configuration vido de NetMeeting, un participant effectue un appel vers un autre participant. Lanalyse de trames permet dtablir un diagramme (Fig. 3) analogue celui de la conversation audio seule, mais o il y a prsent ouverture de 2 canaux RTP dans chaque sens (un pour laudio G711, lautre pour la vido H261) ngocis par le protocole H245. Le port TCP 1720 correspond au protocole Q931 grant les appels H323 (appel, occupation, non rponse et libration de la ligne). Le protocole H245 sur un port TCP ngoci par Q931 permet louverture dun canal de contrle (tablissement du canal de transmission RTP, ngociation de codec, contrle de flux). Le flux RTP audio (ou vido) est ralis sur un port UDP pair ngoci par H245, le port UDP impair directement suprieur est consacr au flux RTCP assurant le contrle du flux RTP. Lors dun changement de qualit lorsquon fait varier la taille des images envoyes dans les options de configuration vido de NetMeeting, lanalyse approfondie des trames du flux RTP vido montre quil sagit du codec H261 ou H263 incluant un format dimage source diffrent en fonction de la taille des images : sub-QCIF 128x96 pixels, QCIF 176x144 pixels, CIF 352x288 pixels.
Participant 1 Participant 2

te Q 9 31 H 225 .0 C S releas e co mple R init ialis atio n conn exion TC P, pr oto cole Q 9 31

UDP 49602 UDP 49600

Flux RTP audio G 711

Fig. 2. Diagramme douverture de session, de transfert de flux audio et de fermeture de session faisant ressortir lenchanement des protocoles (Q931, H225, H245, RTP), de leurs fonctionnalits (requte, rponse, information, acquittement,), des ports UDP/TCP en jeu, des flux audio RTP et des codecs G7xx utiliss.

Flux RTP vido H2 61 Flux RTP vido H261

La premire phase concerne le protocole Q931 sur le port TCP 1720 initialisant la session et ngociant un numro de port pour la connexion TCP du protocole H245. La seconde phase concerne le protocole H245 permettant, entre autres, de saccorder sur le type de codec utilis pour la transmission du flux audio ainsi que du numro de port UDP utilis pour la transmission audio via le protocole RTP (Real-time Transport Protocol [7]). La troisime phase concerne la transmission bidirectionnelle simultane des flux audio via le protocole RTP et le codec G7xx utilis pour coder le signal audio. Enfin, la dernire phase concerne la dconnexion en fin de session, rinitialisant les connexions H245 et Q931. Le schma classique dune confrence audio via la suite de protocoles H323 est alors vrifi.

Fig. 3. Diagramme douverture et de transfert des flux audio et vido faisant ressortir lenchanement des protocoles (H245, RTP), des ports UDP en jeu, des flux audio et vido RTP et des codecs G7xx et H26x utiliss.

C. Pont de confrence H323 La mise en place dun pont de confrence (MCU : Multi Conference Unit) permet ensuite ltude dune confrence plus de 2 participants. Aprs avoir install le logiciel de confrence OpenMCU [5] sur un ordinateur ne faisant pas office de participant, puis dcouvert les nombreuses options du pont de confrence, la mise en place dun pont de confrence audio et vido sans recherche du garde-barrire est ralise par la commande openmcu n v . Le logiciel TCPview permet de voir que le pont de confrence est en coute sur le port TCP 1720 correspondant au protocole de configuration dappel Q931.

UDP 5004 UDP 5002

k H245 OpenLog icalC hann elAc TCP port 5003 acq canal G71 1 RTP port 500 2, R TCP port 5005 acq canal H26 1 RTP po rt 50 04, R H24 5 OpenLo gicalChannelA ck acq canal G71 1 RT P po rt 49600, RTC P po rt 49 601 acq canal H26 1 RTP po rt 49 602, RTC P port 49603 F lux R TP audio G71 1

Chaque participant effectue un appel auprs du pont de confrence. Aprs ouverture de session par le protocole Q931, et ngociation des codecs et ports UDP utiliss pour les transferts audio et vido, les flux RTP audio et vido sont changs entre chaque participant et le pont de confrence. Une analyse dtaille des trames sur chacun des participants et sur le pont de confrence permet llaboration dun diagramme (Fig. 4) et la comprhension du fonctionnement de la confrence o chaque flux RTP est en liaison point point avec le pont de confrence.
Participant 1 Participant 2

Q 93 1

Q9 31

Flux RTP audio G711 Flux RTP vido H261 Participant 3 Q 93 1

MCU : Pont de confrence

H 245

H2 45
Flux RTP audio G711 Flux RTP vido H261 Participant 4

Q9 31

D. Garde-barrire H323 La mise en place dun garde-barrire (gatekeeper, logiciel OpenGK [5]) permet dtudier lacceptation des participants joindre la confrence. Aprs installation du logiciel OpenGK sur un ordinateur ne faisant pas office de participant, la commande opengk debug permet son excution. Le logiciel TCPview permet de voir que le gardebarrire est lcoute sur les ports TCP 1719 et UDP 1719 correspondant au protocole RAS (Registration, Admission, Status) de dialogue avec le garde-barrire. La commande openmcu v permet le dmarrage du pont de confrence audio et vido avec recherche du gardebarrire. Une tude des trames permet dtablir le diagramme (Fig. 6) mettant en vidence la recherche du garde-barrire par le pont de confrence, puis lassociation et lenregistrement du pont de confrence auprs du gardebarrire.
Pont de Broadcast confrence 255.255.255.255 H2 25. 0 RAS Gatekeeper Request UDP 1719 Garde-barrire Co nfirm UDP 1719 H 225 .0 R AS Gat ekeeper H225.0 RAS Registratio n R equest UDP 1719 Confir m UDP 1719 H225.0 R AS Reg istration

H 245
Flux RTP audio G711 Flux RTP vido H261

H245
Flux RTP audio G711 Flux RTP vido H261

Fig. 4. Diagramme douverture de sessions Q931 H245, de transfert des flux audio et vido, de multiples confrences point point avec un pont de confrence.

Le pont assure le mixage audio et vido des flux en provenance des participants (Fig. 5). La fentre vido est dcoupe en 4 permettant de voir jusqu 4 participants simultanment. Le pont de confrence renvoie chaque participant un flux audio qui est la somme des flux audio lui arrivant. Ici, il ny a pas diffusion en multicast avec un adressage IP de classe D dun unique flux audio et dun unique flux vido du pont de confrence vers les participants. Le pont de confrence renvoie autant de flux audio et vido identiques quil y a de participants.
Participant 1 Participant 2 Participant 3 Participant 4

Fig. 6. Dcouverte du garde-barrire puis association et enregistrement du pont de confrence auprs du garde-barrire.

Une tude de trames et des diagrammes associs finalise le fonctionnement dune confrence H323 plus de 2 participants en faisant intervenir un pont de confrence et un garde-barrire. Le diagramme (Fig. 7) montre lacceptation puis la libration du participant auprs du garde-barrire.
Participant 1 Pont de confrence Ouvert ure connexion TCP Q931 TCP 1720 Q931 H225.0 CS setup TCP 1720 eding Garde-barrire TCP 1720 Q931 H225.0 CS call proce H225.0 RAS Admission Requ est UDP 1719 firm UDP 1719 H225.0 RAS Adm ission Con H225.0 RAS Info Requ est Respon se UDP 1719 t Ack UDP 1719 H225.0 RAS Info Reques ct (port 1059) TCP 1720 Q931 H225.0 CS conne Ouverture connexion TCP H245 TCP 1059 H245 Flux RTP

tablissement communication Ngociation codec change flux audio vido en unicast bidirectionnel
MCU

switch

Gestion des GK accs la confrence Pont de confrence GateKeeper Mixage audio et vido Garde barrire

H245 EndSessionCo mmand , Discon nect

Q931 H225 .0 CS release comp lete nd, Disconnect H245 EndS essionC omma Rinitialisation connex ion TCP H245 e compl ete Q931 H225.0 CS releas Riniti alisatio n connexion TCP Q931

TCP 1059 TCP 1720 TCP 1059 TCP 1059 TCP 1720 TCP 1720 H225.0 RAS Disengage Requ est

Confirm H225.0 RAS Diseng age

UDP 1719 UDP 1719

Fig. 5. Schma du rseau regroupant les participants, le pont de confrence et le garde-barrire. Chaque participant envoie un flux unicast audio et un flux unicast vido au pont de confrence effectuant le mixage des flux audio et vido. Le pont de confrence renvoie chaque participant le mme flux audio mix et le mme flux vido mix.

Fig. 7. Acceptation puis libration du participant auprs du gardebarrire.

E. Synthse sur la suite de protocoles H323 Le droulement complet dune confrence H323 a t tudi. Chaque participant ouvre une session H323 (Q931, H245) auprs du pont de confrence. Aprs demande par le pont de confrence auprs du garde-barrire, puis acceptation par ce dernier (H225 RAS), le participant est autoris joindre la confrence. Il ngocie les codecs et les ports utiliss (H245) pour le transport des flux audio et vido RTP en temps rel. En fin de session, le participant se libre de la confrence et rinitialise ses connexions TCP avec le pont de confrence. Ce dernier libre le participant auprs du garde-barrire. IV. TELEPHONIE SUR IP PAR SIP La deuxime solution concerne ltude de communications tlphoniques sur IP laide des protocoles SIP (Session Initiation Protocol [8]) et RTP. La mise en place dun logiciel client de tlphonie sur IP sera ralise dans un premier temps pour tablir une communication audio point point entre 2 participants. Puis, la mise en place dun IPBX autocommutateur de tlphonie sur IP permettra de faire le lien entre les diffrents participants. Enfin, linsertion dun pont de confrence SIP permettra ltude dune confrence ToIP plus de 2 participants. A. Communication audio SIP point point Le logiciel client de tlphonie (softphone Express Talk NCH [6]) est install sur chaque participant. La configuration en liaison directe point point ncessite lattribution dun numro de tlphone SIP (identifiant) pour chaque participant. Pour le moment, il ny a pas de serveur SIP ou IPBX. Par dfaut, le port SIP en coute est UDP 5070, le port RTP pour le transport de laudio en temps rel est UDP 8000. Ces ports et protocoles de transport en coute sont visualiss en permanence par le logiciel TCPview. Un analyseur de trames permettant la capture et lanalyse des trames entrantes et sortantes est en service sur chaque ordinateur. Un participant effectue un appel direct vers un autre participant : identifiant@adresse_IP. Il est remarquer que pour effectuer un appel, il est normal de connatre lidentifiant (le numro de tlphone SIP) de lappel, mais il est aussi ncessaire de connatre ladresse IP du correspondant, ce qui est moins trivial. Une analyse dtaille des trames permet llaboration dun diagramme (Fig. 8) faisant ressortir lenchanement des protocoles (SIP, RTP), de leurs fonctionnalits (requte, rponse, information, acquittement,), des ports UDP en jeu, des flux audio RTP et des codecs G7xx utiliss. Les phases du diagramme sont alors identifies. Transport par UDP, la premire phase concerne le protocole SIP invitant le second participant lappel entrer en communication avec le premier participant lappelant. Le protocole SDP (Session Description Protocol [9]) permet de lister les codecs supports par lappelant. Le port UDP pour le transport des donnes audio temps rel via RTP est aussi transmis. Lors de la seconde phase, aprs une

sonnerie, lappel dcroche et envoie son numro de port UDP pour le transport RTP. La troisime phase concerne la transmission bidirectionnelle simultane des flux audio via le protocole RTP et le codec G7xx utilis pour coder le flux audio. Enfin, la dernire phase concerne la dconnexion SIP lorsquun correspondant raccroche. Le schma classique dune conversation audio via SIP est alors vrifi.
Participant 2 Softphone 10.0.0.2 UDP 5070

SIP INVITE sip:10 1@10. 0.0.1 From: <sip:1 02@10 .0.0.2> To: <sip:10 1@10.0 .0.1> Liste protoco les audio supp orts : SDP session description protocol RTP sur UDP 8000

Participant 1 Softphone 10.0.0.1

UDP 5070

UDP 5070 UDP 5070 UDP 5070 UDP 8000 UDP 8000 UDP 8000 UDP 8000

SIP 180 Ringing SIP 200 OK > From: <sip :102@1 0.0.0.2 To: <sip:1 01@10 .0.0.1> RTP sur UDP 8000
SIP ACK

UDP 5070 Le correspondant dcroche UDP 5070

9 Conf ort Noise RTP Payl oad Type PT=1 RTP Payload Type PT=19 Confo rt Noise 1 RTP Payload Type PT=0 G.71 RTP Payload Type PT=0 G.711 SIP BYE sip:102@10.0.0.2
SIP 200 OK

UDP 5070 UDP 8000 UDP 8000 UDP 8000

UDP 5070 UDP 5070

UDP 8000 Le correspondant raccroche UDP 5070 UDP 5070

Fig. 8. Diagramme douverture de session, de transfert de flux audio et de fermeture de session faisant ressortir lenchanement des protocoles (SIP, RTP), de leurs fonctionnalits (requte, rponse, information, acquittement,), des ports UDP en jeu, des flux audio RTP et des codecs G7xx utiliss.

B. Architecture de ToIP avec un IPBX SIP La premire conversation directe entre 2 softphones ncessitant la connaissance de ladresse IP du correspondant en plus de son identifiant, linstallation dun autocommutateur de tlphonie sur IP (IPBX, logiciel Axon NCH [6]) est ralise sur un ordinateur ne faisant pas office de participant. LIPBX est configur en entrant le nom, le mot de passe et le numro de tlphone SIP de chaque participant. Le logiciel TCPview permet de vrifier que le port UDP 5060 est en coute par dfaut sur lIPBX permettant un participant softphone de sadresser lIPBX via le protocole SIP. Chaque softphone est reconfigur pour prendre en compte lIPBX : le serveur SIP correspond ladresse IP de lIPBX, le numro SIP, le nom et le mot de passe doivent tre identiques ceux entrs dans lIPBX pour le participant en question. Une analyse de trames et le diagramme (Fig. 9) correspondant permettent de comprendre lassociation et lenregistrement de chaque softphone auprs de lIPBX. Lors de lenregistrement du participant, celui-ci demande lIPBX une association de 3600 secondes pour son

identifiant (101), alors que lors de la disjonction, le participant demande une association de 0 seconde provoquant la rupture de lassociation.
Association dun participant softphone auprs de lIPBX Participant 1 IPBX Softphone 10.0.0.4 10.0.0.1 SIP R EGI STE R sip:1 0.0 .0.4 To: <sip:10 1@1 0.0 .0.4 > UDP 5070 Fr om : <sip:1 01@ 10.0.0. 4> UDP 5060 Aut orisatio n exp ires=36 00 s eco ndes 200 OK SIP UDP 5060 UDP 5070 1 bind ing

Participant 2 Participant 1 IPBX Softphone Softphone 10 .0 .0 .4 S IP IN V IT E s ip:101 @10. 10.0.0.2 10 .0.0.1 0. 0. 4 F ro m: < s ip:102 @ 10. 0. 0 . 4> T o: < s ip:101 @ 10 .0 .0 .4 > U D P 5070 Lis te pr otocoles au dio su pp o rts : U D P 5060 S D P s ess ion des cription p r otoco l R TP s ur U DP 80 00 SI P 40 7 pro xy U D P 5060 U D P 5070 authentication requ ire d S IP A C K s ip :101 @ 10. 0. 0 U D P 5070 .4 U D P 5060 S IP IN V ITE s ip:101 @10. 0 . 0. 4 F ro m: < s i p:102 @ 10. 0. 0. 4> T o: < s ip:101 @10 .0 .0 .4 > U D P 5070 L is te pr otocoles au dio s upp ort s : SD P U D P 5060 RTP s ur U D P 8 000 A utor is ation avec diges t M D5 S IP Trying U D P 5060 U D P 5070 S IP I NV IT E s ip:10 1@10 .0 .0 .4 Fro m: <s ip:10 2@ 10 .0 .0 .4 > To: <s ip:10 1@ 10 .0 .0 .4 > U D P 5060 Lis te p rotoco le s audio s upp or U D P 5070 ts : S DP RTP su r U D P 8 000 U D P 5060 U D P 5070

S IP 1 80 R in ging SI P 20 0 OK F rom: < sip:1 02@1 0. 0. 0. 4> To: < sip:10 1@1 0. 0. 0. 4> R T P s ur U DP 80 00 S IP A CK

S IP 18 0 Ring ing

U D P 5060

U D P 5070 Le correspondant dcroche

Rupture de lassociation auprs de lIPBX Participant 1 IPBX Softphone 10.0.0.4 10.0.0.1 SIP REGISTER si p:10.0.0 .4 To: < sip: 101@10 .0.0 .4> UDP 5070 From: <sip :10 1@10.0 .0.4 > UDP 5060 Au tori satio n ex pires=0 second e K SIP 20 0 O UDP 5060 UDP 5070 0 bin din g

U D P 5070

S IP 200 O K Fr om: <s ip:10 2@10 .0 .0 .4 > T o: < s ip:101 @10 .0 .0 .4 > P su r U D P 8 000 RT
SIP A CK

U D P 5060

U D P 5070

U D P 5070

U D P 5060 U D P 8000 U D P 8000 U D P 8000 U D P 8000 Le correspondant raccroche U D P 5070

U D P 8000 U D P 8000

RTP Pa y lo ad Type P T = 19 Co nfo rt N ois e RTP Pay lo ad Typ e P T= 19 Co nfo rt N o is e RT P P a yload Typ e P T = 0 G .7 11

U D P 8000 U D P 8000

R TP P ayload Ty pe PT= 0 G . 711

IPBX 10 .0 .0 .4 U D P 5060

SIP BY E sip :1 02@ 10. 0. 0. 4

S IP 200 O K

Fig. 9. Association puis disjonction dun participant softphone auprs de lIPBX.

U D P 5070 U D P 5070

U D P 5060 U D P 5060 S IP B Y E s ip:10 2@1 0.0 .0 .4

U D P 5070

S IP 2 00 O K

U D P 5060

A prsent, un participant tablit une conversation avec un autre participant via lIPBX, en spcifiant uniquement lidentifiant de lappel sans adresse IP. Lanalyse des trames permet de concevoir un diagramme (Fig. 10) mettant en vidence le fonctionnement de la tlphonie IP via SIP : tablissement de la connexion entre les 2 softphones via lIPBX, puis transfert direct du flux RTP entre les 2 softphones, tude des numros de ports UDP/TCP en jeu, et codecs audio utiliss. Linterprtation de ce diagramme permet didentifier chaque phase. La premire phase concerne lappel du participant dadresse SIP 102 auprs de lIPBX afin dtre mis en relation avec lappel dadresse SIP 101. Aprs authentification de lappelant et envoi des codecs audio supports, lIPBX fait suivre la requte lappel dans la deuxime phase. La sonnerie se fait entendre chez les 2 participants. Lappel dcroche et la troisime phase concerne lacceptation de la mise en relation appelant appel. Les numros de port UDP permettant le transport des donnes temps rel par RTP ont aussi t changs. La quatrime phase concerne le transfert audio direct entre les 2 participants via RTP et le codex G711 utilis, sans passer par lIPBX. Enfin, la dernire phase concerne la libration de la connexion auprs de lIPBX. Il est remarquer que tous les changes SIP se font via le protocole de transport UDP.

Fig. 10. Diagramme douverture de session, de transfert de flux audio et de fermeture de session entre 2 participants via un IPBX faisant ressortir lenchanement des protocoles (SIP, RTP), de leurs fonctionnalits (requte, rponse, information, acquittement,), des ports UDP en jeu, des flux audio RTP et des codecs G7xx utiliss.

C. Pont de confrence SIP La mise en place dun pont de confrence SIP (logiciel Quorum NCH [6]) permet ltude dune conversation tlphonique IP plus de 2 participants. Aprs avoir install le pont de confrence SIP, puis affect un numro de tlphone pour la confrence et un code de confrence permettant lauthentification des participants, il convient de dclarer le numro de tlphone pour la confrence auprs de lIPBX. A prsent, chaque participant dsirant joindre la confrence effectue un appel sur le numro de confrence. Une communication unicast entre chaque participant et le pont de confrence est alors tablie via lIPBX. Chaque participant est invit entrer lidentifiant de confrence par un message audio. Une fois authentifis, les participants se retrouvent en confrence. Une dernire tude des trames et diagrammes associs sur chaque participant, sur lIPBX et le pont de confrence SIP permet la comprhension du fonctionnement dune confrence SIP plus de 2 participants. Il est remarquer que chaque flux RTP est en liaison point point avec le pont de confrence (Fig. 11). Le pont de confrence effectue la somme des flux audio en provenance des participants avant

de renvoyer chaque participant le mme flux mix.

F R lux T u P n l m ux du i ca ix u pa st ni rt au R ca ic d T st ip i o P a a du ud nt po io nt
Participant 1 Softphone 10.0.0.1 Participant 2 Softphone 10.0.0.2

F R lux T u Fl P n m ux du i ca ix un pa st a R ic a r ti c ud T st i p io P a a du ud nt po io nt

Pont de confrence SIP 10.0.0.3

Participant 5 Softphone 10.0.0.5

Participant 6 Softphone 10.0.0.6

Fig. 11. Echange de flux unicast entre chaque participant et le pont de confrence SIP.

D. Synthse sur la ToIP par SIP Le droulement complet dune conversation tlphonique sur IP via le protocole SIP a t tudi entre 2 participants et en confrence (Fig. 12). Chaque participant ouvre une session SIP vers le pont de confrence via lIPBX. Aprs validation de lidentifiant de confrence par le pont de confrence, les participants changent leur flux RTP temps rel audio unicast directement avec le pont de confrence qui renvoie en unicast le flux mix chacun des participants.
Participant 1 Participant 2 Participant 3 Participant 4

participants, chaque flux allant du pont de confrence chacun des participants. La mise en place dun adressage IP multicast entre le pont et les participants permettrait au pont de ne diffuser quun seul flux RTP vers lensemble des participants, rduisant ainsi la bande passante utilise. Il est aussi remarquer que toutes les requtes et rponses douverture de session par le protocole Q931 et de ngociation de codecs et numros de ports par H245, seffectuent via le protocole de transport TCP lors des confrences en H323. En revanche, ces requtes et rponses douverture de session et ngociation de ports par le protocole SIP seffectuent via le protocole de transport UDP. Lors de louverture dune session par SIP, il y a moins dchanges de trames effectuer par rapport une mme ouverture de session par H323. De plus, le protocole UDP est plus rapide que le protocole TCP, d lentte plus simple de UDP. Ainsi, louverture dune session par SIP est plus rapide que par H323. Le protocole SIP est davantage orient temps rel. Enfin, lchange des flux RTP via UDP demeure identique pour les 2 solutions H323 et SIP. VI. PERSPECTIVES DETUDES Dautres tudes peuvent tre menes pour approfondir les connaissances vues jusqu prsent en visioconfrence et tlphonie sur IP. Elles sont donnes ici titre de perspectives. A. Dbit audio Le dbit audio gnr par le codec G711 peut tre tudi en vue deffectuer une synthse des dbits audio entrant et sortant de chaque participant et du pont de confrence. Laspect thorique du codec G711 indique que lchantillonnage est de 8 kHZ avec 8 bits par chantillon, soit un dbit de 64 kbits/s. En tudiant loccurrence des trames RTP incluant le timestamp et les donnes provenant du codec G711, il serait intressant de retrouver le dbit du flux audio. Pour une confrence N participants, le pont de confrence ncessite un dbit entrant de N fois le dbit dun participant, et le mme dbit sortant, lorsque le pont diffuse en unicast. Sil diffusait en multicast, il aurait un dbit sortant N fois moindre. Cela peut entraner une tude sur le nombre de participants pouvant joindre une confrence en fonction des dbits disponibles et de la qualit de transmission donne aux flux audio et vido. Les dbits audio et vido produits par dautres codecs peuvent tre tudis de la mme manire. B. Multicast IP Lors dune confrence plusieurs participants incluant un pont de confrence, ce dernier renvoie N fois le mme flux audio et vido lorsquil est en liaison point point unicast avec chaque participant. Afin de rduire la bande passante utilise sur les rseaux, un adressage multicast de classe D pourrait tre mis en place. Le pont ne renverrait quun seul flux audio et vido, le flux tant multipli par les quipements dinterconnexion en

tablissement communication Ngociation codec

Autocommutateur IP Gestion des participants

Fig. 12. Schma du rseau regroupant les participants, lIPBX et le pont de confrence. Chaque participant envoie un flux unicast audio au pont de confrence effectuant le mixage des flux audio lui arrivant. Le pont de confrence renvoie chaque participant le mme flux audio mix.

La mise en place de confrences audio et vido 2 participants et plus a t tudie selon lensemble de protocoles H323 et selon le protocole SIP, afin den comprendre les mcanismes et fonctionnements. Les notions de protocole IP, de protocoles de transport TCP et UDP, de numro de port, danalyse de trames, de flux, de dbit, de codecs audio et vido et de session ont t utilises. Lors dune confrence plus de 2 participants, il est remarquer lexistence dautant de flux RTP unicast identiques que de

io ud nt t a po o as u di i c d au nt un TP st i pa c ux R i ca ti Fl i x un par m x u lu d F P T R
IPBX

io ud nt t a po io as d i c du a u ant un TP st ip a c ux R ic rt i Fl ix un pa m ux du Fl P T R
MCU

switch

change flux audio RTP en unicast bidirectionnel

Pont de confrence Mixage audio

V. CONCLUSION

fonction de la topologie du rseau et des participants. C. Codec G711 Les donnes audio transportes par le codec G711 pourraient tre analyses afin de comprendre la structure dune trame G711 et retrouver la suite des chantillons audio avec leur codage, leur amplitude, et leur frquence dchantillonnage. Dautres codecs peuvent aussi tre tudis comme les G723 et G729 pour laudio, et les H261 et H263 pour la vido. D. Protocole RTCP Le protocole RTCP (Real-time Transport Control Protocol [10]) permet dobtenir des statistiques de transmission et de rception en terme de perte de segments, variation de gigue, fournissant des informations sur la qualit de la session. Il permet aussi de garder une trace de tous les participants une session de confrence. Lanalyse des trames RTCP permettrait didentifier notamment les pertes de segments, pertes pouvant tre volontairement provoques en dbranchant un cble ou en inondant le rseau. E. Protocole RSVP Le protocole RSVP (Resource reSerVation Protocol [11]) permet de pallier les dfauts (fiabilit et QoS) de RTP en intervenant non pas sur les quipements metteurs/rcepteurs que sont les participants et le pont de confrence, mais sur les quipements dinterconnexion du rseau (routeurs et switchs administrables) en allouant dynamiquement de la bande passante. RSVP est donc conu pour optimiser la transmission de donnes multipoints. Dans le cas dune architecture incluant des routeurs grant la rservation de ressources, une analyse des trames RSVP permettrait de comprendre son fonctionnement en allouant de la bande passante aux flux RTP afin de ne pas perturber ces flux lors dune congestion du rseau. F. Transport de donnes en temps rel La suite de protocoles T120 dfinit une architecture de communication multipoints temps rel de donnes dapplications (tableau blanc, partage dapplications, transfert de fichiers,). Lanalyse de cet ensemble de protocoles permettrait didentifier le rle de chacun et den comprendre le fonctionnement. REFERENCES
[1] [2] [3] [4] [5] WireShark, 2007, logiciel de capture et analyse de trames, ressource en ligne : http://www.wireshark.org. ClearSight Analyzer, 2007, logiciel de capture et analyse de trames, ressource en ligne : http://www.clearsightnet.com. NetMeeting, logiciel de confrence, http://www.microsoft.com/fr/fr/. TCPview, logiciel de ports TCP et UDP, 2007, ressource en ligne http://www.microsoft.com/france/technet/sysinternals/networking/Tcp View.mspx. OpenMCU, Open GK, OpenH323 Project, ressource en ligne http://www.openh323.org.

[6]

Express Talk VoIP Softphone, Quorum Telephone Conference Server, Axon Virtual PBX, NCH Swift Sound Company, ressource en ligne http://nch.com.au. [7] RTP, Real-time Transport Protocol, Juillet 2003, RFC 3550, 3551 [8] SIP, Session Initiation Protocol, Juin 2002, RFC 3261 [9] SDP, Session Description Protocol, Juillet 2006, RFC 4566 [10] RTCP, Real-time Transport Control Protocol, Octobre 2003, RFC 3605 [11] RSVP, Resource Reservation Protocol, Mai 2006, RFC 4495