SIP

(Session Initiation Protocol)

-
Présentation Générale

1
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

2
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 ges-
tion 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 communi-
cation 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é.

3
● 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 ses-
sion 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 ses-

sion 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 loca-
lisation, 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.

4
 SIP Proxy et
Redirect Serveurs

SIP

SIP User
Agents (UAs) SIP SIP

SIP Gateway

RTP
RTC
IP

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 fournis-

sent 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 com-
munication. 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 peu-
vent 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é.

5
 ● 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 loca-
lisation 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 simi-
laire à une adresse e-mail dont le format est: sip:userID@gateway.com. 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'uti-
lisateur. 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'appe-
lant dans le champ Contact de l'en-tête du message "invitation response".

6
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.

INVITE

Réseau Client
Client IP

INVITE

Serveur
Serveur

User agents User agents

Client Serveur

Proxy
Redirect
Server

Requête SIP à travers un Proxy Server

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

Response 200 OK

Réseau Client
Client IP

Response 200 OK

Serveur
Serveur

User agents User agents

Client Serveur

Proxy
Redirect
Server

Requête SIP à travers un Proxy Server

8
Le Proxy Server achemine les acquittements des deux parties. Une session est ensui-
te é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.

ACK
Réseau
IP
Client
Client
RTP

ACK
Serveur
Serveur

User agents
User agents

Client Serveur

Proxy
Redirect
Server

Requête SIP à travers un Proxy Server

9
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'in-
formation vers l'appelant. L'appelant acquitte la réception de l'information.

INVITE

302 Moved temporarily

Client
Client
ACK

Réseau
IP

Serveur
Serveur

User agents
User agents

Client Serveur

Proxy
Redirect
Server

Requête SIP à travers un Redirect Server

10
L'appelant transmet la requête à l'équipement indiqué dans l'information de redirec-
tion (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 ac-
quitte cette réponse. RTP (Real-time Transfer Protocol) est utilisé pour la communi-
cation entre les parties appelante et appelée.

INVITE

200 OK
Client
Client
ACK

RTP

Réseau
IP
Serveur
Serveur

User agents
User agents

Client Serveur

Proxy
Redirect
Server

Requête SIP à travers un Redirect Server

11
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 liai-
son 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 PBX A GW1 GW2 PBX B User B

Réseau IP

1. Setup
2. INVITE
3. Call Proceeding 4. Setup
5. 100 Trying
6. Call Proceeding
7. Alerting
8. 180 Ringing
9. Alerting

Canal voix 1-way Canal RTP 2-way Canal voix 1-way

10. Connect
11. 200 OK
12. Connect
13. Connect ACK 14. ACK
15. Connect ACK

Canal voix 2-way Canal RTP 2-way Canal voix 2-way

17. BYE 16. Disconnect

19. Disconnect
18. Release
20. Release
21. 200 OK
23. Release Complete 22. Release Complete

12
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
1. Setup—PBX A vers Gateway SIP
GW1
2. INVITE— Gateway SIP GW1 vers
Gateway SIP GW2
3. Call Proceeding— Gateway SIP
GW1 vers PBX A
4. Setup— Gateway SIP GW2 vers
PBX B
5. 100 Trying— Gateway SIP
GW2 vers Gateway SIP GW1
Description
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.
La passerelle SIP GW1 transmet une requête INVITE à la
passerelle SIP GW2. La requête invite est une demande
faite à 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:5550100@companyb.com;
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é.
La passerelle SIP GW1 transmet un message Call
Proceeding vers PBX A pour acquitter la requête Setup.
La passerelle SIP GW2 reçoit la requête INVITE de la pas-
serelle SIP GW1 et initie un message Setup vers User B
via PBX B.
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 a
bien é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.
13
Message
6. Call Proceeding—PBX B vers
Gateway SIP GW2
7. Alerting—PBX B vers Gateway
SIP GW2
8. 180 Ringing— Gateway SIP GW2
vers Gateway SIP GW1
9. Alerting— Gateway SIP GW1
vers PBX A
10. Connect— PBX B vers Gateway
SIP GW2
11. 200 OK— Gateway SIP GW2
vers Gateway SIP GW1
12. Connect— Gateway SIP GW1
vers PBX A
13. Connect ACK— PBX A vers
Gateway SIP GW1
14. ACK— SIP Gateway GW1 vers
SIP Gateway GW2
15. Connect ACK— Gateway SIP
GW2 vers PBX B
Description
PBX B transmet un message Call Proceeding vers la
passerelle SIP GW2 pour acquitter la requête Setup.
PBX B localise User B et transmet un message Alert vers
la passerelle SIP GW2. Le téléphone de User B commence
à sonner.
La passerelle SIP GW2 transmet un message 180 Ringing
vers la passerelle SIP GW1. La réponse 180 Ringing indi-
que que la passerelle SIP GW2 a localisé User B et tente
d'alerter User B.
La passerelle SIP GW1 transmet un message Alert vers
User 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 entre
la passerelle SIP GW1 et PBX A et entre la passerelle SIP
GW2 et PBX B. Un canal RTP bidirectionnel est établi en-
tre les passerelles SIP GW1 et 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.
La passerelle SIP GW2 transmet un message 200 OK vers
la 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, il
annonce l'intersection de ses propres capacités média
avec celles de User A dans le message 200 OK. Si User B
ne supporte pas la capacité média annoncée par User A,
il transmet en retour la réponse 400 Bad Request avec
le champ 304 Warning dans l'en-tête.
La passerelle SIP GW1 transmet un message connect vers
PBX A. Le messafe Connect notifie à PBX A que la
connexion a été faite.
PBX A acquitte le message Connect de la passerelle SIP
GW1.
La passerelle SIP GW1 transmet un message ACK vers la
passerelle SIP GW2. Le message ACK confirme que la
passerelle SIP GW1 a reçu le message de réponse 200 OK
de la passerelle GW2.
La passerelle SIP GW2 acquiite le message Connect de
PBX B.
La session est maintenant active à travers un canal voix
RTP (Real-time Transport Protocol) bidirectionnel.
A ce point, un canal voix bidirectionnel est établi entre
la passerelle SIP GW1 et PBX A et entre la passerelle SIP
GW2 et PBX B. Un canal RTP bidirectionnel est établi en-
tre les passerelles SIP GW1 et GW2.
14
 Message Description
16. Disconnect— PBX B vers Lorsque User B raccroche son téléphone, PBX B trans-
Gateway SIP GW2 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 La passerelle SIP GW2 transmet une requête BYE vers la
Gateway SIP GW1 passerelle SIP GW1. La requête BYE indique que User B
veut terminer la communication. Le champ Request-URI
est remplacé par l'URL SIP de PBX A et le champ From
contient l'URL SIP de User B. La valeur du champ CSeq
est incrémentée de 1.
18. Release— Gateway SIP GW2 La passerelle SIP GW2 transmet un message Release vers
vers PBX B PBX B.

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

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

21. 200 OK— GatewaySIP GW1
vers Gateway SIP GW2
22. Release Complete— PBX B
vers Gateway SIP GW2
La passerelle SIP GW1 transmet un message 200 OK en
ré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.
PBX B transmet un message Release Complete vers la
passerelle SIP GW2.

23. Release Complete— Gateway La passerelle SIP GW1 transmet un message Release
SIP GW1 vers PBX A Complete 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

15
User A PBX A GW1 GW2 PBX B User B

Réseau IP

Redirect Server

1. Setup
2. INVITE

3. 300 Multiple
Choice

4. ACK

5. INVITE
7. Call Proceeding 6. Setup
8. 100 Trying
9. Call Proceeding
10. Alerting
11. 180 Ringing
12. Alerting

Canal voix 1-way Canal RTP 2-way Canal voix 1-way

13. Connect
14. 200 OK
15. Connect

16. Connect ACK 17. ACK

18. Connect ACK

Canal voix 2-way Canal RTP 2-way Canal voix 2-way

20. BYE 19. Disconnect

21. Disconnect
22. Release
23. Release
24. 200 OK
26. Release Complete 25. Release Complete

16
Message
1. Setup— PBX A vers Gateway SIP
GW1
2. INVITE— GatewaySIP GW1 vers
redirect server SIP
3. 300 Multiple Choice— Redirect
server SIP vers Gateway SIP GW1
4. ACK— GatewaySIP GW1 vers
Redirect server SIP
5. INVITE— Gateway SIP GW1 vers
Gateway SIP GW2
Description
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.
La passerelle SIP GW1 transmet une requête INVITE au
Redirect Server SIP. La requête invite est une demande
faite à 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:5550100@companyb.com;
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é.
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 ces
adresses possibles à la passerelle SIP GW1 dans le mes-
sage 300 Multiple Choice.
La passerelle SIP GW1 acquitte la réponse 300 Multiple
Choice avec un message ACK.
La passerelle SIP GW1 transmet une requête INVITE à la
passerelle SIP GW2. Cette nouvelle requête INVITE inclut
le premier contact listé dans la réponse 300 Multiple
Choice comme nouvelle adresse pour User B. Un numéro
de transaction plus élevé est placé dans le champ Cseq
et le Call-ID de la première requête INVITE est gardé.
17
Message
6. Setup— Gateway SIP GW2 vers
PBX B
7. Call Proceeding— Gateway SIP
GW1 vers PBX A
8. 100 Trying— Gateway SIP GW2
vers Gateway SIP GW1
9. Call Proceeding—PBX B vers
Gateway SIP GW2
10. Alerting—PBX B vers Gateway
SIP GW2
11. 180 Ringing— Gateway SIP
GW2 vers Gateway SIP GW1
12. Alerting— Gateway SIP GW1
vers PBX A
13. Connect— PBX B vers Gateway
SIP GW2
14. 200 OK— Gateway SIP GW2
vers Gateway SIP GW1
15. Connect— Gateway SIP GW1
vers PBX A
16. Connect ACK— PBX A vers
Gateway SIP GW1
Description
La passerelle SIP GW2 reçoit la requête INVITE de la pas-
serelle SIP GW1 et initie un message Setup vers User B
via PBX B.
La passerelle SIP GW1 transmet un message Call
Proceeding vers PBX A pour acquitter la requête Setup.
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 a
bien é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.
PBX B transmet un message Call Proceeding vers la
passerelle SIP GW2 pour acquitter la requête Setup.
PBX B localise User B et transmet un message Alert vers
la passerelle SIP GW2. Le téléphone de User B commence
à sonner.
La passerelle SIP GW2 transmet un message 180 Ringing
vers la passerelle SIP GW1. La réponse 180 Ringing indi-
que que la passerelle SIP GW2 a localisé User B et tente
d'alerter User B.
La passerelle SIP GW1 transmet un message Alert vers
User 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 entre
la passerelle SIP GW1 et PBX A et entre la passerelle SIP
GW2 et PBX B. Un canal RTP bidirectionnel est établi en-
tre les passerelles SIP GW1 et 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.
La passerelle SIP GW2 transmet un message 200 OK vers
la 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, il
annonce l'intersection de ses propres capacités média
avec celles de User A dans le message 200 OK. Si User B
ne supporte pas la capacité média annoncée par User A,
il transmet en retour la réponse 400 Bad Request avec
le champ 304 Warning dans l'en-tête.
La passerelle SIP GW1 transmet un message connect vers
PBX A. Le messafe Connect notifie à PBX A que la
connexion a été faite.
PBX A acquitte le message Connect de la passerelle SIP
GW1.
18
Message
17. ACK— SIP Gateway GW1 vers
SIP Gateway GW2
18. Connect ACK— Gateway SIP
GW2 vers PBX B
19. Disconnect— PBX B vers
Gateway SIP GW2
20. BYE— Gateway SIP GW2 vers
Gateway SIP GW1
21. Disconnect— Gateway SIP
GW1 vers PBX A
22. Release— Gateway SIP GW2
vers PBX B
23. Release— PBX A vers Gateway
SIP GW1
24. 200 OK— GatewaySIP GW1
vers Gateway SIP GW2
25. Release Complete— PBX B
vers Gateway SIP GW2
26. Release Complete— Gateway
SIP GW1 vers PBX A
Description
La passerelle SIP GW1 transmet un message ACK vers la
passerelle SIP GW2. Le message ACK confirme que la
passerelle SIP GW1 a reçu le message de réponse 200 OK
de la passerelle GW2.
La passerelle SIP GW2 acquiite le message Connect de
PBX B.
La session est maintenant active à travers un canal voix
RTP (Real-time Transport Protocol) bidirectionnel.
A ce point, un canal voix bidirectionnel est établi entre
la passerelle SIP GW1 et PBX A et entre la passerelle SIP
GW2 et PBX B. Un canal RTP bidirectionnel est établi en-
tre les passerelles SIP GW1 et 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.
La passerelle SIP GW2 transmet une requête BYE vers la
passerelle SIP GW1. La requête BYE indique que User B
veut terminer la communication. Le champ Request-URI
est remplacé par l'URL SIP de PBX A et le champ From
contient l'URL SIP de User B. La valeur du champ CSeq
est incrémentée de 1.
La passerelle SIP GW1 transmet un message Disconnect
vers PBX A.
La passerelle SIP GW2 transmet un message Release vers
PBX B.
PBX A transmet un message Release vers la passerelle
SIP GW1.
La passerelle SIP GW1 transmet un message 200 OK en
ré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.
PBX B transmet un message Release Complete vers la
passerelle SIP GW2.
La passerelle SIP GW1 transmet un message Release
Complete vers PBX A et la session est terminée.
19
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 pas-
serelle 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

20
User A PBX A GW1 GW2 PBX B User B

Réseau IP

Proxy
Server

1. Setup
2. INVITE
4. INVITE
3. Call Proceeding
5. 100 Trying 6. Setup
7. 100 Trying
8. Call Proceeding
9. Alerting
10. 180 Ringing
11. 180 Ringing
12. Alerting

Canal voix 1-way Canal RTP 2-way Canal voix 1-way

13. Connect
14. 200 OK
15. 200 OK
16. Connect

17. Connect ACK

18. ACK
19. ACK
20. Connect ACK

Canal voix 2-way Canal RTP 2-way Canal voix 2-way

21. Disconnect
22. BYE
23. BYE
24. Disconnect 25. Release

26. Release
27. 200 OK
28. 200 OK

30. Release Complete 29. Release Complete

SIP Gateway vers SIP Gateway - Appel via Proxy Server

avec Record Route validé

21
Message
1. Setup— PBX A vers Gateway SIP
GW1
2. INVITE— GatewaySIP GW1 vers
Proxy server SIP
3. Call Proceeding— Gateway SIP
GW1 vers PBX A
4. INVITE— Proxy Server SIP vers
Gateway SIP GW2
5. 100 Trying— Proxy Server SIP
vers Gateway SIP GW1
6. Setup— Gateway SIP GW2 vers
PBX B
Description
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.
La passerelle SIP GW1 transmet une requête INVITE au
Proxy Server SIP. La requête invite est une demande
faite à 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:5550100@companyb.com;
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é.
La passerelle SIP GW1 transmet un message Call
Proceeding vers PBX A pour acquitter la requête Setup.
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 la
requê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 nouvelle
requête INVITE vers la passerelle SIP GW2..
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 Proxy
server SIP GW1 et initie un message Setup vers User B
via PBX B.
22
Message
7. 100 Trying— Gateway SIP GW2
vers Proxy server SIP
8. Call Proceeding—PBX B vers
Gateway SIP GW2
9. Alerting—PBX B vers Gateway
SIP GW2
10. 180 Ringing— Gateway SIP
GW2 vers Proxy server SIP
11. 180 Ringing— Proxy server SIP
vers Gateway SIP GW1
12. Alerting— Gateway SIP GW1
vers PBX A
13. Connect— PBX B vers Gateway
SIP GW2
14. 200 OK— Gateway SIP GW2
vers Proxy server SIP
15. 200 OK— Proxy server SIP
vers Gateway SIP GW1
Description
La passerelle SIP GW2 transmet une réponse 100 Trying
vers le Proxy server. Le Proxy server SIP peut acheminer
ou non la réponse 100 Trying vers la passerelle SIP GW1
PBX B transmet un message Call Proceeding vers la
passerelle SIP GW2 pour acquitter la requête Setup.
PBX B localise User B et transmet un message Alert vers
la passerelle SIP GW2. Le téléphone de User B commence
à sonner.
La passerelle SIP GW2 transmet un message 180 Ringing
vers le Proxy server.
Le Proxy server SIP achemine la réponse 180 Ringing
vers la passerelle SIP GW1.
La passerelle SIP GW1 transmet un message Alert vers
User 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 entre
la passerelle SIP GW1 et PBX A et entre la passerelle SIP
GW2 et PBX B. Un canal RTP bidirectionnel est établi en-
tre les passerelles SIP GW1 et 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.
La passerelle SIP GW2 transmet un message 200 OK
( incluant l'en-tête Record-route reçu dans la requête
INVITE) vers le Proxy server SIP. Le message 200 OK
notifie au Proxy server SIP 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, il
annonce l'intersection de ses propres capacités média
avec celles de User A dans le message 200 OK. Si User B
ne supporte pas la capacité média annoncée par User A,
il transmet en retour la réponse 400 Bad Request avec
le champ 304 Warning dans l'en-tête.
Le Proxy server SIP doit acheminer la réponse 200 OK en
amont.
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 dans
le chemin des requêtes suivantespour la même branche
de la communication. Le Proxy server SIP rajoute sa pro-
pre Request-URI dans le champ Record-route.
23
Message
16. Connect— Gateway SIP GW1
vers PBX A
17. Connect ACK— PBX A vers
Gateway SIP GW1
18. ACK— Gateway SIP GW1 vers
Proxy server SIP
19. ACK— Proxy server SIP vers
Gateway SIP GW2
20. Connect ACK— Gateway SIP
GW2 vers PBX B
21. Disconnect— PBX B vers
Gateway SIP GW2
22. BYE— Gateway SIP GW2 vers
Proxy server SIP
23. BYE— Proxy server SIP vers
Gateway SIP GW1
24. Disconnect— Gateway SIP
GW1 vers PBX A
25. Release— Gateway SIP GW2
vers PBX B
26. Release— PBX A vers Gateway
SIP GW1
27. 200 OK— Gateway SIP GW1
vers Proxy server SIP
Description
La passerelle SIP GW1 transmet un message Connect
vers PBX A. Le message Connect notifie à PBX A que la
connexion a été faite.
PBX A acquitte le message Connect de la passerelle SIP
GW1.
La passerelle SIP GW1 transmet un ACK vers le Proxy
server SIP. Le message ACK confirme que la passerelle
SIP GW1 a bien reçu le message 200 OK du Proxy server
SIP.
Selon les valeurs des champs To, From, Cseq et Call-ID le
Proxy server traitera l'ACK localement ou le mandatera. Si
les champs dans l'ACK ne correspondent à ceux des
requê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ête
INVITE.
Le Proxy server SIP achemine la réponse ACK de la pas-
serelle SIP GW1 vers la passerelle SIP GW2.
La passerelle SIP GW2 acquiite le message Connect de
PBX B.
La session est maintenant active à travers un canal voix
RTP (Real-time Transport Protocol) bidirectionnel.
A ce point, un canal voix bidirectionnel est établi entre
la passerelle SIP GW1 et PBX A et entre la passerelle SIP
GW2 et PBX B. Un canal RTP bidirectionnel est établi en-
tre les passerelles SIP GW1 et GW2 sans passer par le
Proxy server SIP.
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.
La passerelle SIP GW2 transmet une requête BYE vers le
Proxy server SIP. La requête BYE indique que User B
veut terminer la communication. Le champ Request-URI
est remplacé par l'URL SIP de PBX A et le champ From
contient l'URL SIP de User B.
Le Proxy server SIP achemine la requête BYE vers la pas-
serelle SIP GW1.
La passerelle SIP GW1 transmet un message Disconnect
vers PBX A.
La passerelle SIP GW2 transmet un message Release vers
PBX B.
PBX A transmet un message Release vers la passerelle
SIP GW1.
La passerelle SIP GW1 transmet un message 200 OK en
ré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.
24
Message Description
28. 200 OK— Proxy server SIP Le Proxy server SIP achmine le message 200 OK vers la
vers Gateway SIP GW2 passerelle SIP GW2.

29. Release Complete— PBX B PBX B transmet un message Release Complete vers la
vers Gateway SIP GW2 passerelle SIP GW2.

30. Release Complete— Gateway La passerelle SIP GW1 transmet un message Release
SIP GW1 vers PBX A Complete vers PBX A et la session est terminée.

SIP Gateway vers SIP Gateway - Appel via Proxy Server

avec Record Route validé

User A PBX A GW1 GW2 PBX B User B

Réseau IP

Proxy
Server

1. Setup
2. INVITE
4. INVITE
3. Call Proceeding
5. 100 Trying 6. Setup
7. 100 Trying
8. Call Proceeding
9. Alerting
10. 180 Ringing
11. 180 Ringing
12. Alerting

Canal voix 1-way Canal RTP 2-way Canal voix 1-way

13. Connect
14. 200 OK
15. 200 OK
16. Connect

17. Connect ACK

18. ACK
19. Connect ACK

Canal voix 2-way Canal RTP 2-way Canal voix 2-way

20. Disconnect
21. BYE
22. Disconnect
23. Release

24. Release
25. 200 OK
30. Release Complete 26. Release Complete

25
Message
1. Setup— PBX A vers Gateway SIP
GW1
2. INVITE— GatewaySIP GW1 vers
Proxy server SIP
3. Call Proceeding— Gateway SIP
GW1 vers PBX A
4. INVITE— Proxy Server SIP vers
Gateway SIP GW2
5. 100 Trying— Proxy Server SIP
vers Gateway SIP GW1
6. Setup— Gateway SIP GW2 vers
PBX B
Description
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.
La passerelle SIP GW1 transmet une requête INVITE au
Proxy Server SIP. La requête invite est une demande
faite à 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:5550100@companyb.com;
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é.
La passerelle SIP GW1 transmet un message Call
Proceeding vers PBX A pour acquitter la requête Setup.
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 la
requê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 nouvelle
requête INVITE vers la passerelle SIP GW2..
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 Proxy
server SIP GW1 et initie un message Setup vers User B
via PBX B.
26
Message
7. 100 Trying— Gateway SIP GW2
vers Proxy server SIP
8. Call Proceeding—PBX B vers
Gateway SIP GW2
9. Alerting—PBX B vers Gateway
SIP GW2
10. 180 Ringing— Gateway SIP
GW2 vers Proxy server SIP
11. 180 Ringing— Proxy server SIP
vers Gateway SIP GW1
12. Alerting— Gateway SIP GW1
vers PBX A
13. Connect— PBX B vers Gateway
SIP GW2
14. 200 OK— Gateway SIP GW2
vers Proxy server SIP
15. 200 OK— Proxy server SIP
vers Gateway SIP GW1
Description
La passerelle SIP GW2 transmet une réponse 100 Trying
vers le Proxy server. Le Proxy server SIP peut acheminer
ou non la réponse 100 Trying vers la passerelle SIP GW1
PBX B transmet un message Call Proceeding vers la
passerelle SIP GW2 pour acquitter la requête Setup.
PBX B localise User B et transmet un message Alert vers
la passerelle SIP GW2. Le téléphone de User B commence
à sonner.
La passerelle SIP GW2 transmet un message 180 Ringing
vers le Proxy server.
Le Proxy server SIP achemine la réponse 180 Ringing
vers la passerelle SIP GW1.
La passerelle SIP GW1 transmet un message Alert vers
User 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 entre
la passerelle SIP GW1 et PBX A et entre la passerelle SIP
GW2 et PBX B. Un canal RTP bidirectionnel est établi en-
tre les passerelles SIP GW1 et 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.
La passerelle SIP GW2 transmet un message 200 OK
( incluant l'en-tête Record-route reçu dans la requête
INVITE) vers le Proxy server SIP. Le message 200 OK
notifie au Proxy server SIP 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, il
annonce l'intersection de ses propres capacités média
avec celles de User A dans le message 200 OK. Si User B
ne supporte pas la capacité média annoncée par User A,
il transmet en retour la réponse 400 Bad Request avec
le champ 304 Warning dans l'en-tête.
Le Proxy server SIP doit acheminer la réponse 200 OK en
amont.
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 dans
le chemin des requêtes suivantespour la même branche
de la communication. Le Proxy server SIP rajoute sa pro-
pre Request-URI dans le champ Record-route.
27
Message
16. Connect— Gateway SIP GW1
vers PBX A
17. Connect ACK— PBX A vers
Gateway SIP GW1
18. ACK— Gateway SIP GW1 vers
Gateway SIP GW2
19. Connect ACK— Gateway SIP
GW2 vers PBX B
20. Disconnect— PBX B vers
Gateway SIP GW2
21. BYE— Gateway SIP GW2 vers
Gateway SIP GW1
22. Disconnect— Gateway SIP
GW1 vers PBX A
23. Release— Gateway SIP GW2
vers PBX B
24. Release— PBX A vers Gateway
SIP GW1
25. 200 OK— Gateway SIP GW1
Gateway SIP GW2
26. Release Complete— PBX B
vers Gateway SIP GW2
27. Release Complete— Gateway
SIP GW1 vers PBX A
Description
La passerelle SIP GW1 transmet un message Connect
vers PBX A. Le message Connect notifie à PBX A que la
connexion a été faite.
PBX A acquitte le message Connect de la passerelle SIP
GW1.
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.
La passerelle SIP GW2 acquiite le message Connect de
PBX B.
La session est maintenant active à travers un canal voix
RTP (Real-time Transport Protocol) bidirectionnel.
A ce point, un canal voix bidirectionnel est établi entre
la passerelle SIP GW1 et PBX A et entre la passerelle SIP
GW2 et PBX B. Un canal RTP bidirectionnel est établi en-
tre les passerelles SIP GW1 et GW2 sans passer par le
Proxy server SIP.
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.
La passerelle SIP GW2 transmet une requête BYE vers la
passerelle SIP GW1. La requête BYE indique que User B
veut terminer la communication. Le champ Request-URI
est remplacé par l'URL SIP de PBX A et le champ From
contient l'URL SIP de User B.
La passerelle SIP GW1 transmet un message Disconnect
vers PBX A.
La passerelle SIP GW2 transmet un message Release vers
PBX B.
PBX A transmet un message Release vers la passerelle
SIP GW1.
La passerelle SIP GW1 transmet un message 200 OK en
ré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.
PBX B transmet un message Release Complete vers la
passerelle SIP GW2.
La passerelle SIP GW1 transmet un message Release
Complete vers PBX A et la session est terminée.
28
Références additionnelles
Documents liés
Thème
Basic router configuration
Cisco IOS command references
Cisco IOS configuration
fundamentals and examples
Cisco IOS Voice Configuration
Library, including library
preface and glossary
Titre du document
• Cisco 2600 series documentation at
http://www.cisco.com/univercd/cc/td/doc/product/
access/acs_mod/cis2600/index.htm
• Cisco 3600 series documentation at
http://www.cisco.com/univercd/cc/td/doc/product/access
/acs_mod/cis3600/index.htm
• Cisco 3700 series documentation at
http://www.cisco.com/univercd/cc/td/doc/product/access
/acs_mod/cis3700/index.htm
• Cisco AS5300 documentation at
http://www.cisco.com/univercd/cc/td/doc/product/access
/acs_serv/5300/index.htm
• Cisco IOS Debug Command Reference, Release 12.3T at
http://www.cisco.com/univercd/cc/td/doc/product/softwa
re/ios123/123tcr/123dbr/index.htm
• Cisco IOS Voice Command Reference, Release 12.3T at
http://www.cisco.com/univercd/cc/td/doc/product/softwa
re/ios123/123tcr/123tvr/index.htm
• Cisco IOS Configuration Fundamentals Configuration Guide at
http://www.cisco.com/univercd/cc/td/doc/product/softwa
re/ios122/122cgcr/ffun_c/
• Cisco IOS Interface Command Reference at
http://www.cisco.com/univercd/cc/td/doc/product/softwa
re/ios122/122cgcr/finter_r/index.htm
• Cisco IOS Interface Configuration Guide at
http://www.cisco.com/univercd/cc/td/doc/product/softwa
re/ios122/122cgcr/finter_c/
• Cisco IOS Voice, Video, and Fax Configuration Guide, Release
12.2 at
http://www.cisco.com/univercd/cc/td/doc/product/softwa
re/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 Configuration Library at
http://www.cisco.com/univercd/cc/td/doc/product/softwa
re/ios123/123cgcr/vcl.htm
29
Thème Titre du document

Developer support • Developer Support Agreement at

http://www.cisco.com/go/developersupport

IVR script information TCL IVR API 2.0 Programming Guide at

http://www.cisco.com/univercd/cc/td/doc/product/access
/acs_serv/vapp_dev/tclivrv2/index.htm

NAT configuration • Configuring Network Address Translation: Getting Started at

http://www.cisco.com/warp/public/556/12.htm

SIP documents • Cisco SIP proxy server documents at

http://www.cisco.com/univercd/cc/td/doc/product/voice/
sipproxy/index.htm

• Guide to Cisco Systems' VoIP Infrastructure Solution for SIP at

http://www.cisco.com/univercd/cc/td/doc/product/voice/
sipsols/biggulp/index.htm
• Session Initiation Protocol Gateway Call Flows at
http://www.cisco.com/univercd/cc/td/doc/product/softwa
re/ios122/rel_docs/sip_flo/index.htm

SS7 for voice gateways • Configuring Media Gateways for the SS7 Interconnect for Voice
Gateways Solution at
http://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 at
http://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 at
http://www.cisco.com/univercd/cc/td/doc/product/softwa
re/ios123/123tcr/123dbr/index.htm

• Cisco IOS Voice Troubleshooting and Monitoring Guide at

http://www.cisco.com/univercd/cc/td/doc/product/softwa
re/ios123/123cgcr/vvfax_c/voipt_c/index.htm

• Internetwork Troubleshooting Guide at

http://www.cisco.com/univercd/cc/td/doc/cisintwk/itg_v1
/index.htm

• Troubleshooting and Debugging VoIP Call Basics at

http://www.cisco.com/warp/public/788/voip/voip_debugca
lls.html

• Voice over IP Troubleshooting and Monitoring at

http://cisco.com/univercd/cc/td/doc/product/software/io
s123/123cgcr/vvfax_c/voipt_c/index.htm

• VoIP Debug Commands at

http://www.cisco.com/univercd/cc/td/doc/product/access
/acs_mod/1700/1750/1750voip/debug.htm

30
Thème Titre du document
VoATM configuration • Configuring AAL2 and AAL5 for the High-Performance Advanced
Integration Module on the Cisco 2600 Series at
http://www.cisco.com/univercd/cc/td/doc/product/softwa
re/ios122/122newft/122limit/122x/122xa/122xa_2/ft_atai
m.htm
VoIP configuration • Voice over IP for the Cisco 2600/3600 Series at
http://www.cisco.com/univercd/cc/td/doc/product/access
/nubuvoip/voip3600/index.htm

• Voice over IP for the Cisco AS5300 at

http://www.cisco.com/univercd/cc/td/doc/product/access
nubuvoip/voip5300/index.htm

• Voice over IP for the Cisco AS5800 at

http://www.cisco.com/univercd/cc/td/doc/product/access
/nubuvoip/voip5800/index.htm
VSA information • RADIUS Vendor-Specific Attributes Voice Implementation Guide
at
http://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 at
http://www.cisco.com/univercd/cc/td/doc/cisintwk/ita/
Cisco Resource Policy Management System 2.0 at
http://www.cisco.com/univercd/cc/td/doc/product/access
/acs_soft/rpms/rpms_2-0/
VoIP Call Admission Control at
http://www.cisco.com/univercd/cc/td/doc/cisintwk/intsol
ns/voipsol/cac.htm

31
Standards
Standards Titre

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

Capability
draft-ietf-avt-profile-new-12.txt RTP Profile for Audio and Video Conferences with Minimal Control

draft-ietf-avt-rtp-cn-06.txt
draft-ietf-avt-rtp-mime-06.txt
draft-ietf-mmusic-sdp-
comedia-04.txt
draft-ietf-sipping-reason-
header-for-preemption-00
draft-ietf-sip-privacy-02
draft-ietf-sip-resource-priority-
05
draft-levy-diversion-06.txt
GR-268-CORE
RTP Payload for Comfort Noise, Internet Draft of the Internet
Engineering Task Force (IETF) Audio/Video Transport (AVT)
working group
MIME Type Registration of RTP Payload Formats
Connection-Oriented Media Transport in SDP
Extending the SIP for Preemption Events
SIP Extensions for Caller Identity and Privacy
Communications Resources Priority for SIP
[Sip] verification of diversion header (draft-levy)
ISDN Basic Rate Interface Call Control Switching and Signalling
Generic Requirements

MIBs
MIBs Liens MIBs
CISCO-SIP-UA-MIB To locate and download MIBs for selected platforms, Cisco IOS
releases, and feature sets, use Cisco MIB Locator found at the
following 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

32
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 Initiation

Protocol (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

33