Le Protocole SIP Avanc et ses Extensions

EFORT http://www.efort.com
Le premier tutoriel sur le protocole SIP propos par EFORT est disponible l'URL : http://www.efort.com/r_tutoriels/SIP_EFORT.pdf. Il introduit les entits SIP, le protocole SIP un haut niveau, l'interfonctionnement SIP/ISUP et l'architecture de services SIP. Ce nouveau tutoriel prsente le protocole SIP de manire approfondie ainsi que ses extensions.

1 Protocole SIP
SIP (Session Initiation Protocol) est un protocole de signalisation dfini par lIETF (Internet Engineering Task Force) permettant ltablissement, la libration et la modification de sessions multimdias. Il hrite de certaines fonctionnalits des protocoles HTTP (Hyper Text Transport Protocol) utilis pour naviguer sur le WEB, et SMTP (Simple Mail Transport Protocol) utilis pour transmettre des courriels (E-mail). Le protocole SIP fournit la signalisation ncessaire la cration, sur rseaux IP, des fonctions de tlphonie similaires celles du protocole ISUP dans le monde SS7 ou celles du protocole H.323. SIP fait l'unanimit dans le monde de la tlphonie sur IP par sa simplicit et sa bonne intgration l'architecture Internet et en font le candidat idal pour les terminaux lgers et mobiles. Dans le premier tutoriel SIP, il a t vu que le protocole SIP est constitu initialement de six requtes (Figures 1 et 2): REGISTER permet l'enregistrement, le r-enregistrement et le dsenregistrement INVITE a pour but l'initiation de session de toute nature : session audio, session vido, session tchat, session fax, session IPTV, etc. ACK sert confirmer la rponse finale une mthode INVITE OPTIONS permet d'obtenir les capacits de l'entit interroge BYE termine une session tablie CANCEL permet d'annuler une session qui n'a pas encore t tablie. Les requtes SIP sont acquittes par des rponses. Les rponses SIP indiquent : Soit une information de progression dappel Soit une information dtat final Les rponses SIP contiennent : Un code dtat (Status Code) qui est un entier sur 3 chiffres Une raison (Reason-Phrase) qui dcrit textuellement la raison. Il existe six classes de rponses : Classe 1xx : Information, la requte a t reue, et est en cours de traitement. Classe 2xx : Succs, la requte a t reue, comprise et accepte. Classe 3xx : Redirection, la session requiert dautres traitements avant de pouvoir dterminer si elle peut tre ralise. Classe 4xx : Erreur requte client, la requte ne peut pas tre interprte par le serveur ou la destination, telle que soumise. La requte doit tre modifie avant dtre renvoye. Classe 5xx : Erreur serveur, le serveur choue dans le traitement dune requte apparemment valide.

Copyright EFORT 2011

Classe 6xx : Echec global, la requte ne peut tre traite par aucun serveur.

REGISTER

UAC

200 OK
Proxy Server

Registrar
OPTIONS 200 OK

OPTIONS

UAC

200 OK INVITE
Proxy Server

UAS

UAC

180 RINGING 200 OK ACK

INVITE 180 RINGING 200 OK ACK BYE 200 OK

UAS

Proxy Server

BYE

UAC

200 OK

UAS

Figure 1 : Mthodes REGISTER, OPTIONS, INVITE, ACK et BYE

UA2
ITE INV GING RI N 180 0 OK 20 K AC

Proxy Server UA1

INVITE 180 RINGING 180 RINGING 200 OK ACK

INVI 180 T E RIN CAN GING CE L 2 487 Tran 00 OK sact io n C ance ACK lled

UA3

Figure 2 : Mthode CANCEL

2 Etablissement d'une session audio avec le protocole SIP

Dans lexemple suivant reprsent la Figure 3, l'appelant a pour URL SIP sip:mary.taylor@tn.com, alors que celle de l'appel est sip:mart.rich@tn.com. Une mthode SIP INVITE est mise par le terminal SIP de l'appelant au Proxy Server. Ce dernier achemine la demande d'initiation de session la destination. La requte INVITE contient un ensemble de headers obligatoires. Par ailleurs, la requte SIP contient une syntaxe SDP (Session Description Protocol). Cette structure consiste en plusieurs lignes qui dcrivent les caractristiques du mdia que lappelant Mary requiert pour la session.

Copyright EFORT 2011

Mary Taylor indique qu'il s'agit d'une session tlphonique (m=audio), que la voix paqutise doit lui tre dlivre l'adresse de transport (port UDP = 45450, adresse IP = 192.23.34.45) avec le protocole RTP et en utilisant un format d'encodage dfini dans le RFC 3551 AVP (Audio Video Profile) et pouvant tre G.711 -law (0) ou G.729 (18). La rponse 180 RINGING est retourne par le destinataire au terminal SIP de l appelant. Lorsque l'appel accepte la session, la rponse 200 OK est mise par son terminal SIP et achemine au terminal SIP de lappelant. Le terminal SIP de l appelant retourne une mthode ACK au destinataire, relaye par l'entit SIP Proxy. L'entit Proxy Server participe l'acheminement de la signalisation entre UAs alors que les UAs tablissent directement des canaux RTP pour le transport de la voix ou de la vido paqutise sans implication du Proxy Server dans ce transport. Lorsque Mary raccroche, son terminal SIP envoie une requte BYE pour terminer la session. Cette requte est dlivre au Proxy Server qui l'achemine au terminal SIP de Mark. Ce dernier retourne la rponse 200 OK.
Proxy Server tn.com

sip:mary.taylor@tn.com SIP UA 1

sip:mark.rich@tn.com SIP UA 2

v = 0 (dans message 1) c = IN IP4 192.23.34.45 m = audio 45450 RTP/AVP 0, 18

1. INVITE 4. 180 RINGING 6. 200 OK 7. ACK

2. INVITE 3. 180 RINGING 5. 200 OK 8. ACK

v=0 (dans message 5) c = IN IP4 192.190.130.38 m = audio 22222 RTP/AVP 0

Flux de mdia RTP

v=version c=connection m=media

9. BYE 12. 200 OK

10. BYE 11. 200 OK

Figure 3 : Etablissement d'une session audio avec le protocole SIP Une requte ou mthode SIP consiste en une request line, plusieurs headers, une empty line et un message body. Le message body est optionnel; certaines requtes SIP n'en disposent pas. Une Request line contient trois lments : method, Request URI, et protocol version. La method indique le type de requte. Le request-URI (Uniform Resource Indicator) indique l'entit destinatrice de la requte. Finalement, la protocol version est SIP/2.0. Une rponse SIP consiste en une status line, plusieurs headers, une empty line, et un message body. Le message body est optionnel; certaines requtes SIP n'en disposent pas. La premire ligne de la mthode SIP, appele request line liste la mthode (ici INVITE), le request URI et le numro de version du protocole SIP utilis (2.0). Alors qu'il est possible lors du routage d'une mthode SIP de modifier le request-URI, le header To doit rester inchang.

Copyright EFORT 2011

Le premier Header suivant la ligne de dbut est le Header Via. Chaque entit SIP qui met ou relaye une mthode SIP insre son adresse de host ou adresse IP dans ce Header Via. Sil sagit dune adresse de host, cette dernire peut tre traduite en une adresse IP par le DNS. Le Header Via contient la version du protocole SIP, puis le type de transport pour le protocole SIP (ici un transport UDP), un espace, suivi du nom de host ou de ladresse IP, de deux points, dun numro de port SIP et d'un paramtre branch. Ici, il sagit du port SIP par dfaut, savoir 5060. Le paramtre branch identifie la transaction SIP. Le Header Via permet de prvenir dventuelles boucles et assure que la rponse suivra le mme chemin que la requte. Les headers suivants sont les headers From et To qui indiquent les adresses SIP de lmetteur et du rcepteur de la requte. Toutefois le routage de la mthode se fait en utilisant le Request URI et non pas le header To. Lorsquun label de nom est utilis (dans lexemple, Mary Taylor et Marc Rich), alors lURL SIP est dlimite par des crochets et permet de router le message. Ce label de nom peut tre utilis lors de lalerte du terminal destinataire. Le header From de la requte INVITE doit contenir un paramtre tag qui est identificateur alatoire choisi par Mary Taylor. Lorsque l'appel retourne des rponses, celles ci doivent inclure un paramtre Tag dans le header To. Ceci permet l'appelant dans un scnario de forking de bien distinguer les diffrentes rponses reues. Si par exemple, l'appel est joignable sur deux terminaux, l'appelant recevra deux rponses 180 Ringing chacune contenant un Header To avec la mme adresse SIP mais des tag diffrents. On peut donc conclure qu'une session est identifie de manire unique grce aux informations CallId, From-tag et To-tag. Le Header Call-ID a une forme similaire celle dune adresse lectronique mais ne fait que reprsenter un identificateur permettant de dsigner une session SIP. Le Header suivant est le Header Cseq. Il est constitu par un numro suivi du nom de la mthode SIP. Dans lexemple, il sagit de la mthode INVITE. Le numro est incrment pour chaque nouvelle mthode SIP mise. Le numro de squence initial choisi dans lexemple est 1 mais il est possible de commencer par nimporte quelle valeur. Le Header Contact est aussi requis dans la requte INVITE. Il contient lURI SIP de terminal de Mary Taylor. Cet URI permet de router des requtes SIP directement au terminal de Mary Taylor. Tout message SIP doit contenir les paramtres obligatoires To, From, Max-Forwards, Via, Call-ID, C-Seq et Contact. Les autres headers sont optionnels. Les headers content type et content length indiquent que le corps du message est une structure dcrite avec SDP (Session Description Protocol) et contient 162 octets. Cette structure consiste en plusieurs lignes qui dcrivent les attributs du mdia que lappelant Mary requiert pour lappel. INVITE sip:mark.rich@tn.com SIP/2.0 Via : SIP/2.0/UDP station1.tn.com:5060; branch=z9hG4bK776asdrgs Max-Forwards : 20 To : Mark Rich <sip:mark.rich@tn.com> From : Mary Taylor <sip:mary.taylor@tn.com>;tag=21272 Call-Id: j1sv235bh8965ws CSeq: 1 INVITE Contact: sip:mary.taylor@192.190.132.20 Content-Type: application/sdp Content-Length:162 v=0 c = IN IP4 192.190.132.20 m = audio 45450 RTP/AVP 0

Copyright EFORT 2011

Le message suivant est la rponse 180 Ringing envoye en rponse la requte INVITE. Cette rponse indique que lappel Mark Rich a reu lINVITE et que lalerte a t initie. Lalerte peut tre faire sonner le tlphone, un message dalerte sur lcran du terminal ou toute autre mthode afin dattirer lattention de lappel Mark Rich. La rponse 180 Ringing, parce quelle appartient la catgorie 1XX est une rponse informationnelle. Une telle rponse est utilise afin de transporte des information non critiques au sujet de la progression dappel. La phrase accompagnant le code de rponse (dans notre cas Ringing) est suggre dans le standard, mais toute texte peut tre utilis. La rponse 180 Ringing est cre en copiant de nombreux headers de la requte INVITE, incluant Via, To, From, Call-ID, et CSeq, puis en ajoutant une ligne de rponse contenant la version du protocole SIP, le code de rponse, et la phrase associe. Le header Via contient le paramtre branch mais dispose dun paramtre supplmentaire received. Ce paramtre contient ladresse IP do la rponse a t reue (192.190.132.23). Il sagit de la mme adresse que lURI dans le Via rsolue par interrogation DNS. Notons que les headers To et From ne sont pas inverss dans la rponse. Bien que cette rponse soit envoye par Mark Rich Mary Taylor, les headers From et To indiquent le contraire. La raison est que les headers To et From dans SIP sont dfinis afin dindiquer la direction de la requte et non pas la direction de la rponse. Puisque Mary Taylor initie la requte, toutes les rponses lINVITE pourront se lire : To: Mark Rich From: Mary Taylor. Le header To contient maintenant un tag gnr par Mark Rich. Toutes les rponses et requtes futures dans cette session contiendront le tag gnr par Mary Taylor et le tag gnr par Mark Rich. La rponse contient aussi un header Contact qui contient une adresse laquelle Mark Rich peut tre contact directement lorsque la session est tablie. SIP/2.0 180 Ringing Via : SIP/2.0/UDP proxy1.tn.com:5060; branch=z9hG4bK7745221 received = 192.190.132.21 Via : SIP/2.0/UDP station1.tn.com:5060; branch=z9hG4bK776asdrgs To : Mark Rich <sip:mark.rich@tn.com>; tag 22454 From : Mary Taylor <sip:mary.taylor@tn.com>;tag=21272 Call-Id : j1sv235bh8965ws Cseq : 1 INVITE Contact : sip:mark.rich@192.190.23.16 Content-Length : 0 Lorsque lappel, Mark Rich dcide daccepter lappel, une rponse 200 OK est retourne. Cette rponse indique aussiqu'un type de mdia propos par lappelant pour la session est acceptable. Le message body de la rponse 200 OK contient les information mdia de Mark Rich. L'appel a l'obligation d'accepter le premier mdia de la liste propose par l'appelant, support par l'appel. Cette rponse 200 OK est construite de la mme faon que la rponse 180 Ringing et contient les mmes To tag et Contact URI. Les capacits mdia du terminal de Mark Rich sont communiques dans le body SDP ajout la rponse. SIP/2.0 200 OK Via : SIP/2.0/UDP proxy1.tn.com:5060; branch=z9hG4bK7745221 received = 192.190.132.21 Via : SIP/2.0/UDP station1.tn.com:5060; branch=z9hG4bK776asdrgs To : Mark Rich <sip:mark.rich@tn.com>; tag 22454 From : Mary Taylor <sip:mary.taylor@tn.com>;tag=21272 Call-Id : j1sv235bh8965ws Cseq : 1 INVITE Contact : sip:mark.rich@192.190.23.16

Copyright EFORT 2011

Content-Type : application/sdp Content-Length :162 v=0 c = IN IP 192.190.23.16 m = audio 52140 RTP/AVP 0 Ltape finale est de confirmer la session avec une requte ACK (Acknowledgment). La confirmation signifie que Mary Taylor a reu avec succs la rponse de John Cook (200 OK de lINVITE). Cet change dinformation mdia permet ltablissement de la session mdia via un autre protocole : Real Time Transport Protocol (RTP) Le Cseq a le mme numro que celui de lINVITE, mais la mthode est positionne ACK. A ce point la session mdia commence en utilisant les informations de mdia transportes dans les messages SIP (descriptions SDP). Le paramtre branch dans le header Via contient un nouvel identificateur de transaction que lINVITE puisque lACK mis pour acquitter la rponse 200 OK est considr comme une nouvelle transaction. Lchange de messages montre que SIP est un protocole de signalisation de bout en bout. ACK sip:mark.rich@tn.com SIP/2.0 Via : SIP/2.0/UDP station1.tn.com:5060; branch= z9hG4bK83bcetfa Max-Forwards : 20 To : Mark Rich <sip:mark.rich@tn.com>; tag 22454 From : Mary Taylor <sip:mary.taylor@tn.com>; tag=21272 Call-Id : j1sv235bh8965ws Cseq : 1 ACK Content-Length : 0 La libration de la session requiert l'envoi d'une mthode BYE par le participant qui souhaite initier cette libration. Le header Via dans cet exemple est renseign avec ladresse du hostname de Mary Taylor et contient un nouvel identificateur de transaction puisque la mthode BYE est considre comme une nouvelle transaction indpendamment des INVITE et ACK. Les headers To et From montrent que la requte est initie par Mary Taylor. Si cest Mark Rich qui dcide de librer la session, alors le header From indiquerait la SIP URI de Mark Rich. BYE sip:mark.rich@tn.com SIP/2.0 Via : SIP/2.0/UDP station1.tn.com:5060; branch= z9hG4bK883bcrfg Max-Forwards : 20 To : Mark Rich <sip:mark.rich@tn.com>; tag 22454 From : Mary Taylor <sip:mary.taylor@tn.com>; tag=21272 Call-Id : j1sv235bh8965ws Cseq : 2 BYE Content-Length : 0 La rponse la mthode BYE est 200 OK. Cette rponse rappelle le Cseq de la requte BYE. Il ny a pas dACK mis puisque lACK nest envoy que pour acquitter une rponse finale lINVITE. SIP/2.0 200 OK Via : SIP/2.0/UDP proxy1.tn.com:5060; branch=z9hG4bK7745343 received = 192.190.132.21 Via : SIP/2.0/UDP station1.tn.com:5060; branch= z9hG4bK883bcrfg To : Mark Rich <sip:mark.rich@tn.com>; tag 22454 From : Mary Taylor <sip:mary.taylor@tn.com>;tag=21272

Copyright EFORT 2011

Call-Id : j1sv235bh8965ws Cseq : 2 BYE Content-Length : 0

3 Description SDP
La finalit de SDP (Session Description Protocol) est de transportr les informations se rapportant aux flux de donnes multimdia dans une session multimdia afin de permettre aux rcepteurs de cette description de session de participer cette session. L'exemple suivant dcrit les informations pouvant tre transportes par le protocole SDP: v = 0. Version du protocole SDP (0) o = Mary 2890844526 2890844526 IN IP4 . Origine de la session dcrite travers le username (Mary), lidentificateur de la session (2890844526), la version de la session, le type de rseau (IN = Internet), le type dadresse (IP4 = IPv4), et ladresse rseau de la machine o la session a t cre (192.190.132.20). s = session name; Il sagit dune chane de caractres, nom de la session, qui peut tre affiche aux participants de la session i= Information; contient des informations sur la session. Il peut contenir n importe quel nombre de caractres. u= URI; contient une uniform resource indicator (URI) avec plus d information sur la session. e= e-mail; contient une adresse E-mail du host de la session. Si un nom est aussi utilis, l adresse e-mail est mise entre <>. p= phone; contient un numro de tlphone avec un format globalis commenant par +, puis le code pays, puis un espace ou - , puis le numro local. Un commentaire peut tre rajout entre parenthses. c = connection; IN IP4 192.190.132.20 . Donnes de connexion incluant le type de rseau (IN = Internet), le type dadresse (IP4=IPv4) et ladresse de connexion (192.190.132.20) diffrencier du rseau et de ladresse laquelle la session a t cre. b= bandwidth; contient des informations sur la bande passante requise. L information est de la forme b=modifier:bandwidth-value. Le modifier est soit CT pour Conference total ou AS pour Application Specific. CT est utilis pour une session multicast pour spcifier le dbit total qui peut tre utilis par tous les participants dans la session. AS est utilis affin de spcifier le dbit pour un unique site. Le dbit est exprim en kilobits par seconde. t = time; Instant de la session. Il indique les instants de dbut et de fin de la session Ces instants sont gaux 0 pour une session tablie dynamiquement comme un appel tlphonique. Ces instants sont positionns des valeurs particulires lorsqu'il s'agit d'une confrence pr-arrange avec un dbut et une fin de confrence programms m = media; audio 45450 RTP/AVP 0. Type de mdia (audio), port de transport o la voix ou la vido paqutise doit tre envoye (45450), le protocole de transport (RTP) et le type de format (AVP 0 = G.711 m-law). a=attributes; contient des attributs de la session mdia. Il peut tre utilis pour tendre la description SDP avec plus d information sur le mdia. Les informations fournies qui ne sont pas comprises par l usager SDP, peuvent tre ignores. Pluseurs lignes a peuvent tre prsentes pour chaque type de codec list. v=0 o=Mary 2890844526 2890844526 IN IP4 192.190.132.20 s=Rsum runion i=Traite des points importants de la dernire runion u=http://www.sipstation.com e=Mary Taylor <mary.taylor@tn.com>

Copyright EFORT 2011

p=+33 672192222 (Appeler uniquement de 9h00 17h00) c=IN IP4 192.190.132.20 b=AS:64 t=2877631875 2879633673 m=audio 45450 RTP/AVP 0 8 99 a=rtpmap:0 PCMU/8000 a=rtpmap:8 PCMA/8000 a=rtpmap:99 iLBC/8000 m=video 23422 RTP/AVP 31 a=rtpmap:31 H261/90000

4 Enregistrement
La mthode REGISTER est utilise par un User Agent pour informer le rseau SIP de son adresse IP et de son URL pour laquelle il souhaite recevoir des sessions. Lenregistrement SIP est similaire lenregistrement du terminal mobile lors de son attachement au rseau GSM. L'enregistrement est important afin d'tre authentifi, afin d'tre localis et ainsi recevoir des appels entrants depuis des Proxy servers qui servent le domaine de l'usager. La mthode REGISTER est utilise par un User agent afin dindiquer au Registrar son adresse de localisation (e.g., adresse IP) ainsi que son adresse SIP (SIP URL). Le user agent peut connatre par avance son Registrar par configuration (adresse IP du Registrar prconfigure dans le User agent) auquel cas il met une mthode REGISTER uniquement ce Registrar. Le user agent peut aussi apprendre dynamiquement l'adresse du Registrar par exemple via un serveur DHCP. Sinon, le User agent met le message tous les Registrars du domaine en utilisant ladresse multicast (224.0.1.175). La mthode SIP Register contient les headers suivants : Le header From indique ladresse de lentit ayant initi lenregistrement. Le header To indique ladresse de lusager enregistr. Les headers From et To ont la mme valeur si lutilisateur senregistre lui-mme. Ladresse de la fonction REGISTRAR nest indique que dans la premire ligne de la commande REGISTER dans le champ Request-URI. Le header CallID. Un User agent utilisera un mme Call-ID pour lensemble de ses enregistrements. Le header Cseq. A chaque nouvel enregistrement pour le mme user agent, le numro Cseq est incrment. Le header Contact indique les diffrentes adresses auxquelles lusager SIP est joignable. Le champ Expires associ au header Contact est optionnel et exprime une dure denregistrement en secondes. Sil est absent, alors lURL SIP sera supprime de la table denregistrement de la fonction Registrar au bout dune heure aprs lenregistrement pour l'environnement Internet et au bout d'une semaine pour l'environnement IMS. La fonction Registrar retourne une rponse 200 OK en cas de succs de lenregistrement. Ses headers Via, From, To, Call-ID et Cseq ont les mmes valeurs que dans la requte REGISTER. Le champ Expires de la rponse 200 OK peut indiquer une valeur gale ou infrieure celle spcifie dans la requte REGISTER. Dans lexemple la Figure 4, Mary sest loggue sur la machine station1.tn.com. Une mthode REGISTER a alors t mise la fonction Registrar locale. Le header Contact indique que Mary Taylor est joignable l'adresse IP 192.190.132.20. La requte et la rponse contiennent les headers prsents ci-dessus.

Copyright EFORT 2011

UA 1 (Mary)

Registrar sip : registrar.tn.com

Base de donne de localisation

Register sip:registrar.tn.com SIP/2.0 Via: SIP/2.0/UDP station1.tn.com:5060;branch=z9hG4bKus19 Max-Forwards : 20 To: Mary Taylor<sip :mary.taylor@tn.com> From: Mary Taylor<sip :mary.taylor@tn.com>; tag = 3233 Call-Id: 23456789Z567 CSeq: 1 REGISTER Contact : sip: mary.taylor@192.190.132.20 Content-Length: 0

SIP/2.0 200 OK Via: SIP/2.0/UDP station1.tn.com:5060;branch=z9hG4bKus19 To: Mary Taylor<sip :mary.taylor@tn.com>; tag=4551 From: Mary Taylor<sip :mary.taylor@tn.com>; tag = 3233 Call-Id: 23456789Z567 CSeq: 1 REGISTER Contact : sip:mary.taylor@192.190.132.20; expires=3600 Content-Length: 0

sip:mary.taylor@tn.com sip:mary.taylor@192.190.132.20
Cet exemple d enregistrement associe l adresse SIP de Mary sip:mary.taylor@tn.com avec l adresse IP du terminal sur lequel Mary s est enregistre, savoir 192.190.130.20

Figure 4 : Procdure d'enregistrement

Dans l'exemple de la Figure 5, Mary Taylor est enregistre simultanment sur deux terminaux. Le header Contact de chaque mthode REGISTER prcise l'adresse IP du terminal associ ainsi que la dure d'enregistrement souhaite par Mary Taylor sur le terminal.

Copyright EFORT 2011

sip : mary.taylor@tn.com UA 1 (Mary)

sip : mary.taylor@tn.com UA 2 (Mary)

sip : registrar.tn.com Registrar

Register sip:registrar.tn.com SIP/2.0 Via: SIP/2.0/UDP station2.tn.com:5060; branch=z9hG4bKdr324 Max-Forwards : 20 To: Mary Taylor<sip :mary.taylor@tn.com> From: Mary Taylor<sip :mary.taylor@tn.com>; tag = 3233 Call-Id: 13456789TZ12 CSeq: 1 REGISTER Contact : sip: mary.taylor@192.190.132.27; expires = 7200 Content-Length: 0

Register sip:registrar.tn.com SIP/2.0 Via: SIP/2.0/UDP station1.tn.com:5060; branch=z9hG4bKst456 Max-Forwards : 20 To: Mary Taylor<sip :mary.taylor@tn.com> From: Mary Taylor<sip :mary.taylor@tn.com>; tag = 2627 Call-Id: 234567890ZR26 CSeq: 1 REGISTER Contact : sip: mary.taylor@192.190.132.20; expires = 3600 Content-Length: 0

200 OK

200 OK
Figure 5 : Enregistrements multiples pour la mme identit SIP

5 Mthodes SIP additionnelles

Huit mthodes SIP additionnelles ont t proposes dans divers RFCs : SUBSCRIBE : Demande de notification dvnement de session (RFC 3265) NOTIFY : Notifie un vnement pour lequel une souscription a t effectue (RFC 3265) PUBLISH : Publie un tat (RFC 3903) MESSAGE : Transporte un message de donnes hors session (RFC 3428) REFER : Transfre lutilisateur une URL (RFC 3515) UPDATE : Modifie la session avant son acceptation (RFC 3311) INFO : Permet lchange de signalisation comme les tonalits DTMF pendant la session (RFC 2976) PRACK : Acquitte des rponses provisoires (RFC 3262) Une entit SIP peut souscrire un vnement afin dtre notifie de son occurrence. La requte SUBSCRIBE permet la souscription alors que la requte NOTIFY est utilise afin de notifier l'vnement souscrit. PUBLISH permet un usager de mettre jour son information d tat dans le contexte d un service tel que la prsence . La mthode REFER renvoie un client SIP vers une ressource identifie dans la mthode. REFER permet dmuler diffrents services ou applications dont le transfert de session. Considrons UA1, lentit lorigine du transfert, UA2, lentit transfre et UA3, le destinataire du transfert. Le transfert dappel permet UA1 de transformer un appel en cours entre UA1 et UA2 en un nouvel appel entre UA2 et un UA3 choisi par UA1. Si le transfert dappel aboutit, UA2 et UA3 pourront communiquer tandis que UA1 ne pourra plus dialoguer avec UA2 ou UA3. La mthode MESSAGE a t propose comme extension au protocole SIP afin de permettre le transfert de messages instantans. La messagerie instantane (IM, Instant Messaging) consiste en lchange de messages entre usagers en pseudo temps rel. Cette nouvelle mthode est route entre usagers comme toute mthode SIP. La requte MESSAGE peut transporter plusieurs types de contenus en sappuyant sur le codage MIME.

Copyright EFORT 2011

10

La mthode INFO permet de transfrer des informations de signalisation durant lappel. Parmi les exemples dinformation figurent les digits DTMF, les informations relatives la taxation dun appel, des images, etc. Les rponses finales 2XX, 3XX, 4XX, 5XX et 6XX une requte INVITE sont acquittes par la requte ACK alors que les rponses provisoires de type 1XX ne sont pas acquittes. Or, certaines rponses provisoires telles que 180 Ringing sont critiques et leur rception est essentielle pour la dtermination de l tat de la session, notamment lors de linterconnexion avec le RTCP. La mthode PRACK a donc t dfinie afin dacquitter la rception de rponses provisoires, de type 1XX sauf 100 Trying. La mthode UPDATE permet un user agent de mettre jour les paramtres dune session multimdia. (e.g., flux mdia et leurs codecs). La mthode UPDATE peut tre envoye avant que la session soit tablie. UPDATE est donc particulirement utile lorsquil sagit de mettre jour des paramtres de session avant son tablissement, e.g. mise en attente du destinataire.

5.1

Mthode SUBSCRIBE

La mthode SUBSCRIBE est utilise par un UA afin d tablir une souscription pour la rception de notifications (via la mthode NOTIFY) lorsqu un vnement souscrit survient. Une souscription tablit un dialogue entre l UAC et l UAS. La requte de souscription contient un header Expires qui indique la dure souhaite pour la souscription. Aprs cette dure de souscription, la souscription est automatiquement termine. La souscription peut tre rafrachie via un autre SUBSCRIBE dans le dialogue avant le moment d expiration. Un serveur qui accepte la souscription retourne une rponse 200 OK qui contient un header Expires gal ou plus petit que celui propos dans le SUBSCRIBE. Il n existe pas de mthode UNSUBSCRIBE avec SIP. La requte SUBSCRIBE avec un header Expires positionn 0 demande la fin de la souscription et donc du dialogue. Une souscription termine cause de l expiration de la souscription ou parce qu une demande explicite de fin de souscription t mise rsulte en un NOTIFY final indiquant que la souscription est termine.

5.2

Mthode NOTIFY

La mthode NOTIFY est utilise par un UA pour transporter linformation sur loccurrence dun vnement particulier. Une requte NOTIFY est toujours mise dans un dialogue lorsquune souscription existe entre le souscripteur et le notificateur. Une requte NOTIFY est normalement acquitte par une rponse 200 OK pour indiquer quelle a t reue. Une requte NOTIFY contient un header Event indiquant le nom du package utilis lors de la souscription et un header Subscription-State indiquant ltat courant de la souscription (active, pending ou terminated). Une requte NOTIFY est toujours mise au dbut de la souscription et la fin de la souscription comme le montre la Figure 6. UA1 souscrit un vnement auprs d'UA2 (1-2). UA2 notifie que la demande est active (34). L'vnement souscrit est observ; il est donc notiti par UA2 UA1 (5-6). La dure de souscription a expir. UA2 notifie cet vnement a UA1 (7-8).

Copyright EFORT 2011

11

SIP UA 1

SIP UA2

1. SUBSCRIBE 2. 200 OK 3. NOTIFY 4. 200 OK 5. NOTIFY 6. 200 OK

Un changement dans ltat souscrit sest produit Un changement dans ltat souscrit sest produit

7. NOTIFY 8. 200 OK

La souscription a expir

Figure 6 : Modle de souscription/notification avec SIP Diffrents vnements ont t spcifis dans diffrents RFCs: [RFC 3515]: event package for the REFER method. Cet vnement permet de notifier le rsultat d'une opration de transfert par la mthode REFER. [RFC 3680]: event package for SIP-registration events. Cet vnement permet de notifier le changement d'tat d'enregistrement d'un usager. [RFC 3842]: event package for voice-mail notification events. Cet vvnement permet de notifier le changement d'tat de la bote vocale d'un usager. [RFC 3856]: Event Package for SIP Presence events. Cet vnement permet de notifier le changement d'tat de prsence d'un usager. [RFC 4235]: event package for SIP-dialog events. Cet vnement permet de notifier le changement d'tat d'un dialogue, utile notamment un service comme le rappel automatique sur occupation. [RFC 4575]: event package for SIP-conferencing events. Cet vnement permet de notifier le changement d'tat d'un participant une confrence (a joint, a quitt, a mis en garde la confrence) [RFC 4730]: event package for media server events. Cet vnement ermet un serveur application de demander un serveur de mdia de le notifier lorsque l'usager a compos des touches DTMF particulires. L'exemple de la Figure 7 concerne le modle souscription / notification associ l'vnement voice-mail notification. Mary Taylor doit participer une runion. Elle active le renvoi d'appel inconditionnel sur messagerie vocale. Elle souscrit par ailleurs pour une dure de 3 heures la messagerie vocale afin d'tre notifie lorsqu'un nouveau message est enregistr dans sa bote vocale (12). Le systme de messagerie vocale lui retourne une notification (3-4) pour lui indiquer que sa souscription est active. Mary Taylor reoit un appel renvoy la messagerie vocale. Comme un message vocal est dpos, l'tat de sa bote vocale a chang et une notification lui est envoye (5-6).

Copyright EFORT 2011

12

La dure de souscription a expir. Mary Taylor reoit une nouvelle mthode NOTIFY qui l'informe de cet vnement (7-8). Comme la runion n'est pas termine, elle re-souscrit l'vnement de changement d'tat de bote vocale pour une dure d'une heure (9-10). Elle est notifie du fait que la souscription est active (11-12). Comme la runion se termine avant la fin de la souscription, Mary Taylor envoie une mthode SUBSCRIBE pour annuler cette souscription (13-14). Elle reoit une notification qui lui indique la fin de la suscription.

UA 1
(sip:mary.taylor@tn.com)

UA 2
(sip:mtaylor@voicemail.tn.com) Voicemail 1. SUBSCRIBE 2. 200 OK 3. NOTIFY 4. 200 OK 5. NOTIFY 6. 200 OK 7. NOTIFY 8. 200 OK 9. SUBSCRIBE 10. 200 OK 11. NOTIFY 12. 200 OK 13. SUBSCRIBE 14. 200 OK 15. NOTIFY 16. 200 OK Souscription ltat de la boite vocale pour 3 heures Notification immdiate de ltat courant Notification dun nouveau message Notification de la fin de la souscription Re-souscription Notification immdiate de ltat courant Annulation de la souscription Notification de la fin de la souscription

Figure 7 : Scnario de souscription/notification de l'vnement voice-mail notification SUBSCRIBE sip: mtaylor@voicemail.tn.com SIP/2.0 Via : SIP/2.0/UDP station1.tn.com:5060; branch=z9hG4bK776asdrgs Max-Forwards : 20 To : <sip:mtaylor@voicemail.tn.com> From : Mary Taylor <sip:mary.taylor@tn.com>; tag=1928301774 Call-Id: a84b4c76e66710 CSeq: 2342 SUBSCRIBE Allow-Events : message-summary, presence Contact: sip:mary.taylor@192.190.132.20 Event : message-summary Expires : 10800 Accept : application/ message-summary Content-Length : 0 NOTIFY sip: mary.taylor@tn.com SIP/2.0 Via : SIP/2.0/UDP station1.tn.com:5060; branch=z9hG4bK756asebgt Max-Forwards : 20 To : Mary Taylor <sip:mary.taylor@tn.com>; tag= 1928301774 From : < sip:mtaylor@voicemail.tn.com >; tag= 456887766 Call-Id: a84b4c76e66710 CSeq: 755 NOTIFY

Copyright EFORT 2011

13

Allow-Events : message-summary Contact: sip:mary.taylor@192.190.132.29 Event: message-summary Subscription-State: active Content-Type: application/simple-message-summary Content-Length: 99 Messages-Waiting: yes Message-Account: sip:mary.taylor@vmail.tn.com Voice-Message: 2/8 (0/2) 2/8 (0/2) signifie que la bote vocale contient 2 messages non lus et 8 anciens messages lus mais conservs. Parmi les messages non lus, aucun n'est urgent. Parmi les messages lus et conservs, deux taient urgents.

5.3

Mthode MESSAGE

La messagerie instantane (IM, Instant Messaging) consiste en lchange de messages entre usagers en pseudo temps rel. Ces messages sont gnralement courts, mais pas ncessairement. La messagerie instantane est utilise en mode conversationnel, i.e., lchange de messages entre les usagers est rapide afin de maintenir une conversation interactive. Les messages instantans ne sont gnralement pas stocks ( la diffrence des SMS dans le monde GSM) ; en effet, ce stockage nest pas forcment ncessaire car des usagers schangent en principe des messages instantans lorsquils sont tous connects. Cest la raison pour laquelle, le service de messagerie instantane est souvent coupl avec le service de prsence afin que les usagers sinforment de leur prsence avant de schanger des messages instantans. Toutefois, il est possible dintroduire un serveur de messagerie instantane ralisant la fonction de store-and-forward similaire un SMSC (Short Message Service Center) dans un rseau mobile. La mthode MESSAGE a t propose comme extension au protocole SIP afin de permettre le transfert de messages instantans. La mthode MESSAGE ninitie pas de session la diffrence des mthodes INVITE/200 OK/ACK; il sagit dun message asynchrone (Figure 8). On peut noter la similitude avec le monde GSM. En effet, un usager GSM tablit un appel tlphonique en utilisant le protocole Call Control (messages SETUP, ALERTING, CONNECT quivalents INVITE/180 Ringing/200OK) et envoie des SMS sparment travers le protocole Short Messaging (messages SUBMIT, DELIVER quivalents MESSAGE). Une rponse 200 OK est retourne par la destination si elle accepte la mthode MESSAGE mais cela ne signifie pas pour autant que la destination a lu son contenu. Une rponse 4xx ou 5xx indique que la mthode MESSAGE na pas t dlivre correctement. Une rponse 6xx signifie que la mthode MESSAGE a pu t dlivre mais a t refuse par la destination. La taille maximum dun message instantan ne doit pas excder 1300 octets. Pour des contenus volumineux, lURL o le contenu est accessible pourrait tre indique dans le corps de la mthode MESSAGE. Le contenu pourrait tre tlcharg par le destinataire de la mthode MESSAGE en utilisant le protocole HTTP.

Copyright EFORT 2011

14

Proxy Server UA1

SIP AS = Messaging Server

SIP AS

Proxy Server UA2

MESSAGE MESSAGE

MESSAGE 200 OK

MESSAGE 200 OK

200 OK

200 OK

Figure 8 : Envoi d'un message instantan. MESSAGE sip :mark.rich@tn.com SIP/2.0 Via: SIP/2.0/UDP 192.190.132.20:5060; branch=z9hG4bK3 Max-Forwards : 20 To: Mark Rich <sip :mark.rich@tn.com> From: Mary Taylor<sip :mary.taylor@tn.com>; tag=1949 Call-Id: 123456782349 CSeq: 121 MESSAGE Contact : sip :mary.taylor@192.190.132.20 Content-Type : text/plain Content-Length : 24 Mark, How are you today? SIP/2.0 200 OK Via: SIP/2.0/UDP 192.190.132.20:5060; branch=z9hG4bK3 To: Mark Rich <sip :mark.rich@tn.com>;tag=2774 From: Mary Taylor<sip :mary.taylor@tn.com>;tag=1949 Call-Id: 123456782349 CSeq: 121 MESSAGE Content-Length : 0

5.4

Mthode REFER

La mthode REFER renvoie le rcepteur vers une ressource identifie dans la mthode. REFER. Cette mthode permet dmuler diffrents services ou applications dont le transfert de session. Considrons UA1, lentit lorigine du transfert, UA2, lentit transfre et UA3, le destinataire du transfert. Le transfert de session permet UA1 de transformer une session en cours entre UA1 et UA2 en un nouvelle session entre UA2 et un UA3 choisi par UA1. Si le transfert de session aboutit, UA2 et UA3 pourront communiquer tandis que UA1 ne pourra plus dialoguer avec UA2 ou UA3. Dans l exemple de transfert de session la Figure 9, UA2 tablit une session tlphonique avec UA1 (1-4). UA1 met une mthode REFER (5-6) UA2 afin que ce dernier tablisse une nouvelle session avec UA3. UA1 met en garde la session en cours avec UA2; il s'agit d'un transfert supervis (7-9). UA2 tablit une nouvelle session avec UA3 (10-13) et notifie UA1 (14-15) ds lors que la session est effective entre UA2 et UA3. Si le transfert aboutit, UA1 peut librer la session avec UA2 (16-17).

Copyright EFORT 2011

15

sip:mary.taylor@tn.com UA1 1. INVITE 2. 180. Ringing

sip:mark.rich@tn.com UA2

sip:john.cook@tn.com UA3

3. 200 OK 4. ACK RTP channels 5. REFER Refer-To : sip:john.cook@tn.com 6. 202 Accepted 10. INVITE Referred-By: sip:mary.taylor@tn.com 7. re-INVITE 11. 180 Ringing 8. 200 OK 12. 200 OK 9. ACK 13. ACK 14. NOTIFY (event : refer) RTP channels 15. 200 OK 16. BYE 17. 200 OK

No more RTP channel

Figure 9: Mthode REFER REFER sip:mark.rich@tn.com SIP/2.0 SIP/2.0 Via SIP/2.0/UDP 192.120.11.12:5060; branch=z9hG4bK932039 Max-Forwards: 20 To: Mark Rich <sip:mark.rich@tn.com> From: Mary Taylor <sip:mary.taylor@tn.com>;tag=213424 Call-ID: 3419fak3kFD23s1A9dkl CSeq: 5412 REFER Refer-To: <sip:john.cook@tn.com> Referred-By: <sip:mary.taylor@tn.com> Contact: sip: < sip:mary.taylor@192.120.11.12 > Content-Length: 0

5.5

Mthode INFO

Les tonalits Dual tone multifrequency (DTMF) sont utilises pour l'change de signalisation usager usager pendant la session, par exemple envoi d'un code d'accs aprs avoir tabli la communication avec un serveur vocal interactif. Comme son nom l indique, DTMF gnre deux frquences pour mettre un digit (09, *, #, ou moins communment, AF). Dans le rseau RTC, DTMF est encod comme la voix avec le codec G.711 (DTMF dans la bande). Par contre, les codecs bas dbit utiliss pour la voix sur IP qui optimisent l encodage de la voix, n encodent pas gnralement les tonalits DTMF de faon fiable. Dautres approches sont considrer pour l envoi des DTMFs dans ce contexte: Tonalits DTMF dans le flux RTP (RFC 4733). Tonalits DTMF dans la mthode SIP INFO La mthode INFO (Figure 10) permet de transfrer des informations de signalisation durant la session. Parmi les exemples dinformation figurent les tonalits DTMF, les informations relatives la taxation dun appel, etc. La mthode INFO na pas pour but de changer ltat de la session en cours ou des paramtres de la session ; la mthode re-INVITE est utilise ces fins. La route de signalisation emprunte par la requte INFO est la mme que celle

Copyright EFORT 2011

16

utilise par les requtes SIP qui ont permis ltablissement de la session correspondante (e.g., INVITE, ACK). Par ailleurs une mthode ne pas tre mise si la session n'a pas t tablie. Linformation peut tre communique dans un header ou dans le corps du message INFO. Une des rponses suivantes est retourne par le destinataire de la requte INFO : 200 OK si la requte INFO est applicable une session, 481 Call Leg/Transaction Does Not Exist, si la requte INFO ne correspond aucune session en cours, 415 Unsupported Media Type message si la requte INFO contient un corps de message que le rcepteur n'a pas su interprter faute de disposer des rgles de traitement correspondantes. 4xx, 5xx et 6xx comme pour les autres mthodes SIP. UA 2
UA 1
sip:mary.taylor@tn.com sip:callcenter@tn.com

Messagerie Vocale 1. INVITE 2. 180 Ringing 3. 200 OK 4. ACK

Media Flows over RTP

Svp, fournissez votre mot de passe

5. INFO 6. 200 OK

Figure 10 : Mthode INFO L'entit mettrice ne peut mettre qu'un seul DTMF par mthode INFO, avec un header Content-Type positionn application/dtmf-relay. Si tel est le cas, alors l'entit rceptrice, recherche le DTMF sans la ligne Signal= line et la dure du DTMF en millisecondes dans la ligne Duration= . Si plus d'un DTMF est prsent dans la mthode INFO, seul le premier sera accept et trait. INFO sip: callcenter@tn.com SIP/2.0 Via: SIP/2.0/UDP station1.tn.com:5060 ; branch=z9hG4bK932039 Max-Forwards : 20 From: Mary Taylor<sip : mary.taylor@tn.com>; tag=213424 To: < sip: callcenter@netphone.com>; tag=435642 Subject : Accs la boite vocale Call-Id: 214534zte4 CSeq: 5 INFO Content-Type: application/dtmf-relay Content-Length: 26 Signal= 6 Duration= 100

Copyright EFORT 2011

17

5.6

Mthode PRACK

Le protocole dinitiation de session (SIP) (RFC 3261) est un protocole de demande-rponse pour initier et grer des sessions de communication. SIP dfinit deux types de rponses, provisoires et finales. Les rponses finales apportent le rsultat du traitement de la demande, et leur envoi est fiable. Les rponses provisoires fournissent des informations sur la progression du traitement de la demande, mais leur envoi nest pas fiable dans le RFC 3261. Il a t observ par la suite que la fiabilit tait importante dans plusieurs cas, y compris celui des scnarios dinteroprabilit avec le RTC. Il tait donc ncessaire de disposer dune capacit facultative prendre en charge la transmission fiable des rponses provisoires. Cest le rle de la requte PRACK. Alors que la mthode ACK acquitte une rponse finale a requte INVITE, la mthode PRACK acquitte une rponse provisoire la requte INVITE. Si un UA reoit une requte INVITE contenant le header Require dont la valeur est 100rel, il doit mettre toute rponse provisoire (e.g., 180 Ringing) de manire fiable. Sil ne le peut pas, il doit rejeter la demande en retournant une rponse 420 Bad Extension contenant un header Unsupported dont la valeur est 100rel. Lmetteur de la mthode INVITE devra alors retransmettre cette mthode sans header Require . Si un UA reoit une requte INVITE contenant le header Supported dont la valeur est 100rel, il peut mettre sil le souhaite toute rponse provisoire de manire fiable. Enfin, il ne doit pas mettre de rponse provisoire de faon fiable si la mthode INVITE reue ne contient pas de header Require ou Supported . Supposons le cas dun UA qui souhaite mettre une rponse provisoire de manire fiable (Figure 11). La rponse provisoire (e.g., 180 Ringing) doit contenir un header Require dont la valeur est 100rel et un header Rseq qui correspond un numro de squence fiable, dont la valeur est choisie initialement de manire alatoire entre 1 et 231-1. Cette valeur doit tre incrmente de 1 chaque envoi dune nouvelle rponse provisoire. Un temporisateur T1 dont la valeur par dfaut est 500 ms est arm lors de lenvoi de la rponse 180 Ringing. Si le temporisateur expire avant quune requte PRACK soit reue, la rponse 180 Ringing doit tre retransmise. La rception dune mthode PRACK indique que la rponse provisoire a bien t reue, et annule toute retransmission de la rponse provisoire. La requte PRACK doit tre acquitte par une rponse 200 OK qui aura pour effet dannuler toute retransmission de la requte PRACK. En effet, lmetteur de la requte PRACK arme un temporisateur T1 ds son envoi. Si aucune rponse nest reue avant lexpiration de ce temporisateur, la mthode PRACK doit tre retransmise. Une mthode PRACK doit contenir un header RACK qui doit contenir les valeurs des headers Cseq et Rseq prsents dans la rponse provisoire permettant de corrler la requte PRACK et la rponse provisoire quelle acquitte.

Copyright EFORT 2011

18

SIP UA 1
INVITE Supported : 100rel Cseq: 1 INVITE

SIP UA 2

100 Trying Cseq: 1 INVITE 180 Ringing Require : 100rel CSeq: 1 INVITE Rseq: 124 180 Ringing Require : 100rel CSeq: 1 INVITE Rseq: 124 PRACK CSeq: 2 PRACK RAck: 124 1 INVITE 200 OK Cseq: 2 PRACK 200 OK Cseq: 1 INVITE ACK Cseq: 1 ACK

T1

RTP channels + RTCP channel

Figure 11 : Mthode PRACK

5.7

Mthode UPDATE

La mthode UPDATE permet un user agent de mettre jour les paramtres dune session multimdia. (e.g., flux mdia et leurs codecs). Son rle est similaire celui de la mthode reINVITE la diffrence prs que la mthode UPDATE peut tre envoye avant que la session soit tablie. UPDATE est donc particulirement utile lorsquil sagit de mettre jour des paramtres de session avant son tablissement, e.g. mise en attente du destinataire. Lorsquun UA met une mthode INVITE, elle doit contenir un header Allow dont la valeur doit contenir UPDATE pour indiquer sa capacit recevoir des mthodes UPDATE. Cela vaut aussi pour le rcepteur lorsque ce dernier retourne une rponse provisoire fiable. Si la rponse provisoire nest pas retourne de faon fiable, elle peut contenir le header Allow alors quune rponse finale 2XX doit le contenir. Cette information permettra dindiquer lmetteur que la destination a la capacit de supporter une procdure UPDATE. Considrons lexemple de la Figure 12 pour illustrer ltablissement d un appel entre deux usagers IMS avec QoS : UA1 met un mthode INVITE (1) contenant une description SDP1 pour tablir une session avec UA2. Cette description SDP indique des prconditions de QoS pour la session (e.g., session tlphonique). UA1 ne souhaite pas que UA2 soit alert tant que les ressources n'ont pas t rserves dans les deux sens (sendrecv). UA2 accepte de rserver des ressources pour cette session avant d'alerter l'appel. UA2 prend en charge la rservation des ressources dans le sens UA2?UA1 ; par ailleurs il est ncessaire que UA1 rserve des ressources dans le sens UA1?UA2. Afin de le lui indiquer, UA2 retourne une rponse provisoire 183 Session Progress (2) UA1 lui demandant de commencer la rservation des ressources et de confirmer UA2 ds que la session est prte dans le sens UA1?UA2. Cette rponse provisoire contient aussi une description SDP2. A La rception du 183 Session Progress, UA1 met une mthode PRACK (3) acquitte par 200 OK (4).

Copyright EFORT 2011

19

UA1 et UA2 commencent la rservation de ressources (dans le cas de UE SIP, en crant des contextes PDP avec la QoS requise pour la session; cette cration implique les entits UE, SGSN et GGSN). Mme si UA2 a reu une confirmation du rseau qui indique la rservation des ressources, l'appel n'est pas alert tant qu'une confirmation n'est pas envoye par UA1. Lorsque UA1 a finalis sa procdure de rservation, il met un message UPDATE (5) UA2 contenant une description SDP3 qui indique cette rservation dans le sens UA1?UA2. UA2 retourne une rponse 200 OK (6) de confirmation de la mthode UPDATE, indiquant que toutes les prconditions de Qos pour la session ont t remplies et que la QoS a bien t rserve dans les deux sens (La rponse 200 OK contient la description SDP4). A cet instant, UA2 alerte l'appel. Une rponse provisoire 180 Ringing (7) est mise par l'UA2 l'UA1. L'appel dcroche. UA2 retourne une rponse 200 OK (10) (rponse la mthode INVITE) sans description SDP. UA1 met une mthode ACK (11) afin de finaliser ltablissement dappel. L'change de mdia peut donc avoir lieu entre les deux participants la session.
SIP UA 1 SIP UA 2

Contrle de Service

1. INVITE (SDP1) 2. 183 Session Progress (SDP2) 3. PRACK 4. 200 OK (PRACK)

Rservation de ressource

Rservation de Ressource

Rservation de Ressource

5. UPDATE (SDP3) 6. 200 OK (UPDATE) (SDP4) 7. 180 Ringing 8. PRACK 9. 200 OK (PRACK) 10. 200 OK (INVITE) 11. ACK

Alerte et Rponse

Flux mdia RTP

Figure 12 : Mthode UPDATE SDP1 m=audio 20000 RTP/AVP 97 c=IN IP4 192.0.2.2 a=curr:qos local none a=curr:qos remote none a=des:qos mandatory local sendrecv a=des:qos mandatory remote sendrecv SDP2 m=audio 30000 RTP/AVP 97 c=IN IP4 192.0.2.4 a=curr:qos local none

Copyright EFORT 2011

20

a=curr:qos remote none a=des:qos mandatory local sendrecv a=des:qos mandatory remote sendrecv SDP3 m=audio 20000 RTP/AVP 97 c=IN IP4 192.0.2.2 a=curr:qos local sendrecv a=curr:qos remote none a=des:qos mandatory local sendrecv a=des:qos mandatory remote sendrecv SDP4 m=audio 30000 RTP/AVP 97 c=IN IP4 192.0.2.4 a=curr:qos local sendrecv a=curr:qos remote sendrecv a=des:qos mandatory local sendrecv a=des:qos mandatory remote sendrecv

Rfrences
RFC 2778 A Model for Presence and Instant Messaging. M. Day, J. Rosenberg, H. Sugano. February 2000. RFC 2779 Instant Messaging/Presence Protocol Requirements. M. Day, S. Aggarwal, G. Mohr, J. Vincent. February 2000. RFC 2976 The SIP INFO Method. S. Donovan. October 2000. RFC 3261 SIP: Session Initiation Protocol. J. Rosenberg, H. Schulzrinne, G. Camarillo, A. Johnston, J. Peterson, R. Sparks, M. Handley, E. Schooler. June 2002. RFC 3262 Reliability of Provisional Responses in Session Initiation Protocol (SIP). J. Rosenberg, H. Schulzrinne. June 2002. RFC 3263 Session Initiation Protocol (SIP): Locating SIP Servers. J. Rosenberg, H. Schulzrinne. June 2002. RFC 3264 An Offer/Answer Model with Session Description Protocol (SDP). J. Rosenberg, H. Schulzrinne. June 2002. RFC 3265 Session Initiation Protocol (SIP)-Specific Event Notification. A. B. Roach. June 2002.. RFC 3311 The Session Initiation Protocol (SIP) UPDATE Method. J. Rosenberg. October 2002. RFC 3515 The Session Initiation Protocol (SIP) Refer Method. R. Sparks. April 2003. RFC 3680 A Session Initiation Protocol (SIP) Event Package for Registrations. J. Rosenberg. March 2004. RFC 3842 A Message Summary and Message Waiting Indication Event Package for the Session Initiation Protocol (SIP). R. Mahy. August 2004. RFC 3856 A Presence Event Package for the Session Initiation Protocol (SIP). J.Rosenberg. August 2004. RFC 3903 Session Initiation Protocol (SIP) Extension for Event State Publication. A. Niemi, ed. October 2004. RFC 4566 SDP: Session Description Protocol. M. Handley, V. Jacobson, C. Perkins. July 2006.

Copyright EFORT 2011

21