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

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

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

Présentation de SIP Qu’est ce que c’est ? Qui l’a développé ? 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

Présentation du NAT Pourquoi les NAT ? Différents types de 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

Présentation du NAT Exemple du NAT symétrique Proxy SIP 1 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

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

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”

Call Flow

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 ?

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.

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.

Des questions ?