From: Simon H. <li...@th...> - 2007-10-31 07:58:31
|
Kenneth Burgener wrote: > > This is a SIP device, and you probably have the SIP NAT problem - the >> problem being that SIP is a stupid protocol. <rant>On a matter of personal opinion, it's not the SIP that's stupid, it works 'just fine' on an unbroken network ! Where NAT is involved, the network is fundamentally broken and there are no workarounds for what it does that are 100% reliable - all that can be said is that it works 'well enough' for enough people enough of the time for people to be fooled into thinking it's a good idea. Meanwhile, by 'fixing' the problem of available addresses, it's delayed the uptake of IPv6 by many, many years and thus delayed for many years to come the real solution to a lack of addresses. Bear in mind that I've yet to see a SIP device that supports IPv6 so we're now stuck with the problem even if every ISP in the world turned on IPv6 today.</rant> > Adding the >> nf_conntrack_sip module to your kernel should work around it. > >I have an ip_conntrack_sip module already loaded, but I do not see >mention of an nf_conntrack_sip module: That could well be the problem then. My guess is that the phone device is doing STUN or something to find out what address & ports to use in the SIP messages - then the SIP helper mangles the packet and breaks things. Try : 1) Don't load the ip_conntrack_sip module 2) Reconfigure the phone to not do network detection (typically turn off STUN) 3) Reconfigure the phone to use a different port (eg 5061) so that the SIP helper doesn't kick in. 1 & 3 are avoiding the gateway doing anything to the packets, 2 is stopping the phone correcting for the NAT and letting the gateway do it. |