Processus des Communications SIP dans la solution d'infrastructure VoIP Cisco pour SIP

Sommaire • Introduction • Scénarios d'appels réussis - Passerelle SIP à Passerelle SIP - Etablissement d'appel et Libération - Passerelle SIP à Passerelle SIP - Appel via un serveur de Redirection - Passerelle SIP à Passerelle SIP - Appel via un serveur Proxy - Passerelle SIP à Passerelle SIP - Etablissement d'appel avec contrôleur d'appel tierce partie - Passerelle SIP à Passerelle SIP - Redirection avec CC-Diversion - Passerelle SIP à Passerelle SIP - Réponse de redirection SIP 3xx - Passerelle SIP à IP Phone SIP - Etablissement d'appel et Appel en attente réussis - Passerelle SIP à IP Phone SIP - Etablissement d'appel et Transfert réussis - Passerelle SIP à uOne - Etablissement d'appel Voice Mail - IP Phone SIP à Passerelle SIP - Sélection automatique de route - IP Phone SIP à Passerelle SIP - Etablissement d'appel et Appel en attente avec tierce partie - IP Phone SIP à IP Phone SIP - Appel mis en attente - IP Phone SIP à IP Phone SIP - Appel mis en attente avec consultation - IP Phone SIP à IP Phone SIP - Appel en attente - IP Phone SIP à IP Phone SIP - Transfert d'appel avec - IP Phone SIP à IP Phone SIP - Acheminement d'appel réseau (Inconditionnel) (Occupé) - IP Phone SIP à IP Phone SIP - Acheminement d'appel inconditionnel - IP Phone SIP à IP Phone SIP - Acheminement d'appel sur occupation non réponse indisponibilité

• Scénarios d'appels avec échec - Passerelle SIP à Passerelle SIP - L'appelé est Occupé - Passerelle SIP à Passerelle SIP - L'appelé ne répond pas - Passerelle SIP à Passerelle SIP - Erreur Client, Serveur ou Globale - Passerelle SIP à Passerelle SIP via Serveur de Redirection SIP - L'appelé est Occupé - L'appelé ne répond pas - Erreur Client, Serveur ou globale - Passerelle SIP à Passerelle SIP via Serveur Proxy SIP - Erreur Client ou Serveur - Erreur Globale - Passerelle SIP à IP Phone SIP - L'appelé est Occupé - Passerelle SIP à IP Phone SIP - L'appelé ne répond pas - Passerelle SIP à IP phone SIP - Erreur Client, Serveur ou - IP Phone SIP à IP Phone SIP - L'appelé est Occupé - IP Phone SIP à IP Phone SIP - - IP Phone SIP à IP Phone SIP - Liste non-autorisé - IP Phone SIP à IP Phone SIP - L'appelé ne répond pas - IP Phone SIP à IP Phone SIP - Erreur d'authentification

et Libération Passerelle SIP à Passerelle SIP - Etablissement d'appel La figure suivante montre un établissement d'appel et une déconnexion réussis. Dans ce scénario d'appel, les deux utilisateurs aux extrémités sont User A et User B. User A est situé sur PBX A. PBXA est connecté à la passerelle SIP (GW1) via une liaison T1/E1. User B est situé sur PBX B. PBX est connecté à la passerelle SIP (GW2) via une liaison T1/E1. Le numéro de téléphone de USER B est 555 0002. La passerelle SIP GW1 est connectée à la passerelle GW2 par un réseau IP. Le scénario de la communication est le suivant: 1. User A appelle User B 2. User B répond à l'appel 3. User B termine la communication User A User B PBX A PBX B GW1 GW2 Réseau IP 2. INVITE 5. 100 Trying 8. 180 Ringing Canal RTP 2-sens 11. 200 OK 14. ACK 17. BYE 21. 200 OK 1. Setup 3. Call Proceeding 9. Alerting Canal voix 1-sens 12. Connect 13. Connect ACK Canal voix 2-sens 19. Disconnect 20. Release 4. Setup 6. Call Proceeding 7. Alerting 10. Connect 15. Connect ACK 16. Disconnect 18. Release 22. Release Complete 23. Release Complete

Action Description 1. Setup—PBX A vers Gateway SIP GW1 Le message d'appel est transmis du PBX A vers la Gate- way SIP GW1. Le message Call Setup comprend les tran-sactions standards effectuées lorsque User A tente d'appeler User B. 2. INVITE— Gateway SIP GW1 vers Gateway SIP GW2 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 pas un nom d'utilisateur. ● PBX A est 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 branche unique est identifiée par le champ Cseq. ● La capacité média de User A qui est "ready to receive" est spécifiée. ● Le port sur lequel la passerelle SIP GW1 est prête à recevoir les données RTP est spécifié. 3. Call Proceeding— Gateway SIP GW1 vers PBX A La passerelle SIP GW1 transmet un message Call Proceeding vers PBX A pour acquitter la requête Call Setup. 4. Setup— Gateway SIP GW2 vers PBX B La passerelle SIP GW2 reçoit la requête INVITE de la pas- serelle SIP GW1 et initie un message Call Setup vers User B via PBX B. 5. 100 Trying— Gateway SIP GW2 vers Gateway SIP GW1 La passerelle SIP GW2 transmet une réponse 100 Trying à la requête INVITE transmise par 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, telle que la consultation d'une base de données, est en cours.

Action Description 6. Call Proceeding—PBX B vers Gateway SIP GW2 PBX B transmet un message Call Proceeding vers la passerelle SIP GW2 pour acquitter la requête Call Setup. 7. Alerting—PBX B vers Gateway SIP GW2 PBX B localise User B et transmet un message Alert vers la passerelle SIP GW2. Le téléphone de User B commence à sonner. 8. 180 Ringing— Gateway SIP GW2 vers Gateway SIP GW1 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. 9. Alerting— Gateway SIP GW1 vers PBX A 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. 10. Connect— PBX B vers Gateway User B répond à l'appel. PBX B transmet un message Connect vers la passerelle SIP GW2. Le message Connect notifie à la passerelle GW2 que la connexion a été faite. 11. 200 OK— Gateway SIP GW2 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. 12. Connect— Gateway SIP GW1 La passerelle SIP GW1 transmet un message Connect vers PBX A. Le message Connect notifie au PBX A que la connexion a été faite. 13. Connect ACK— PBX A vers Gateway SIP GW1 PBX A acquitte le message Connect de la passerelle SIP GW1. 14. ACK— SIP Gateway GW1 vers SIP Gateway GW2 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. 15. Connect ACK— Gateway SIP GW2 vers PBX B La passerelle SIP GW2 acquitte 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

Action Description 16. Disconnect— PBX B vers Gateway SIP GW2 Lorsque User B raccroche son téléphone, PBX B trans- met un message Disconnect vers la passerelle SIP GW2. Le message Disconnect démarre le processus de libéra- tion de la session de communication. 17. BYE— Gateway SIP GW2 vers Gateway SIP GW1 La passerelle SIP GW2 transmet une requête BYE vers 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. 18. Release— Gateway SIP GW2 vers PBX B La passerelle SIP GW2 transmet un message Release vers PBX B. 19. Disconnect— Gateway SIP GW1 vers PBX A La passerelle SIP GW1 transmet un message Disconnect vers PBX A. 20. Release— PBX A vers Gateway SIP GW1 PBX A transmet un message Release vers la passerelle SIP GW1. 21. 200 OK— Gateway SIP GW1 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çu la requête BYE. 22. Release Complete— PBX B PBX B transmet un message Release Complete vers la passerelle SIP GW2. 23. Release Complete— Gateway SIP GW1 vers PBX A La passerelle SIP GW1 transmet un message Release Complete vers PBX A et la session est terminée.

SIP Gateway vers SIP Gateway - Appel via un serveur de Redirection La figure suivante montre un établissement d'appel et une déconnexion réussis via un Serveur de redirection. 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 passe- relle SIP GW1 via une liaison T1/E1. La passerelle SIP GW1 utilise un serveur de re- direction. 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 0002. 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 Serveur de redirection SIP 2. User B répond à l'appel 3. User B termine la communication User A User B PBX A PBX B GW1 GW2 Réseau IP 2. INVITE 1. Setup Redirect Server 8. 100 Trying 11. 180 Ringing Canal RTP 2-sens 14. 200 OK 17. ACK 20. BYE 24. 200 OK 7. Call Proceeding 12. Alerting Canal voix 1-sens 15. Connect 16. Connect ACK Canal voix 2-sens 21. Disconnect 23. Release 6. Setup 9. Call Proceeding 10. Alerting 13. Connect 18. Connect ACK 19. Disconnect 22. Release 25. Release Complete 26. Release Complete 5. INVITE 3. 300 Multiple Choice 4. ACK

Message Description 1. Setup— PBX A vers Gateway SIP GW1 Le message d'appel est transmis du PBX A vers la Gate- way SIP GW1. Le message Setup comprend les transac- tions standards effectuées lorsque User A tente d'appe- ler User B. 2. INVITE— Gateway SIP GW1 vers redirect server SIP 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:5550002@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 A est 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 branche unique est identifiée par le champ Cseq. ● La capacité média de User A qui est "ready to receive est spécifiée. ● Le port sur lequel la passerelle SIP GW1 est prête à recevoir les données RTP est spécifié. 3. 300 Multiple Choice— Redirect server SIP vers Gateway SIP GW1 Le serveur Redirect SIP transmet une réponse 300 Multi- ple Choice à la passerelle SIP GW1. La réponse 300 Mul- tiple Choice indique que le serveur Redirect SIP a accepté la requête INVITE, contacté un serveur de localisation avec tout ou partie de l'URL SIP de User B et que le ser- veur de localisation a fourni une liste de localisations possibles de User B. Le serveur Redirect SIP retourne ces adresses possibles à la passerelle SIP GW1 dans le mes- sage 300 Multiple Choice. 4. ACK— Gateway SIP GW1 vers Redirect server SIP La passerelle SIP GW1 acquitte la réponse 300 Multiple Choice avec un message ACK. 5. INVITE— Gateway SIP GW1 vers Gateway SIP GW2 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é.

Message Description 6. Setup— Gateway SIP GW2 vers PBX B 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. 7. Call Proceeding— Gateway SIP GW1 vers PBX A La passerelle SIP GW1 transmet un message Call Proceeding vers PBX A pour acquitter la requête Setup. 8. 100 Trying— Gateway SIP GW2 vers Gateway SIP GW1 La passerelle SIP GW2 transmet une réponse 100 Trying à la requête INVITE transmise par 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. 9. Call Proceeding—PBX B vers Gateway SIP GW2 PBX B transmet un message Call Proceeding vers la passerelle SIP GW2 pour acquitter la requête Setup. 10. Alerting—PBX B vers Gateway SIP GW2 PBX B localise User B et transmet un message Alert vers la passerelle SIP GW2. Le téléphone de User B commence à sonner. 11. 180 Ringing— Gateway SIP GW2 vers Gateway SIP GW1 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. 12. Alerting— Gateway SIP GW1 vers PBX A 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. 13. Connect— PBX B vers Gateway User B répond à l'appel. PBX B transmet un message Connect vers la passerelle SIP GW2. Le message Connect notifie à la passerelle GW2 que la connexion a été faite. 14. 200 OK— Gateway SIP GW2 vers Gateway SIP GW1 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. 15. Connect— Gateway SIP GW1 La passerelle SIP GW1 transmet un message connect vers PBX A. Le message Connect notifie à PBX A que la connexion a été faite. 16. Connect ACK— PBX A vers Gateway SIP GW1 PBX A acquitte le message Connect de la passerelle SIP GW1.

Message Description 17. ACK— SIP Gateway GW1 vers SIP Gateway GW2 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. 18. Connect ACK— Gateway SIP GW2 vers PBX B La passerelle SIP GW2 acquitte 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. 19. Disconnect— PBX B vers Gateway SIP GW2 Lorsque User B raccroche son téléphone, PBX B trans- met un message Disconnect vers la passerelle SIP GW2. Le message Disconnect démarre le processus de libéra-tion de la session de communication. 20. BYE— Gateway SIP GW2 vers Gateway SIP GW1 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. 21. Disconnect— Gateway SIP GW1 vers PBX A La passerelle SIP GW1 transmet un message Disconnect vers PBX A. 22. Release— Gateway SIP GW2 vers PBX B La passerelle SIP GW2 transmet un message Release vers 23. Release— PBX A vers Gateway SIP GW1 PBX A transmet un message Release vers la passerelle SIP GW1. 24. 200 OK— Gateway SIP GW1 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çu la requête BYE. 25. Release Complete— PBX B PBX B transmet un message Release Complete vers la passerelle SIP GW2. 26. Release Complete— Gateway SIP GW1 vers PBX A La passerelle SIP GW1 transmet un message Release Complete vers PBX A et la session est terminée.

SIP Gateway vers SIP Gateway - Appel via Proxy Server Les figures suivantes montrent des établissements d'appel et une déconnexion passe- relle vers passerelle réussis via un Proxy server. Les deux utilisateurs d'extrémités sont User A et User B. User A est situé sur PBX A qui est connecté à une passerelle SIP (GW1) via une liaison T1/E1. La passerelle SIP GW1 contient le Proxy Server. La passerelle SIP GW1 est connectée à la passerelle GW2 par un réseau IP. User B est situé sur PBX B qui est connecté à une passerelle SIP (GW2) via une liaison T1/E1. Le numéro de téléphone de USER B est 5550002. 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 validé chaque Proxy Server ajoute sa Request-URI en début de liste. Quand Record-route est dévalidé, les messages SIP passent directement par la passe- relle une fois que la communication a été établie. Le 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

SIP Gateway vers SIP Gateway - Appel via Proxy Server 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-sens Canal RTP 2-sens Canal voix 1-sens 13. Connect 14. 200 OK 15. 200 OK 16. Connect 17. Connect ACK 18. ACK 19. ACK 20. Connect ACK Canal voix 2-sens Canal RTP 2-sens Canal voix 2-sens 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é

Message Description 1. Setup— PBX A vers Gateway SIP GW1 Le message d'appel est transmis du PBX A vers la Gate- way SIP GW1. Le message Setup comprend les transac- tions standards effectuées lorsque User A tente d'appe- ler User B. 2. INVITE— Gateway SIP GW1 vers Proxy server SIP 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:5550002@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 A est 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 branche unique est identifiée par le champ Cseq. ● La capacité média de User A qui est "ready to receive est spécifiée. ● Le port sur lequel la passerelle SIP GW1 est prête à recevoir les données RTP est spécifié. 3. Call Proceeding— Gateway SIP GW1 vers PBX A La passerelle SIP GW1 transmet un message Call Proceeding vers PBX A pour acquitter la requête Setup. 4. INVITE— Proxy Server SIP vers Gateway SIP GW2 La Proxy Server SIP vérifie si sa propre adresse est conte- nue dans le champ Via (pour éviter les boucles), copie di- rectement les champs To, From, Call-ID et Contact de 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.. 5. 100 Trying— Proxy Server SIP vers Gateway SIP GW1 Le Proxy Server SIP transmet la réponse 100 Trying à la passerelle SIP GW1. 6. Setup— Gateway SIP GW2 vers PBX B 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.

Message Description 7. 100 Trying— Gateway SIP GW2 vers Proxy server SIP 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 8. Call Proceeding—PBX B vers Gateway SIP GW2 PBX B transmet un message Call Proceeding vers la passerelle SIP GW2 pour acquitter la requête Setup. 9. Alerting—PBX B vers Gateway SIP GW2 PBX B localise User B et transmet un message Alert vers la passerelle SIP GW2. Le téléphone de User B commence à sonner. 10. 180 Ringing— Gateway SIP GW2 vers Proxy server SIP La passerelle SIP GW2 transmet un message 180 Ringing vers le Proxy server. 11. 180 Ringing— Proxy server SIP vers Gateway SIP GW1 Le Proxy server SIP achemine la réponse 180 Ringing vers la passerelle SIP GW1. 12. Alerting— Gateway SIP GW1 vers PBX A 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. 13. Connect— PBX B vers Gateway User B répond à l'appel. PBX B transmet un message Connect vers la passerelle SIP GW2. Le message Connect notifie à la passerelle GW2 que la connexion a été faite. 14. 200 OK— Gateway SIP GW2 vers Proxy server SIP La passerelle SIP GW2 transmet un message 200 OK ( incluant l'en-tête Record-route reçu dans la requê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. 15. 200 OK— Proxy server SIP 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 suivantes pour la même branche de la communication. Le Proxy server SIP rajoute sa pro- pre Request-URI dans le champ Record-route.

Message Description 16. Connect— Gateway SIP GW1 vers PBX A La passerelle SIP GW1 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 GW1 PBX A acquitte le message Connect de la passerelle SIP GW1. 18. ACK— Gateway SIP GW1 vers Proxy server SIP 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. 19. ACK— Proxy server SIP vers Gateway SIP GW2 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. 20. Connect ACK— Gateway SIP GW2 vers PBX B La passerelle SIP GW2 acquitte 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. 21. Disconnect— PBX B vers 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. 22. BYE— Gateway SIP GW2 vers 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. 23. BYE— Proxy server SIP vers Le Proxy server SIP achemine la requête BYE vers la pas- serelle SIP GW1. 24. Disconnect— Gateway SIP GW1 vers PBX A La passerelle SIP GW1 transmet un message Disconnect vers PBX A. 25. Release— Gateway SIP GW2 vers PBX B La passerelle SIP GW2 transmet un message Release vers 26. Release— PBX A vers Gateway SIP GW1 PBX A transmet un message Release vers la passerelle SIP GW1. 27. 200 OK— Gateway SIP GW1 vers Proxy server SIP 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.

SIP Gateway vers SIP Gateway - Appel via Proxy Server Message Description 28. 200 OK— Proxy server SIP vers Gateway SIP GW2 Le Proxy server SIP achemine le message 200 OK vers la passerelle SIP GW2. 29. Release Complete— PBX B PBX B transmet un message Release Complete vers la 30. Release Complete— Gateway SIP GW1 vers PBX A La passerelle SIP GW1 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 dé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-sens Canal RTP 2-sens Canal voix 1-sens 13. Connect 14. 200 OK 15. 200 OK 16. Connect 17. Connect ACK 18. ACK 19. Connect ACK Canal voix 2-sens Canal RTP 2-sens Canal voix 2-sens 20. Disconnect 21. BYE 22. Disconnect 23. Release 24. Release 25. 200 OK 27. Release Complete 26. Release Complete

Message Description 1. Setup— PBX A vers Gateway SIP GW1 Le message d'appel est transmis du PBX A vers la Gate- way SIP GW1. Le message Setup comprend les transac- tions standards effectuées lorsque User A tente d'appe- ler User B. 2. INVITE— Gateway SIP GW1 vers Proxy server SIP 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:5550002@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 A est 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 branche unique est identifiée par le champ Cseq. ● La capacité média de User A qui est "ready to receive est spécifiée. ● Le port sur lequel la passerelle SIP GW1 est prête à recevoir les données RTP est spécifié. 3. Call Proceeding— Gateway SIP GW1 vers PBX A La passerelle SIP GW1 transmet un message Call Proceeding vers PBX A pour acquitter la requête Setup. 4. INVITE— Proxy Server SIP vers Gateway SIP GW2 La Proxy Server SIP vérifie si sa propre adresse est conte- nue dans le champ Via (pour éviter les boucles), copie di- rectement les champs To, From, Call-ID et Contact de 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.. 5. 100 Trying— Proxy Server SIP vers Gateway SIP GW1 Le Proxy Server SIP transmet la réponse 100 Trying à la passerelle SIP GW1. 6. Setup— Gateway SIP GW2 vers PBX B 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.

Message Description 7. 100 Trying— Gateway SIP GW2 vers Proxy server SIP 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 8. Call Proceeding—PBX B vers Gateway SIP GW2 PBX B transmet un message Call Proceeding vers la passerelle SIP GW2 pour acquitter la requête Setup. 9. Alerting—PBX B vers Gateway SIP GW2 PBX B localise User B et transmet un message Alert vers la passerelle SIP GW2. Le téléphone de User B commence à sonner. 10. 180 Ringing— Gateway SIP GW2 vers Proxy server SIP La passerelle SIP GW2 transmet un message 180 Ringing vers le Proxy server. 11. 180 Ringing— Proxy server SIP vers Gateway SIP GW1 Le Proxy server SIP achemine la réponse 180 Ringing vers la passerelle SIP GW1. 12. Alerting— Gateway SIP GW1 vers PBX A 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. 13. Connect— PBX B vers Gateway User B répond à l'appel. PBX B transmet un message Connect vers la passerelle SIP GW2. Le message Connect notifie à la passerelle GW2 que la connexion a été faite. 14. 200 OK— Gateway SIP GW2 vers Proxy server SIP La passerelle SIP GW2 transmet un message 200 OK ( incluant l'en-tête Record-route reçu dans la requê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. 15. 200 OK— Proxy server SIP 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 suivantes pour la même branche de la communication. Le Proxy server SIP rajoute sa pro- pre Request-URI dans le champ Record-route.

Message Description 16. Connect— Gateway SIP GW1 vers PBX A La passerelle SIP GW1 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 GW1 PBX A acquitte le message Connect de la passerelle SIP GW1. 18. ACK— Gateway SIP GW1 vers Gateway SIP GW2 La passerelle SIP GW1 transmet un ACK vers la passe-relle SIP GW2. Le message ACK confirme que la passe-relle SIP GW1 a bien reçu le message 200 OK du Proxy server SIP. 19. Connect ACK— Gateway SIP GW2 vers PBX B La passerelle SIP GW2 acquitte 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. 20. Disconnect— PBX B vers 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. 21. BYE— Gateway SIP GW2 vers 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. 22. Disconnect— Gateway SIP GW1 vers PBX A La passerelle SIP GW1 transmet un message Disconnect vers PBX A. 23. Release— Gateway SIP GW2 vers PBX B La passerelle SIP GW2 transmet un message Release vers 24. Release— PBX A vers Gateway SIP GW1 PBX A transmet un message Release vers la passerelle SIP GW1. 25. 200 OK— Gateway 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. 26. Release Complete— PBX B vers Gateway SIP GW2 PBX B transmet un message Release Complete vers la passerelle SIP GW2. 27. Release Complete— Gateway SIP GW1 vers PBX A La passerelle SIP GW1 transmet un message Release Complete vers PBX A et la session est terminée.

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/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 /acs_mod/cis3700/index.htm • Cisco AS5300 documentation at /acs_serv/5300/index.htm Cisco IOS command references • 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 re/ios123/123tcr/123tvr/index.htm Cisco IOS configuration fundamentals and examples • Cisco IOS Configuration Fundamentals Configuration Guide at re/ios122/122cgcr/ffun_c/ • Cisco IOS Interface Command Reference at re/ios122/122cgcr/finter_r/index.htm • Cisco IOS Interface Configuration Guide at re/ios122/122cgcr/finter_c/ • Cisco IOS Voice, Video, and Fax Configuration Guide, Release 12.2 at 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, including library preface and glossary • Cisco IOS Voice Configuration Library at re/ios123/123cgcr/vcl.htm

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 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 /sc/rel7/soln/das22/gateway/dascfg5.htm Tcl IVR programming • Tcl IVR API Version 2.0 Programmer's Guide at Troubleshooting • Cisco IOS Debug Command Reference, Release 12.3T at re/ios123/123tcr/123dbr/index.htm • Cisco IOS Voice Troubleshooting and Monitoring Guide at 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 /acs_mod/1700/1750/1750voip/debug.htm

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 nubuvoip/voip5300/index.htm • Voice over IP for the Cisco AS5800 at /nubuvoip/voip5800/index.htm VSA information • RADIUS Vendor-Specific Attributes Voice Implementation Guide at /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 /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 /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

Standards MIBs RFCs 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-sdp- comedia-04.txt Connection-Oriented Media Transport in SDP draft-ietf-sipping-reason- header-for-preemption-00 Extending the SIP for Preemption Events draft-ietf-sip-privacy-02 SIP Extensions for Caller Identity and Privacy draft-ietf-sip-resource-priority- 05 Communications Resources Priority for SIP draft-levy-diversion-06.txt [Sip] verification of diversion header (draft-levy) GR-268-CORE ISDN Basic Rate Interface Call Control Switching and 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

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