“an extension to the session initiation protocole for symetric response routing”

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

Upload: mannix-duke

Post on 30-Dec-2015

35 views

Category:

Documents


7 download

DESCRIPTION

“An extension to the Session Initiation Protocole for Symetric Response Routing”. RFC 3581. 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. - PowerPoint PPT Presentation

TRANSCRIPT

Page 1: “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

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

2

Plan

IntroductionIntroduction

Présentation de SIPPrésentation de SIP

Présentation du NATPrésentation du NAT

SIP/NAT : la problématiqueSIP/NAT : la problématique

Solution de la RFC3581

Call Flow

Protocole UNSAF

Conclusion de l’IAB

Conclusion

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

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

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

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

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

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

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

6

Présentation du NAT

Routeur NAT@IP publique : 193.56.2.3N° port : 9999

Mathieu@ IP : 192.168.1.1N° port : 4043

Proxy SIP 1@ IP 213.103.102.13N° port : 5060

Proxy SIP 2@ IP : 195.220.1.12N° port: 5070

N° port : 5070

N° port : 5060

Exemple du NAT symétrique

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

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

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

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”

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

9

Call Flow

INVITE sip:[email protected] SIP/2.0Via : sip/ 2.0/UDP 192.168.4.7:4045

;rport;branch=qsdfghjk

INVITE sip:[email protected] SIP/2.0Via : sip/ 2.0/UDP 192.168.4.7:4045

;rport;branch=qsdfghjk

INVITE sip:[email protected] SIP/2.0Via : SIP/ 2.0/UDP proxy.example.com;branch=wxcvbnjh

Via : SIP/2.0/UDP 192.168.4.7:4045;received=193.34.65.1;rport=9994;branch=qsdfghjk

SIP/2.0 200 OKVia: SIP/2.0/UDP proxy.example.com;branch=wxcvbnjh

Via: SIP/2.0/UDP 192.168.4.7:4045;received=193.34.65.1;rport=9994;branch=qsdfghjk

SIP/2.0 200 OKVia : SIP/2.0/UDP

192.168.4.7:4045;received=193.34.65.1;rport=9994;branch=qsdfghjk

SIP/2.0 200 OKVia : SIP/2.0/UDP

192.168.4.7:4045;received=193.34.65.1;rport=9994;branch=qsdfghjk

Routeur Nat @IP publique : 193.34.65.1N° Port : 9994

Proxy SIP (proxy.example.com)@IP 193.34.65.2N°Port : 5060N°Port : 5070

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

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 ?

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

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.

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

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.

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

13

Des questions ?