SIP Session Initiation Protocol Prsentation Gnrale 1 Sommaire

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 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 avec un Proxy Server ● Comment SIP fonctione avec un Redirect Server ● Communications SIP ● Références additionnelles Information sur 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 Vo. IP, 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 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 modifications 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 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 (e. Xtensible Markup Language). Ces services applicatifs fournissent des services aux extrémités tels que répertoir, authentification et facturation. 4

SIP Proxy et Redirect Serveurs SIP User Agents (UAs) 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 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é. 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 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 optionnellement 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: user. ID@gateway. com. Le user. ID peut être soit un nom d'utilisateur soit une adresse E 164. Note: Une adresse E 164 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 chacune 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". 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 IP Client INVITE Serveur 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 IP Client Response 200 OK Serveur User agents Client Serveur Proxy Redirect Server Requête SIP à travers un Proxy Server 8

Le Proxy Server achemine les acquittements 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. ACK Réseau IP Client RTP ACK Serveur 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'information vers l'appelant. L'appelant acquitte la réception de l'information. INVITE 302 Moved temporarily Client ACK Réseau IP Serveur 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 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. INVITE 200 OK Client ACK RTP Réseau IP Serveur 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 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 (GW 1) via une liaison T 1/E 1. User B est situé sur PBX B qui est connecté à une passerelle SIP (GW 2) via une liaison T 1/E 1. Le numéro de téléphone de USER B est 555 0100. La passerelle SIP GW 1 est connectée à la passerelle GW 2 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 GW 1 GW 2 PBX B User B Réseau IP 1. Setup 3. Call Proceeding 2. INVITE 5. 100 Trying 4. Setup 6. Call Proceeding 7. Alerting 9. Alerting 8. 180 Ringing Canal RTP 2 -way Canal voix 1 -way 12. Connect 13. Connect ACK 11. 200 OK 14. ACK Canal RTP 2 -way Canal voix 2 -way 19. Disconnect 20. Release 23. Release Complete 17. BYE Canal voix 1 -way 10. Connect 15. Connect ACK Canal voix 2 -way 16. Disconnect 18. Release 21. 200 OK 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 Description 1. Setup—PBX A vers Gateway SIP GW 1 Le message d'appel est transmis du PBX A vers la Gateway SIP GW 1. Le message Setup comprend les transactions standards effactuées lorsque User A tente d'appeler User B. 2. INVITE— Gateway SIP GW 1 vers Gateway SIP GW 2 La passerelle SIP GW 1 transmet une requête INVITE à la passerelle SIP GW 2. La requête invite est une demande faite à User B de participer à une session de communication. 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 apparait comme "INVITE sip: 5550100@companyb. com; user=phone". Le paramètre "user=phone" indique 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 GW 1 est prête à recevoir les données RTP est spécifié. 3. Call Proceeding— Gateway SIP GW 1 vers PBX A La passerelle SIP GW 1 transmet un message Call Proceeding vers PBX A pour acquitter la requête Setup. 4. Setup— Gateway SIP GW 2 vers PBX B La passerelle SIP GW 2 reçoit la requête INVITE de la passerelle SIP GW 1 et initie un message Setup vers User B via PBX B. 5. 100 Trying— Gateway SIP GW 2 vers Gateway SIP GW 1 La passerelle SIP GW 2 transmet une réponse 100 Trying à la requête INVITE transmise pr la passerelle SIP GW 1. La réponse 100 Trying indique la requête INVITE a bien été reçue par la passerelle SIP GW 2 mais que User B n'a pas été encore localisé et qu'une action non spécifiée est en cours. 13

Message Description 6. Call Proceeding—PBX B vers Gateway SIP GW 2 PBX B transmet un message Call Proceeding vers la passerelle SIP GW 2 pour acquitter la requête Setup. 7. Alerting—PBX B vers Gateway SIP GW 2 PBX B localise User B et transmet un message Alert vers la passerelle SIP GW 2. Le téléphone de User B commence à sonner. 8. 180 Ringing— Gateway SIP GW 2 vers Gateway SIP GW 1 La passerelle SIP GW 2 transmet un message 180 Ringing vers la passerelle SIP GW 1. La réponse 180 Ringing indique la passerelle SIP GW 2 a localisé User B et tente d'alerter User B. 9. Alerting— Gateway SIP GW 1 vers PBX A La passerelle SIP GW 1 transmet un message Alert vers User A via PBX A. Le message Alert indique la passerelle SIP GW 1 a reçu une réponse 180 Ringing de la passerelle SIP GW 2. User A entend la tonalité de retour d'appel qui indique User B est alerté. A ce point, un canal voix unidirectionnel est établi entre la passerelle SIP GW 1 et PBX A et entre la passerelle SIP GW 2 et PBX B. Un canal RTP bidirectionnel est établi entre les passerelles SIP GW 1 et GW 2. 10. Connect— PBX B vers Gateway SIP GW 2 User B répond à l'appel. PBX B translet un message Connect vers la passerelle SIP GW 2. Le message Connect notifie à la passerelle GW 2 que la connexion a été faite. 11. 200 OK— Gateway SIP GW 2 vers Gateway SIP GW 1 La passerelle SIP GW 2 transmet un message 200 OK vers la passerelle SIP GW 1. Le message 200 OK notifie à la passerelle SIP GW 1 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 GW 1, 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. 12. Connect— Gateway SIP GW 1 vers PBX A La passerelle SIP GW 1 transmet un message connect vers PBX A. Le messafe Connect notifie à PBX A que la connexion a été faite. 13. Connect ACK— PBX A vers Gateway SIP GW 1 PBX A acquitte le message Connect de la passerelle SIP GW 1. 14. ACK— SIP Gateway GW 1 vers SIP Gateway GW 2 La passerelle SIP GW 1 transmet un message ACK vers la passerelle SIP GW 2. Le message ACK confirme que la passerelle SIP GW 1 a reçu le message de réponse 200 OK de la passerelle GW 2. 15. Connect ACK— Gateway SIP GW 2 vers PBX B La passerelle SIP GW 2 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 GW 1 et PBX A et entre la passerelle SIP GW 2 et PBX B. Un canal RTP bidirectionnel est établi entre les passerelles SIP GW 1 et GW 2. 14

Message Description 16. Disconnect— PBX B vers Gateway SIP GW 2 Lorsque User B raccroche son téléphone, PBX B transmet un message Disconnect vers la passerelle SIP GW 2. Le message Disconnect démarre le processus de libéra-tion de la session de communication. 17. BYE— Gateway SIP GW 2 vers Gateway SIP GW 1 La passerelle SIP GW 2 transmet une requête BYE vers la passerelle SIP GW 1. La requête BYE indique 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 GW 2 vers PBX B La passerelle SIP GW 2 transmet un message Release vers PBX B. 19. Disconnect— Gateway SIP GW 1 vers PBX A La passerelle SIP GW 1 transmet un message Disconnect vers PBX A. 20. Release— PBX A vers Gateway SIP GW 1 PBX A transmet un message Release vers la passerelle SIP GW 1. 21. 200 OK— Gateway. SIP GW 1 vers Gateway SIP GW 2 La passerelle SIP GW 1 transmet un message 200 OK en réponse à la passerelle SIP GW 2. Le message 200 OK notifie à la passerelle SIP GW 2 que la passerelle SIP GW 1 a reçue la requête BYE. 22. Release Complete— PBX B vers Gateway SIP GW 2 PBX B transmet un message Release Complete vers la passerelle SIP GW 2. 23. Release Complete— Gateway SIP GW 1 vers PBX A La passerelle SIP GW 1 transmet un message Release 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 est connecté à la passerelle SIP GW 1 via une liaison T 1/E 1. La passerelle SIP GW 1 utilise un Redirect Server. User B est situé sur PBX B est connecté à la passerelle SIP GW 2 via une liaison T 1/E 1. Le numéro de téléphone de User B est 555 0100. La passerelle SIP GW 1 est connectée à la passerelle GW 2 par un réseau IP. Le scénario de la communication est le suivant: 1. User A appelle User B via GW 1 en utilisant un Redirect Server 2. User B répond à l'appel 3. User B termine la communication 15

User A PBX A GW 1 GW 2 PBX B User B Réseau IP Redirect Server 1. Setup 2. INVITE 3. 300 Multiple Choice 4. ACK 5. INVITE 7. Call Proceeding 8. 100 Trying 6. Setup 9. Call Proceeding 10. Alerting 12. Alerting 11. 180 Ringing Canal RTP 2 -way Canal voix 1 -way 15. Connect 16. Connect ACK 14. 200 OK 17. ACK Canal RTP 2 -way Canal voix 2 -way 21. Disconnect 23. Release 26. Release Complete 20. BYE Canal voix 1 -way 13. Connect 18. Connect ACK Canal voix 2 -way 19. Disconnect 22. Release 24. 200 OK 25. Release Complete 16

Message Description 1. Setup— PBX A vers Gateway SIP GW 1 Le message d'appel est transmis du PBX A vers la Gateway SIP GW 1. Le message Setup comprend les transactions standards effactuées lorsque User A tente d'appeler User B. 2. INVITE— Gateway. SIP GW 1 vers redirect server SIP La passerelle SIP GW 1 transmet une requête INVITE au Redirect Server SIP. La requête invite est une demande faite à User B de participer à une session de communication. 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 apparait comme "INVITE sip: 5550100@companyb. com; user=phone". Le paramètre "user=phone" indique 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 GW 1 est prête à recevoir les données RTP est spécifié. 3. 300 Multiple Choice— Redirect server SIP vers Gateway SIP GW 1 Le serveur Redirect SIP transmet une réponse 300 Multiple Choice à la passerelle SIP GW 1. La réponse 300 Multiple Choice indique 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 serveur de localisation a fourni une liste de localisations possibles de User B. Le serveur Redirect SIP retourne ces adresses possibles à la passerelle SIP GW 1 dans le message 300 Multiple Choice. 4. ACK— Gateway. SIP GW 1 vers Redirect server SIP La passerelle SIP GW 1 acquitte la réponse 300 Multiple Choice avec un message ACK. 5. INVITE— Gateway SIP GW 1 vers Gateway SIP GW 2 La passerelle SIP GW 1 transmet une requête INVITE à la passerelle SIP GW 2. 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 Description 6. Setup— Gateway SIP GW 2 vers PBX B La passerelle SIP GW 2 reçoit la requête INVITE de la passerelle SIP GW 1 et initie un message Setup vers User B via PBX B. 7. Call Proceeding— Gateway SIP GW 1 vers PBX A La passerelle SIP GW 1 transmet un message Call Proceeding vers PBX A pour acquitter la requête Setup. 8. 100 Trying— Gateway SIP GW 2 vers Gateway SIP GW 1 La passerelle SIP GW 2 transmet une réponse 100 Trying à la requête INVITE transmise pr la passerelle SIP GW 1. La réponse 100 Trying indique la requête INVITE a bien été reçue par la passerelle SIP GW 2 mais que User B n'a pas été encore localisé et qu'une action non spécifiée est en cours. 9. Call Proceeding—PBX B vers Gateway SIP GW 2 PBX B transmet un message Call Proceeding vers la passerelle SIP GW 2 pour acquitter la requête Setup. 10. Alerting—PBX B vers Gateway SIP GW 2 PBX B localise User B et transmet un message Alert vers la passerelle SIP GW 2. Le téléphone de User B commence à sonner. 11. 180 Ringing— Gateway SIP GW 2 vers Gateway SIP GW 1 La passerelle SIP GW 2 transmet un message 180 Ringing vers la passerelle SIP GW 1. La réponse 180 Ringing indique la passerelle SIP GW 2 a localisé User B et tente d'alerter User B. 12. Alerting— Gateway SIP GW 1 vers PBX A La passerelle SIP GW 1 transmet un message Alert vers User A via PBX A. Le message Alert indique la passerelle SIP GW 1 a reçu une réponse 180 Ringing de la passerelle SIP GW 2. User A entend la tonalité de retour d'appel qui indique User B est alerté. A ce point, un canal voix unidirectionnel est établi entre la passerelle SIP GW 1 et PBX A et entre la passerelle SIP GW 2 et PBX B. Un canal RTP bidirectionnel est établi entre les passerelles SIP GW 1 et GW 2. 13. Connect— PBX B vers Gateway SIP GW 2 User B répond à l'appel. PBX B translet un message Connect vers la passerelle SIP GW 2. Le message Connect notifie à la passerelle GW 2 que la connexion a été faite. 14. 200 OK— Gateway SIP GW 2 vers Gateway SIP GW 1 La passerelle SIP GW 2 transmet un message 200 OK vers la passerelle SIP GW 1. Le message 200 OK notifie à la passerelle SIP GW 1 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 GW 1, 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. 15. Connect— Gateway SIP GW 1 vers PBX A La passerelle SIP GW 1 transmet un message connect vers PBX A. Le messafe Connect notifie à PBX A que la connexion a été faite. 16. Connect ACK— PBX A vers Gateway SIP GW 1 PBX A acquitte le message Connect de la passerelle SIP GW 1. 18

Message Description 17. ACK— SIP Gateway GW 1 vers SIP Gateway GW 2 La passerelle SIP GW 1 transmet un message ACK vers la passerelle SIP GW 2. Le message ACK confirme que la passerelle SIP GW 1 a reçu le message de réponse 200 OK de la passerelle GW 2. 18. Connect ACK— Gateway SIP GW 2 vers PBX B La passerelle SIP GW 2 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 GW 1 et PBX A et entre la passerelle SIP GW 2 et PBX B. Un canal RTP bidirectionnel est établi entre les passerelles SIP GW 1 et GW 2. 19. Disconnect— PBX B vers Gateway SIP GW 2 Lorsque User B raccroche son téléphone, PBX B transmet un message Disconnect vers la passerelle SIP GW 2. Le message Disconnect démarre le processus de libéra-tion de la session de communication. 20. BYE— Gateway SIP GW 2 vers Gateway SIP GW 1 La passerelle SIP GW 2 transmet une requête BYE vers la passerelle SIP GW 1. La requête BYE indique 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. 21. Disconnect— Gateway SIP GW 1 vers PBX A La passerelle SIP GW 1 transmet un message Disconnect vers PBX A. 22. Release— Gateway SIP GW 2 vers PBX B La passerelle SIP GW 2 transmet un message Release vers PBX B. 23. Release— PBX A vers Gateway SIP GW 1 PBX A transmet un message Release vers la passerelle SIP GW 1. 24. 200 OK— Gateway. SIP GW 1 vers Gateway SIP GW 2 La passerelle SIP GW 1 transmet un message 200 OK en réponse à la passerelle SIP GW 2. Le message 200 OK notifie à la passerelle SIP GW 2 que la passerelle SIP GW 1 a reçu la requête BYE. 25. Release Complete— PBX B vers Gateway SIP GW 2 PBX B transmet un message Release Complete vers la passerelle SIP GW 2. 26. Release Complete— Gateway SIP GW 1 vers PBX A La passerelle SIP GW 1 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 (GW 1) via une liaison T 1/E 1. La passerelle SIP GW 1 contient le Proxy Server. La passerelle SIP GW 1 est connectée à la passerelle GW 2 par un réseau IP. User B est situé sur PBX B qui est connecté à une passerelle SIP (GW 2) via une liaison T 1/E 1. Le numé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 Server. 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 Record-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 GW 1 en utilisant un Proxy Server 2. User B répond à l'appel 3. User B termine la communication 20

User A GW 1 PBX A GW 2 PBX B User B Réseau IP Proxy Server 1. Setup 2. INVITE 3. Call Proceeding 4. INVITE 6. Setup 5. 100 Trying 7. 100 Trying 8. Call Proceeding 10. 180 Ringing 9. Alerting 11. 180 Ringing 12. Alerting Canal voix 1 -way Canal RTP 2 -way 14. 200 OK Canal voix 1 -way 13. Connect 15. 200 OK 16. Connect 17. Connect ACK 18. ACK 19. ACK Canal RTP 2 -way Canal voix 2 -way 22. BYE 20. Connect ACK Canal voix 2 -way 21. Disconnect 23. BYE 25. Release 24. Disconnect 26. Release 27. 200 OK 30. Release Complete 28. 200 OK 29. Release Complete SIP Gateway vers SIP Gateway - Appel via Proxy Server avec Record Route validé 21

Message Description 1. Setup— PBX A vers Gateway SIP GW 1 Le message d'appel est transmis du PBX A vers la Gateway SIP GW 1. Le message Setup comprend les transactions standards effactuées lorsque User A tente d'appeler User B. 2. INVITE— Gateway. SIP GW 1 vers Proxy server SIP La passerelle SIP GW 1 transmet une requête INVITE au Proxy Server SIP. La requête invite est une demande faite à User B de participer à une session de communication. 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 apparait comme "INVITE sip: 5550100@companyb. com; user=phone". Le paramètre "user=phone" indique 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 GW 1 est prête à recevoir les données RTP est spécifié. 3. Call Proceeding— Gateway SIP GW 1 vers PBX A La passerelle SIP GW 1 transmet un message Call Proceeding vers PBX A pour acquitter la requête Setup. 4. INVITE— Proxy Server SIP vers Gateway SIP GW 2 La Proxy Server SIP vérifie si sa propre adresse est contenue dans le champ Via (pour éviter les boucles), copie directement les champs To, From, Call-ID et Contact de la requête reçue de la passerelle SIP GW 1, change la Request-URI pour indiquer le serveur vers lequel il va envoyer la requête INVITE et ensuite transmet la nouvelle requête INVITE vers la passerelle SIP GW 2. . 5. 100 Trying— Proxy Server SIP vers Gateway SIP GW 1 Le Proxy Server SIP transmet la réponse 100 Trying à la passerelle SIP GW 1. 6. Setup— Gateway SIP GW 2 vers PBX B La passerelle SIP GW 2 reçoit la requête INVITE du Proxy server SIP GW 1 et initie un message Setup vers User B via PBX B. 22

Message Description 7. 100 Trying— Gateway SIP GW 2 vers Proxy server SIP La passerelle SIP GW 2 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 GW 1 8. Call Proceeding—PBX B vers Gateway SIP GW 2 PBX B transmet un message Call Proceeding vers la passerelle SIP GW 2 pour acquitter la requête Setup. 9. Alerting—PBX B vers Gateway SIP GW 2 PBX B localise User B et transmet un message Alert vers la passerelle SIP GW 2. Le téléphone de User B commence à sonner. 10. 180 Ringing— Gateway SIP GW 2 vers Proxy server SIP La passerelle SIP GW 2 transmet un message 180 Ringing vers le Proxy server. 11. 180 Ringing— Proxy server SIP vers Gateway SIP GW 1 Le Proxy server SIP achemine la réponse 180 Ringing vers la passerelle SIP GW 1. 12. Alerting— Gateway SIP GW 1 vers PBX A La passerelle SIP GW 1 transmet un message Alert vers User A via PBX A. Le message Alert indique la passerelle SIP GW 1 a reçu une réponse 180 Ringing de la passerelle SIP GW 2. User A entend la tonalité de retour d'appel qui indique User B est alerté. A ce point, un canal voix unidirectionnel est établi entre la passerelle SIP GW 1 et PBX A et entre la passerelle SIP GW 2 et PBX B. Un canal RTP bidirectionnel est établi entre les passerelles SIP GW 1 et GW 2. 13. Connect— PBX B vers Gateway SIP GW 2 User B répond à l'appel. PBX B translet un message Connect vers la passerelle SIP GW 2. Le message Connect notifie à la passerelle GW 2 que la connexion a été faite. 14. 200 OK— Gateway SIP GW 2 vers Proxy server SIP La passerelle SIP GW 2 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 GW 1, 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. 15. 200 OK— Proxy server SIP vers Gateway SIP GW 1 Le Proxy server SIP achemine la réponse 200 OK qu'il a reçue de la passerelle SIP GW 2 vers la passerelle SIP GW 1. Dans la réponse 200 OK, le Proxy server SIP achemine 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 propre Request-URI dans le champ Record-route. 23

Message Description 16. Connect— Gateway SIP GW 1 vers PBX A La passerelle SIP GW 1 transmet un message Connect vers PBX A. Le message Connect notifie à PBX A que la connexion a été faite. 17. Connect ACK— PBX A vers Gateway SIP GW 1 PBX A acquitte le message Connect de la passerelle SIP GW 1. 18. ACK— Gateway SIP GW 1 vers Proxy server SIP La passerelle SIP GW 1 transmet un ACK vers le Proxy server SIP. Le message ACK confirme que la passerelle SIP GW 1 a bien reçu le message 200 OK du Proxy server SIP. 19. ACK— Proxy server SIP vers Gateway SIP GW 2 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 correspondance , l'ACK est mandaté comme si c'était une requête INVITE. Le Proxy server SIP achemine la réponse ACK de la passerelle SIP GW 1 vers la passerelle SIP GW 2. 20. Connect ACK— Gateway SIP GW 2 vers PBX B La passerelle SIP GW 2 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 GW 1 et PBX A et entre la passerelle SIP GW 2 et PBX B. Un canal RTP bidirectionnel est établi entre les passerelles SIP GW 1 et GW 2 sans passer par le Proxy server SIP. 21. Disconnect— PBX B vers Gateway SIP GW 2 Lorsque User B raccroche son téléphone, PBX B transmet un message Disconnect vers la passerelle SIP GW 2. Le message Disconnect démarre le processus de libéra-tion de la session de communication. 22. BYE— Gateway SIP GW 2 vers Proxy server SIP La passerelle SIP GW 2 transmet une requête BYE vers le Proxy server SIP. La requête BYE indique 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. 23. BYE— Proxy server SIP vers Gateway SIP GW 1 Le Proxy server SIP achemine la requête BYE vers la passerelle SIP GW 1. 24. Disconnect— Gateway SIP GW 1 vers PBX A La passerelle SIP GW 1 transmet un message Disconnect vers PBX A. 25. Release— Gateway SIP GW 2 vers PBX B La passerelle SIP GW 2 transmet un message Release vers PBX B. 26. Release— PBX A vers Gateway SIP GW 1 PBX A transmet un message Release vers la passerelle SIP GW 1. 27. 200 OK— Gateway SIP GW 1 vers Proxy server SIP La passerelle SIP GW 1 transmet un message 200 OK en réponse vers le Proxy server. Le message 200 OK notifie à la passerelle SIP GW 2 que la passerelle SIP GW 1 a reçu la requête BYE. 24

Message Description 28. 200 OK— Proxy server SIP vers Gateway SIP GW 2 Le Proxy server SIP achmine le message 200 OK vers la passerelle SIP GW 2. 29. Release Complete— PBX B vers Gateway SIP GW 2 PBX B transmet un message Release Complete vers la passerelle SIP GW 2. 30. Release Complete— Gateway SIP GW 1 vers PBX A La passerelle SIP GW 1 transmet un message Release 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 GW 1 GW 2 PBX B User B Réseau IP Proxy Server 1. Setup 2. INVITE 3. Call Proceeding 4. INVITE 6. Setup 5. 100 Trying 7. 100 Trying 8. Call Proceeding 10. 180 Ringing 9. Alerting 11. 180 Ringing 12. Alerting Canal voix 1 -way Canal RTP 2 -way 14. 200 OK Canal voix 1 -way 13. Connect 15. 200 OK 16. Connect 17. Connect ACK 18. ACK 19. Connect ACK Canal RTP 2 -way Canal voix 2 -way 21. BYE 22. Disconnect 24. Release 30. Release Complete Canal voix 2 -way 20. Disconnect 23. Release 25. 200 OK 26. Release Complete 25

Message Description 1. Setup— PBX A vers Gateway SIP GW 1 Le message d'appel est transmis du PBX A vers la Gateway SIP GW 1. Le message Setup comprend les transactions standards effactuées lorsque User A tente d'appeler User B. 2. INVITE— Gateway. SIP GW 1 vers Proxy server SIP La passerelle SIP GW 1 transmet une requête INVITE au Proxy Server SIP. La requête invite est une demande faite à User B de participer à une session de communication. 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 apparait comme "INVITE sip: 5550100@companyb. com; user=phone". Le paramètre "user=phone" indique 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 GW 1 est prête à recevoir les données RTP est spécifié. 3. Call Proceeding— Gateway SIP GW 1 vers PBX A La passerelle SIP GW 1 transmet un message Call Proceeding vers PBX A pour acquitter la requête Setup. 4. INVITE— Proxy Server SIP vers Gateway SIP GW 2 La Proxy Server SIP vérifie si sa propre adresse est contenue dans le champ Via (pour éviter les boucles), copie directement les champs To, From, Call-ID et Contact de la requête reçue de la passerelle SIP GW 1, change la Request-URI pour indiquer le serveur vers lequel il va envoyer la requête INVITE et ensuite transmet la nouvelle requête INVITE vers la passerelle SIP GW 2. . 5. 100 Trying— Proxy Server SIP vers Gateway SIP GW 1 Le Proxy Server SIP transmet la réponse 100 Trying à la passerelle SIP GW 1. 6. Setup— Gateway SIP GW 2 vers PBX B La passerelle SIP GW 2 reçoit la requête INVITE du Proxy server SIP GW 1 et initie un message Setup vers User B via PBX B. 26

Message Description 7. 100 Trying— Gateway SIP GW 2 vers Proxy server SIP La passerelle SIP GW 2 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 GW 1 8. Call Proceeding—PBX B vers Gateway SIP GW 2 PBX B transmet un message Call Proceeding vers la passerelle SIP GW 2 pour acquitter la requête Setup. 9. Alerting—PBX B vers Gateway SIP GW 2 PBX B localise User B et transmet un message Alert vers la passerelle SIP GW 2. Le téléphone de User B commence à sonner. 10. 180 Ringing— Gateway SIP GW 2 vers Proxy server SIP La passerelle SIP GW 2 transmet un message 180 Ringing vers le Proxy server. 11. 180 Ringing— Proxy server SIP vers Gateway SIP GW 1 Le Proxy server SIP achemine la réponse 180 Ringing vers la passerelle SIP GW 1. 12. Alerting— Gateway SIP GW 1 vers PBX A La passerelle SIP GW 1 transmet un message Alert vers User A via PBX A. Le message Alert indique la passerelle SIP GW 1 a reçu une réponse 180 Ringing de la passerelle SIP GW 2. User A entend la tonalité de retour d'appel qui indique User B est alerté. A ce point, un canal voix unidirectionnel est établi entre la passerelle SIP GW 1 et PBX A et entre la passerelle SIP GW 2 et PBX B. Un canal RTP bidirectionnel est établi entre les passerelles SIP GW 1 et GW 2. 13. Connect— PBX B vers Gateway SIP GW 2 User B répond à l'appel. PBX B translet un message Connect vers la passerelle SIP GW 2. Le message Connect notifie à la passerelle GW 2 que la connexion a été faite. 14. 200 OK— Gateway SIP GW 2 vers Proxy server SIP La passerelle SIP GW 2 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 GW 1, 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. 15. 200 OK— Proxy server SIP vers Gateway SIP GW 1 Le Proxy server SIP achemine la réponse 200 OK qu'il a reçue de la passerelle SIP GW 2 vers la passerelle SIP GW 1. Dans la réponse 200 OK, le Proxy server SIP achemine 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 propre Request-URI dans le champ Record-route. 27

Message Description 16. Connect— Gateway SIP GW 1 vers PBX A La passerelle SIP GW 1 transmet un message Connect vers PBX A. Le message Connect notifie à PBX A que la connexion a été faite. 17. Connect ACK— PBX A vers Gateway SIP GW 1 PBX A acquitte le message Connect de la passerelle SIP GW 1. 18. ACK— Gateway SIP GW 1 vers Gateway SIP GW 2 La passerelle SIP GW 1 transmet un ACK vers la passe-relle SIP GW 2. Le message ACK confirme que la passe-relle SIP GW 1 a bien reçu le message 200 OK du Proxy server SIP. 19. Connect ACK— Gateway SIP GW 2 vers PBX B La passerelle SIP GW 2 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 GW 1 et PBX A et entre la passerelle SIP GW 2 et PBX B. Un canal RTP bidirectionnel est établi entre les passerelles SIP GW 1 et GW 2 sans passer par le Proxy server SIP. 20. Disconnect— PBX B vers Gateway SIP GW 2 Lorsque User B raccroche son téléphone, PBX B transmet un message Disconnect vers la passerelle SIP GW 2. Le message Disconnect démarre le processus de libéra-tion de la session de communication. 21. BYE— Gateway SIP GW 2 vers Gateway SIP GW 1 La passerelle SIP GW 2 transmet une requête BYE vers la passerelle SIP GW 1. La requête BYE indique 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. 22. Disconnect— Gateway SIP GW 1 vers PBX A La passerelle SIP GW 1 transmet un message Disconnect vers PBX A. 23. Release— Gateway SIP GW 2 vers PBX B La passerelle SIP GW 2 transmet un message Release vers PBX B. 24. Release— PBX A vers Gateway SIP GW 1 PBX A transmet un message Release vers la passerelle SIP GW 1. 25. 200 OK— Gateway SIP GW 1 Gateway SIP GW 2 La passerelle SIP GW 1 transmet un message 200 OK en réponse vers la passerelle SIP GW 2. Le message 200 OK notifie à la passerelle SIP GW 2 que la passerelle SIP GW 1 a reçu la requête BYE. 26. Release Complete— PBX B vers Gateway SIP GW 2 PBX B transmet un message Release Complete vers la passerelle SIP GW 2. 27. Release Complete— Gateway SIP GW 1 vers PBX A La passerelle SIP GW 1 transmet un message Release Complete vers PBX A et la session est terminée. 28

Références additionnelles Documents liés Thème Titre du document Basic router configuration • Cisco 2600 series documentation at http: //www. cisco. com/univercd/cc/td/doc/product/ access/acs_mod/cis 2600/index. htm • Cisco 3600 series documentation at http: //www. cisco. com/univercd/cc/td/doc/product/access /acs_mod/cis 3600/index. htm • Cisco 3700 series documentation at http: //www. cisco. com/univercd/cc/td/doc/product/access /acs_mod/cis 3700/index. htm • Cisco AS 5300 documentation at http: //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. 3 T at http: //www. cisco. com/univercd/cc/td/doc/product/softwa re/ios 123/123 tcr/123 dbr/index. htm • Cisco IOS Voice Command Reference, Release 12. 3 T at http: //www. cisco. com/univercd/cc/td/doc/product/softwa re/ios 123/123 tcr/123 tvr/index. htm Cisco IOS configuration fundamentals and examples • Cisco IOS Configuration Fundamentals Configuration Guide at http: //www. cisco. com/univercd/cc/td/doc/product/softwa re/ios 122/122 cgcr/ffun_c/ • Cisco IOS Interface Command Reference at http: //www. cisco. com/univercd/cc/td/doc/product/softwa re/ios 122/122 cgcr/finter_r/index. htm • Cisco IOS Interface Configuration Guide at http: //www. cisco. com/univercd/cc/td/doc/product/softwa re/ios 122/122 cgcr/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/ios 122/122 cgcr/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, including library preface and glossary • Cisco IOS Voice Configuration Library at http: //www. cisco. com/univercd/cc/td/doc/product/softwa re/ios 123/123 cgcr/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/tclivrv 2/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' Vo. IP 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/ios 122/rel_docs/sip_flo/index. htm SS 7 for voice gateways • Configuring Media Gateways for the SS 7 Interconnect for Voice Gateways Solution at http: //www. cisco. com/univercd/cc/td/doc/product/access /sc/rel 7/soln/das 22/gateway/dascfg 5. 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/tclivrv 2/index. htm Troubleshooting • Cisco IOS Debug Command Reference, Release 12. 3 T at http: //www. cisco. com/univercd/cc/td/doc/product/softwa re/ios 123/123 tcr/123 dbr/index. htm • Cisco IOS Voice Troubleshooting and Monitoring Guide at http: //www. cisco. com/univercd/cc/td/doc/product/softwa re/ios 123/123 cgcr/vvfax_c/voipt_c/index. htm • Internetwork Troubleshooting Guide at http: //www. cisco. com/univercd/cc/td/doc/cisintwk/itg_v 1 /index. htm • Troubleshooting and Debugging Vo. IP Call Basics at http: //www. cisco. com/warp/public/788/voip_debugca lls. html • Voice over IP Troubleshooting and Monitoring at http: //cisco. com/univercd/cc/td/doc/product/software/io s 123/123 cgcr/vvfax_c/voipt_c/index. htm • Vo. IP Debug Commands at http: //www. cisco. com/univercd/cc/td/doc/product/access /acs_mod/1700/1750 voip/debug. htm 30

Thème Titre du document Vo. ATM configuration • Configuring AAL 2 and AAL 5 for the High-Performance Advanced Integration Module on the Cisco 2600 Series at http: //www. cisco. com/univercd/cc/td/doc/product/softwa re/ios 122/122 newft/122 limit/122 xa/122 xa_2/ft_atai m. htm Vo. IP configuration • Voice over IP for the Cisco 2600/3600 Series at http: //www. cisco. com/univercd/cc/td/doc/product/access /nubuvoip/voip 3600/index. htm • Voice over IP for the Cisco AS 5300 at http: //www. cisco. com/univercd/cc/td/doc/product/access nubuvoip/voip 5300/index. htm • Voice over IP for the Cisco AS 5800 at http: //www. cisco. com/univercd/cc/td/doc/product/access /nubuvoip/voip 5800/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/vsaig 3. htm WAN configuration • Cisco IOS Wide-Area Networking Command Reference at http: //www. cisco. com/univercd/cc/td/doc/product/software/ios 122/122 cgcr /fwan_r/index. htm • Cisco IOS Wide-Area Networking Configuration Guide at http: //www. cisco. com/univercd/cc/td/doc/product/software/ios 122/122 cgcr /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_2 -0/ Vo. IP Call Admission Control at http: //www. cisco. com/univercd/cc/td/doc/cisintwk/intsol ns/voipsol/cac. htm 31

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 RTP Payload for Comfort Noise, Internet Draft of the Internet Engineering 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-sdpcomedia-04. txt Connection-Oriented Media Transport in SDP draft-ietf-sipping-reasonheader-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 Signalling Generic Requirements 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 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