Sip2 Efort PDF

Copyright EFORT 2011 1
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.
Classe 6xx : Echec global, la requte ne peut tre traite par aucun serveur.
Figure 1 : Mthodes REGISTER, OPTIONS, INVITE, ACK et BYE
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.
INVITE
180 RINGING
200 OK
ACK
BYE
OPTIONS
Registrar
UAC
UAC
UAC
UAC UAS
UAS
REGISTER
200 OK
UAS
INVITE
180 RINGING
200 OK
ACK
BYE
200 OK
200 OK
200 OK
200 OK
OPTIONS
Proxy Server
Proxy Server
Proxy Server
IN
V
IT
E
IN
V
IT
E
2
0
0

O
K
INVITE 1
8
0
R
IN
G
I
N
G
1
8
0
R
IN
G
IN
G
180 RINGING
A
C
K
C
A
N
C
E
L
2
0
0
O
K
200 OK
ACK
UA1
Proxy Server
UA2
UA3
4
8
7
T
ra
n
s
a
c
tio
n
C
a
n
c
e
lle
d
A
C
K
180 RINGING
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.
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.
SIP UA 2
1. INVITE
SIP UA 1
2. INVITE
5. 200 OK
8. ACK
7. ACK
6. 200 OK
Proxy Server
tn.com
sip:mary.taylor@tn.com
sip:mark.rich@tn.com
v =0 (dans message 1)
c =IN IP4 192.23.34.45
m =audio 45450 RTP/AVP 0, 18
v =0 (dans message 5)
c =IN IP4 192.190.130.38
m =audio 22222 RTP/AVP 0
v=version
c=connection
m=media
3. 180 RINGING
4. 180 RINGING
Flux de mdia RTP
9. BYE
10. BYE
11. 200 OK
12. 200 OK
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
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
To : Mark Rich <sip:mark.rich@tn.com>; tag 22454
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
received =192.190.132.21
Cseq : 1 INVITE
Contact : sip:mark.rich@192.190.23.16
Content-Type : application/sdp
Content-Length :162
v =0
c =IN IP 192.190.23.16
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 J ohn 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
From : Mary Taylor <sip:mary.taylor@tn.com>; tag=21272
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
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
received =192.190.132.21
Via : SIP/2.0/UDP station1.tn.com:5060; branch=z9hG4bK883bcrfg
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>
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.
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.
Base de donne
de localisation
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
Registrar
UA 1
(Mary)
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
Call-Id: 23456789Z567
CSeq: 1 REGISTER
Contact : sip:mary.taylor@192.190.132.20; expires=3600
Content-Length: 0
sip:mary.taylor@192.190.132.20
sip : registrar.tn.com
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.
UA 2
(Mary)
Registrar
Via: SIP/2.0/UDP station1.tn.com:5060;
branch=z9hG4bKst456
Max-Forwards : 20
Call-Id: 234567890ZR26
CSeq: 1 REGISTER
Contact : sip: mary.taylor@192.190.132.20;
expires =3600
Content-Length: 0
200 OK
UA 1
(Mary)
sip : mary.taylor@tn.com
200 OK
sip : registrar.tn.com
sip : mary.taylor@tn.com
Via: SIP/2.0/UDP station2.tn.com:5060;
branch=z9hG4bKdr324
Max-Forwards : 20
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
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 (3-
4). 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).
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 (1-
2).
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).
1. SUBSCRIBE
2. 200 OK
3. NOTIFY
4. 200 OK
SIP UA 1
SIP UA2
Un changement dans ltat
souscrit sest produit
5. NOTIFY
6. 200 OK
Un changement dans ltat
souscrit sest produit
7. NOTIFY
8. 200 OK
La souscription a expir
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.
Figure 7 : Scnario de souscription/notification de l'vnement voice-mail notification
SUBSCRIBE sip: mtaylor@voicemail.tn.com SIP/2.0
Max-Forwards : 20
To : <sip:mtaylor@voicemail.tn.com>
Call-Id: a84b4c76e66710
CSeq: 2342 SUBSCRIBE
Allow-Events : message-summary, presence
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
UA 1
(sip:mary.taylor@tn.com)
UA 2
(sip:mtaylor@voicemail.tn.com)
Voicemail
2. 200 OK
4. 200 OK
6. 200 OK
10. 200 OK
12. 200 OK
14. 200 OK
13. SUBSCRIBE
Annulation de la souscription
3. NOTIFY
1. SUBSCRIBE
5. NOTIFY
9. SUBSCRIBE
Re-souscription
11. NOTIFY
8. 200 OK
7. NOTIFY
Notification de la fin de la
souscription
16. 200 OK
15. NOTIFY
Notification de la fin de la
souscription
Notification immdiate de
ltat courant
Souscription ltat de la
boite vocale pour 3 heures
Notification dun nouveau
message
Notification immdiate de
ltat courant
Allow-Events : message-summary
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.
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).
MESSAGE
200 OK
UA1
Proxy Server
MESSAGE
MESSAGE
200 OK
200 OK
MESSAGE
200 OK
UA2
SIP AS =
Messaging Server
SIP
AS
Proxy Server
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
UA1
UA2 UA3
5. REFER Refer-To : sip:john.cook@tn.com
10. INVITE Referred-By: sip:mary.taylor@tn.com
11. 180 Ringing
12. 200 OK
13. ACK
RTP channels
No more RTP channel
sip:mary.taylor@tn.com sip:mark.rich@tn.com sip:john.cook@tn.com
1. INVITE
2. 180. Ringing
3. 200 OK
4. ACK
RTP channels
6. 202 Accepted
16. BYE
17. 200 OK
14. NOTIFY (event : refer)
15. 200 OK
7. re-INVITE
8. 200 OK
9. ACK
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.
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
1. INVITE
2. 180 Ringing
4. ACK
3. 200 OK
Media Flows over RTP
Messagerie
Vocale
Svp, fournissez
votre mot de passe
5. INFO
6. 200 OK
UA 1
UA 2
sip:callcenter@tn.com
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 2
31
-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.
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 re-
INVITE 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).
SIP UA 1
SIP UA 2
INVITE
Supported : 100rel
Cseq : 1 INVITE
100 Trying
Cseq : 1 INVITE
180 Ringing
Require : 100rel
CSeq: 1 INVITE
Rseq : 124
X
T1
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
RTP channels +RTCP channel
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.
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
c=IN IP4 192.0.2.4
a=curr:qos local none
SIP UA 1
SIP UA 2
1. INVITE (SDP1)
2. 183 Session Progress (SDP2)
3. PRACK
4. 200 OK (PRACK)
7. 180 Ringing
10. 200 OK (INVITE)
11. ACK
5. UPDATE (SDP3)
6. 200 OK (UPDATE) (SDP4)
Flux mdia RTP
8. PRACK
9. 200 OK (PRACK)
Rservation
de Ressource
Alerte et
Rponse
Rservation de
ressource
Contrle de
Service
Rservation
de Ressource
SDP3
c=IN IP4 192.0.2.2
a=curr:qos local sendrecv
SDP4
c=IN IP4 192.0.2.4
a=curr:qos local sendrecv
a=curr:qos 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.
J ohnston, J . Peterson, R. Sparks, M. Handley, E. Schooler. J une 2002.
RFC 3262 Reliability of Provisional Responses in Session Initiation Protocol (SIP). J .
Rosenberg, H. Schulzrinne. J une 2002.
RFC 3263 Session Initiation Protocol (SIP): Locating SIP Servers. J . Rosenberg, H.
Schulzrinne. J une 2002.
RFC 3264 An Offer/Answer Model with Session Description Protocol (SDP). J . Rosenberg,
H. Schulzrinne. J une 2002.
RFC 3265 Session Initiation Protocol (SIP)-Specific Event Notification. A. B. Roach. J une
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. J acobson, C. Perkins. J uly
2006.

Sip2 Efort PDF

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Sip2 Efort PDF

Transféré par

Droits d'auteur :

Formats disponibles

Copyright EFORT 2011 1

Le Protocole SIP Avanc et ses Extensions

Vous aimerez peut-être aussi