SIP : Session Initiation Protocol

Simon ZNATY et Jean-Louis DAUPHIN

EFORT
http://www.efort.com

1 Introduction
SIP (Session Initiation Pr
ot
ocol
)estunpr
ot
oc
ol
edesi
gnal
i
s
at
i
ondf
i
niparl

I
ETF(
I
nt
er
net
Engineering Tas
k For
ce)per
met
t
antl

t
abl
i
ssement
,l
al
i
br
at
i
on etl
a modi
f
i
cat
i
on de
sessions multimdias (RFC 3261). 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 messages lectroniques (E-mails). SIP
s
appui
esurunmodl
et
r
ansac
t
i
onnelcl
i
ent
/
ser
v
eurcommeHTTP.L
adr
essageut
i
l
i
sel
e
conceptd
URL SI
P(
Uniform Resource Locator) qui ressemble une adresse E-mail.
Chaque participant dans un rseau SIP est donc adressable par une URL SIP. Par ailleurs,
les requtes SIP sont acquittes par des rponses identifies par un code numrique.
D
ai
l
l
eur
s,l
apl
upar
tdescodesder
ponsesSI
Pontt
empr
unt
saupr
ot
ocol
eHTTP.Par
ex
empl
e,l
or
s
quel
edest
i
nat
ai
r
en
es
tpasl
oc
al
i
s,uncodeder
ponse404 Not Found
est retourn. Une requte SIP est constitue de headers comme une commande SMTP.
Enfin SIP comme SMTP est un protocole textuel.
SIP a t tendu afin de supporter de nombreux services tels que la prsence, la
messagerie instantane (similaire au service SMS dans les rseaux mobiles), le transfert
d
appel
,l
aconf
r
ence,l
esser
v
i
cescompl
ment
ai
r
esdet
l
phoni
e,et
c
.
SI
P at
r
et
enuparl
e3GPP pourl

ar
chi
t
ec
t
ur
eI
MS (
I
P Multimedia Subsystem) comme
protocole pour le contrle de session et le contrle de service. Il remplacera terme les
pr
ot
oc
ol
esI
SUP(
ut
i
l
i
spourl
econt
r
l
ed
appeldansl
eRseauTl
phoni
queCommut
)et
I
NAP(
ut
i
l
i
spourl
econt
r
l
edeser
v
i
cedansl

ar
chi
t
ect
ur
eRseauI
nt
el
l
i
gent
)
Le pr
ot
ocol
e SI
P n
estqu
un pr
ot
ocol
e de si
gnal
i
sat
i
on.Une f
oi
sl
as
essi
on t
abl
i
e,l
es
par
t
i
ci
pant
s de l
a ses
si
on s
changentdi
r
ect
ementl
eurt
r
af
i
c audio/vido travers le
protocole RTP (Real-Time Transport Protocol).
Parai
l
l
eur
s,SI
P n
es
tpasunpr
ot
ocol
eder
ser
v
at
i
onder
essour
c
e,i
lnepeutdoncpas
assurer la QoS.I
ls

agi
td
unpr
ot
ocol
edecont
r
l
ed
appeletnondecont
r
l
edumdi
a.
SI
P n
estpasnonpl
usun pr
ot
ocol
e de t
r
ans
f
er
tdef
i
chi
ert
elque HTTP,ut
i
l
i
s af
i
nde
transporter de grands volumes de donnes. Il a t conu pour transmettre des messages
de si
gnal
i
sat
i
on cour
t
s af
i
n d
t
abl
i
r
,mai
nt
eni
retl
i
br
erdes s
essi
ons mul
t
i
mdi
a.Des
messages courts non relatifs un appel peuvent nanmoins tre transports par SIP la
manire des SMS.
Le paragraphe 2 introduit les entits SIP. Le paragraphe 3 prsente le protocole SIP. Au
par
agr
aphe 4 es
t dcr
i
tl
ef
onct
i
onnement du pr
ot
ocol
e SI
P av
ec l

enr
egi
st
r
ement
l

t
abl
i
ssement
/
l
al
i
br
at
i
on d
appelSI
P.Le par
agr
aphe 5 pr
sent
el
es ex
t
ensi
ons du
pr
ot
oc
ol
e SI
P.Le par
agr
aphe 6 t
r
ai
t
el

interfonctionnement entre rseau SIP et rseau

t
l
phoni
quecommut
.Lepar
agr
aphe7dc
r
i
tl

ar
chi
t
ect
ur
edeser
v
i
ceSI
P; le paragraphe
8t
r
ai
t
el
ami
seenuv
r
edesser
v
i
ces.

2 Entits SIP
SI
P df
i
ni
tdeuxt
y
pesd
ent
i
t
s: les clients et les serveurs. Plus prcisment les entits
dfinies par SIP sont (Figure 1):

Copyright EFORT 2005

 Le serveur proxy (Proxy server) :I

lr
eoi
tdesr
equt
esdecl
i
ent
squ
i
l traite lui-mme ou
qu
i
lachemi
ne d
aut
r
es ser
v
eur
s apr
s av
oi
r v
ent
uel
l
ement r
al
i
s cer
t
ai
nes
modifications sur ces requtes.
Le serveur de redirection (Redirect server) :I
ls
agi
td
un ser
v
eurquiaccept
e des
requtes SIP, traduit l'adresse SIP de destination en une ou plusieurs adresses rseau et
les retourne au client. Contrairement au Proxy server, le Redirect server n'achemine pas
de r
equt
esSI
P.Dansl
ec
asd
un r
env
oid
appel
,l
e Proxy server a la capacit de
t
r
adui
r
el
e numr
o de l

appel
dansl
e mes
sage SI
Pr
eu,en un numr
o de r
env
oi
d
appeletd'
achemi
nerl

appelcet
t
enouv
el
l
edest
i
nat
i
on,etce,def
aont
r
anspar
ent
e
pour le client origine ; pour le mme service, le Redirect server retourne le nouveau
numr
o(
numr
oder
env
oi
)auc
l
i
entor
i
gi
nequisechar
ged
t
abl
i
runappelv
er
scet
t
e
nouvelle destination.
L
agentut
i
l
i
sat
eur(
UA,UserAgent
) :I
ls
agi
td
uneappl
i
cat
i
onsurunqui
pementde
l

usagerquimetetr
eoi
tdesr
equt
esSI
P.I
ls
emat
r
i
al
i
separunl
ogi
ci
eli
nst
al
l
sur
un PC, sur un tlphone IP ou sur une station mobile UMTS (UE, User Equipment).
L
enr
egi
s
t
r
eur(
Registrar) ;I
l
s
agi
td
unser
v
eurquiaccept
el
esr
equt
esSI
PREGI
STER.
SI
P di
spose de l
af
onct
i
on d
enr
egi
st
r
ementd
ut
i
l
i
sat
eur
s.L
ut
i
l
i
sat
euri
ndi
que parun
message REGISTER mis au Regi
st
r
ar
,l

adr
esseoi
les
tj
oi
gnabl
e(
e.g., adresse IP).
Le Regi
s
t
r
armetal
or
sj
ourunebasededonnedel
ocal
i
sat
i
on.L
enr
egi
st
r
eurestune
fonction associe un Proxy server ou un Redirect server. Un utilisateur peut
s
enr
egi
s
t
r
ersurdi
f
f
r
ent
sUAs SIP ;danscecas
,l

appell
uiser
adl
i
v
r
surl

ens
embl
e
de ces UAs.
Proxy/Redirect/Registrar
Server
Location
Database

SIP Gateway
SIP UA

Rseau SIP

RTCP

SIP UA
Tlphone RNIS
ou tlphone analogique

Figure 1:Ent
i
t
sd
unr
seauSI
P

3 Mthodes et Rponse SIP

3.1

Mthodes SIP

Le RFC 3261 dfinit six requtes ou mthodes SIP.

La mthode INVITE estut
i
l
i
seaf
i
nd
t
abl
i
runesessi
onent
r
eUAs. INVITE correspond au
messageI
SUPI
AM ouaumessageQ.
931SETUPetcont
i
entl
esi
nf
or
mat
i
onssurl

appel
ant
etl

appel
etsurl
et
y
pedef
l
uxquiser
ontchangs(
v
oi
x
,v
i
do,et
c.
)
.
Lor
s
qu
unUAay
antmi
sl
amt
hodeSI
PI
NVI
TEr
eoi
tuner
ponsef
i
nal
el

i
nv
i
t
at
i
on(
i
.
e.
,
200 OK), il confirme la rception de cette rponse par une mthode ACK. Une rponse telle
que busy ou answer es
tc
onsi
dr
ecommef
i
nal
eal
or
squ
une r
ponset
el
l
e que
ringing si
gni
f
i
antquel

appel
es
tal
er
t
,es
tuner
ponsepr
ov
i
soi
r
e.

Copyright EFORT 2005

La mthode BYE per

metl
al
i
br
at
i
ond
unesess
i
onpr
al
abl
ementt
abl
i
e.El
l
ecor
r
espond
au message RELEASE des protocoles ISUP et Q.931. Un message BYE peut tre mis par
l

appel
antoul

appel
.
La mthode REGISTER estut
i
l
i
separunUAaf
i
nd
i
ndi
querauRegistrar la correspondance
entre son adresse SIP et son adresse de contact (e.g., adresse IP).
La mthode CANCEL est utilise pour demander l
abandond
unappelencour
smai
sn
a
aucun effet sur un appel dj accept. En effet, seule la mthode BYE peut terminer un
appel tabli.
La mthode OPTIONS es
tut
i
l
i
seaf
i
nd
i
nt
er
r
ogerl
escapaci
t
setl

t
atd
unUseragentou
d
un ser
v
eur
.La r
ponse c
ont
i
entses c
apaci
t
s (
e.g., type de mdia tant support,
mthodes supportes, langue supporte) ou le fait que l'UA soit indisponible.

3.2

Rponses SIP

Aprs avoir reu et interprt une requte SIP, le destinataire de cette requte retourne une
rponse SIP. 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 : Redi
r
ect
i
on, l

appel r
equi
er
t d
aut
r
es t
r
ai
t
ement
s av
ant de pouv
oi
r
dt
er
mi
ners
i
lpeutt
r
er
al
i
s.
Classe 4xx : Erreur requte client, la requte ne peut pas tre interprte ou servie par le
ser
v
eur
.Lar
equt
edoi
tt
r
emodi
f
i
eav
antd
t
r
er
env
oy
e.
Classe 5xx :Er
r
eurser
v
eur
,l
e ser
v
eurchoue dans l
et
r
ai
t
ementd
une r
equt
e
apparemment valide.
Classe 6xx : Echec global, la requte ne peut tre traite par aucun serveur.

4 Fonctionnement du protocole SIP

4.1

Enregistrement au rseau SIP

La mthode REGISTER es
tut
i
l
i
separunUseragentaf
i
nd
i
ndi
querl
af
onct
i
onRegistrar
(physiquement implante dans un Proxy server ou Redirect server) la correspondance entre
son adresse SIP (e.g., sip:mary.taylor@orange.com) et son adresse IP (e.g.,
sip:mary.taylor@192.190.132.20). L'adresse IP peut tre statique ou obtenue
dynamiquement par DHCP. La fonction Registrar met alors jour une base de donnes de
localisation. A partir de cet instant, le User Agent peut recevoir des appels puisqu'il est
localis. Si un usager SIP veut renvoyer ses appels de son domaine courant un autre
domaine (e.g., du domaine orange.com au domaine francetelecom.com), il lui suffit
d
i
ndi
quer l
af
onc
t
i
on Registrar de orange.com son adresse SIP dans le domaine
francetelecom.com. Quand un message INVITE doit tre dlivr par le proxy serveur du
domaine orange.com sip:mary.taylor@orange.com, la base de donnes mise jour par la
fonction Registrar indique au Proxy Server que le message doit tre relay
sip:mary.taylor@francetelecom.com. Alors le Proxy server effectue une recherche par le
DNS del

adr
esseI
P duProxy server du domaine francetelecom.com afin de lui relayer le
message SIP acheminer la destination approprie (sip:mary.taylor@francetelecom.com).
Dans un rseau IMS (IP Multimedia Subsystem), le Proxy Server correspond une entit
CSCF (Call State Control Function), alors que la base de donnes de localisation est
reprsente par l'entit HSS (Home Subscriber Ser
v
er
)
.LeHSSdansl

I
MSpourl
esmobi
l
es
est un HLR contenant par ailleurs le profil de l'usager pour les services IMS souscrits.

Copyright EFORT 2005

4.2

Etablissement et libration de session SIP

Dans l

ex
empl
e sui
v
ant
,l
'
appel
anta pourURL SI
P si
p:
mar
y
.
t
ay
l
or
@f
r
ancet
el
ecom.
com,
alors que celle de l'appel est sip:mart.rich@francetelecom.com (Figure 2).
Unmessaged'
t
abl
i
ssementd'
appelSI
PI
NVI
TE es
tmi
sparL
UA SI
P del
'
appel
antau
Proxy Server. Ce dernier interroge la base de donnes de localisation pour identifier la
localisation de l'appel (adresse IP) et achemine l'appel la destination. Le message INVITE
contient diffrents headers obligatoires dont l'adresse SIP de l'appelant "From", l'adresse SIP
de l'appel "To", un identifiant d'appel "Call-ID", un numro de squence "Cseq", un nombre
maximum de sauts max-forwards . Le header Via est mis jour par toutes les entits
qui ont particip au routage de la requte INVITE. Cela assure que la rponse suivra le
mme chemin que la requte.
Par ailleurs, la requte SIP INVITE contient une syntaxe SDP (Session Description Protocol).
Cette structure consiste en plusieurs lignes qui dcrivent les caractristiques du mdia que
l

appel
antMary r
equi
er
tpourl

appel
.
Mary Taylor indique que la description SDP utilisation la version 0 du protocole, 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 AVP (Audio Video Profile) et pouvant
tre G.711 -law ou G.728.
SIP Proxy Server
ps1.francetelecom.com
sip:mary.taylor@francetelecom.com

sip:mark.rich@francetelecom.com

SIP UA 1

SIP UA 2

1. INVITE
4. 180 RINGING

2. INVITE
3. 180 RINGING
5. 200 OK

6. 200 OK
7. ACK

8. ACK

Flux RTP
9. BYE
12. 200 OK

10. BYE
11. 200 OK

Figure 2 : Etablissement et libration de session SIP

INVITE sip:mark.rich@francetelecom.com SIP/2.0
Via : SIP/2.0/UDP station1.francetelecom.com:5060
Max-Forwards : 20
To : Mark Rich <sip:mark.rich@francetelecom.com>
From : Mary Taylor <sip:mary.taylor@francetelecom.com>
Call-Id: 23456789@station1.francetelecom.com

Copyright EFORT 2005

CSeq: 1 INVITE
Contact: 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 15

Lar
ponse180RI
NGI
NG estr
et
our
neparl
edes
t
i
nat
ai
r
el

UAdel
appel
ant
.
Lorsque l'appel accepte la session, la rponse 200 OK est mise par son UA et achemine
l

UAdelappel
ant
.
SIP/2.0 200 OK
Via : SIP/2.0/UDP ps1.francetelecom.com:5060
Via : SIP/2.0/UDP station1.francetelecom.com:5060
Max-Forwards : 20
To : Mark Rich <sip:mark.rich@francetelecom.com>
From : Mary Taylor <sip:mary.taylor@francetelecom.com>
Call-Id: 23456789@station1.francetelecom.com
CSeq: 1 INVITE
Contact: mark.rich@192.190.132.27
Content-Type: application/sdp
Content-Length:162
v=0
c = IN IP4 192.190.132.27
m = audio 22220 RTP/AVP 0

L
UAdel
appel
antr
et
our
neunemt
hodeACKaudest
i
nat
ai
r
e,r
el
ay
eparl
'
ent
i
t
Proxy
Server.
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 UA envoie une requte BYE pour terminer la session. Cette
requte est remise au Proxy Ser
v
erquil
'
achemi
nel

UAdeMar
k.Ceder
ni
err
et
our
nel
a
rponse 200 OK.
BYE sip:mark.rich@francetelecom.com SIP/2.0
Via : SIP/2.0/UDP station1.francetelecom.com:5060
Max-Forwards : 20
To : Mark Rich <sip:mark.rich@francetelecom.com>
From : Mary Taylor <sip:mary.taylor@francetelecom.com>
Call-Id: 23456789@station1.francetelecom.com
CSeq: 2 BYE
SIP/2.0 200 OK
Via : SIP/2.0/UDP ps1.francetelecom.com:5060
Via : SIP/2.0/UDP station1.francetelecom.com:5060
Max-Forwards : 20
To : Mark Rich <sip:mark.rich@francetelecom.com>
From : Mary Taylor <sip:mary.taylor@francetelecom.com>
Call-Id: 23456789@station1.francetelecom.com
CSeq: 2 BYE

Copyright EFORT 2005

5 Extensions du protocole SIP

Uneent
i
t
SI
P peutsouscr
i
r
eunv
nementaf
i
nd
t
r
enot
i
f
i
edesonoccur
r
ence.La
requte SUBSCRIBE permet la souscription alors que la requte NOTIFY est utilise afin de
notifier (RFC 3265). La mthode PUBLISH permet quant elle de publier son tat.
La mthode REFER (RFC 3515) renvoie le rcepteur vers une ressource identifie dans la
mt
hode.REFER per
metd
mul
erdi
f
f
r
ent
s ser
v
i
ces ou appl
i
cat
i
ons dontl
et
r
ans
f
er
t
d
appel
.Consi
dr
onsT1,l

ent
i
t
l

or
i
gi
ne du t
r
ans
f
er
t
,T2,l

ent
i
t
t
r
ans
f
r
e etT3,l
e
dest
i
nat
ai
r
edut
r
ans
f
er
t
.Let
r
ans
f
er
td
appelper
metT1det
r
ans
f
or
merunappelencour
s
ent
r
eT1etT2enunnouv
elappelent
r
eT2etunT3choi
siparT1.Sil
et
r
ans
f
er
td
appel
aboutit, T2 et T3 pourront communiquer tandis que T1 ne pourra plus dialoguer avec T2 ou
T3.
La mthode MESSAGE (RFC 3428) a t propose comme extension au protocole SIP afin
de permettre le transfert de messages instantans. La messagerie instantane (IM, Instant
Messagi
ng)consi
st
eenl

changedemessagesent
r
eusager
senps
eudot
empsr
el
.Cet
t
e
nouvelle mthode hrite de toutes les fonctions offertes par le protocole SIP telles que le
routage et la scurit. La requte MESSAGE peut transporter plusieurs types de contenus
ens
appuy
antsurl
ecodageMI
ME.
La mthode INFO (RFC 2976) permet de transfrer des informations de signalisation durant
l

appel
.Par
mil
esex
empl
esd
i
nf
or
mat
i
onf
i
gur
entles digits DTMF, les informations relatives
l
at
ax
at
i
ond
unappel
,desi
mages
,et
c
.
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
t
atdel

appel
,not
ammentl
or
sdel

i
nt
er
connex
i
on
avec le RTCP. La mthode PRACK (
RFC 3262)a donc t
df
i
ni
e af
i
n d
acqui
t
t
erl
a
rception de rponses provisoires, de type 1XX.
La mthode UPDATE (RFC 3311) permet un terminal SIP de mettre jour les paramtres
d
unesessi
onmul
t
i
mdi
a.(
e.g., flux mdia et leurs codecs). La mthode UPDATE peut tre
env
oy
eav
antquel
asessi
onsoi
tt
abl
i
e.UPDATE es
tdoncpar
t
i
cul
i
r
ementut
i
l
el
or
s
qu
i
l
s
agi
tdemet
t
r
ej
ourdespar
amt
r
esdes
essi
onav
antsont
abl
i
ssement
,e.g., mise en
attente du destinataire.

6 Interfonctionnement entre SIP et RTC

Pourl

interfonctionnement entre RTC (Rseau Tlphonique Commut) et SIP, il est

ncessai
r
ed
i
nt
r
odui
r
eunGat
ewayRTC/
SI
P quis
i
nt
er
f
aced
unepar
tauRTC etd
aut
r
e
part un rseau SIP. Ce Gateway a deux fonctions :
Traduction de la signalisation ISUP (ISDN User Part) en signalisation SIP et inversement
Conversion des signaux audio en paquets RTP et inversement ; en effet ce Gateway
tablit des canaux logiques RTP avec le terminal SIP et tablit des circuits de parole avec un
Class 5 ou Class 4 switch. Le Class5 Switch reprsente un commutateur tlphonique
l

accsal
or
squel
eCl
ass4Switch est un commutateur tlphonique de transit.
Dansl

ex
empl
econsi
dr
l
af
i
gur
e3,unt
er
mi
nalr
el
i
auRTC appel
l
eunUA SI
P.Le
Class 5 Swi
t
ch auquelestr
at
t
ach l

appel
ant
,metunmessageI
SUP I
AM au Gateway
RTC/
SI
P.Cemessagec
ont
i
entl
enumr
odudes
t
i
nat
ai
r
e,l

i
dent
i
f
i
cat
eurdeci
r
cui
tchoi
sipar
le Class 5 Swi
t
chpourl

appel(
CI
C,Ci
r
c
ui
tI
dent
i
f
i
c
at
i
onCode)ai
nsiquedesi
nf
or
mat
i
ons
i
ndi
quantl
anat
ur
edel

appel(
par
ol
e,f
ax
,donnes,et
c.
)
.LeGateway RTC/SIP traduit ce

Copyright EFORT 2005

message en une requte SIP INVITE qui contient une adresse de destination SIP dont le
champ user est un numro de tlphone. Il passe le message au SIP Proxy server qui
obt
i
entl

adr
esseI
Pdudest
i
nat
ai
r
epar
t
i
rdel

adr
es
seSI
Ppari
nt
er
r
ogat
i
ond
unebasede
donnes ou d
un ser
v
eurde l
ocal
i
sat
i
on.Le message I
NVI
TE estr
el
ay
l

UA SI
P.
Paralllement, le Proxy server notifie au Gateway la rception de la requte INVITE par la
rponse 100 Trying. Le terminal SIP retourne au Proxy server une rponse 180 Ringing pour
informer l
appel
antdel

al
er
t
edel

appel
,messager
el
ay
parl
eProxy server au Gateway.
Le Gateway traduit cette rponse en un message ISUP ACM (Address Complete Message)
renvoy au Class 5 Switch. Ce message est traduit par le Class 5 Switch en un message
Alerting si le terminal appelant est un terminal RNIS ou en un signal Ringing Tone dans
l
ecasd
unt
er
mi
nalanal
ogi
que.
Lor
s
quel

appel
dcr
oc
he,uner
ponse200OKes
tr
et
our
neauProxy server qui la relaye
au Gateway. Le Gateway acquitte la rception de cette rponse par une requte ACK
achemine par le Proxy Server au destinataire. Paralllement, le Gateway gnre un
message ISUP ANM (Answer Message) mis au Class 5 Switch.
Cetchangedesi
gnal
i
sat
i
onaper
mi
sl

t
abl
i
ssementdecanauxRTPent
r
el
et
er
mi
nalSI
P
et le Gat
ewayetl
ami
seenpl
aced
unci
r
cui
tdepar
ol
eent
r
el
eGat
ewayetl
e Cl
ass5
Switch.

SIP Terminal

SIP Proxy Server

SIP Gateway

Class 5
Switch

ISUP IAM
SIP INVITE
SIP INVITE
180 Ringing
200 OK

SIP ACK

100 Trying
180 Ringing
ISUP ACM
200 OK
SIP ACK
ISUP ANM

Canaux RTP

Circuit de parole

Figure 3 : Interfonctionnement RTC/SIP

Pendantl
aphasedet
r
ans
f
er
td
i
nf
or
mat
i
on,l
eGateway convertit les signaux audio reus sur
le circuit de parole en paquets RTP envoys sur les canaux RTP et inversement.

7 Architecture de service SIP

L
ar
chi
t
ect
ur
edeser
v
i
ceSI
Pdebasees
tconst
i
t
uedeser
v
eur
sd
appl
i
cat
i
on,deser
v
eur
s
de mdia et de S-CSCF.
Le serveur d'application SIP excutent des services (e.g., Push To Talk, Prsence,
Prpaid, Instant messaging, etc.) et peuvent influencer le droulement de la session la
demande du service. Le serveur d
appl
i
cat
i
oncor
r
espondauSCPduRseauI
nt
el
l
i
gent
.
Le serveur de mdia SIP (appel dans les recommandations le MRF pour Multimedia
Resource Function) tablit des confrences multimdias, joue des annonces vocales ou

Copyright EFORT 2005

mul
t
i
mdi
a etcol
l
ect
e desi
nf
or
mat
i
onsut
i
l
i
sat
eur
.I
ls
agi
tde l

v
ol
ut
i
on de l

ent
i
t
SRP
(Specialized Resource Point) dans le monde multimdia.
Le serveur d
appelSI
P(
Proxy server) joue le rle de point depuis lequel un service peut
t
r
ei
nv
oqu.I
ldi
sposedupr
of
i
ldeser
v
i
cedel

abonnquil
uii
ndi
que l
esser
v
i
cessouscr
i
t
s
parl

abonn etsous quel

l
e condi
t
i
on i
nv
oquerces ser
v
i
c
es.I
lcor
r
espond au SSP de
l

ar
chi
t
ect
ur
eRseauI
nt
el
l
i
gent
.

7.1

Ser
veurd
appl
i
cat
i
on

Un serveur d
appl
i
cat
i
onSI
Pf
our
ni
tunenv
i
r
onnementd
ex
cut
i
onpourdesappl
i
cat
i
ons,
appel SLEE (Service Logic Execution Environment). Il fournit un ensemble de services
permettant de simplifier les tches des dveloppeurs d
appl
i
cat
i
onetdes administrateurs.
Le but est de disposer d
une pl
at
ef
or
me met
t
anten uv
r
et
out
es l
es f
onc
t
i
onnal
i
t
s
permettant ainsi au dveloppeur de ne se focaliser que sur la logique mtier de
l
appl
i
cat
i
on.
Lesf
onc
t
i
onsd
unser
v
eurd
appl
i
cat
i
onsont:
La gestion des ressources : Le serveur d
appl
i
cat
i
oncont
r
l
el
acr
at
i
onetl
ut
i
l
i
sat
i
ondes
ressources telles que les threads, les connexions de transport, les composants applicatifs
(e.g., scripts CPL, servlets SIP) ainsi que les sessions d
appl
i
cat
ion.
La gestion d
appl
i
cat
i
on: L
appl
i
cat
i
onpeutt
r
eassoci
eunpr
of
i
ldeconf
i
gur
at
i
onl
or
s
de son dploiement. Ce profil peut contenir des paramtres pouvant tre modifis travers
l
i
nt
er
f
aceadmi
ni
st
r
at
i
v
el
or
sdudpl
oi
ementdel
appl
i
cat
i
on ou pendant son excution.
La composition d
appl
i
cat
i
on : Le serveur d
appl
i
cat
i
on doi
tper
met
t
r
e l
ex
cut
i
on de
plusieurs applications pour une mme requte SIP. Cela fournit une capacit de
modularisation. En effet, des lments de service peuvent tre dvelopps indpendamment
et peuvent tre combins en fonction des besoins d
appl
i
cat
i
on.Cel
aper
metparai
l
l
eur
sun
meilleur contrle des interactions de service.
L
i
nt
gr
at
i
on WEB : afin de fournir une GUI Web pour l
admi
ni
st
r
at
i
on et pour
l
interfonctionnement avec des serveurs WEB fournissant des services.
La programmation : Le serveur d
appl
i
cat
i
on f
our
ni
tun suppor
tpourl
e dv
el
oppement
d
appl
i
cat
i
on,i
.
e.
,desAPI
s(
JAI
N API
,SI
PServlet API, etc.) et des langages de script. Les
scripts peuvent tre crs l
ai
ded
env
i
r
onnement
sdecr
at
i
ondeser
v
i
ce.
L
interfonctionnement : Le serveur d
appl
i
cat
i
oncommuni
queenut
i
l
i
santl
epr
ot
ocol
eSI
P
avec le serveur de mdia (IP media server) pour les interactions avec l
usageretav
ecl
e
serveur d
appel(
CSCF)pourl
er
out
agedel
asi
gnal
i
sat
i
on.
La scurit : Le serveur d
appl
i
cat
i
on doi
tf
our
ni
r des mcani
smes d
encryptage,
d
aut
hent
i
f
i
cat
i
onetd
aut
or
i
sat
i
onaf
i
nd
as
sur
erunaccsscur
i
sauxser
v
i
ces.
Les capacits non fonctionnelles : haute disponibilit, partage de charge, tolrance aux
fautes. Ces caractristiques sont similaires celles exiges pour un SCP dans l
ar
c
hi
t
ec
t
ur
e
Rseau Intelligent.

7.2

Le serveur de mdia SIP

Le serveur mdia SIP est une plate-forme puissante et volutive pour le dveloppement de
services de portail vocaux et services vocaux/vido interactifs capables de supporter des
centaines voir des milliers de sessions simultanes dans un large ventail de configurations.
Leser
v
eurdemdi
aSI
Pestunqui
pementphy
si
queetmetenuv
r
el
ent
i
t
f
onct
i
onnel
l
e
MRF (Multimedia Resource Func
t
i
on)df
i
ni
eparl

I
MS.Leser
v
eurdemdi
aSI
Pf
our
ni
tl
es
fonctions permettant des interactions entre usagers et applications travers des ressources
vocales/vido. Par exemple, il peut rpondre un appel et jouer une annonce, ou lire un
message lectronique en utilisant des fonctions de synthse vocale, ou encore collecter une
i
nf
or
mat
i
ondel

usager(
e.
g.
,motdepasse,v
ot
e,numr
o)etl
ar
et
our
nerl

appl
i
cat
i
on.
Leser
v
eurdemdi
aSI
Pmetenuv
r
edeuxt
y
pesdef
onct
i
ons:

Copyright EFORT 2005

 Les fonctions de ressources mdia telles que les fonctions de dtection de tonalit, de
synthse vocale, de reconnaissance vocale, de traduction de mdia, etc. C
es
tla
fonction MRFP (Multimedia Resource Function Processor).
Les fonctions de contrle du mdia qui fournissent aux applications les moyens de
contrler les ressources mdia tels que, jouer un message, collecter un vote, enregistrer
un message, etc, et ce, travers le protocole SIP. C
es
tl
af
onc
t
i
onMRFC (
Multimedia
Resource Function Controller).
L'
ar
chi
t
ect
ur
e di
st
r
i
bue du ser
v
eur de mdi
a SI
P /
s
er
v
eur d
appl
i
cat
i
on spar
el
es
applications voix / vido du contrle des mdias, ce qui permet aux oprateurs de rduire les
cots des ressources rseau et d'hberger moindre frais les applications clients. Le
serveur de mdia IP supporte le protocole de contrle SIP. En plus du serveur de mdia IP
etduser
v
eurd
appl
i
cat
i
on,l
esent
i
t
ss
ui
v
ant
espeuv
entt
r
econsi
dr
es:
Browser VoiceXML : Ce composant intgr dans le serveur de mdia IP fournit un exemple
d
env
i
r
onnementd
ex
cut
i
ond
appl
i
cat
i
onsv
ocal
es.Lesappl
i
cat
i
onsdv
el
oppessel
on
les spcifications VoiceXML peuvent tre interprtes et excutes par le browser
VoiceXML. Ce browser ne fait qu
i
nt
er
pr
t
eretdt
er
mi
nerl
est
apesat
omi
quesducal
lflow.
C
estl
eser
v
eurdemdi
aI
Pquii
nt
er
agi
tav
ecl
usager
.
Serveur ASR : Ce composant fournit le service Automatic Speech Recognition (ASR). Le
flux audio de l
usageres
tt
r
anspor
t
surRTP duMedi
aGateway ou du tlphone IP de
l
usagerau ser
v
eurASR.Le Browser VoiceXML contacte le serveur ASR lorsqu
une
reconnaissance de parole est ncessaire.
Serveur TTS : Ce composant fournit le service Text-To-Speech (TTS). Une chaine de
caractre est mise ce composant et est convertie en une annonce vocale qui peut tre
mise l
usagersousf
or
medef
l
uxRTP.Lebrowser VoiceXML contacte le serveur TTS
lorsqu
unt
ex
t
edoit tre traduit en un message vocal et dlivr l
usager
.
Serveur WEB : Ce composant est un serveur standard HTTP. Il est utilis afin d
hber
gerl
e
contenu vocal. Ce contenu consiste en des scripts VoiceXML, des annonces vocales/vido,
des messages d
accueil, et des grammaires de reconnaissance de la parole. Les scripts
VoiceXML dfinissent la logique d
appl
i
cat
i
on.Desmessagesd
ac
cuei
lassi
st
entl
us
ager
dans sa navigation dans une application. Les grammaires contiennent les mots permis ou les
phrases qu
un usagerpeutpr
ononcerl
or
s
que l
appl
i
cat
i
on l
uidemande d
ent
r
erdes
informations.

7.2.1

Fonctionnalits du serveur de mdia

Les fonctionnalits du serveur de mdia SIP incluent les fonctions de contrle du mdia et
de ressources mdia :
Annonces : Lapl
upar
tdesser
v
i
cesv
ol
usut
i
l
i
sedesf
or
mesd
annonc
es,qu
i
ls
agi
sse
d
unmessagedebi
env
enuel
or
sdel

accssaboi
t
edemessageuni
f
i
eoud
unmes
sage
d
i
nt
r
oduct
i
onunpor
t
ai
lv
ocal
.L
ut
i
l
i
sat
i
ond
unser
v
eurdemdi
aSI
P pourr
al
i
serdes
ser
v
i
cesd
annoncesper
metdenepasav
oi
rdpl
oy
erunnouv
eauser
v
eurd
annonces
;
r
dui
santai
nsil
e nombr
e d
l
ment
s de r
seau etsi
mpl
i
f
i
antl
a gest
i
on de r
seau.Un
quipement de stockage externe peut tre utilis afin de stocker les annonces crant ainsi
une solution fiable et scal
abl
e.Lepr
ot
ocol
eRTPes
tut
i
l
i
spourdl
i
v
r
erl

annoncel

usager
.
Automated Speech Recognition (ASR, Automated Speech Recognition) : La
r
econnai
ssancedel
apar
ol
ees
tuncomposantdel
apl
upar
tdesser
v
i
cesl

usagert
el
sque
messagerie vocale (voicemail), la messagerie unifie, les jeux interactifs, et les portails
vocaux.
Gnration d
i
nf
or
mat
i
on det
axat
i
on: Une taxation prcise et juste est une exigence
pour les oprateurs de service afin d
of
f
r
i
rdesservices voix et donnes forte valeur
ajoute. Le serveur de mdia SIP gnre des informations de taxation.

Copyright EFORT 2005

Interactive Voice Response (IVR) : Le serveur de mdia SIP doit supporter la dtection des
tonalits DTMF envoyes dans la bande ainsi que les digits reus via SIP INFO.
Enregistrement : Le serveur de mdia SIP a des capacits d
enr
egi
st
r
ementetde
restitution (playback). De nombreuses applications telles que la messagerie vocale, la
messagerie unifie, le push-to-talk et la confrence utilisent cette fonction, i.e.,
enregistrement de l
appelaf
i
nqu
i
lsoi
tr
est
i
t
uul
t
r
i
eur
ement
.Leser
v
eurdemdi
aSI
P
utilise des serveurs de stockage existants chez l
opr
at
eurdeser
v
i
ce.
Text-To-Speech : La technologie text-to-speech est troitement associe la fonctionnalit
IVR. Le text-to-speech est utilis dans des applications telles que la messagerie unifie afin
de lire des E-mail ou des fax travers le tlphone. La traduction peut tre ralise en
plusieurs langues.
Gestion du multiparties : Le serveur de mdia SIP doit tre capable de fournir tous les
mcanismes de contrle des appels plusieurs participants Cette fonctionnalit est utilise
dans de nombreuses applications tels que confrence ou le push to talk.
Transcodage : Le transcodage permet de convertir un schma d
encodagenumr
i
queen
un autre. Dans le cas d
uneconf
r
enceoul
espar
t
i
ci
pant
snedi
sposentpasd
unmme
codec commun, le serveur de mdia SIP assurera alors les traductions de mdia
ncessaires.
Interfaces standard ouvertes : Le serveur de mdia SIP doit pouvoir tre contrl travers
le protocole SIP et doit pouvoir excuter des scripts VoiceXML.

8 Mi
sesenuvr
edesser
vi
ces
L
appr
oched
i
nt
r
oduc
t
i
onduser
v
i
cedpenddut
y
pedeser
v
i
ceetdesacompl
ex
i
t
.Ai
nsi
uns
er
v
i
cepeutt
r
emi
senuv
r
esurl
et
er
mi
nalSI
P,l
eser
v
eurdemdi
aSI
P,l
eser
v
eur
d
appl
i
cat
i
onoul
eProxy Server.
Certains services requirent des interactions complexes avec l
usager(
e.g., messagerie
unifie, IVR, etc.). Pour ces services vocaux une approche centralise est ncessaire avec
les entits AS SIP contenant la logique d
appl
i
cat
i
onetser
v
eurdemdi
aSI
Pcont
enantl
e
script vocal.
Certains services requirent une base de donnes centralise. Pour ces services de
traduction de numro (service de numro abrg, service prpaid, service VPN), un AS SIP
contenant la logique d
appl
i
cat
i
onestnces
sai
r
e.
Certains services de routage flexible ncessitent un script personnalis par abonn. Le
langage CPL (Call Processing Language) peut tre utilis pour ce faire. Il est possible de
faire excuter ce script par un AS SIP ou par le proxy server.
Certains services ne se prtent pas bien un traitement centralis. L'apparition de terminaux
SIP reposant sur une machine Java a offert la possibilit de dvelopper des services sur les
terminaux :
Leser
v
i
cesonner
i
edi
f
f
r
ent
i
eper
metdemodi
f
i
erl
asonner
i
edupos
t
eappel
enf
onct
i
on
de l'identit de l'appelant. Ce service basique est typiquement un service qu'il faut dployer
sur le poste.
Leser
v
i
cef
i
l
t
r
aged'
appeles
tunev
ar
i
ant
eduser
v
i
cepr
cdentdansl
aquel
l
el
'
i
dent
i
t
de
l'appel sert dterminer si l'appel doit tre accept, renvoy ou refus.
Leser
v
i
ceannuai
r
emont
r
el
'
i
nt
r
td'
uneconnex
i
ondi
r
ect
edut
er
mi
nalav
ecunannuai
r
e
d'entreprise : il permet l'utilisateur de consulter un annuaire LDAP depuis le tlphone, de
slectionner un numro parmi les rsultats et de lancer un appel vers ce numro.

Copyright EFORT 2005

10

9 Conclusion
Les formations proposes par EFORT autour de SIP prsentent les architectures de rseau
et de service SIP, ainsi que :
Leposi
t
i
onnementdeSI
Pdansl

I
MS
Lar
el
at
i
onent
r
eSI
Petl
esaut
r
espr
ot
ocol
esdel

I
MSt
el
squeSDP,COPS,DI
AMETER,
RTP/RTCP, RTSP, MSRP
L
interfonctionnement entre SIP et les rseaux lgataires tels que rseaux RTC, GSM,
H.323.
Lami
seenuv
r
edesser
v
i
cescompl
ment
ai
r
esdel
at
l
phoni
eav
ecSI
P
Lami
seenuv
r
edes
er
v
i
c
esv
al
euraj
out
est
r
av
er
sl
esASetl
esMRF(
Multimedia
resource Function) SIP.

Rfrences
J. Rosenberg, H. Schulzrinne, G. Camarillo, A. Johnston, J. Peterson, R. Sparks, M. Handley, E.
School
er
,SIP : Session Initiation Protocol
,RFC3261,June 2002.
B. Roach,Specific Event Notification
,RFC3265,June 2002.
J. Lennox, H. Schul
z
r
i
nne,Call Processing Language Framework and Requirements
,RFC 2824,
May 2000.
S. Donov
an,The SIP INFO Method
,RFC2976,October 2000
J. Rosenberg, H. Schul
z
r
i
nne,Reliability of Provisional Responses in the Session Initiation Protocol
(SIP)
,RFC3262,June 2002.
J. Rosenberg, SIP UPDATE Method
,RFC3311,September 2002.
Campbell, J. Rosenberg, H. Schulzrinne, C. Huitema, D. Gur
l
e,SIP Extension for Instant
Messaging
,RFC3428,December 2002.
M. Handley, V. Jacobson,
SDP:Sessi
onDescr
i
pt
i
onPr
ot
ocol

,RFC2327,April 1998.

Copyright EFORT 2005

11