l'inspection SIP ça existe quand même... et heureusement ! (de même que
l'inspection FTP pour ne pas avoir besoin de se faire chier à ouvrir
10000 ports pour le FTP passif...)
Le 03/09/2014 09:06, David Ponzone a écrit :
Michel,
Le 3 sept. 2014 à 05:42, Michel Py <mic...@arneill-py.sacramento.ca.us> a écrit
:
Régis M a écrit :
Personnellement, les polycoms que j'ai manipulé ne savait pas géré le NAT (il y
a 3 à 4 ans)....
Ce n'est pas que les Polycoms. SIP est un protocole qui a été conçu pour ne pas
traverser NAT, toutes les marques sont dans le même bateau. Faut être fou pour
faire du SIP à travers NAT, c'est des emmerdes à n'en plus finir. Donc tout le
monde fait un VLAN pour les téléphones SIP qui ne traverse pas NAT.
Ca fait longtemps que les opérateurs qui ont besoin de faire du SIP à travers
NAT utilisent des softswitch/Centrex/class 5/SBC sérieux qui font de l’autoNAT
(également appelé RTP-autoadjust, NAT autolearn, etc…) et qui affranchissent
totalement d’avoir à gérer le NAT du côté du téléphone SIP (ou MGCP d’ailleurs).
Après, quand l’opérateur gère le lien et le LAN du client, il va en effet
préférer laisser la téléphonie en IP privées routées, c’est indéniable.
Pour ma part, c’est surtout pour des raisons de facilité de management distant
des équipements.
Mais les emmerdes en faisant du NAT sont très relatives. Pour ma part, j’ai
surtout rencontré des ennuis à cause d’équipements buggés (Draytek pour ne pas
les citer).
Il y aussi le cas du routeur client qu’on ne contrôle pas, qui a un SIP ALG qui
met le bordel et qu’on ne peut pas désactiver. Un bon SoftSwitch s’en sortira
quand même (FreeSWITCH), un moins bon sera peut-être gêné.
Cela étant dit, je te rejoins sur le fait que SIP n’a pas été conçu pour ça et
ce que je viens de décrire est un hack pour contourner le problème.
---------------------------
Liste de diffusion du FRnOG
http://www.frnog.org/
---------------------------
Liste de diffusion du FRnOG
http://www.frnog.org/
