“An extension to the Session Initiation Protocole for Symetric Response Routing”

1. “An extension to the Session Initiation Protocole for Symetric Response Routing” • RFC 3581

2. Plan • Introduction • Présentation de SIP • Présentation du NAT • SIP/NAT : la problématique • Solution de la RFC3581 • Call Flow • Protocole UNSAF • Conclusion de l’IAB • Conclusion

3. Introduction • Mise en place de nouveaux services • VoIP, Téléconférence, Vidéoconférence, VOD • Ces applications utilisent le protocole SIP • Problématique des NAT car non prévus pour cette utilisation • Création de la RFC 3581 par l’IETF en 2003 • Prolongation pour le protocole SIP pour le cheminement à réponse symétrique

4. Présentation de SIP • Qu’est ce que c’est ? • Protocole de signalisation extensible. • mode client/serveur. • gestion de sessions multimédia. • indépendant du protocole de Transport • Qui l’a développé ? • Conçu par le groupe MMUSIC de l’IETF, repris par un groupe de travail SIP • Référencé par la RFC 2543 puis par la RFC 3261

5. Présentation du NAT • Pourquoi les NAT ? • Répondre à la pénurie d ’adresses publiques IPv4 mode client/serveur. • Interconnecter de manière sécurisée des LANs distants à travers Internet. • Différents types de NAT : • Statique • PAT/NAT dynamique • Cône plein, Cône restrictif, Cône à port restrictif • NAT symétrique

6. Présentation du NAT Exemple du NAT symétrique Proxy SIP 1 @ IP 213.103.102.13 N° port : 5060 Mathieu @ IP : 192.168.1.1 N° port : 4043 Routeur NAT @IP publique : 193.56.2.3 N° port : 9999 N° port : 5070 N° port : 5060 Proxy SIP 2 @ IP : 195.220.1.12 N° port: 5070

7. SIP/NAT : la problématique • Le routeur NAT bloque les communications entrantes • Pas de connaissance de l’adressage public associé à l’adresse privée du client. • Le client doit connaitre l’adresse et le port qui lui seront affectés par le NAT

8. Solution de la RFC 3581 • Création d’un nouveau paramètre “rport”: • Ce paramètre se trouve au niveau du champ “Via” et contient le port affecté par le routeur NAT. • Rôle du client SIP • Insertion du paramètre “rport” si placé derrière un routeur NAT. • Emission régulière d’une requète INVITE jusqu’à réception d’une réponse valide. • Rôle du proxy SIP • Détection et mise à jour des paramètres “rport” et “received”

9. Call Flow

10. Protocoles UNSAF • RFC 3464 : IAB créé la classe de protocoles UNSAF • Permet à un client SIP, situé derrière un routeur NAT, de connaitre l’adresse IP et le port par lesquels il peut être joint(exemple du protocole STUN ). • 2 buts principaux • Mettre à jour le champ “Contact” lorsque un client SIP émet une requète “REGISTER”. • Echange de requètes SIP entre un proxy et un serveur via un routeur NAT. • La RFC 3581, un protocole UNSAF?

11. Conclusion de l’IAB • Principales faiblesses de la RFC 3581 • Multiplication des requètes “REGISTER” suite à la mise à jour de la table de correspondance des routeurs NAT. • Risque de perte d’appels. • Le client peut recevoir une réponse uniquement provenant du serveur auquel il a envoyé une requète. • LA RFC 3581 ne définit pas un nouveau protocole UNSAF.

12. Conclusion • Les terminaux SIP du marché sont compatibles avec la RFC 3581. • Mais dans le cas de routeurs NAT symétriques ( solution considéré comme la plus sûre ), la mise en place du protocole UNSAF, via des serveurs TURN, reste une solution pour contourner le problème.

13. Des questions ?