[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: NAT state not deleted after IP change (DHCP)



On 22:55, Tue 08 Feb 05, Cyrill R?ttimann wrote:
> Hi Daniel,
> 
> Thanks for the answer and insights to the lower levels of the networked 
> world. I have now hopefully solved my problem. I can see in the state 
> table, that the state expires and after a few seconds, the state is 
> recreated again (heartbeat 25s, timeout 20s):
> 
> # voip
> nat on $ext_if from <sipphones> to any -> ($ext_if) static-port
> pass out quick on $ext_if inet proto {udp} from ($ext_if) to any port 
> sip keep state (udp.first 20, udp.single 20, udp.multiple 20)
> 
> 
> >
> >If you force a constant proxy port to be used for all such connections,
> >neither peer will not notice that you removed and re-created state 
> >entries.
> >With one little catch: during the time when there is no state entry
> >(after the previous state has been removed and before the next one is
> >created), the external peer will not be able to send your phone any UDP
> >packets (assuming you create state on outgoing packets from the phone
> >only). I don't know the SIP protocol, but it's possible that the peer
> >might want to send the phone a packet without being actively queried by
> >the phone first (like, when there's a call to pick up or such).
> 
> - after sucessfully registering, the client (phone) sends a keep alive 
> heartbeat to the sip-proxy. No packet is sent back from the sip-proxy.
> 
> - there is a reregistration every x seconds
> 
> - if someone calls me, packets are sent (only udp) from the sip-proxy 
> to my phone (that is why the sip-protocol is not well suite to handle 
> firewalls (specially NAT). They have to handle out the port to send RTP 
> packages.
> 
> That problem keeped me busy for a too long time.
> 
> For those who are interested, we will roll out (now in production test) 
> soon a Firewall based on OpenBSD/AMD64 and pf to load balance traffic 
> to our SIP-Proxies. We started with the Soekris Net4801. But load tests 
> pointed out, that the 3 network interfaces are sitting on the same IRQ. 
> The CPU was nearly only handling interrupts and  the solution was 
> capable to filter about 20-25 phone calls at the same time (not the 
> promises 20Mbit/s). A phone call produces a lot of traffic (depending 
> on the interval sending RTP-Packages). We now have switched to a 
> cluster (CARP) of HP DL145's with AMD's Opteron CPU :-)
> 
> Regards,
> 
> Cyrill
Hi,
I couldn't resist to comment on some lines here.
First of all, if you enable keepalive from the sip proxy to
the phones (both SER and asterisk can do that) the state
from server to phone won't be expiring. That way it is also
not true that SIP is not well suited for firewalled
connections. I have a asterisk server behind a natting
firewall on location A and some phones on different
residential places and both Linux and OpenBSD firewalls and
all is working smoothly. Just be sure to limit the RTP port
range so it's easy to forward it to the internal VOIP
server.
Then about the bandwidth:
What codec are you using ? If you use ulaw/alaw the soekris
should keep up at 20 calls. Try to stay away from iLIBc, it
is huge but doesn't sound any better then ulaw.
Just my 2 cents.
-- 
Michiel van Baak
http://lunteren.vanbaak.info
[email protected]
GnuPG key: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x7E0B9A2D
"Two of the most famous products of Berkeley are LSD and BSD. I don't think that this is a coincidence."