1 sip (session initiation protocol) - présentation générale

1

SIP (Session Initiation Protocol)

-Présentation Générale

2

Sommaire

• Introduction - Contenu

• Information sur SIP - Capacités de SIP - Composants de SIP - Clients SIP - Serveurs SIP

• Comment SIP fonctionne

• Comment SIP fonctionne avec un Proxy Server

• Comment SIP fonctionne avec un Redirect Server

• Communications SIP

- SIP Gateway vers SIP Gateway - Call Setup et Disconnect - SIP Gateway vers SIP Gateway - Appel via Redirect Server - SIP Gateway vers SIP Gateway - Appel via Proxy Server • Références additionnelles

- Documents liés - Standards - MIB - RFC

3

Introduction

Ce document fournit une présentation générale de SIP (Session Initiation protocol).

Contenu

● Information sur SIP ● Comment fonctionne SIP ● Comment SIP fonctionne ● Comment SIP fonctionne avec un Proxy Server ● Comment SIP fonctione avec un Redirect Server ● Communications SIP ● Références additionnelles

Information sur SIP

SIP (Session Initiation Protocol) est un protocole de contrôle de couche application basé sur l'ASCII qui peut être utilisé pour établir, maintenir, libérér des appels entre deux ou plusieurs points d'extrémités. SIP est un protocole alternatif développé par l'IETF (Internet Engineering Task Force) pour de la conférence multimédia sur IP. Les fonctionnalités de SIP vsont conformes avec le RFC 2543, SIP Session Iniatiation Protocol, publié en Mars 1997.

L'implémentation SIP de Cisco permet aux plateformes Cisco supportées de signaler l'établissement d'appels pour la voix et le multimédia sur des réseaux IP.

Comme d'autres protocoles VoIP, SIP est conçu pour répondre aux fonctions de gestion de la signalisation et de session dans un réseau de téléphonie par paquets. La signalisation permet aux informations d'apprl d'être transportées à travers le réseau. La gestion de session fournit la possibilité de controler les attributs d'une communication de bout en bout.

Capacités de SIP

SIP a les capacités suivantes:

● Localise l'extrémité cible -- SIP supporte la résolution d'adresse, le mapping de nom et la redirection d'appel.

● Détermine les capacités média de l'extrémité cible -- SIP détermine le niveau de service commun le plus bas entre les deux extrémités au travers de SDP (Session Description Protocol). Les conférences sont établies en utilisant les capacités média qui peuvent être supportées par les deux extrémités.

● Détermine la disponibilité de l'extrémité -- Si un appel ne peut pas aboutir car l'extrémité cible est indisponible, SIP détermine si l'extrémitée appelée est déjà

connectée avec un appel en cours ou ne répond pas après le nombre de sonneries paramétré.

4

● Etablit une session entre les extrémités origine et cible -- Si l'appel peut aboutir, SIP établit une session entre les extrémités. SIP supporte également les modifica- tions en cours de communication telles que l'addition d'une autre extrémité à la conférence, le changement de caractéristique de média ou de codec.

● Gère le transfert et la fin de communication -- SIP supporte le transfert d'appel d'une extrémité vers une autre. Pendant le transfert d'appels, SIP établit une session entre le transféré et la nouvelle extrémité ( spécifiée par la partie transférante) et termine la session entre le transféré et la partie transférante. A la fin de la session SIP ferme les sessions entre toutes les parties.

Note: Le terme conférence décrit une session (appel) établie entre deux ou plusieurs extrémités. "Conferences consist of two or more users and can be established using multicast or multiple unicast session. Composants SIP

SIP est un protocole d'égal à égal (Peer-to-Peer). Les extrémités dans une session sont appelées agents utilisateurs (User Agents). Un agent utilisateur peut avoir un des rôles suivants:

● User-Agent Client (UAC) - Une application cliente qui initie une requête SIP. ● User-Agent-Server (UAS) - Une application serveur qui contacte l'utilisateur quand une requête SIP est reçue et qui retourne une réponse à la demande de l'utilisateur.

Typiquement, une extrémité SIP est capable de fonctionner dans les modes UAC et UAS, mais fonctionne dans l'un ou l'autre mode par transaction. Que l'extrémité fonctionne comme un UAC ou un UAS dépend de l'agent utilisateur qui a initié la requête.

D'un point de vue architectural, les composants physiques d'un réseau SIP peuvent être groupés en deux catégories: Clients (extrémités) et Serveurs. La figure suivante illustre l'architecture d'un réseau SIP.

Note: De plus les serveurs SIP peuvent interopérer avec d'autres services applicatifs tels que des servurs LDAP (Lightweight Directory Access Protocol), serveurs de localisation, application base de données ou application XML (eXtensible Markup Lan- guage). Ces services applicatifs fournissent des services aux extrémités tels que ré- pertoir, authentification et facturation.

5

SIP

SIP SIP

SIP Proxy etRedirect Serveurs

RTPRTC

SIP Gateway

SIP UserAgents (UAs)

PABX

Clients SIP

● Téléphones - Peuvent agir comme UAC ou UAS.

- Des Softphones (PCs avec des fonctions téléphone installées) et des téléphones Cisco SIP IP peuvent initier des requêtes SIP et répondre aux requêtes.

- ephones - Téléphones IP non configurés sur la passerelle.

● Passerelles (Gateways) - Fournissent le contrôle d'appel. Les passerelles fournissent plusieurs services, le plus commun étant une fonction de traduction entre les extrémités de conférence SIP et d'autres types de terminaux. Cette fonction comprend la traduction des formats de transmission et des procédures de communication. En plus la passerelle traduit entre codecs audio et vidéo, réalise l'établissement d'appel et la libération de communication du côté LAN et du côté réseau à commutation de circuits.

Serveurs SIP

● Proxy Server - Reçoit les requêtes SIP d'un client et les achemine vers l'autre client. De manière basique, les serveurs proxy reçoivent des messages SIP et les acheminent vers le prochain serveur SIP dans le réseau. Les serveurs proxy peuvent fournir des fonctions telles que l'authentification, l'autorisation, le contrôle d'accès réseau, du routage, la retransmission fiable de requête et la sécurité.

IP

6

● Redirect Server - Fournit au client l'information sur le ou les prochains sauts qu'un message doit atteindre et ensuite le client contacte le serveur du prochain saut ou l'UAS directement.

● Registrar Server - Traite les requêtes des UACs pour l'enregistrement de leur localisation courante. Les serveurs d'enregistrement sont très souvent localisés avec le redirect server ou le proxy server.

Comment SIP fonctionne

SIP est un protocole simple, basé sur l'ASCII, qui utilise des requêtes et des réponses pour établir des communications parmi les divers composants d'un réseau et option- nellement d'établir une conférence entre deux ou plusieurs extrémités. Les utilisateurs d'un réseau SIP sont identifiés par une adresse SIP unique. Une adresse SIP est similaire à une adresse e-mail dont le format est: sip:[email protected]. Le userID peut être soit un nom d'utilisateur soit une adresse E164.

Note: Une adresse E164 est un numéro de téléphone avec une chaîne de chiffres dé- cimaux qui identifie de manière unique le point de terminaison du réseau public. Le numéro contient l'information nécessaire pour router l'appel vers ce point terminal.

Les utilisateurs s'enregistrent avec un serveur d'enregistrement en utilisant leur adresse SIP affectée. Le serveur d'enregistrement fournit cette information au serveur de localisation sur requête.

Quand un utilisateur initie un appel, une requête SIP est transmise vers un serveur SIP (soit un serveur proxy soit un redirect serveur). La requête comprend l'adresse de l'appelant (dans le champ From de l'en-tête) et l'adresse de la partie appelée (dans le champ To de l'en-tête).

Au cours du temps, un utilisateur SIP peut se déplacer d'un système d'extrémité à un autre. La localisation d'un utilisateur peut être enregistrée dynamiquement avec un serveur SIP. Le serveur de localisation peut utiliser un ou plusieurs protocoles (LDAP, Finger, rwhois,…) pour localiser l'utilisateur. Comme l'utilisateur peut être connecté sur plusieurs stations et que le serveur de localisation peut avoir quelque fois des informations imprécises, celui-ci peut retourner plusieurs adresses pour l'utilisateur. Si la requête vient au travers d'un proxy server, le proxy server essaie chacu- ne des adresses retournées jusqu'à ce qu'il localise l'utilisateur. Si la requête vient d'un Redirect server SIP, le Redirect server achemine toutes les adresses vers l'appelant dans le champ Contact de l'en-tête du message "invitation response".

7

Comment SIP fonctionne avec un Proxy Server

Si un Proxy server est utilisé, l'agent utilisateur de l'appelant transmet un requête INVITE ao Proxy server, le proxy server détermine le chemin et achemine la requête vers la partie appelée.

Proxy

Serveur

ClientClient

Client

RedirectServer

Serveur

Serveur

RéseauIP

INVITE

INVITE

Requête SIP à travers un Proxy Server

User agents User agents

8

La partie appelée répond au Proxy Server qui à son tour achemine la réponse vers l'appelant.

Proxy

Serveur

ClientClient

Client

RedirectServer

Serveur

Serveur

RéseauIP

Response 200 OK

Response 200 OK


User agents User agents

9

Le Proxy Server achemine les acquittements des deux parties. Une session est ensuite établie entre les parties appelante et appelée. RTP (Real-time Transfer Protocol) est utilisé pour la communication entre les parties appelante et appelée.

Proxy

Serveur

ClientClient

Client

RedirectServer

Serveur

Serveur

RéseauIP

ACK

ACK

User agentsUser agents


RTP

10

Comment SIP fonctionne avec un Redirect Server

Si un Redirect Server est utilisé, l'agent utilisateur de l'appelant transmet une requête INVITE au Redirect Server, le Reditrect Server contacte le serveur de localisation pour déterminer le chemin vers la partie appelée et ensuite le Redirect Server renvoie l'information vers l'appelant. L'appelant acquitte la réception de l'information.

Proxy

Serveur

ClientClient

Client

RedirectServer

Serveur

Serveur

RéseauIP

INVITE

ACK


Requête SIP à travers un Redirect Server

302 Moved temporarily

11

L'appelant transmet la requête à l'équipement indiqué dans l'information de redirection (qui peut être la partie appelée ou un autre serveur qui achemine la requête). Une fois que la requête atteint la partie appelée, celle-ci une réponse et l'appelant acquitte cette réponse. RTP (Real-time Transfer Protocol) est utilisé pour la communication entre les parties appelante et appelée.

Proxy

Serveur

ClientClient

Client

RedirectServer

Serveur

Serveur

RéseauIP

INVITE

ACK


Requête SIP à travers un Redirect Server

200 OK

RTP

12

Communications SIP

Cette section décrit les communications pour les scénarios suivants qui illustrent des communications réussies:

● SIP Gateway vers SIP Gateway - Call Setup et Disconnect ● SIP Gateway vers SIP Gateway - Appel via Redirect Server SIP ● SIP Gateway vers SIP Gateway - Appel via Proxy Server SIP

SIP Gateway vers SIP Gateway - Call Setup et Disconnect

La figure suivante montre un établissement d'appel et une déconnexion Gateway vers Gateway réussis. Les deux utilisateurs d'extrémités sont User A et User B. User A est localisé sur PBX A qui est connecté à une passerelle SIP (GW1) via une liaison T1/E1. User B est situé sur PBX B qui est connecté à une passerelle SIP (GW2) via une liaison T1/E1. Le numéro de téléphone de USER B est 555 0100. La passerelle SIP GW1 est connectée à la passerelle GW2 par un réseau IP.

Le scénario de la communication est le suivant:

1. User A appelle User B 2. User B répond à l'appel 3. User B termine la communication

User A User BPBX A PBX B

GW1 GW2

Réseau IP

2. INVITE

5. 100 Trying

8. 180 Ringing

Canal RTP 2-way

11. 200 OK

14. ACK

Canal RTP 2-way

17. BYE

21. 200 OK

1. Setup

3. Call Proceeding

9. Alerting

Canal voix 1-way

12. Connect

13. Connect ACK

Canal voix 2-way

19. Disconnect

20. Release

4. Setup

6. Call Proceeding

7. Alerting

Canal voix 1-way

10. Connect

15. Connect ACK

Canal voix 2-way

16. Disconnect

18. Release

22. Release Complete23. Release Complete

13

Note: Le RFC 2543-bis-04 requiert qu'un UAS qui reçoit une requête BYE envoie d'abord une réponse à toutes les requêtes en attente pour cette communication avant de déconnecter. Après avoir reçu une requête BYE, l'UAS doit répondre d'état 487 (Request Cancelled).

Message Description

1. Setup—PBX A vers Gateway SIP GW1

Le message d'appel est transmis du PBX A vers la Gate-way SIP GW1. Le message Setup comprend les transac-tions standards effactuées lorsque User A tente d'appe-ler User B.

2. INVITE— Gateway SIP GW1 versGateway SIP GW2

La passerelle SIP GW1 transmet une requête INVITE à lapasserelle SIP GW2. La requête invite est une demandefaite à User B de participer à une session de communica-tion. La requête INVITE contient les informations suivan-tes:

● Le numéro de téléphone de User B est inséré dans la requête - Champ URI dans la forme d'une URL SIP. L'URL SIP identifie l'adresse de User B et prend une forme similaire à celle d'une adresse e-mail. (user@host dans laquelle user est le numéro de télé- phone et host est soit un nom de domaine soit une adresse de réseau numérique). Par exemple, le champ Request-URI dans la requête INVITE vers User B appa- rait comme "INVITE sip:[email protected]; user=phone". Le paramètre "user=phone" indique que l'adresse Request-URI est un numéro de téléphone et non un nom d'utilisateur.

● PBX Aest identifié comme l'initiateur de la session d'appel dans le champ From.

● Un identifieur numérique unique est affecté à l'appel et inséré dans le champ Call-ID.

● Un numéro de transaction dans une brance unique est identifiée par le champ Cseq.

● La capacité média de User A qui est "ready to receive est spécifiée.

● Le port sur lequel la passerelle SIP GW1 est prête à recevoir les données RTP est spécifié.

3. Call Proceeding— Gateway SIPGW1 vers PBX A

La passerelle SIP GW1 transmet un message Call Proceeding vers PBX A pour acquitter la requête Setup.

4. Setup— Gateway SIP GW2 versPBX B

La passerelle SIP GW2 reçoit la requête INVITE de la pas-serelle SIP GW1 et initie un message Setup vers User Bvia PBX B.

5. 100 Trying— Gateway SIP

GW2 vers Gateway SIP GW1

La passerelle SIP GW2 transmet une réponse 100 Tryingà la requête INVITE transmise pr la passerelle SIP GW1.La réponse 100 Trying indique que la requête INVITE abien été reçue par la passerelle SIP GW2 mais que User B n'a pas été encore localisé et qu'une action non spéci-fiée est en cours.

14

Message Description

6. Call Proceeding—PBX B versGateway SIP GW2

PBX B transmet un message Call Proceeding vers la passerelle SIP GW2 pour acquitter la requête Setup.

7. Alerting—PBX B vers Gateway SIP GW2

PBX B localise User B et transmet un message Alert versla passerelle SIP GW2. Le téléphone de User B commenceà sonner.

8. 180 Ringing— Gateway SIP GW2vers Gateway SIP GW1

La passerelle SIP GW2 transmet un message 180 Ringingvers la passerelle SIP GW1. La réponse 180 Ringing indi-que que la passerelle SIP GW2 a localisé User B et tented'alerter User B.

9. Alerting— Gateway SIP GW1 vers PBX A

La passerelle SIP GW1 transmet un message Alert versUser A via PBX A. Le message Alert indique que la passe-relle SIP GW1 a reçu une réponse 180 Ringing de la pas-serelle SIP GW2. User A entend la tonalité de retour d'ap-pel qui indique que User B est alerté.

A ce point, un canal voix unidirectionnel est établi entrela passerelle SIP GW1 et PBX A et entre la passerelle SIPGW2 et PBX B. Un canal RTP bidirectionnel est établi en-tre les passerelles SIP GW1 et GW2.

10. Connect— PBX B vers Gateway SIP GW2

User B répond à l'appel. PBX B translet un message Con-nect vers la passerelle SIP GW2. Le message Connect no-tifie à la passerelle GW2 que la connexion a été faite.

11. 200 OK— Gateway SIP GW2 vers Gateway SIP GW1

La passerelle SIP GW2 transmet un message 200 OK versla passerelle SIP GW1. Le message 200 OK notifie à la passerelle SIP GW1 que la connexion a été faite.

Si User B supporte la capacité média annoncée dans le message INVITE transmis par la passerelle SIP GW1, ilannonce l'intersection de ses propres capacités médiaavec celles de User A dans le message 200 OK. Si User Bne supporte pas la capacité média annoncée par User A,il transmet en retour la réponse 400 Bad Request avecle champ 304 Warning dans l'en-tête.

12. Connect— Gateway SIP GW1 vers PBX A

La passerelle SIP GW1 transmet un message connect vers PBX A. Le messafe Connect notifie à PBX A que laconnexion a été faite.

13. Connect ACK— PBX A versGateway SIP GW1

PBX A acquitte le message Connect de la passerelle SIPGW1.

14. ACK— SIP Gateway GW1 vers SIP Gateway GW2

La passerelle SIP GW1 transmet un message ACK vers lapasserelle SIP GW2. Le message ACK confirme que lapasserelle SIP GW1 a reçu le message de réponse 200 OK de la passerelle GW2.

15. Connect ACK— Gateway SIPGW2 vers PBX B

La passerelle SIP GW2 acquiite le message Connect dePBX B.

La session est maintenant active à travers un canal voixRTP (Real-time Transport Protocol) bidirectionnel.

A ce point, un canal voix bidirectionnel est établi entrela passerelle SIP GW1 et PBX A et entre la passerelle SIPGW2 et PBX B. Un canal RTP bidirectionnel est établi en-tre les passerelles SIP GW1 et GW2.

15

Message Description

16. Disconnect— PBX B vers Gateway SIP GW2

Lorsque User B raccroche son téléphone, PBX B trans-met un message Disconnect vers la passerelle SIP GW2. Le message Disconnect démarre le processus de libéra-tion de la session de communication.

17. BYE— Gateway SIP GW2 vers Gateway SIP GW1

La passerelle SIP GW2 transmet une requête BYE vers lapasserelle SIP GW1. La requête BYE indique que User Bveut terminer la communication. Le champ Request-URIest remplacé par l'URL SIP de PBX A et le champ Fromcontient l'URL SIP de User B. La valeur du champ CSeq est incrémentée de 1.

18. Release— Gateway SIP GW2vers PBX B

La passerelle SIP GW2 transmet un message Release versPBX B.

19. Disconnect— Gateway SIP GW1 vers PBX A

La passerelle SIP GW1 transmet un message Disconnect vers PBX A.

20. Release— PBX A vers Gateway SIP GW1

PBX A transmet un message Release vers la passerelle SIP GW1.

21. 200 OK— GatewaySIP GW1vers Gateway SIP GW2

La passerelle SIP GW1 transmet un message 200 OK enréponse à la passerelle SIP GW2. Le message 200 OK no-tifie à la passerelle SIP GW2 que la passerelle SIP GW1 a reçue la requête BYE.

22. Release Complete— PBX Bvers Gateway SIP GW2

PBX B transmet un message Release Complete vers lapasserelle SIP GW2.

23. Release Complete— Gateway SIP GW1 vers PBX A

La passerelle SIP GW1 transmet un message ReleaseComplete vers PBX A et la session est terminée.

SIP Gateway vers SIP Gateway - Appel via Redirect Server

La figure suivante montre un établissement d'appel et une déconnexion réussis via un Redirect Server. Dans ce scénario, les deux extrémités sont identifiées comme User A et User B. User A est situé sur PBX A. PBX A est connecté à la passerelle SIP GW1 via une liaison T1/E1. La passerelle SIP GW1 utilise un Redirect Server. User B est situé sur PBX B. PBX B est connecté à la passerelle SIP GW2 via une liaison T1/E1. Le numéro de téléphone de User B est 555 0100. La passerelle SIP GW1 est connectée à la passerelle GW2 par un réseau IP.

Le scénario de la communication est le suivant:

1. User A appelle User B via GW1 en utilisant un Redirect Server 2. User B répond à l'appel 3. User B termine la communication

16

8. 100 Trying

11. 180 Ringing

Canal RTP 2-way

14. 200 OK

17. ACK

Canal RTP 2-way

20. BYE

24. 200 OK

7. Call Proceeding

12. Alerting

Canal voix 1-way

15. Connect

16. Connect ACK

Canal voix 2-way

21. Disconnect

23. Release

6. Setup

9. Call Proceeding

10. Alerting

Canal voix 1-way

13. Connect

18. Connect ACK

Canal voix 2-way

19. Disconnect

22. Release


5. INVITE

3. 300 MultipleChoice

4. ACK


GW1 GW2

Réseau IP

2. INVITE1. Setup

Redirect Server

17

Message Description

1. Setup— PBX A vers Gateway SIP GW1


2. INVITE— GatewaySIP GW1 versredirect server SIP

La passerelle SIP GW1 transmet une requête INVITE auRedirect Server SIP. La requête invite est une demandefaite à User B de participer à une session de communica-tion. La requête INVITE contient les informations suivan-tes:







3. 300 Multiple Choice— Redirect server SIP vers Gateway SIP GW1

Le serveur Redirect SIP transmet une réponse 300 Multi-ple Choice à la passerelle SIP GW1. La réponse 300 Mul-tiple Choice indique que le serveur Redirect SIP a acceptéla requête INVITE, contacté un serveur de localisation avec tout ou partie de l'URL SIP de User B et que le ser-veur de localisation a fourni une liste de localisations possibles de User B. Le serveur Redirect SIP retourne cesadresses possibles à la passerelle SIP GW1 dans le mes-sage 300 Multiple Choice.

4. ACK— GatewaySIP GW1 vers Redirect server SIP

La passerelle SIP GW1 acquitte la réponse 300 MultipleChoice avec un message ACK.

5. INVITE— Gateway SIP GW1 versGateway SIP GW2

La passerelle SIP GW1 transmet une requête INVITE à lapasserelle SIP GW2. Cette nouvelle requête INVITE inclutle premier contact listé dans la réponse 300 Multiple Choice comme nouvelle adresse pour User B. Un numérode transaction plus élevé est placé dans le champ Cseqet le Call-ID de la première requête INVITE est gardé.

18

Message Description


La passerelle SIP GW2 reçoit la requête INVITE de la pas-serelle SIP GW1 et initie un message Setup vers User Bvia PBX B.



8. 100 Trying— Gateway SIP GW2 vers Gateway SIP GW1

La passerelle SIP GW2 transmet une réponse 100 Tryingà la requête INVITE transmise pr la passerelle SIP GW1.La réponse 100 Trying indique que la requête INVITE abien été reçue par la passerelle SIP GW2 mais que User B n'a pas été encore localisé et qu'une action non spéci-fiée est en cours.





11. 180 Ringing— Gateway SIP GW2 vers Gateway SIP GW1

La passerelle SIP GW2 transmet un message 180 Ringingvers la passerelle SIP GW1. La réponse 180 Ringing indi-que que la passerelle SIP GW2 a localisé User B et tented'alerter User B.






14. 200 OK— Gateway SIP GW2 vers Gateway SIP GW1

La passerelle SIP GW2 transmet un message 200 OK versla passerelle SIP GW1. Le message 200 OK notifie à la passerelle SIP GW1 que la connexion a été faite.



La passerelle SIP GW1 transmet un message connect vers PBX A. Le messafe Connect notifie à PBX A que laconnexion a été faite.



19

Message Description

17. ACK— SIP Gateway GW1 vers SIP Gateway GW2

La passerelle SIP GW1 transmet un message ACK vers lapasserelle SIP GW2. Le message ACK confirme que lapasserelle SIP GW1 a reçu le message de réponse 200 OK de la passerelle GW2.




A ce point, un canal voix bidirectionnel est établi entrela passerelle SIP GW1 et PBX A et entre la passerelle SIPGW2 et PBX B. Un canal RTP bidirectionnel est établi en-tre les passerelles SIP GW1 et GW2.




La passerelle SIP GW2 transmet une requête BYE vers lapasserelle SIP GW1. La requête BYE indique que User Bveut terminer la communication. Le champ Request-URIest remplacé par l'URL SIP de PBX A et le champ Fromcontient l'URL SIP de User B. La valeur du champ CSeq est incrémentée de 1.







24. 200 OK— GatewaySIP GW1vers Gateway SIP GW2

La passerelle SIP GW1 transmet un message 200 OK enréponse à la passerelle SIP GW2. Le message 200 OK no-tifie à la passerelle SIP GW2 que la passerelle SIP GW1 a reçu la requête BYE.





20

SIP Gateway vers SIP Gateway - Appel via Proxy Server

Les figures suivantes montre des établissement d'appel et un déconnexion gateway vers gateway réussis via un Proxy server. Les deux utilisateurs d'extrémités sont User A et User B. User A est situé sur PBX A qui est connecté à une passerelle SIP (GW1) via une liaison T1/E1. La passerelle SIP GW1 contient le Proxy Server. La passerelle SIP GW1 est connectée à la passerelle GW2 par un réseau IP. User B est situé sur PBX B qui est connecté à une passerelle SIP (GW2) via une liaison T1/E1. Le nu- méro de téléphone de USER B est 555 0100.

Note: Le champ Record-Route de l'en-tête est inséré par les Proxy Servers dans une requête pour forcer les requêtes futures de l'échange à être routées vers le Proxy Ser- ver.

Dans la figure suivante, la fonctionnalité Record-route est validée sur le Proxy Server.

Quand la fonctionnalité Record-route est validée, le Proxy Server ajoute le champ Record-route dans l'en-tête des messages SIP pour s'assurer qu'il sera sur le chemin des requêtes suivantes pour la même branche de la communication. Le champ Re- cord-route contient une Request-URI globalement accessible qui identifie le Proxy Server. Quand Record-route est dévalidé, les messages SIP passent directement par la passerelle une fois que la communication a été établie.

La scénario de la communication est le suivant:

1. User A appelle User B via GW1 en utilisant un Proxy Server 2. User B répond à l'appel 3. User B termine la communication

21


GW1 GW2

Réseau IP

Proxy Server

7. 100 Trying

10. 180 Ringing

15. 200 OK

18. ACK

Canal RTP 2-way

22. BYE

27. 200 OK

3. Call Proceeding

12. Alerting

Canal voix 1-way

16. Connect

17. Connect ACK

Canal voix 2-way

24. Disconnect

26. Release

6. Setup

8. Call Proceeding

9. Alerting

Canal voix 1-way

13. Connect

20. Connect ACK

Canal voix 2-way

21. Disconnect

25. Release


2. INVITE

19. ACK

1. Setup

4. INVITE

11. 180 Ringing

5. 100 Trying

Canal RTP 2-way

14. 200 OK

23. BYE

28. 200 OK

SIP Gateway vers SIP Gateway - Appel via Proxy Server avec Record Route validé

22

Message Description



2. INVITE— GatewaySIP GW1 versProxy server SIP

La passerelle SIP GW1 transmet une requête INVITE auProxy Server SIP. La requête invite est une demandefaite à User B de participer à une session de communica-tion. La requête INVITE contient les informations suivan-tes:









4. INVITE— Proxy Server SIP versGateway SIP GW2

La Proxy Server SIP vérifie si sa propre adresse est conte-nue dans le champ Via (pour éviter les boucles), copie di-rectement les champs To, From, Call-ID et Contact de larequête reçue de la passerelle SIP GW1, change la Request-URI pour indiquer le serveur vers lequel il va en-voyer la requête INVITE et ensuite transmet la nouvellerequête INVITE vers la passerelle SIP GW2..

5. 100 Trying— Proxy Server SIP vers Gateway SIP GW1

Le Proxy Server SIP transmet la réponse 100 Trying à la passerelle SIP GW1.


La passerelle SIP GW2 reçoit la requête INVITE du Proxyserver SIP GW1 et initie un message Setup vers User Bvia PBX B.

23

Message Description

7. 100 Trying— Gateway SIP GW2 vers Proxy server SIP

La passerelle SIP GW2 transmet une réponse 100 Tryingvers le Proxy server. Le Proxy server SIP peut acheminer ou non la réponse 100 Trying vers la passerelle SIP GW1





10. 180 Ringing— Gateway SIP GW2 vers Proxy server SIP

La passerelle SIP GW2 transmet un message 180 Ringingvers le Proxy server.

11. 180 Ringing— Proxy server SIPvers Gateway SIP GW1

Le Proxy server SIP achemine la réponse 180 Ringing vers la passerelle SIP GW1.






14. 200 OK— Gateway SIP GW2 vers Proxy server SIP

La passerelle SIP GW2 transmet un message 200 OK( incluant l'en-tête Record-route reçu dans la requêteINVITE) vers le Proxy server SIP. Le message 200 OK notifie au Proxy server SIP que la connexion a été faite.


Le Proxy server SIP doit acheminer la réponse 200 OK enamont.

15. 200 OK— Proxy server SIP vers Gateway SIP GW1

Le Proxy server SIP achemine la réponse 200 OK qu'il a reçue de la passerelle SIP GW2 vers la passerelle SIP GW1. Dans la réponse 200 OK, le Proxy server SIP ache-mine l'en-tête Record-route pour s'assurer qu'il sera dansle chemin des requêtes suivantespour la même branchede la communication. Le Proxy server SIP rajoute sa pro-pre Request-URI dans le champ Record-route.

24

Message Description


La passerelle SIP GW1 transmet un message Connect vers PBX A. Le message Connect notifie à PBX A que laconnexion a été faite.



18. ACK— Gateway SIP GW1 vers Proxy server SIP

La passerelle SIP GW1 transmet un ACK vers le Proxyserver SIP. Le message ACK confirme que la passerelle SIP GW1 a bien reçu le message 200 OK du Proxy server SIP.

19. ACK— Proxy server SIP versGateway SIP GW2

Selon les valeurs des champs To, From, Cseq et Call-ID leProxy server traitera l'ACK localement ou le mandatera. Si les champs dans l'ACK ne correspondent à ceux desrequêtes précédentes traitées par le Proxy server SIP,le serveur mandatera l'ACK. S'il n'y a aucune correspon-dance , l'ACK est mandaté comme si c'était une requêteINVITE.

Le Proxy server SIP achemine la réponse ACK de la pas-serelle SIP GW1 vers la passerelle SIP GW2.




A ce point, un canal voix bidirectionnel est établi entrela passerelle SIP GW1 et PBX A et entre la passerelle SIPGW2 et PBX B. Un canal RTP bidirectionnel est établi en-tre les passerelles SIP GW1 et GW2 sans passer par leProxy server SIP.



22. BYE— Gateway SIP GW2 vers Proxy server SIP

La passerelle SIP GW2 transmet une requête BYE vers leProxy server SIP. La requête BYE indique que User Bveut terminer la communication. Le champ Request-URIest remplacé par l'URL SIP de PBX A et le champ Fromcontient l'URL SIP de User B.

23. BYE— Proxy server SIP versGateway SIP GW1

Le Proxy server SIP achemine la requête BYE vers la pas-serelle SIP GW1.







27. 200 OK— Gateway SIP GW1vers Proxy server SIP

La passerelle SIP GW1 transmet un message 200 OK enréponse vers le Proxy server. Le message 200 OK no-tifie à la passerelle SIP GW2 que la passerelle SIP GW1 a reçu la requête BYE.

25

Message Description

28. 200 OK— Proxy server SIPvers Gateway SIP GW2

Le Proxy server SIP achmine le message 200 OK vers lapasserelle SIP GW2.






GW1 GW2

Réseau IP

Proxy Server

7. 100 Trying

10. 180 Ringing

15. 200 OK

18. ACK

Canal RTP 2-way

21. BYE

25. 200 OK

3. Call Proceeding

12. Alerting

Canal voix 1-way

16. Connect

17. Connect ACK

Canal voix 2-way

22. Disconnect

24. Release

6. Setup

8. Call Proceeding

9. Alerting

Canal voix 1-way

13. Connect

19. Connect ACK

Canal voix 2-way

20. Disconnect

23. Release


2. INVITE1. Setup

4. INVITE

11. 180 Ringing

5. 100 Trying

Canal RTP 2-way

14. 200 OK

SIP Gateway vers SIP Gateway - Appel via Proxy Server avec Record Route validé

26

Message Description



2. INVITE— GatewaySIP GW1 versProxy server SIP

La passerelle SIP GW1 transmet une requête INVITE auProxy Server SIP. La requête invite est une demandefaite à User B de participer à une session de communica-tion. La requête INVITE contient les informations suivan-tes:









4. INVITE— Proxy Server SIP versGateway SIP GW2

La Proxy Server SIP vérifie si sa propre adresse est conte-nue dans le champ Via (pour éviter les boucles), copie di-rectement les champs To, From, Call-ID et Contact de larequête reçue de la passerelle SIP GW1, change la Request-URI pour indiquer le serveur vers lequel il va en-voyer la requête INVITE et ensuite transmet la nouvellerequête INVITE vers la passerelle SIP GW2..

5. 100 Trying— Proxy Server SIP vers Gateway SIP GW1

Le Proxy Server SIP transmet la réponse 100 Trying à la passerelle SIP GW1.


La passerelle SIP GW2 reçoit la requête INVITE du Proxyserver SIP GW1 et initie un message Setup vers User Bvia PBX B.

27

Message Description

7. 100 Trying— Gateway SIP GW2 vers Proxy server SIP

La passerelle SIP GW2 transmet une réponse 100 Tryingvers le Proxy server. Le Proxy server SIP peut acheminer ou non la réponse 100 Trying vers la passerelle SIP GW1





10. 180 Ringing— Gateway SIP GW2 vers Proxy server SIP

La passerelle SIP GW2 transmet un message 180 Ringingvers le Proxy server.

11. 180 Ringing— Proxy server SIPvers Gateway SIP GW1

Le Proxy server SIP achemine la réponse 180 Ringing vers la passerelle SIP GW1.






14. 200 OK— Gateway SIP GW2 vers Proxy server SIP

La passerelle SIP GW2 transmet un message 200 OK( incluant l'en-tête Record-route reçu dans la requêteINVITE) vers le Proxy server SIP. Le message 200 OK notifie au Proxy server SIP que la connexion a été faite.


Le Proxy server SIP doit acheminer la réponse 200 OK enamont.

15. 200 OK— Proxy server SIP vers Gateway SIP GW1

Le Proxy server SIP achemine la réponse 200 OK qu'il a reçue de la passerelle SIP GW2 vers la passerelle SIP GW1. Dans la réponse 200 OK, le Proxy server SIP ache-mine l'en-tête Record-route pour s'assurer qu'il sera dansle chemin des requêtes suivantespour la même branchede la communication. Le Proxy server SIP rajoute sa pro-pre Request-URI dans le champ Record-route.

28

Message Description


La passerelle SIP GW1 transmet un message Connect vers PBX A. Le message Connect notifie à PBX A que laconnexion a été faite.



18. ACK— Gateway SIP GW1 vers Gateway SIP GW2

La passerelle SIP GW1 transmet un ACK vers la passe-relle SIP GW2. Le message ACK confirme que la passe-relle SIP GW1 a bien reçu le message 200 OK du Proxy server SIP.




A ce point, un canal voix bidirectionnel est établi entrela passerelle SIP GW1 et PBX A et entre la passerelle SIPGW2 et PBX B. Un canal RTP bidirectionnel est établi en-tre les passerelles SIP GW1 et GW2 sans passer par leProxy server SIP.




La passerelle SIP GW2 transmet une requête BYE vers lapasserelle SIP GW1. La requête BYE indique que User Bveut terminer la communication. Le champ Request-URIest remplacé par l'URL SIP de PBX A et le champ Fromcontient l'URL SIP de User B.







25. 200 OK— Gateway SIP GW1Gateway SIP GW2

La passerelle SIP GW1 transmet un message 200 OK enréponse vers la passerelle SIP GW2. Le message 200 OK notifie à la passerelle SIP GW2 que la passerelle SIP GW1 a reçu la requête BYE.





29

Références additionnelles

Documents liés

Thème Titre du document

Basic router configuration • Cisco 2600 series documentation athttp://www.cisco.com/univercd/cc/td/doc/product/access/acs_mod/cis2600/index.htm

• Cisco 3600 series documentation athttp://www.cisco.com/univercd/cc/td/doc/product/access/acs_mod/cis3600/index.htm

• Cisco 3700 series documentation athttp://www.cisco.com/univercd/cc/td/doc/product/access/acs_mod/cis3700/index.htm

• Cisco AS5300 documentation athttp://www.cisco.com/univercd/cc/td/doc/product/access/acs_serv/5300/index.htm

Cisco IOS command references

• Cisco IOS Debug Command Reference, Release 12.3T athttp://www.cisco.com/univercd/cc/td/doc/product/software/ios123/123tcr/123dbr/index.htm

• Cisco IOS Voice Command Reference, Release 12.3T athttp://www.cisco.com/univercd/cc/td/doc/product/software/ios123/123tcr/123tvr/index.htm

Cisco IOS configurationfundamentals and examples

• Cisco IOS Configuration Fundamentals Configuration Guide athttp://www.cisco.com/univercd/cc/td/doc/product/software/ios122/122cgcr/ffun_c/

• Cisco IOS Interface Command Reference athttp://www.cisco.com/univercd/cc/td/doc/product/software/ios122/122cgcr/finter_r/index.htm

• Cisco IOS Interface Configuration Guide athttp://www.cisco.com/univercd/cc/td/doc/product/software/ios122/122cgcr/finter_c/

• Cisco IOS Voice, Video, and Fax Configuration Guide, Release 12.2 athttp://www.cisco.com/univercd/cc/td/doc/product/software/ios122/122cgcr/fvvfax_c/index.htm

• Cisco Systems Technologies website at http://cisco.com/en/US/tech/index.html

From the website, select a technology category and subsequent hierarchy of subcategories, then click Technical Documentation > Configuration Examples.

Cisco IOS Voice ConfigurationLibrary, including librarypreface and glossary

• Cisco IOS Voice Configuration Library athttp://www.cisco.com/univercd/cc/td/doc/product/software/ios123/123cgcr/vcl.htm

30


Developer support • Developer Support Agreement at http://www.cisco.com/go/developersupport

IVR script information TCL IVR API 2.0 Programming Guide athttp://www.cisco.com/univercd/cc/td/doc/product/access/acs_serv/vapp_dev/tclivrv2/index.htm

NAT configuration • Configuring Network Address Translation: Getting Started athttp://www.cisco.com/warp/public/556/12.htm

SIP documents • Cisco SIP proxy server documents athttp://www.cisco.com/univercd/cc/td/doc/product/voice/sipproxy/index.htm

• Guide to Cisco Systems' VoIP Infrastructure Solution for SIP athttp://www.cisco.com/univercd/cc/td/doc/product/voice/sipsols/biggulp/index.htm• Session Initiation Protocol Gateway Call Flows athttp://www.cisco.com/univercd/cc/td/doc/product/software/ios122/rel_docs/sip_flo/index.htm

SS7 for voice gateways • Configuring Media Gateways for the SS7 Interconnect for Voice Gateways Solution athttp://www.cisco.com/univercd/cc/td/doc/product/access/sc/rel7/soln/das22/gateway/dascfg5.htm

Tcl IVR programming • Tcl IVR API Version 2.0 Programmer's Guide athttp://www.cisco.com/univercd/cc/td/doc/product/access/acs_serv/vapp_dev/tclivrv2/index.htm

Troubleshooting • Cisco IOS Debug Command Reference, Release 12.3T athttp://www.cisco.com/univercd/cc/td/doc/product/software/ios123/123tcr/123dbr/index.htm

• Cisco IOS Voice Troubleshooting and Monitoring Guide athttp://www.cisco.com/univercd/cc/td/doc/product/software/ios123/123cgcr/vvfax_c/voipt_c/index.htm

• Internetwork Troubleshooting Guide athttp://www.cisco.com/univercd/cc/td/doc/cisintwk/itg_v1/index.htm

• Troubleshooting and Debugging VoIP Call Basics athttp://www.cisco.com/warp/public/788/voip/voip_debugcalls.html

• Voice over IP Troubleshooting and Monitoring athttp://cisco.com/univercd/cc/td/doc/product/software/ios123/123cgcr/vvfax_c/voipt_c/index.htm

• VoIP Debug Commands athttp://www.cisco.com/univercd/cc/td/doc/product/access/acs_mod/1700/1750/1750voip/debug.htm

31


VoATM configuration • Configuring AAL2 and AAL5 for the High-Performance Advanced Integration Module on the Cisco 2600 Series athttp://www.cisco.com/univercd/cc/td/doc/product/software/ios122/122newft/122limit/122x/122xa/122xa_2/ft_ataim.htm

VoIP configuration • Voice over IP for the Cisco 2600/3600 Series athttp://www.cisco.com/univercd/cc/td/doc/product/access/nubuvoip/voip3600/index.htm

• Voice over IP for the Cisco AS5300 athttp://www.cisco.com/univercd/cc/td/doc/product/accessnubuvoip/voip5300/index.htm

• Voice over IP for the Cisco AS5800 athttp://www.cisco.com/univercd/cc/td/doc/product/access/nubuvoip/voip5800/index.htm

VSA information • RADIUS Vendor-Specific Attributes Voice Implementation Guide athttp://www.cisco.com/univercd/cc/td/doc/product/access/acs_serv/vapp_dev/vsaig3.htm

WAN configuration • Cisco IOS Wide-Area Networking Command Reference at

http://www.cisco.com/univercd/cc/td/doc/product/software/ios122/122cgcr

/fwan_r/index.htm

• Cisco IOS Wide-Area Networking Configuration Guide at

http://www.cisco.com/univercd/cc/td/doc/product/software/ios122/122cgcr

/fwan_c/wcfatm.htm

Other documents Cisco Internetworking Terms and Acronyms athttp://www.cisco.com/univercd/cc/td/doc/cisintwk/ita/Cisco Resource Policy Management System 2.0 athttp://www.cisco.com/univercd/cc/td/doc/product/access/acs_soft/rpms/rpms_2-0/VoIP Call Admission Control athttp://www.cisco.com/univercd/cc/td/doc/cisintwk/intsolns/voipsol/cac.htm

32

Standards Titre

ANSI TI.619/a ISDN Multi-Level Precedence and Preemption (MLPP) ServiceCapability

draft-ietf-avt-profile-new-12.txt

RTP Profile for Audio and Video Conferences with Minimal Control

draft-ietf-avt-rtp-cn-06.txt RTP Payload for Comfort Noise, Internet Draft of the InternetEngineering Task Force (IETF) Audio/Video Transport (AVT)working group

draft-ietf-avt-rtp-mime-06.txt MIME Type Registration of RTP Payload Formats

draft-ietf-mmusic-sdp-comedia-04.txt

Connection-Oriented Media Transport in SDP

draft-ietf-sipping-reason-header-for-preemption-00

Extending the SIP for Preemption Events

draft-ietf-sip-privacy-02 SIP Extensions for Caller Identity and Privacy

draft-ietf-sip-resource-priority-05

Communications Resources Priority for SIP

draft-levy-diversion-06.txt [Sip] verification of diversion header (draft-levy)

GR-268-CORE ISDN Basic Rate Interface Call Control Switching and SignallingGeneric Requirements

Standards

MIBs

MIBs Liens MIBs

CISCO-SIP-UA-MIB To locate and download MIBs for selected platforms, Cisco IOSreleases, and feature sets, use Cisco MIB Locator found at thefollowing URL:http://www.cisco.com/go/mibs

RFCs

RFC Titre

• RFC 1889 RTP: A Transport Protocol for Real-Time Applications

• RFC 2052 A DNS RR for Specifying the Location of Service (DNS SRV)

• RFC 2543 and RFC 2543-bis-04 SIP: Session Initiation Protocol

• RFC 2617 HTTP Authentication: Basic and Digest Access Authentication

• RFC 2782 A DNS RR for specifying the location of services (DNS SRV)

• RFC 2806 URLs for Telephone Calls

• RFC 2833 RTP Payload for DTMF Digits, Telephony Tones and Telephony Signals

• RFC 2976 SIP INFO Method

• RFC 3261 SIP: Session Initiation Protocol

33

RFCs

RFC Titre

• RFC 3262 Reliability of Provisional Responses in Session Initiation Protocol(SIP)

• RFC 3264 An Offer/Answer Model with Session Description Protocol (SDP)

• RFC 3265 Session Initiation Protocol (SIP)-Specific Event Notification

• RFC 3311 The Session Initiation Protocol (SIP) UPDATE Method

• RFC 3312 Integration of Resource Management and Session InitiationProtocol (SIP)

• RFC 3326 The Reason Header Field for the Session Initiation Protocol

• RFC 3420 Internet Media Type message/sipfrag

• RFC 3515 The Session Initiation Protocol (SIP) Refer Method