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/
