Problmes des appels entrants causs par lexpiration du NAT port mapping

Oussama Hammami, 2011-06-27 Switzernet Problmes des appels entrants causs par lexpiration du NAT port mapping.................1 Introduction......................................................................................................................1 Problmatique .................................................................................................................3 Exemple........................................................................................................................3 Conclusion....................................................................................................................3 SIP OPTION.....................................................................................................................4 SIP NOTIFY.....................................................................................................................4 Configuration................................................................................................................5 Statistique.....................................................................................................................5 Utilisation CPU..........................................................................................................9 Rfrence.......................................................................................................................11

Introduction
Un routeur NAT, comme son nom l'indique, redirige les paquets qu'il reoit en fonction d'une table de routage vers le routeur suivant jusqu' atteindre le rseau local de destination. Chaque paquet comporte l'adresse d'origine et l'adresse de destination. Dans le cas d'adresses prives, l'adresse d'origine est une adresse prive inconnue de l'Internet. Le destinataire ne pourra pas rpondre. Il faut donc remplacer l'adresse prive d'origine par une adresse publique. C'est le travail du routeur NAT (Network Address Translation) qui effectue la transformation des adresses. Pour pouvoir configurer correctement un routeur NAT, il faut comprendre la notion de port. Le protocole TCP/IP utilise des ports (un nombre de 0 65535) comme le moyen de nommer les bouts d'une connexion logique, une conversation qui comporte plusieurs changes. Les ports permettent de raliser simultanment des milliers de connexions logiques sur la mme adresse IP. Ils permettent de partager la liaison Internet entre des programmes diffrents et des machines diffrentes. Comme pour les adresses IP, l'IANA a class les ports en 3 catgories [http://www.iana.org/assignments/port-numbers]. 0 1023, les "Well Known" ports utilisables seulement par le systme ou des fonctions associes. 1024 49151 les "Registered" ports utilisables par les programmes utilisateurs. 49152 65535 les ports dynamiques ou privs. Par dfaut, le protocole SIP utilise le port 5060, http le port 80, le SMTP le port 25, etc. Lorsqu'une machine du rseau local envoie des paquets un serveur l'extrieur, l'adresse d'origine est une adresse prive. Le destinataire ne pourra pas rpondre cette adresse. Pour rsoudre ce problme, le routeur NAT remplace l'adresse et le port d'origine par l'adresse Internet publique du routeur et un numro de port libre choisi au hasard en notant adresse et port associs la machine locale (voir sur le dessin ci-aprs).

FROM: 192.168.1.130:5060 TO : 91.121.205.108:5060 FROM: 91.121.205.108:5060 TO: 192.168.1.130:5060

FROM: 212.147.8.99:6 TO : 91.121.205.108:

FROM: 91.121.205.10 TO : 212.147.8.99:65

La machine de destination renvoie la rponse sur l'adresse et le port visible de l'Internet au routeur NAT. Celui-ci fait alors la transformation inverse pour renvoyer les paquets vers la machine locale. Dans ce cas de figure, il n'y a rien de spcial configurer. C'est comme cela que fonctionnent le VOIP. Le tlphone SIP dans le rseau priv se connecte au serveur SIP (Asterisk) qui connat ainsi l'adresse externe et le numro de port du routeur qui permet de contacter cette machine. En revanche, une machine qui appelle depuis l'Internet pour atteindre une adresse prive n'a aucun moyen d'y arriver puisque le routeur ne sait pas sur quelle machine du rseau Interne il faut router l'appel sauf si le port forwarding est configur sur ce dernier.

Problmatique
Lors de lenregistrement du tlphone SIP (REGISTER), lAstrad garde lIP et le Port (URI) de ce dernier dans sa base de donnes (table MySQL sipppeer), linformation remonte jusquau serveur de routage et de ce cette manire tous les appels entrant vers ce client seront routs vers lAsterisk en question. Ce dernier utilisera lIP et le port utiliss par le tlphone lors du dernier enregistrement pour router les appels entrants de ce client mais il arrive que le routeur NAT du client libre ce port et par consquent la transformation inverse pour renvoyer les paquets SIP vers lIP locale devient impossible.

Exemple
Ci-dessous un scnario dun appel entrant chou cause de la perte de porta mapping du compte 41215500327. 2011-06-24 10:27:23 le tlphone du compte 41215500327 senregistre avec [txt] : IP: 81.62.117.251 Port: 64920 2011-06-24 10:30:46 une tentative dappels entrant choue aprs plusieurs INVITEs non rpondus envoys 81.62.117.251:64920 [txt]. 2011-06-24 10:31:45 le tlphone SIP 41215500327 senregistre de nouveau avec [txt]: IP: 81.62.117.251 Port: 55466

Le tlphone a chang le port aprs 3 minutes.

Conclusion
En gnrale, le routeur libre les ports inactifs durant les 3 dernires minutes. Pour contourner ce problme, les tlphones SIP Siemens Gigaset (C450, C470 ) envoi des paquets UDP vides vers le serveur SIP denregistrement afin de garder le port dans le routeur NAT ouvert [eml]:

"To keep NAT/firewall bindings open, empty UDP packets are sent to any SIP proxy and registration gateway of all registered ITSP The filter behavior is of no interest to the HiPath / OpenScape telephony system: It always assumes that it needs to open a binding to the IP address and port of its peers and thus send empty UDP packets to open connections (RTP) or keeping bindings alive (SIP registration)." http://wiki.siemens-enterprise.com/wiki/Network_Configuration_for_VoIP_Providers La mme solution est aussi utilise par les serveurs SIP Porta-Sip [eml]: http://switzernet.com/3/public/110623-portasip-vs-astradV7-incoming/ Pour plus dinformation sur limplmentation de cette solution (paquets UDP vide) sur les Astrad: http://switzernet.com/3/public/110627-astrad-empty-udp-keepalive/ Autrement et pour rsoudre ce problme une solution trs simple consiste forcer la dure denregistrement a une valeur plus petite que 3 minutes, ce qui est possible avec Asterisk (les options maxexpiry, minexpiry, defautlexpiry dans le fichier sip.conf) [eml] : http://switzernet.com/3/public/112706-astrad-forcing-expire-time/

SIP OPTION
Une premire solution consiste utiliser qualify dans sip.conf dAsterisk mais on a abandonn l'utilisation cette option car la frquence par dfaut est trs leve ce qui peut causer le redmarrage du tlphone. Loption qualifyfreq (qualify frquence) est disponible depuis la version 1.6 dAsterisk. An OPTIONS request MAY be sent as part of an established dialog to query the peer on capabilities that may be utilized later in the dialog. RFC3261 [http://www.faqs.org/rfcs/rfc3261.html]

SIP NOTIFY
Cette solution consiste a envoyer des paquets SIP NOTIFY avec lvnement keepalive au lieu dun paquet UDP vide, la mme solution est utilise par les tlphone SIP Cisco Linksys (SPA921, SPA1001)

U 85.3.70.29:58984 -> 94.23.225.212:5060 NOTIFY sip:astrad.switzernet.com SIP/2.0. Via: SIP/2.0/UDP 192.168.1.121:5060;branch=z9hG4bK-15a5b87c. From: "41215500327" <sip:41215500327@astrad.switzernet.com>;tag=da7194e2851cd498o0. To: <sip:astrad.switzernet.com>. Call-ID: a68e04ea-f787e430@192.168.1.121. CSeq: 1 NOTIFY. Max-Forwards: 70. Event: keep-alive. User-Agent: Linksys/SPA921-5.1.8. Content-Length: 0.

Configuration
Le fichier de configuration de cette option est : sip_notify.conf [nat] Event=>keep-alive Content-Length=>0 Pour activer cette fonctionnalit il suffit dajouter ce fichier dans le rpertoire de configuration dasterisk (/etc/asterisk) et de reloader ce dernier (/etc/init.d/asterisk reload). Vous pouvez envoyer les paquets NOTIFY depuis Asterisk Manager comme suit : # asterisk -rx 'sip notify nat <USER>' Lchange SIP est le suivant:: U 94.23.225.212:5060 -> 85.3.70.29:58984 NOTIFY sip:41215500327@192.168.1.121:5060 SIP/2.0. Via: SIP/2.0/UDP 94.23.225.212:5060;branch=z9hG4bK6e3e0254;rport. From: "asterisk" <sip:asterisk@94.23.225.212>;tag=as34c24274. To: <sip:41215500327@192.168.1.121:5060>. Contact: <sip:asterisk@94.23.225.212>. Call-ID: 392bb43a250918af5f5ee1b71c650916@94.23.225.212. CSeq: 102 NOTIFY. User-Agent: Asterisk PBX. Max-Forwards: 70. Event: keep-alive. Content-Length: 0. . U 85.3.70.29:58984 -> 94.23.225.212:5060 SIP/2.0 200 OK. To: <sip:41215500327@192.168.1.121:5060>;tag=46d36a4f71acb611i0. From: "asterisk" <sip:asterisk@94.23.225.212>;tag=as34c24274. Call-ID: 392bb43a250918af5f5ee1b71c650916@94.23.225.212. CSeq: 102 NOTIFY. Via: SIP/2.0/UDP 94.23.225.212:5060;branch=z9hG4bK6e3e0254. Server: Linksys/SPA921-5.1.8. Content-Length: 0. . Pour plus dinformation sur ces tests : [eml] http://switzernet.com/3/public/110609astradv8-notify/

Statistique
Les graphes ci-dessous ont t obtenus de la manire suivante [eml] : On a lanc le script Perl ast-send-notify.pl [zip] qui cherche la liste des clients enregistr depuis la table location3 (MySQL) et qui envoi les NOTIFY grce une connexion avec Asterisk Manager en utilisant le module Asterisk::AMI.

Au moment de lancement de script denvoie de NOTIFY on a aussi lanc la commande suivante qui gnre une fichier log contenant tous les paquets NOTIFY : # ngrep -pql -W byline "" port 5060 | egrep -i -B6 '^CSeq.*NOTIFY' | perl -ne 'use POSIX;print strftime("%Y-%m-%d %H:%M:%S", localtime(time()))." ".$_' > notify.log A la fin de ce teste et pour gnrer le fichier CSV utilis pour gnrer ces graphes on a utilis le script perl t3.pl [zip] : # cat notify.log | perl ./t3.pl > 110622-astrad5-notify.csv 1-

Notify rs ponce los rate on as Notify res s trad5.s witz pons los rate on as ernet.com s e trad9 with 191 clients with 234 clients
12% 10% 8% 6% 4% 2% 0%
Source : [xls] [eml] [protected]

16% 14% 12% 10% 8% 6% 4% 2% 0%

Source : [xls] [eml] [protected]

11 -0 620 16 :0 11 4: 48 -0 620 16 :1 11 9: 12 -0 620 16 :3 11 3: 36 -0 620 16 :4 11 8: 00 -0 11 6 -2 -0 0 6- 1 20 7: 1702 11 :4 :24 -0 5: 636 11 20 -0 1 6 7: 11 -20 16: -0 18 48 620 :14: 11 17 24 -0 :3 11 620 1:12 -0 6- 18 20 :4 17 3: :4 12 11 5: -0 36 620 19 :1 2: 00 11 -0 620 19 :4
Le routeurs NAT de certains clients change ou libre le port (port mapping) utilis pour router le trafic SIP plus frquemment que la frquence d'enregistrement de l'UA (User Agent). En consquence, aprs un certain temps l'UA n'est plus joignable. Dans cette exprience, nous envoyons des NOTIFY tous les UA enregistrs sur le serveur SIP et nous enregistrons le taux de rponses renvoyes par lUA. Si le port dans le routeur NAT est libr, l'UA ne rpondra pas. Cependant, comme nous continuons envoyer les NOTIFY, ds que l'UA nous envoie un nouveau enregistrement et quil met jour son port, le flux de messages de notification (NOTIFY) gardera le port ouvert jusqu' l'enregistrement suivant quel que soit le dlai de lexpire. Cela signifie que nous devons observer un taux lev de pertes qui diminuera progressivement la suite de la rception des enregistrements des UA dont la valeur dexpire est grande. Nous

envoyons des NOTIFY tous les utilisateurs avec un intervalle de 30 secondes. L'envoie prend environ 5 secondes ainsi, la priodicit est d'environ 35 secondes. 2-

L rate on astrad5.sw oss itzernet.comw 48025notifies sent to 171 ith clients from18:24Jun 21throug 08:38Jun 22, w 46880replies, h ith and 1145losses
14% 12% 10% 8% 6% 4% 2%
Source: [xls] [eml] [protected]

0%

11 -0 621 16 :4 8: 00 11 -0 621 19 :1 2: 00 11 -0 621 21 :3 6: 00 11 -0 622 00 :0 0: 00 11 -0 622 02 :2 4: 00 11 -0 622 04 :4 8: 00 11 -0 622 07 :1 2: 00 11 -0 622 09 :3 6: 00

Ce graphique montre le rsultat d'une exprience o nous envoyons des NOTIFY tous UA enregistrs sur un serveur SIP donne et o lon mesure le taux de rponses retournes. Les premiers NOTIFY sont envoys avec un long intervalle, mais la frquence augmente progressivement. Si le mappage de port de l'UA est expir, l'UA ne rpondra pas aux NOTIFY. Cependant, comme nous continuons envoyer des messages de notification ( l'adresse:port enregistr dans la table de localisation), ds que l'UA met jour son emplacement, et si la frquence denvoi des NOTIFY est suffisamment leve, ce flux gardera obligatoirement le port NAT ouvert et il n'y aura plus de pertes. Tant que les NOTIFY sont envoys avec un taux lev, les pertes vont disparatre indpendamment du retard entre les enregistrements. Cela signifie que nous devons observer un taux lev de pertes de rponses aux NOTIFY (environ 14%) au dbut (lorsque les NOTIFY sont envoys aussi lentement que le plus lent enregistrement). L'allure du graphe changera et les pertes disparatront graduellement au cour de la rception des mises jour d'enregistrement provenant de tlphones SIP. Nous envoyons des NOTIFY tous les utilisateurs avec un intervalle entre les vagues denvoie de dpart d'une valeur de 4000 secondes. L'envoie prend environ 5 secondes. L'intervalle diminue progressivement avec un facteur de 1,1 jusqu' ce qu'il atteigne le plus bas niveau autoris de 30 secondes. Une fois ce niveau atteint, les NOTIFY sont envoys en continu pendant un certain temps (environ 2h).

3-

E ffect of notifiestra nsm ittedto a 1 1custom witha ll 7 ers n interva of initia 4 0 secondsdecrea l lly 0 0 singexponentia bya lly fa ctor of 1 .1downto the floor va of 3 secondsm inta /1 lue 0 a ined for a nother 0 h2 m 2 0
18% 16% 14% 12% 10% 8% 6% 4% 2% 0%
20 11 -0 621 14 20 11 :2 4 -0 621 16 20 11 :4 8 -0 621 19 20 11 :1 2 -0 621 21 20 11 :3 6 -0 622 00 20 :0 11 0 -0 622 02 20 11 :2 4 -0 622 04 20 11 :4 8 -0 622 07 20 11 :1 2 -0 622 09 20 11 :3 6 -0 622 12 :0 0
Source: [xls] [eml] [protected] Le graphique suivant montre le pourcentage de clients avec un port diffrent pour chaque enregistrement (courbe bleue) et le taux de perte de NOTIFY (courbe rouge) Nous voyons que ds que le taux with changed port m tomb(location 1%, le ratiohistory) Ratio of clients de perte de NOTIFY est apping environ database de tlphones avec une instabilit de mappage de port tombe ainsi environ 4%. Le ratio de non nul est probablement d une douzaine de tlphones partageant le Loss rate of notifies launched on 18:24 Jun 21 and ended on 08:38 Jun mme compte. Nous observons galement que l'instabilit de mappage de port dpasse 12% ds que la 22 transmission des NOTIFY est interrompue. La procdure MySQL utilise pour obtenir la courbe bleue est StatReg dont le code est [eml] [zip]. Cette dernire est base sur location_history qui tait ajout avec la version 3 de DBA [DBA-V3] Son algorithme est [eml] : Assume we have a period from A to B. For each account Count records Where Start < B and Stop > A (meaning any intersection) If count = 1 Then the account does not loose its port Else the telephone looses the connection

Mais cette dernire avait une erreur car avec intervalle de 30 min il affiche des valeurs dans les deux colonnes alors quavec intervalle de 5 minutes, il affiche zro dans la dernire colonne. Si l'algorithme est correct, mme avec des intervalles trs petits la dernire colonne doit afficher une valeur non nulle. Pour contourner se problme on a excut cette procdure plusieurs fois avec un intervalle de 30 minutes et en incrmentant la valeur de START de 5 minutes [zip]. Version complte des statistiques ci-dessus [protected] Version complete de projects mail archive [protected]

Utilisation CPU
1- Ci-dessous les graphes dutilisation CPU pour astrad6 et astrad7 avant (2011-06-16) et aprs (2011-06-17) lactivation de Notify (durant la nuit : de 00h 07h) Lenvoi des Notify est regroup par 10 [eml].

On remarque que lutilisation CPU a augment de 2%.

2- ci-dessous les graphes dutilisation CPU dastrad5 dans lequel on a activ lenvoi de Notify un par un de 01 :00 03 :00 et par groupes de 20 de 03 :00 05 :00 [eml]

On remarque que le regroupement de Notify optimise lutilisation CPU (03 :00).

05 :00 on a dsactiv lenvoi de Notify. Ce test a t programm dans le cron comme il suit [eml]: cron # cat /etc/cron.d/astrad 00 01 * * * root /etc/astrad/script/ast-notify-send-1.pl Lacement de lenvoi de NOTIFY un par un.

00 03 * * * root /etc/astrad/cron/teststart Arrt de premier script denvoie et lancement de lenvoi de NOTIFY par groupes de 20 00 05 * * * root /etc/astrad/cron/teststop Arrt de deuxime script denvoi de NOTIFY. Les scripts utiliss lors de ce teste sont les suivants [zip]:

Rfrence
Notify response loss on astrad5.switzernet.com with 191 clients [xls] [eml] [protected] Notify response loss rate on astrad9.switzernet.com with 234 clients [xls] [eml] [protected] Loss rate on astrad5.switzernet.com with 48025 notifies sent to 171 clients from 18:24 Jun 21through 08:38 Jun 22, with 46880 replies, and 1145 losses [xls] [eml] [protected] Effect of notifies transmitted to all 171 customers with an interval of initially 4000 seconds decreasing exponentially by a factor 1/1.1 down to the floor value of 30 seconds maintained for another 02h20m [xls] [eml] [protected] Statistic of NOTIFY sending (Original Excel files with customer account, unpublished in the public version of this document) [protected] Projects@ mail archive [public] Version complte de Projects@ mail archive [protected] Test dAstrad vs PortaSip (maintient du port SIP ouvert) http://switzernet.com/3/public/110623-portasip-vs-astradV7-incoming/ Forcing expire time on asterisk http://switzernet.com/3/public/112706-astrad-forcing-expire-time/ Send empty UDP packets to keeping NAT router port alive http://switzernet.com/3/public/110627-astrad-empty-udp-keepalive/ Astrad V8 : Test Notify http://switzernet.com/3/public/110609-astradv8-notify/ Asterisk & NAT http://switzernet.com/3/public/110303-asterisk-nat/

DBA versions http://switzernet.com/3/public/110317-db3-versions/ Astrad Versionning http://switzernet.com/3/public/110126-astrad-versions/