Vous êtes sur la page 1sur 109

Architectures Protocolaires VoIP

Session Initiation Protocol ou SIP


From : Prof. Noureddine Idboufker
To : GRT-2
n.idboufker@uca.ma
Version 2015-2016
La  standardisa*on  SIP  

q  SIP  (Session  Ini+a+on  Protocol)  a  été  normalisé  par  le  groupe  de  
travail  WG  MMUSIC  (Work  Group  Mul+party  Mul+media  Session  
Control)  de  l’IETF.    
q  La  version  1  est  sor+e  en  1997,  et  une  seconde  version  majeure  a  
été  proposée  en  mars  1999  (RFC  2543).    
q  La  version  2  a  elle-­‐même  été  largement  revue,  complétée  et  
corrigée  en  juin  2002  (RFC  3261).    
q  Des  compléments  au  protocole  ont  été  définis  dans  les  RFC  3262  
à  3265.  

2
GRT5-M3.4-ASC-1
Intérêt  croissant  pour  SIP  
q  De  nombreuses  extensions  sont  apparues  
q  4  groupes  de  travails  IETF  (SIP,  SIPPING,  SIMPLE,  XCON)  traitent  du  
protocole  SIP  et  de  ses  applica+ons  
q  Plus  de  100  extensions  (RFCs)  publiées  et  bien  d'autres  discutées  
q  De  nouvelles  normes  étendent  considérablement  les  fonc+onnalités  
de  SIP...  et  sa  complexité  

q   Prise  en  compte  progressive  des  besoins  des  opérateurs  télécoms  (même  si  
pas  de  volonté  de  supporter  toutes  les  fonc+ons  actuelles  des  réseaux  
téléphoniques)  
q   Services  "innovants"  :  présence,  instant  messaging,  conférence  

q  SIP  est  choisi  par  différents  organismes  de  normalisa+on  


q  3GPP,  ETSI  TISPAN,  PacketCable,  ITU-­‐T,  MSF  …etc.  

3
GRT5-M3.4-ASC-1
Adop*on  du  protocole  SIP  

33  Companies  
Ericsson  
100  
Number  of  A=endees  

16  Companies  

50  
8  Companies  

SIP  Accepted  
By  IETF  
0  
   March  1999                  April  1999                August  1999                      December  1999  
   

4
GRT5-M3.4-ASC-1
Growth of SIP in the IETF

January
1998: November Nov 2005:
IETF August
1999: First SIP
forms 2001:
SIP gets Operation
iptel wg – SIPPING
its own s Group
officially WG
Working Formed:
doing Formed
Group speermint
VoIP

1998 1999 2000 2001 2002 2003 2004 2005 2006

March
June
1999: March Aug 2004:
2002: SIP Nov 2005:
SIP 2001: SIP for
bis Real Time
published SIMPLE Presence
published Area
as RFC WG Published
as formed in
2543 in Formed as RFC
RFC3261 IETF
mmusic 3856

5
GRT5-M3.4-ASC-1
SIP  ?  

q  SIP  est  au  sens  propre  un  protocole  de  signalisa+on  hors  bande    
q  SIP  vise  l’établissement,  le  main+en,  la  modifica+on,  la  ges+on  
et  la  fermeture  de  sessions  interac+ves  entre  u+lisateurs  pour  :  
q  la  téléphonie    
q  et  la  vidéoconférence,    
q  et  plus  généralement  pour  toutes  les  communica+ons  mul+médias.  

6
GRT5-M3.4-ASC-1
Intérêt pour SIP

Les raisons
q  SIP est issu du monde de l'internet
q  Comme IP, RTP, UDP …etc.

q  Permet l'utilisation des technologies de l'internet


q  Similaire à HTTP
q  Codage texte
q  Facilité & Rapidité de développement des applications SIP
q  Cible un très grand nombre développeurs
q  Bénéficie du succès de l'internet.

7
GRT5-M3.4-ASC-1
Intégra*on  de  SIP  aux  autres  protocoles  
q  RTP  (Real-­‐*me  Transport  Protocol),  RFC  3550,  qui  se  charge  du  transport  des  flux  temps  réel.  
q  RTCP  (Real-­‐*me  Transport  Control  Protocol),  RFC  3550,  qui  fournit  des  informa+ons  dynamiques  
sur  l’état  du  réseau.  
q  RTSP  (Real-­‐Time  Streaming  Protocol),  RFC  2326,  pour  contrôler  la  diffusion  de  flux  mul+médias  
en  temps  réel.  
q  SDP  (Session  Descrip*on  Protocol),  RFC  2327,  qui  fournit  la  descrip+on  d’une  session,  c’est-­‐à-­‐
dire  les  paramètres  u+lisés  dans  une  communica+on  SIP.  
q  SAP  (Session  Adver*sement  Protocol),  RFC  2974,  pour  les  communica+ons  mul+cast,  qui  permet  
d’ajouter  les  spécifica+ons  d’une  nouvelle  session.  
q  MIME  (Mul*purpose  Internet  Mail  Extension),  RFC  2045,  standard  pour  les  descrip+ons  de  
contenus,  u+lisé  sur  Internet.  
q  RSVP  (Resource  reSerVa*on  Protocol),  RFC  2205,  pour  obtenir  des  garan+es  de  qualité  de  
service  et  effectuer  des  réserva+ons  de  ressources.  
q  HTTP  (HyperText  Transfer  Protocol),  RFC  2616,  pour  le  traitement  des  pages  Web  sur  Internet  
(on  peut  inclure  des  adresses  SIP  directement  dans  des  pages  Web).  
q  MGCP  (Media  Gateway  Control  Protocol),  RFC  3435,  pour  le  contrôle  des  passerelles  assurant  la  
connec+vité  entre  un  réseau  IP  et  un  réseau  téléphonique.  
8
GRT5-M3.4-ASC-1
Le  protocole  SIP  de  base  (RFC  3261)  

q  Le  protocole  SIP  de  base  permet  (RFC3261)  permet:  


1.  D'établir  des  sessions  mul+médias  
2.  De  changer  les  caractéris+ques  de  la  session  média  
3.  De  gérer  la  disponibilité  de  l'u+lisateur  
4.  De  vérifier  des  caractéris+ques  du  terminal  
5.  Intégrer  quelques  mécanismes  de  sécurité  

9
GRT5-M3.4-ASC-1
Le  protocole  SIP  de  base  (RFC  3261)  

q  Le  protocole  SIP  ne  définit  pas:  


1.  de  services  applica+fs  
2.  de  mécanisme  de  QoS  (Quality  of  Service)  
3.  de  mécanisme  de  contrôle  sur  le  flux  média  (e.g.  collecte  de  
DTMF,  interac+on  vocale  )  
4.  de  fonc+ons  de  taxa+on  

q  Mais  SIP  fournit  les  briques  nécessaires  pour  rendre  ces  
fonc+onnalités  

10
GRT5-M3.4-ASC-1
Plans  SIP    

q  Sépara+on  complète  entre  signalisa+on  et  plan  média/transfert  


q  SIP  est  conçu  pour  être  indépendant  de  l'architecture  réseau  
sous-­‐jacente  

Etablissement  d’appel    
(Signalisa*on)  

Flux  Média  (RTP)  

Accès/Collecte   Dorsal  IP   Accès/Collecte  

11
GRT5-M3.4-ASC-1
Principes de  SIP  

q  SIP  s’appuie  sur  un  concept  client/serveur.  


q  Forte  influence  des  protocoles  IETF  (HTTP/SMTP).    
q  Il  hérite  de  la  structure  protocolaire  de  HTTP  (requête/
réponse)  et  des  entêtes  de  SMTP  (From,  To,  …).    
q  codage  ASCII  et  codes  de  réponse  

q  Le  client  envoie  des  requêtes  au  serveur,  qui  lui  renvoie  
une  réponse.  
q  Adressage  SIP  du  type  URL  
q  Fait  appel  au  SDP  (Session  Descrip+on  Protocol)  
q   RFC  2327  est  u+lisé  pour  formater  le  message.  

12
GRT5-M3.4-ASC-1
Les  adresses  SIP  

q  Dis+nc+on  de  deux  types  d'adresses  :  


q  Address  of  record  =  adresse  logique  
q  Address  of  contact  =  adresse  IP  ou  FQDN  (permet  de  retrouver  l'adresse  IP  via  
DNS)  

q  Besoin  d'un  intermédiaire  réseau  pour  traduire  l'adresse  logique  


du  demandé  en  son  adresse  de  contact    
q  Théoriquement,  Il  est  possible  de  faire  établir  des  communica+ons  
point-­‐à  point  directement  entre  les  terminaux,  mais  cela  suppose  que  
l'appelant  connaisse  l'adresse  IP  courante  de  l'appelé.  
q  Nécessite  une  procédure  d'enregistrement  des  terminaux  auprès  du  réseau  
q  Cons+tue  une  base  pour  le  Nomadisme  

13
GRT5-M3.4-ASC-1
PLAN  

q  Introduc)on  
q  En)tés  SIP  
q  Messages  SIP  
q  Etablissement  d’un  appel  SIP  
q  Programma+on  de  services  SIP  
q  Comparaison  SIP  et  H.323  

14
GRT5-M3.4-ASC-1
Architecture  de  SIP  

q  Contrairement  à  H.323,  largement  fondé  sur  une  architecture  


physique,  le  protocole  SIP  s’appuie  sur  une  architecture  
purement  logicielle.  
q  SIP  est  un  protocole  d'égal  à  égal  (Peer-­‐to-­‐Peer).    
q  Les  extrémités  dans  une  session  sont  appelées  agents  u+lisateurs  
(User  Agents).    
q  Un  agent  u+lisateur  peut  avoir  un  des  rôles  suivants:  
1.  User-­‐Agent  Client  (UAC)  -­‐  Une  applica+on  cliente  qui  ini+e  une  requête  
SIP.  
2.  User-­‐Agent-­‐Server  (UAS)  -­‐  Une  applica+on  serveur  qui  contacte  
l'u+lisateur  quand  une  requête  SIP  est  reçue  et  qui  retourne  une  
réponse  à  la  demande  de  l'u+lisateur.  
15
GRT5-M3.4-ASC-1
Modèle  client/serveur  

q  Clients  
q  En*tés  qui  éme=ent  des  requêtes  SIP  
q  Ex:  User  Agent  Client  

q  Serveurs  
q  En*tés  qui  répondent  aux  requêtes  SIP  
q  Ex:  User  Agent  Server  

q  User  Agent  =  UAC  +  UAS  


q   En+té  à  la  fois  cliente  et  serveur  Implémentée  dans  IP-­‐phone,  PC  
mul+média…  

16
GRT5-M3.4-ASC-1
Architecture  SIP  

Serveur  proxy   Serveur  de  localisa*on  

Terminal  SIP  

Serveur  de  redirec*on   Serveur  d’enregistrement  

• De  plus  les  serveurs  SIP  peuvent  interopérer  avec  d'autres  services  applica+fs  tels  que  des  serveurs  LDAP,  
serveurs  de  localisa+on,  applica+on  base  de  données  ou  applica+on  XML.    
• Ces  services  applica+fs  fournissent  des  services  aux  extrémités  tels  que  l’annuaire,  le  service  
d’authen+fica+on  et  le  service  de  factura+on.    
17
GRT5-M3.4-ASC-1
Architecture  SIP  

Serveur  proxy   Serveur  de  localisa*on  

Terminal  SIP  

Serveur  de  redirec*on   Serveur  d’enregistrement  

les serveurs de redirection et proxy, qui facilitent le routage des messages de


signalisation et jouent le rôle d’intermédiaires,

18
GRT5-M3.4-ASC-1
Architecture  SIP  

Serveur  proxy   Serveur  de  localisa*on  

Terminal  SIP  

Serveur  de  redirec*on   Serveur  d’enregistrement  

les serveurs de localisation et d’enregistrement, qui ont pour fonction d’enregistrer ou


de déterminer la localisation des abonnés du réseau.

19
GRT5-M3.4-ASC-1
Terminal  SIP  
q  Le  terminal  est  l’élément  dont  dispose  l’u+lisateur  pour  appeler  et  être  
appelé.    
q  Il  doit  donc  permenre  de  composer  des  numéros  de  téléphone.  
q  Il  peut  se  présenter  sous  la  forme  d’un  composant  matériel  (un  téléphone)  ou  
d’un  composant  logiciel  (un  programme  lancé  à  par+r  d’un  ordinateur).  
q  Le  terminal  est  appelé  UA  (User  Agent)  et  est  cons+tué  de  deux  sous-­‐en+tés  
UAC  chargée  d’émenre  les  requêtes  et  UAS  qui  est  en  écoute,  reçoit  et  traite  
les  requêtes.    
q  L’associa+on  des  requêtes  et  des  réponses  entre  deux  en+tés  de  type  UA  
cons+tue  un  dialogue.  
User   Requête   User  
Agent   Agent  
Client   Server  
Réponse  

20
GRT5-M3.4-ASC-1
Terminal  SIP  
q  Par  analogie,  on  peut  remarquer  que  la  même  chose  se  produit  avec  le  
protocole  HTTP  dans  une  applica+on  Web  :    
q  un  u+lisateur  exploite  son  navigateur  comme  client  pour  envoyer  des  requêtes  et  
contacter  une  machine  serveur,  laquelle  répond  aux  requêtes  du  client.    

q  La  différence  essen+elle  par  rapport  aux  applica+ons  standards  u+lisant  HTTP  
est  qu’en  téléphonie  un  terminal  doit  être  à  la  fois  u+lisé  pour  joindre  un  
interlocuteur  et  pour  appeler.    
q  Chaque  terminal  possède  donc  la  double  fonc+onnalité  de  client  et  de  
serveur.  
q  La  communica+on  peut  être  clôturée  indifféremment  par  l’User  Agent  Client  
ou  l’User  Agent  Server.  
q  Parmi  les  clients  SIP  les  plus  réputés,  citons  notamment  les  suivants  :  
q  X-­‐Lite  Free  
q  Phone  Gaim  
q  Wengo,  SJPhone,  SNOM,….  
21
GRT5-M3.4-ASC-1
SIP Architecture

Request
Response
Media
SIP Redirect
Server Location Service
2
3

5
4
6
1
7
11
12 10
SIP Proxy
13 SIP Proxy
8
SIP Client 14 9

SIP Client
(User Agent Server)

22
GRT5-M3.4-ASC-1
Serveur  Registrar  
q  Deux  terminaux  peuvent  communiquer  entre  eux  sans  passer  
par  un  serveur  d’enregistrement,  à  la  condi+on  que  l’appelant  
connaisse  l’adresse  IP  de  l’appelé.    
q  Cene  contrainte  est  fas+dieuse,  car  un  u+lisateur  peut  être  mobile  et  
donc  ne  pas  avoir  d’adresse  IP  fixe,  par  exemple  s’il  se  déplace  avec  son  
terminal  ou  s’il  se  connecte  avec  la  même  iden+té  à  son  travail  et  à  son  
domicile.    
q  En  outre,  l’adresse  IP  peut  être  fournie  de  manière  dynamique  par  un  
serveur  DHCP.  

q  Le  serveur  d’enregistrement  (Registrar  Server)  offre  un  moyen  


de  localiser  un  correspondant  avec  souplesse,  tout  en  gérant  la  
mobilité  de  l’u+lisateur.    
q  Il  peut  en  outre  supporter  l’authen+fica+on  des  abonnés.  
23
GRT5-M3.4-ASC-1
Serveur  Registrar    
q  En+té  serveur  
q  Il  accepte  les  requêtes  REGISTER  qui  lui  permenent  d’enregistrer  
les  infos  concernant  un  u+lisateur  dans  une  base  de  donnée  
q  Le  client  lui  indique  sa  présence  et  sa  posi+on  de  localisa+on  
courante  dans  le  réseau  
q  Le  registrar  sauvegarde  cene  posi+on  en  l’enregistrant  auprès  
du  serveur  de  localisa+on.    
q  L'enregistrement  a  une  durée  de  vie  
q  Spécifiée  par  l'en-­‐tête  ‘Expire’    
q  Le  terminal  envoie  périodiquement  de  nouveaux  REGISTER  pour  maintenir  l'associa+on  dans  
le  réseau  

q  En  général,  co-­‐localisé  avec  un  Proxy  ou  Redirect  Server  


24
GRT5-M3.4-ASC-1
Serveur  Registrar    

q  L’enregistrement  d’un  u+lisateur  est  cons+tué  par  l’associa+on  


de  son  iden+fiant  et  de  son  adresse  IP.    
q  Un  u+lisateur  peut  s’enregistrer  sur  plusieurs  serveurs  
d’enregistrement  en  même  temps.    
q Dans  ce  cas,  il  est  joignable  simultanément  sur  l’ensemble  
des  posi+ons  qu’il  a  renseignées.  

25
GRT5-M3.4-ASC-1
Proxy  Server  
q  En+té  à  la  fois  cliente  et  serveur  
q  Il  accepte  des  requêtes  de  clients,  soit  en  y  répondant,  soit  en  les  passant  à  
d’autres  serveurs,  éventuellement  après  les  avoir  modifiés  
q  Ini+alement  conçu  pour  un  rôle  très  restreint    
1.  localiser  un  correspondant  ;  
2.  Authen*fica*on  des  abonnés  
3.  Routage  des  messages  SIP  
4.  ini*er,  maintenir  et  terminer  une  session  vers  un  correspondant.  

q  Son  rôle  s'est  considérablement  accru  depuis,  


q  Inser+on  de  la  localisa+on  géographique  de  l'usager,  d'informa+on  liée  à  la  taxa+on  …  
q  Invoca+on  de  serveurs  D'applica+on  …  

q  L'IETF  affiche  toujours  la  volonté  de  déporter  l'intelligence  dans  les  UA    
q  Possibilités  réduites  d'interven+on  d'un  proxy  sur  les  messages  SIP  
q  e.g.  aucune  manipula+on  du  body  des  messages  SIP…  
26
GRT5-M3.4-ASC-1
Proxy  Server  

q  En  contrepar+e,  le  serveur  proxy  est  une  en+té  beaucoup  plus  sollicitée  que  
le  serveur  de  redirec+on,  et  donc  plus  lourde  
q  Lorsqu’un  u+lisateur  demande  à  un  serveur  proxy  de  localiser  un  
correspondant,  ce  dernier  effectue  la  recherche  
q  Au  lieu  de  retourner  le  résultat  au  demandeur  (comme  le  ferait  un  serveur  de  
redirec+on),  il  u+lise  cene  réponse  pour  effectuer  lui-­‐même  l’ini+alisa+on  de  
la  communica+on  en  invitant  le  correspondant  à  ouvrir  une  session.  
q  Bien  que  fournissant  le  même  type  de  service  de  localisa+on  qu’un  serveur  
de  redirec+on,  un  serveur  proxy  va  donc  plus  loin  que  la  simple  localisa+on  en  
ini+ant  la  mise  en  rela+on  des  correspondants  de  façon  transparente  pour  le  
client.  
q  Il  peut  acheminer  tous  les  messages  de  signalisa+on  des  terminaux,  de  
l’ini+alisa+on  de  la  communica+on  à  sa  terminaison,  en  passant  par  sa  
modifica+on.  

27
GRT5-M3.4-ASC-1
Proxy  Server  

q  Les  serveurs  proxy  jouent  aussi  un  rôle  collabora+f,  puisque  les  
requêtes  qu’ils  véhiculent  peuvent  transiter  d’un  serveur  proxy  
à  un  autre,  jusqu’à  aneindre  le  des+nataire.    
q  Notons  que  le  serveur  proxy  ne  fait  jamais  transiter  de  données  
mul+médias  et  qu’il  ne  traite  que  les  messages  SIP.  

28
GRT5-M3.4-ASC-1
Proxy  Server  :  Trapèze  SIP  

DNS   Loca,on  Server  


Server  

DNS  
Registrar  
SIP  

Outgoing   Incoming  
Proxy   Proxy  
SIP   SIP   SIP  

SIP  
Origina+ng   Termina+ng  
User  Agent   RTP   User  Agent  

29
GRT5-M3.4-ASC-1
Triangle  SIP  

DNS   Loca,on  Server  


Server  

DNS  
Registrar  

Incoming  
Proxy  
SIP   SIP   SIP  

SIP  
Origina+ng   Termina+ng  
User  Agent   RTP   User  Agent  

30
GRT5-M3.4-ASC-1
SIP Peer to Peer!

SIP
Originating Terminating
User Agent RTP User Agent

31
GRT5-M3.4-ASC-1
Proxy  Server  

q  On  dis+ngue  deux  types  de  serveurs  proxy  :  


1.  Proxy  statefull,  qui  main,ent  pendant  toute  la  durée  des  sessions  
l’état  des  connexions.  
2.  Proxy  stateless,  qui  achemine  les  messages  indépendamment  les  
uns  des  autres,  sans  sauvegarder  l’état  des  connexions.  
q  Les  proxy  stateless  sont  plus  rapides  et  plus  légers  que  les  proxy  
statefull,  mais  ils  ne  disposent  pas  des  mêmes  capacités  de  
traitement  sur  les  sessions  

32
GRT5-M3.4-ASC-1
Proxy  Server  

q  Plusieurs  logiciels  implémentent  les  diverses  fonc+onnalités  des  


serveurs  SIP,  notamment  les  suivants  :  
q  SIP  Express  Router  (h?p://www.iptel.org/ser/)  ;  
q  Partysip  SIP  Proxy  Server  (h?p://www.nongnu.org/partysip/
partysip.html).  

q  Ces  deux  logiciels  libres,  respec+vement  sous  licence  GPL  et  
LGPL,  fonc+onnent  exclusivement  sur  plate-­‐forme  Linux.  
q  Une  solu+on  payante  et  propriétaire  de  Cisco,  Cisco  SIP  Proxy  
Server  (h?p://www.cisco.com/univercd/cc/td/doc/product/
voice/sipproxy/),  peut  également  être  installée.  

33
GRT5-M3.4-ASC-1
Redirect  Server  
q  Applica+on  serveur  
q  Le  serveur  de  redirec+on  (Redirect  Server)  agit  comme  un  
intermédiaire  entre  le  terminal  client  et  le  serveur  de  
localisa+on.    
q  Il  est  sollicité  par  le  terminal  client  pour  contacter  le  serveur  de  
localisa+on  afin  de  déterminer  la  posi+on  courante  d’un  
u+lisateur.  
q  A  la  récep+on  d'une  requête,  il  retourne  une  réponse  de  
redirec+on  avec  une  adresse  à  contacter  
q  Fournit  au  client  l'informa+on  sur  le  ou  les  prochains  sauts  qu'un  
message  doit  aneindre    
q  Ensuite  le  client  contacte  le  serveur  du  prochain  saut  ou  l'UAS  
directement  
34
GRT5-M3.4-ASC-1
Redirect  Server  

1.  L’appelant  envoie  une  requête  de  localisa+on  d’un  


correspondant  (il  s’agit  en  réalité  d’un  message  d’invita+on,  
qui  est  interprété  comme  une  requête  de  localisa+on)  au  
serveur  de  redirec+on.    
2.  Celui-­‐ci  joint  le  serveur  de  localisa+on  afin  d’effectuer  la  
requête  de  localisa+on  du  correspondant  à  joindre.    
3.  Le  serveur  de  localisa+on  répond  au  serveur  de  redirec+on,  
lequel  informe  l’appelant  en  lui  fournissant  la  localisa+on  
trouvée.    
q  Ainsi,  l’u+lisateur  n’a  pas  besoin  de  connaître  l’adresse  du  
serveur  de  localisa+on.  

35
GRT5-M3.4-ASC-1
Serveur  de  localisa*on  

q  Le  serveur  de  localisa+on  (Loca+on  Server)  joue  un  rôle  complémentaire  par  
rapport  au  serveur  d’enregistrement  en  permenant  la  localisa+on  de  
l’abonné.  
q  Ce  serveur  con+ent  la  base  de  données  de  l’ensemble  des  abonnés  qu’il  
gère.    
q  Cene  base  est  renseignée  par  le  serveur  d’enregistrement.  
q  Chaque  fois  qu’un  u+lisateur  s’enregistre  auprès  du  serveur  
d’enregistrement,  ce  dernier  en  informe  le  serveur  de  localisa+on.  
q  Presque  toujours,  le  serveur  de  localisa+on  et  le  serveur  d’enregistrement  
sont  implémentés  au  sein  d’une  même  en+té.  
q  On  parle  alors  souvent  non  pas  de  serveur  de  localisa)on,  mais  de  service  de  
localisa)on  d’un  serveur  d’enregistrement,  tant  ces  fonc)onnalités  sont  
proches  et  dépendantes.  

36
GRT5-M3.4-ASC-1
Serveur  de  localisa*on  
q  Le  fonc+onnement  d’un  serveur  de  localisa+on  est  analogue  à  
celui  d’un  serveur  DNS  dans  le  monde  Internet  :    
q  pour  joindre  un  site  Internet  dont  on  ne  connaît  que  le  nom,  il  faut  u+liser  un  
serveur  DNS,  qui  effectue  la  conversion  (on  parle  de  résolu+on)  du  nom  en  
adresse  IP.    
q  Ce  serveur  a  connaissance  d’une  mul+tude  d’adresses,  qu’il  peut  résoudre  parce  
qu’elles  appar+ennent  à  son  domaine  ou  qu’il  a  la  capacité  d’apprendre  
dynamiquement  en  fonc+on  des  échanges  qu’il  voit  passer.    
q  Dès  qu’un  nom  lui  est  inconnu,  il  fait  appel  à  un  autre  DNS,  plus  important  ou  
dont  le  domaine  est  plus  adéquat.    

q  De  la  même  manière,  les  serveurs  de  localisa+on  prennent  en  
charge  un  ou  plusieurs  domaines  et  se  complètent  les  uns  les  
autres.  

37
GRT5-M3.4-ASC-1
Gateway  SIP  

q  SIP  a  été  conçu  ini+alement  pour  les  réseaux  à  commuta+on  de  
paquets  de  type  IP,  mais  ses  u+lisateurs  peuvent  aussi  joindre  
des  terminaux  connectés  à  des  réseaux  de  nature  différente.  
q  il  est  nécessaire  de  menre  en  place  des  passerelles  (gateways),  
assurant  la  conversion  des  signaux  d’un  réseau  à  un  autre.  
q  La  GW  est  une  en+té  à  la  fois  cliente  et  serveur  
q  Type  par+culier  de  User  Agent  permenant  d’interfacer  un  réseau  
SIP  avec  un  réseau  u+lisant  un  autre  protocole  de  signalisa+on  
(ISUP…)  
q  Une  gateway  termine  le  canal  de  signalisa+on  SIP  et  parfois  aussi  
le  canal  RTP  audio/vidéo    
  38
GRT5-M3.4-ASC-1
En*tés  SIP  

q  Gateway  SIP  d’entreprise  


q  Appar+ent  à  l’entreprise  
q  Conversion  de  la  signalisa+on  SIP  en  
q  CAS  (Circuit  Asso+ated  Signaling)  si  téléphones  analogiques  

q  Q.931  si  téléphones  numériques  

q   Conversion  des  2  canaux  RTP  en  canal  64  Kbits/s  

q  Gateway  SIP  /  RTC  


q  Appar+ent  à  l’opérateur  RTC  
q  Conversion  de  la  signalisa+on  SIP  en  ISUP  
q  Conversion  des  2  canaux  RTP  en  canal  64  Kbits/s  

39
GRT5-M3.4-ASC-1
En*tés  SIP    

q  Gateway  SIP  /  H.323  


q  Appar+ent  à  l’entreprise  ou  à  l’opérateur  H.323  
q  Conversion  de  la  signalisa+on  SIP  en  H.323  
q  Si  l’UA  SIP  et  le  terminal  H.323  u+lisent  le  même  codec  
q  2  canaux  RTP  directs  entre  eux  

q  Si  l’UA  SIP  et  le  terminal  H.323  u+lisent  des  codecs  différents  
q  2  canaux  RTP  de  l’UA  SIP  vers  la  gateway  

q  2  canaux  RTP  de  la  gateway  vers  le  terminal  H.323  

40
GRT5-M3.4-ASC-1
Entités SIP

Téléphone PBX d’entreprise


analogique
Téléphones Gateway SIP Gateway
analogiques d’entreprise SIP/RTC
RTC
Téléphone
RNIS
PC avec SIP
Réseau SIP Réseau
Gateway H.323
SIP/H.323

SIP-Phones
PC avec H.323 Terminal H.323

41
GRT5-M3.4-ASC-1
URI  (Universal  Ressource  Iden*fier)  SIP  

q  Un  URI  définit  une  syntaxe  permenant  de  désigner  de  manière  
unique,  formelle  et  normalisée  une  ressource,  qu’il  s’agisse    
q  d’un  document  textuel,    
q  audio,    
q  vidéo    
q  ou  plus  généralement  d’une  en+té  logique  ou  physique.  

q  Une  ressource  décrite  par  un  URI  peut  être  déplacée  ou  même  
supprimée.    
q  L’URI  correspondant  n’en  conserve  pas  moins  de  manière  
permanente  la  valeur  descrip+ve  de  la  ressource.  

42
GRT5-M3.4-ASC-1
 
URI  (Universal  Ressource  Iden*fier)  SIP  
 
q  Le  format  d’une  adresse  SIP  (ou  URL  SIP)  respecte  la  RFC  3986  (nommée  
Uniform  Resource  Iden+fier:  Generic  Syntax)  
q  Un  UA  est  iden+fié  par  une  URL  SIP  
q  Format  dérivé  d’une  adresses  E-­‐mail:  «  sip:user@host  »    
q  “user”  peut  être  un  nom  d’u+lisateur  ou  un  n°  de  téléphone  
q  “host”  peut  être  un  nom  de  domaine,  un  nom  de  host,  ou  une  adresse  numérique  

q  Exemples  d’URL  SIP:  


q  sip:etudiant@ensa.ac.ma  
q  sip:mohamed@192.190.132.20  
q  sip:+212-­‐24-­‐44-­‐44-­‐44@ensa.ac.ma  
q  Mohamed  
q  +212524434547  

43
GRT5-M3.4-ASC-1
Avantages  adressage  SIP  

1.  L’adressage  est  indépendant  de  la  localisa+on  géographique  


des  abonnés  :    
q  Assurer  la  mobilité  de  ses  u+lisateurs,  et  donc  permenre  de  joindre  
quelqu’un  avec  une  adresse  SIP  unique.    
q  Portabilité  des  adresses  :  Le  réseau  peut  toutefois  adopter  un  plan  de  
numérota+on  selon  n’importe  quel  critère,  comme  la  localisa+on  
géographique,  sans  que  cela  soit  gênant.  

2.  Un  u+lisateur  peut  avoir  plusieurs  adresses  SIP  abou+ssant  


toutes  au  même  terminal.  
q  U+lisa+on  de  terminal  unique  pour  plusieurs  iden+fiants  

44
GRT5-M3.4-ASC-1
Localisa*on  et  résolu*on  d’une  adresse  SIP  

q  une  adresse  SIP  spécifie  un  u+lisateur  et  un  nom  de  domaine.  
q  Pour  localiser  l’u+lisateur:  
1.  il  faut  d’abord  contacter  le  serveur  gérant  le  domaine    
q  Si  la  par+e  indiquant  le  serveur  de  domaine  con+ent  une  adresse  IP,  ce  
serveur  est  joint  directement.    
q  À  défaut,  l’adresse  IP  du  serveur  sera  déterminée  après  une  résolu+on  DNS.  

2.  puis  solliciter  ce  serveur  pour  déterminer  la  posi+on  de  l’u+lisateur.  

45
GRT5-M3.4-ASC-1
L'enregistrement  
q  L'enregistrement  permet  au  terminal  de  no+fier  au  réseau  son  
adresse  de  contact  à  associer  avec  l'iden+té  logique  qu'il  sert.  
q  Permet  au  réseau  de  pouvoir  router  les  requêtes  à  des+na+on  
de  l'iden+té  logique  enregistrée.  
q  Plusieurs  terminaux  peuvent  enregistrer  la  même  adresse  
logique  
q  Une  iden+té  logique  peut  être  associée  à  plusieurs  adresses  de  contact  
q  Si  le  proxy  responsable  de  cene  iden+té  est  satefull,  à  l'arrivée  d'une  requête  
des+née  à  cene  iden+té  il  peut:  

q   Faire  du  forking  parallèle:  envoyer  la  requête  à  tous  les  terminaux  enregistrés  
(i.e.  toutes  les  adresses  de  contacts),  celui  qui  répond  le  premier  gagne.  
q  Faire  du  forking  séquen+el:  essayer  les  terminaux  un  à  un  jusqu'à  ce  qu'un  
réponde.  

46
GRT5-M3.4-ASC-1
Enregistrement  

q  L’u+lisateur    
q  A  besoin  de  s’enregistrer  auprès  du  Registrar  avant  de  pouvoir  par+ciper  
au  réseau  SIP  
q  Pour  cela,  l’UAC  envoie  une  requête  REGISTER  au  Registrar  
q  La  requête  REGISTER  con+ent  des  infos  concernant  l’u+lisateur  
q  URL  SIP,  adresse(s)  IP,  préférences…  

q  Indiquant  s’il  est  joignable  et  où  /  comment  le  joindre    

q  Le  Registrar  
q  Extrait  les  infos  de  la  requête  REGISTER  
q  Puis  stocke  ces  infos  dans  une  base  de  donnée  appelée  Loca+on  Service    

47
GRT5-M3.4-ASC-1
Enregistrement  

Registrar
1

48
GRT5-M3.4-ASC-1
Découverte  du  Registrar  
q  Dans  la  configura+on  de  l’UAC  
q  Adresse  IP  du  Registrar  
q  Nom  DNS  du  Registrar  
q  Grâce  à  l’u+lisa+on  d’une  adresse  mul+cast  
q  Envoi  de  la  requête  REGISTER  à  l’adresse  IP  mul+cast  iden+fiant  l’ensemble  des  
Registrars  du  réseau  
REGISTER sip:172.18.192.232 SIP/2.0
Via: SIP/2.0/UDP 10.80.17.134:5060;branch=z9hG4bK776asdhds
From: sip:15691@172.18.192.232
To: sip:15691@172.18.192.232
Call-ID: c2943000-1405d-666-382e3031@10.80.17.134
CSeq: 100 REGISTER
Contact: <sip:15691@10.80.17.134:5060>
Expires: 3600
Content-Length: 0

REGISTER sip:172.18.192.232 SIP/2.0


Via: SIP/2.0/UDP 10.80.17.134:5060;branch=z9hG4bK776asdada
From: sip:bgracely@172.18.192.232
To: sip:bgracely@172.18.192.232
Call-ID: c2943000-2405d-666-382e3031@10.80.17.134
CSeq: 100 REGISTER
Contact: <sip:bgracely@10.80.17.134:5060>
Expires: 3600
Content-Length: 0
49
GRT5-M3.4-ASC-1
Registrar  

q REGISTER  sip:192.168.3.3  SIP/2.0  


Via:  SIP/2.0/UDP  127.0.0.1:4524;branch=z9hG4bK-­‐
azw0uuow2h5q;rport  
From:  "  Mohamed"  <sip:100@192.168.3.3>;tag=ctder1wfv3  
To:  "  Mohamed"  <sip:100@192.168.3.3>  
Call-­‐ID:  5f028447c866-­‐hkzr8tvkarws@snomSo„-­‐000413FFFFFF  
CSeq:  1  REGISTER  
Max-­‐Forwards:  70  
Contact:  <sip:100@127.0.0.1:4524;line=ojn9itpa>;  

50
GRT5-M3.4-ASC-1
Registrar

q  L’enregistrement n’est pas requis pour initier des appels


q  L’enregistrement est requis pour recevoir des appels
q  L’@ du serveur registrar est indiquée à la première ligne
q  REGISTER sip:192.168.3.3 SIP/2.0
q  Via: indique le protocole de transport de Register :
q  Via: SIP/2.0/UDP
q  from: indique l’@ de l’entité origine de Register
q  From: " Mohamed" <sip:100@192.168.3.3>;
q  to: indique la meme @ vue que l’utilisateur s’enregistre lui-même
q  To: " Mohamed" <sip:100@192.168.3.3>
q  Call-Id : indique l’identificateur des enregistrements du User Agent
q  Call-ID: 5f028447c866-hkzr8tvkarws@snomSoft-000413FFFFFF

51
GRT5-M3.4-ASC-1
Proxy  server  
q  Rôle  

q Recevoir  des  requêtes  SIP  

q Traiter  chaque  requête  SIP  


q  En  envoyant  une  réponse  SIP  

q  En  relayant  la  requête  SIP  vers  sa  des+na+on  

q   Déterminer  le  next-­‐hop  


q  UAS,  Proxy  server  ou  Redirect  server  

q  Consulta+on  du  Loca+on  Service  

q   Forwarder  la  requête  SIP  

q   Aucune  ac+on  sur  les  canaux  RTP  


52
GRT5-M3.4-ASC-1
Découverte  du  Proxy  server  

q  Outbound  proxy  


q  Proxy  server  par  défaut  où  l’UAC  doit  envoyer  les  requêtes  
q  Dans  la  configura+on  de  l’UAC  
q  Adresses  IP  d’un  Proxy  server  primaire  et  d’un  secondaire  

q  Noms  DNS  d’un  Proxy  server  primaire  et  d’un  secondaire  

q  Incoming  proxy  


q  Proxy  server  vers  où  envoyer  les  réponses  
q  Récupéra+on  du  domaine  DNS  à  par+r  de  l’URL  SIP  (from:)    

53
GRT5-M3.4-ASC-1
Proxy  server  stateless  vs  statefull  

q  Stateless  
q  Aucun  état  des  messages  SIP  échangés  n’est  mémorisé  
q  Chaque  message  SIP  est  traité  à  par+r  de  son  contenu  
q  Aucun  +mer  donc  aucune  retransmission  de  message  SIP  

q  Statefull  
q  Un  état  des  messages  SIP  échangés  est  mémorisé  
q  Chaque  message  SIP  est  traité  en  tenant  compte  de  cet  état  
q  Timer  donc  retransmission  de  message  SIP  sur  expira+on  

54
GRT5-M3.4-ASC-1
Stateless  Proxy  

q  Proxy  stateless  ou  "transac+on  stateless«    


q  Simple  relais  de  messages  SIP  (routage)  
q  Ne  stocke  pas  les  états  des  transac+ons  
q  Ne  peut  pas  "forker«    

q   Si  plusieurs  adresses  de  contacts  enregistrées,  choisi  une  seule  
q  Ne  filtre  et  ne  génère  pas  les  retransmission  

55
GRT5-M3.4-ASC-1
Statefull  Proxy  

q  Statefull  Proxy  ou  "transac+on  statefull"  Proxy  


q  Stocke  les  états  des  transac+ons  en  cours  (UAC,  n  UAS)  
q  Gère  les  retransmissions  
q  Peut  "forker«    
q  Envoyer  la  requête  à  plusieurs  adresses  de  contacts  

q  Deux  types  de  forking  existent:  parallèle  et  séquen+els  

56
GRT5-M3.4-ASC-1
Redirect  server  
q  Rôle  
q  Recevoir  des  requêtes  SIP  

q  Traiter  chaque  requête  SIP  

q  En  envoyant  une  réponse  SIP  

q Où  l’adresse  de  des+na+on  (to:)  est  remplacée  par  zéro  


ou  plusieurs  nouvelles  adresses  
q  Remplacement  de  l’adresse  demandée  par  une  ou  plusieurs  
autres  adresses  
q  Consulta+on  du  Loca+on  Service    

57
GRT5-M3.4-ASC-1
Loca*on  service  
q  Contenu  
q  Infos  sur  les  u+lisateurs  
q  Infos  sur  les  Proxy  servers  et  les  Gateways  

q  Interface  avec  les  serveurs  SIP    


q  Pas  normalisée  
q  LDAP  (Lightweight  Directory  Access  Protocol,  RFC  1777)  préconisé  
q  JDBC  (Java  DataBase  Connec+vity)…  

q  Accès  par  les  serveurs  SIP  


q  Registrar  :    mise  à  jour  
q  Proxy  server  :    consulta+on  
q  Redirect  server  :    consulta+on  
58
GRT5-M3.4-ASC-1
L'authen*fica*on  SIP  

q  Basée  sur  l'authen+fica+on  HTTP  (RFC2617)  


q  Un  mot  de  passe  est  partagé  entre  l'UA  et  le  serveur  
q  Ce  mot  de  passe  n'est  jamais  véhiculé  dans  les  messages  SIP  
q  Mécanisme  :  
1.  A  la  récep+on  d'une  requête  SIP,  le  serveur  demande  à  l'UA  de  s'authen+fier  en  répondant  
par  un  code  401  (ou  code  407)  
q  Cene  réponse  con+ent  un  "challenge"  (chaine  de  caractères)  
2.  L'UA  réémet  la  requête  en  incluant  la  réponse  à  ce  "challenge«    
q  La  réponse  est  générée  à  par+r  du  challenge  et  du  mot  de  passe  
3.  Le  serveur  génère  également  de  son  côté  la  réponse  à  ce  "challenge"  et  la  compare  à  la  
réponse  reçue  de  l'UA  
q  S    i  les  deux  valeurs  correspondent  alors  l'UA  est  authen+fié,  la  requête  est  traitée  

59
GRT5-M3.4-ASC-1
Serveurs  SIP  
Domaine  auprès  
duquel  l'usager  doit  
s'authen+fier  
REGISTER  
To:  Etudiant<sip:Etudiant@ensa.ac.ma>  
From:  Etudiant<sip:Etudiant@ensa.ac.ma>  
Via:  SIP/2.0/TCP  host2.ensa.ac.ma  
Contact:  <sip:Etudiant@host2.ensa.ac.ma>   Registrar    
(authen+ca+on  Server)  
 
User  Agent   401  Unauthorized  

To:  Etudiant<sip:Etudiant@ensa.ac.ma>  
From:  Etudiant<sip:Etudiant@ensa.ac.ma>  
Via:  SIP/2.0/TCP  host2.ensa.ac.ma  
WWW-­‐Authen+cate:  Digest  realm=«  ensa.ac.ma",  
nonce="892cf55087d88f122088da39aaf66db2",   "Challenge"  :  chaine  
algorithm=MD5   aléatoire  de  
caractères  

Algorithme  à  u+liser  
pour  la  réponse  au  
"Challenge"  

Seuls  certains  en-­‐têtes  et  


GRT5-M3.4-ASC-1 paramètres  sont  représentés   60
Serveurs  SIP  
Réponse  au  Challenge  
REGISTER  
To:  Etudiant<sip:Etudiant@ensa.ac.ma>  
From:  Etudiant<sip:Etudiant@ensa.ac.ma>  
Via:  SIP/2.0/TCP  host2.ensa.ac.ma  
Contact:  <sip:Etudiant@host2.ensa.ac.ma>   Registrar    
Authoriza+on:  Digest  username=“Etudiant",   (authen+ca+on  Server)  
realm=“ensa.ac.ma",    
User  Agent   nonce="892cf55087d88f122088da39aaf66db2",  
uri="  sip:Etudiant@ensa.ac.ma  ",  
response="e867f9710021a6e4aaa1e3fd18d13186",  
algorithm=MD5  

200  OK  

To:  Etudiant<sip:Etudiant@ensa.ac.ma>  
From:  Etudiant<sip:Etudiant@ensa.ac.ma>  
Via:  SIP/2.0/TCP  host2.ensa.ac.ma  
Contact:  <sip:Etudiant@host2.ensa.ac.ma>  

Seuls  certains  en-­‐têtes  et  


GRT5-M3.4-ASC-1 paramètres  sont  représentés   61
PLAN  

q  Introduc)on  
q  En)tés  SIP  
q  Messages  SIP  
q  Etablissement  d’un  appel  SIP  
q  Programma+on  de  services  SIP  
q  Comparaison  SIP  et  H.323  

62
GRT5-M3.4-ASC-1
Les  messages  SIP  

q  Les  messages  SIP  sont  décrits  dans  la  RFC  822  :  
q  définit  la  syntaxe  à  la  fois  des  requêtes  et  des  réponses.    
q  très  forte  influence  des  autres  protocoles  de  l’IETF,  principalement  HTTP  
et  SMTP.    

q  Le  format  des  requêtes  et  réponses  est  en  effet  similaire  à  celui  
u+lisé  dans  le  protocole  HTTP  
q  Les  en-­‐têtes  s’apparentent  à  celles  u+lisées  dans  le  protocole  
SMTP.    
q  On  y  retrouve  par  ailleurs  le  concept  d’URL.  

63
GRT5-M3.4-ASC-1
Format  général  des  messages  SIP  

q  Les  messages  SIP  sont  codés  en  u+lisant  la  syntaxe  de  message  
HTTP/1.1  (RFC  2068).  
q  Qu’il  soit  une  requête  ou  une  réponse  à  une  requête,  un  
message  SIP  doit  respecter  le  format  suivant  :    
q  Ligne  de  début  

q  Plusieurs  entêtes  

q  Corps  

64
GRT5-M3.4-ASC-1
Les  messages  SIP  

1.  La  première  par+e  est  soit  une  ligne  de  requête,  s’il  s’agit  
d’une  requête,  soit  une  ligne  d’état,  s’il  s’agit  d’une  réponse.    
2.  La  seconde  par+e  rassemble  les  en-­‐têtes  du  message.  
3.  La  troisième  con+ent  le  corps  du  message  qui  est  Op+onnel  
q  La  spécifica+on  du  protocole  limite  le  nombre  d’en-­‐têtes  
possible,  ce  qui  permet  de  borner  le  temps  de  lecture  ou  
d’écriture  des  messages.    
q  En  théorie,  36  en-­‐têtes  peuvent  être  u+lisés  au  maximum.    
q  Dans  la  pra+que,  un  peu  plus  d’une  dizaine  est  u+lisée  simultanément.  

65
GRT5-M3.4-ASC-1
Les  messages  SIP  
1.  Le  client  envoie  une  requête  à  un  serveur  
q  Une  requête  véhicule  le  nom  de  la  méthode  à  invoquer  

2.  Le  serveur  répond  au  client  par  une  réponse  SIP  


q  Un  échange  requête  +  réponse(s)  associée(s)  cons+tue  une  
transac+on  SIP  
q  Certains  paramètres  généraux  peuvent  être  partagés  à  la  fois  
par  les  messages  de  requête  et  par  les  messages  de  réponse.  
q  Les  messages  appartenant  à  une  transac+on  ont  un  unique  
iden+fiant,  Cseq  

66
GRT5-M3.4-ASC-1
Les  messages  SIP  
q  Certaines  méthodes  établissent  des  dialogues  SIP  
q  Un  dialogue  SIP  est  un  échange  de  messages  entre  deux  UAs  
ayant  le  même  iden*fiant  
q  Plusieurs  transac+ons  peuvent  être  échangées  au  cours  d'un  
dialogue  
q  Au  cours  d'un  même  dialogue  les  rôles  client  et  serveur  sont  
interchangeable  
q  Seules  certaines  requêtes  peuvent  créer  un  dialogue  SIP.    
q  Dans  la  RFC  3261,  seule  la  requête  INVITE  peut  créer  un  
dialogue  
q  Une  requête  SIP  peut  donner  lieu  à  la  créa+on  de  plusieurs  
dialogues  SIP   67
GRT5-M3.4-ASC-1
Format  général  des  messages  SIP  

q  Ligne  de  début  


q  Plusieurs  entêtes  
q  Corps  

La  RFCs  3261  précise  pour  chaque  en-­‐tête  les  messages  


dans  lesquels  il  peut  être  présent,  op+onnellement  ou  
obligatoirement  
68
GRT5-M3.4-ASC-1
Exemple de requête

Ligne de début INVITE sip:mohamed@grt.ma SIP/2.0


Entête général Via: SIP/2.0/UDP station1.ensa.ma:5060
From: Mostafa<sip:Mostafa@ensa.ma>
To: Mohamed<sip:mohamed@grt.ma>
Call-Id: 23456789@station1.ensa.ma
Cseq: 1 INVITE
Entête d’entité Content-type: application/sdp
Content-length: 162

Corps v=0
o = Mostafa 123456 123456 IN IP4 station1.ensa.ma
s = annonce importante
c = IN IP4 192.190.132.20
t=00
m = audio 45450 RTP/AVP 0

69
GRT5-M3.4-ASC-1
Structure  des  messages  SIP  
q  Headers  
q  "A  header  is  a  component  of  a  SIP  message  that  conveys  informa,on  
about  the  message«    

q  Body  (op+onal)  


q  Transporte  des  données  non  SIP  (ex  SDP)  

q  Types  de  messages  SIP  


1.  Requêtes  (ou  méthode)  
q  "A  SIP  message  sent  from  a  client  to  a  server,  for  the  purpose  of  
invoking  a  par,cular  opera,on«    
2.  Réponses  (provisional  or  final)  
q   "A  SIP  message  sent  from  a  server  to  a  client,  for  indica,ng  the  status  
of  a  request  sent  from  the  client  to  the  server"  
70
GRT5-M3.4-ASC-1
Entêtes  des  messages  SIP  
q  Rôle  
q  Fournir  des  infos  sur  le  message  
q  Permenre  le  traitement  du  message  
q  Types  d’entêtes  
1.  En-­‐têtes  généraux,  qui  peuvent  être  u+lisés  indifféremment  pour  des  messages  de  
requête  ou  des  messages  de  réponse.  
2.  En-­‐têtes  de  requête,  exclusivement  employés  pour  les  messages  de  requête.  
3.  En-­‐têtes  de  réponse,  exclusivement  employés  pour  les  messages  de  réponse.  
4.  En-­‐têtes  d’en+té,  qui  donnent  des  informa+ons  descrip+ves  sur  le  corps  du  
message.  
q  Structure  générale  d’un  entête  
q  Plusieurs  champs  
q  Chaque  champs  obéit  à  un  format  général  

71
GRT5-M3.4-ASC-1
Genres  d’en-­‐tetes  

q Deux  genres  d'entêtes  


1.   Bout  en  bout:  échangés  entre  Uas    terminaux  

q   Exemples:  Subject,  Accept,  Allow  …etc.  


2.  Saut  par  saut  :  subissent  un  traitement  à  chaque  noeud  

q   Exemples:  Route  et  Via  

72
GRT5-M3.4-ASC-1
Entête  général  
q  U+lisa+on  
q  Toujours  présent  
q  Requêtes    

q  Réponses  

q  Rôle  
q  Con+ent  les  infos  de  base  permenant  le  traitement  du  message  
q  Syntaxe  Champs    
q  Nom_du_champs  :  valeur_du_champs  CRLF    

q  Ex.  From:  «  Etudiant"  <sip:100@192.168.3.3>  


q   From  est  un  header  

q "  Etudiant"  <sip:100@192.168.3.3>  est  la  valeur  du  header  

73
GRT5-M3.4-ASC-1
Entête  général:  Champs  obligatoires  

q  Via  :  
q  Obligatoire    

q  Con+ent  les  adresses  des  serveurs  traversés  par  la  requête.  

q  Permet  d'éviter  les  boucles  

q  Sert  pour  le  routage  des  réponses.  

q  Chaque  en+té  qui  émet  ou  relaye  un  message  SIP  insère  un  
Via  afin  de  prévenir  les  boucles  et  d’indiquer  le  chemin  de  la  
réponse  
q Exemlple  :  SIP/2.0/UDP  host_émeneur:port_UDP  

74
GRT5-M3.4-ASC-1
Entête  général:  Champs  obligatoires  

q  From  
q  Obligatoire    

q  Con+ent    
q  une  URI  iden+fiant  l'ini+ateur  du  message    
q  et  tag  Permenant  l'iden+fica+on  du  dialogue  (From  tag)  

q Exemple  :  Nom  <URL_SIP_de_l’émeneur_de_la_requête>  

75
GRT5-M3.4-ASC-1
Entête  général:  Champs  obligatoires  

q  To  
q  Obligatoire    

q  con+ent    
q  une  URI  iden+fiant  le  des+nataire  ini+al  du  message    
q  et  tag  permenant  l'iden+fica+on  du  dialogue  (To  tag)  
q Exemple  :  Nom  <URL_SIP_du_récepteur_de_la_requête>  

76
GRT5-M3.4-ASC-1
Entête  général:  Champs  obligatoires  

q  Call-­‐ID  
q  Obligatoire    

q  iden+fiant  unique  de  transac+on  

q  Chaîne_de_caractères@host_émeneur  

q  Les  messages  appartenant  à  une  transac+on  ont  un  unique  


iden+fiant,  Call  id  

77
GRT5-M3.4-ASC-1
Entête  général:  Champs  obligatoires  

q   Cseq  
q   Numéro  Type_de_requête  

q   Le  numéro  est  incrémenté  à  chaque  nouvelle  


requête    

78
GRT5-M3.4-ASC-1
Champs  obligatoires  :  Exemple  

Via:  SIP/2.0/UDP  sta+on1.ensa.ac.ma:5060  


From:  etud1<sip:etud1@ensa.ac.ma>  
To:  Ali<sip:ali@fst.ac.ma>  
Call-­‐Id:  23456789@sta+on1.ensa.ac.ma  
Cseq:  1  INVITE  

79
GRT5-M3.4-ASC-1
Les entêtes généraux  

Certains  entêtes  peuvent  se  trouver  dans  


les  requêtes  et  réponses  SIP  
q  Accept   q  From  

q  Accept-­‐Encoding   q  Oraganiza+on  

q  Accept-­‐language   q  Record-­‐Route  

q  Authoriza+on   q  Require  

q  Call-­‐ID   q  Supported  

q  Contact   q  Timestamp  

q  Cseq   q  To  

q  Date   q  User  Agent  


q  Via  
q  MIMEversion  

80
GRT5-M3.4-ASC-1
Entête  de  requête  

q  U+lisa+on  
q  Parfois  présent  
q  Requêtes    

q  Rôle  
q  Con+ent  les  infos  supplémentaires  à  des+na+on  du  serveur  SIP  (UAS)  
q  Permenant  le  traitement  de  la  requête  par  celui-­‐ci  

q  Champs  
q  Authoriza+on,  Contact,  Hide,  Max-­‐Forward,  Organiza+on,  Priority,  Proxy-­‐
Authoriza+on,  Proxy-­‐Require,  Route,  Require,  Response-­‐Key,  Subject,  
User-­‐Agent  

81
GRT5-M3.4-ASC-1
Entête  de  réponse  

q  U+lisa+on  
q  Parfois  présent  
q  Réponses    

q  Rôle  
q  Con+ent  les  infos  supplémentaires  ajoutées  par  serveur  SIP  (UAS)  
q  Permenant  le  traitement  de  la  réponse  

q  Champs  
q  Allow,  Proxy-­‐Authoriza+on,  Retry-­‐A„er,  Server,  Unsupported,  Warning,  
WWW-­‐Authen+cate  

82
GRT5-M3.4-ASC-1
Entête  d’en*té  

q  U+lisa+on  
q  Toujours  présent  
q  Requêtes  
q  Réponses    

q  Rôle  
q  Définit  le  type  et  le  format  des  infos  contenues  dans  le  corps  du  message  

q  Champs  
q  Content-­‐Encoding,  Content-­‐Length,  Content-­‐Type    

83
GRT5-M3.4-ASC-1
Corps  des  messages  SIP    
q  U+lisa+on  
q  Parfois  absent  
q  Rôle  
q  Fournir  suffisamment  d’infos  pour  permenre  la  par+cipa+on  à  une  session  
mul+média  

q  Un  exemple  de  body  :  Session  Descrip+on  Protocol  (SDP)  


q  Véhicule  les  paramètres  de  la  session  média  entre  terminaux  SIP  
q  Codec,  vitesse  d’échan+llonage  

q  Des+na+on  (adresse  IP,  port  UDP)  

q  Nom  de  la  session  

q  Timestamps  de  début  et  fin  de  session  

q  Codage  en  SDP  


q  Champs  v,  o,  s,  c,  t,  m,…  

84
GRT5-M3.4-ASC-1
Corps  des  messages  SIP    

q  D'autres  types  sont  possibles  permenant  de  nombreuses  


applica+ons  
q  Informa,ons  de  Présence  
q  Informa,ons  liée  à  la  ges,on  de  conférences  
q  Informa,ons  de  localisa,on  
q  Messages  ISUP  (protocole  de  commande  RTC)  (SIP-­‐I  ou  SIP-­‐T)  
q  Photos  iden,fiant  les  par,cipants  à  une  session  
q  …  

85
GRT5-M3.4-ASC-1
Principaux  champs  du  corps  
q  v(ersion  SDP)  
q  o(rigin)  
q  Username:  nom  de  l’ini+ateur  de  la  session  
q  SessionID:  la  RFC  2327  recommande  d’u+liser  un  +mestamp  NTP  
q  Version:  version  de  la  session  
q  Network  type:  IN  
q  Address  type:  IP4  ou  IP6  
q  Address:  adresse  IP  de  l’ini+ateur  de  la  session  
q  s(ession  name)  
q  c(onnec*on  informa*on)  
q  Connec+on  type:  IN  
q  Network  type:  IP4  
q  Connec+on  address:  adresse  IP  de  l’ini+ateur  de  la  session  

86
GRT5-M3.4-ASC-1
Principaux  champs  du  corps  

q  t(ime  of  the  session)  


q  Timestamp  NTP  de  début  de  session  en  représenta+on  décimale  
q  Timestamp  NTP  de  fin  de  session  en  représenta+on  décimale  

q  m(edia)  
q  Media  type:  audio  
q  Transport  port:  n°  de  port  UDP  
q  Transport  protocol:  RTP  
q  Media  format:  codec  (ex:  AVP  =  G.711  loi  m)  

87
GRT5-M3.4-ASC-1
Exemple  de  corps  de  message  SIP  

v  =  0  
o  =  Etudiant  123456  123456  IN  IP4  sta,on1.ensa.ac.ma    
s  =  annonce  importante  
c  =  IN  IP4  193.188.23.16  
t  =  0  0  
m  =  audio  52140  RTP/AVP  0  

88
GRT5-M3.4-ASC-1
q  Les  requêtes  SIP  

q  Les  réponses  SIP  

89
GRT5-M3.4-ASC-1
Requêtes  SIP  
q  Terminologie  
q  Les  requêtes  sont  appelées  Méthodes  

q  Requêtes  de  base  


1.  REGISTER,    
2.  INVITE,    
3.  ACK,    
4.  OPTIONS,    
5.  CANCEL,    
6.  BYE  

q  Requêtes  addi+onnelles  


q  En  cours  de  standardisa+on  
q  INFO,  PRACK,  SUBSCRIBE,  UNSUBSCRIBE,  REFER,  MESSAGE,  COMET  
90
GRT5-M3.4-ASC-1
Requêtes  de  base  
q  REGISTER  :  Indica+on  par  l’UA  au  Registrar  de  son  adresse  IP  et  
de  l’URL  (ou  son  nom  de  domaine)  pour  laquelle  il  souhaite  
recevoir  des  appels  (associe  une  adresse  logique,  permanente,  à  
une  adresse  de  contact  représentant  la  localisa+on  courante)    
q  INVITE  :  établit  une  session  /  modifie  les  paramètres  d'une  
session  établie  entre  UAs  
q  ACK  :  U+lisée  pour  acquiner  une  réponse  finale  à  la  requête  
INVITE.  confirme  l'établissement  d'une  session  
q  OPTIONS  :  U+lisée  pour  demander  à  un  terminal  ou  serveur  les  
capacités  supportées  (extensions,  codecs  …etc.)  
q  CANCEL  :  annule  une  requête  INVITE  non  répondue  
q  BYE  :  termine  une  session  
91
GRT5-M3.4-ASC-1
Exemple de requête

Ligne de début INVITE sip:mohamed@grt.ma SIP/2.0


Entête général Via: SIP/2.0/UDP station1.ensa.ma:5060
From: Mohamed@grt.ma
To : Mostafasip:Mostafa@ensa.ma
Call-Id: 23456789@station1.ensa.ma
Cseq: 1 INVITE
Entête d’entité Content-type: application/sdp
Content-length: 162

Corps v=0
o = Mostafa 123456 123456 IN IP4 station1.ensa.ma
s = annonce importante
c = IN IP4 192.190.132.20
t=00
m = audio 45450 RTP/AVP 0

92
GRT5-M3.4-ASC-1
Les  Réponses  SIP  

q  Les  réponses  SIP  indiquent  


q   Soit  une  informa+on  de  progression  d’appel  
q   Soit  une  informa+on  d’état  final  

q  Syntaxe  empruntée  à  HTTP  


q  Les  réponses  SIP  con+ennent  
q  Numéro  'xyz'  +  texte  explica+f  
q  Un  code  d’état  (Status  Code)  qui  est  un  en+er  sur  3  chiffres  
q  Une  raison  (Reason-­‐Phrase)  qui  décrit  textuellement  la  raison  

93
GRT5-M3.4-ASC-1
Les  réponses  SIP  

q  1yz  Provisional  :  Le  traitement  de  la  requête  est  en  cours  
q  2yz  Success:  La  requête  a  été  bien  reçue,  comprise  et  acceptée  
(ex  :  200  OK)  
q  3yz  Redirec*on:  Redirec+on  vers  une  autre  en+té,  d'autres  
ac+ons  devraient  être  entreprises    
q  4yz  Request  failure  :  Erreur  client,  la  requête  est  syntaxiquement  
erronée  ou  n‘a  pu  être  traitée  avec  succes  
q  5yz  Server  failure:  Le  serveur  n'a  pu  traiter  une  requête  valide  
q  6yz  Global  Failure:  la  requête  ne  peut  être  traitée  par  aucun  
serveur  

94
GRT5-M3.4-ASC-1
Codes  d’état  et  raisons  

q  1xx  (Informa+onal)  


q  Trying,  ringing,  Call  is  being  forwarded,  Queued,…  
q  2xx  (Success)  
q  OK,…  
q  3xx  (Redirec+on)  
q  Moved  permanently,  Moved  temporarily,…  

q  4xx  (Client  error)  


q  Bad  request,  Unauthorized,  Not  found,  Busy,…  
q  5xx  (Server  error)  
q  Server  error,  Not  implemented,  Bad  gateway,…  

q  6xx  (Global  failure)  


q  Busy  everywhere,  Does  not  exist  anywhere,…  
95
GRT5-M3.4-ASC-1
Exemple de réponse

Ligne début SIP/2.0 200 Ok


Entête général Via: SIP/2.0/UDP station1.ensa.ma:5060
From: Mostafa<sip:mostafa@ensa.ma>
To: Mohamed<sip:mohamed@grt.ma>
Call-Id: 23456789@station1.ensa.ma
Cseq: 1 INVITE
Entête d’entité Content-type: application/sdp
Content-length: 162

Corps v=0
o = Mostafa123456 123456 IN IP4 station1.ensa.ma
s = annonce importante
c = IN IP4 193.188.23.16
t=00
m = audio 52140 RTP/AVP 0

96
GRT5-M3.4-ASC-1
Fiabilisa*on  des  transmissions  

q  Nécessaire  lorsque  le  protocole  de  transport  n'est  pas  fiable:  
UDP  
q  Dans  la  RFC  3261  la  transmission  des  requêtes  et  de  la  réponse  
200  OK  à  l'INVITE  sont  fiabilisés.  
q  La  réponse  200  OK  est  fiabilisée  avec  la  requête  ACK  

97
GRT5-M3.4-ASC-1
PLAN  

q  Introduc)on  
q  En)tés  SIP  
q  Messages  SIP  
q  Etablissement  d’un  appel  SIP  
q  Programma+on  de  services  SIP  
q  Comparaison  SIP  et  H.323  

98
GRT5-M3.4-ASC-1
 Direct  signalling  
UA1   UA2  
sip  :etud1@ensa.ac.ma   sip  :etud2@ucam.ac.ma  

INVITE  
From,  To,  Via,  Call-­‐ID,  Cseq,  SDP  
180  Ringing  

200  OK  

ACK  

Media  Flows  over  RTP  

BYE  

200  OK  
99
GRT5-M3.4-ASC-1
Réponses  1xx  

q  Informa+on  
q  100  Trying  
q  180  Ringing  
q  181  Call  forwarding  
q  182  Queued  for  service  
q  183  Session  progress  

q  Succès  
q  200  OK  

100
GRT5-M3.4-ASC-1
Réponses  100  vs  180  

q  100  Trying  (fait  la  différence  entre  un  state  full  et  state  less  proxy  
server)  
q  Générée  par  un  UAS  ou  un  Proxy  server  
q  Sans  corps  
q  Jamais  propagée  de  proche  en  proche  (hop-­‐by-­‐hop)  
q  Analogue  à  Q.931  Call  Proceeding  

q  180  Ringing  


q  Générée  par  un  UAS  
q  Propagée  de  proche  en  proche  vers  l’UAC  
q  Analogue  à  Q.931  Aler+ng  

101
GRT5-M3.4-ASC-1
Réponses  3xx  

q  Redirec+on  
q  300  Mul+ple  choices  
q  301  Moved  permanently  
q  302  Moved  temporarily  
q  305  Use  proxy  
q  380  Alterna+ve  service  

102
GRT5-M3.4-ASC-1
Réponses  4xx  
q  Erreur  de  requête  client  
q  400  Bad  request  
q  401  Unauthorized  
q  402  Payment  required  
q  403  Forbidden  
q  404  Not  found  
q  405  Method  not  allowed  
q  406  Not  acceptable  
q  407  Proxy  authen+fica+on  request  
q  408  request  +meout  
q  409  Conflict  
q  410  Gone  
q  411  Length  required  
q  413  Request  en+ty  too  large  
q  414  Request-­‐URI  too  long  
103
GRT5-M3.4-ASC-1
Réponses  4xx  (suite)  

q  Erreur  de  requête  client  


q  415  Unsupported  media  
q  420  Bad  extension  
q  421  Extension  required  
q  480  Temporarily  unavailable  
q  481  Call  leg/transac+on  does  not  exist  
q  482  Loop  detected  
q  483  Too  many  hops  
q  484  Uncomplete  address  
q  485  Ambiguous  
q  486  Busy  here  
q  487  Request  cancelled  

104
GRT5-M3.4-ASC-1
Réponses  5xx  

q  Erreur  serveur  


q  500  Server  internal  error  
q  501  Not  implemented  
q  502  Bad  gateway  
q  503  Service  unavailable  
q  504  Gateway  +meout  
q  505  Version  not  supported  

105
GRT5-M3.4-ASC-1
Réponses  6xx  

q  Echec  global  


q  600  Busy  everywhere  
q  603  Decline  
q  604  Does  not  exist  anywhere  
q  606  Not  acceptable    

106
GRT5-M3.4-ASC-1
SIP Mobilité
Les utilisateurs et les terminaux sont gérés comme des
entités séparés.

Appel entrant

Call Controller Server

IP
NETWORK

Connexion sur
RING! ce téléphone

Mon téléphone

107
GRT5-M3.4-ASC-1
SIP Mobilité
Les utilisateurs et les terminaux sont gérés comme des
entités séparés.

Nouvel appel entrant

Call Controller Server

IP
NETWORK

RING!
Mise à jour de
la connexion

Mon téléphone

108
GRT5-M3.4-ASC-1
SIP Mobilité
Les utilisateurs et les terminaux sont gérés comme des
entités séparés.

Appel entrant

Call Controller Server

IP
NETWORK

RING!
RING!

Connexion sur
les 2
téléphones
109
GRT5-M3.4-ASC-1

Vous aimerez peut-être aussi