Barry Fawthrop wrote:
Hi all
I didn't change anything that's my point
It has be running and working just fine then at 4:32 pm yesterday I
could not make or recieve VoIP calls via our VoIP Provider
They say the Invite packet was being rejected and thus there was no
"real" connection even though SIP SHOW PEERS has us registered
They also say it's due to the Sonicwall which has changed port
assignments and thus blocking ports.
I see in the Sonicwall log UDP Packet Dropped with the Providers IP
Address but it talks about port 36612 which is not SIP
They say along with the log that SIP is using 36612 why when all the
VoIP SIP setting are enabled/configured and SIP is packet forwarded to the
Asterisk Box due to Sonicwall NAT
Are you sure that you're not confusing the SOURCE vs DESTINATION port?
Your system would send a sip packet to your provider with a destination
port of udp/5060, but your source port can be anything greater then
1024. (That's likely to be 36612 in your notes, above.)
Your provider would reverse those in its response, sending their packet
to the destination port of udp/xxxx (the same greater then 1024
mentioned above), and a source port of udp/5060. That's just standard IP
stuff.
The nat function within the firewall keeps track of every udp and tcp
conversation by building a table entry that includes source IP and
source port (associated with the internal lan device that created the
packet), and a destination IP and destination port (associated with your
provider's device. That table entry is constantly referred to for every
packet that passes through the firewall in either direction, translating
private addresses into public addresses, etc.
If the conversation is "udp" based, that table entry will timeout (and
disappear) after some period of time. I don't recall what the default
sonicwall timeout value happens to be, but its typically some number of
low minutes (as opposed to low number of seconds).
If the conversation is "tcp" based, that table entry will disappear when
the tcp session is closed by the end devices. I can only guess that a
tcp timeout value exists as well, however it would oriented around
timing out a table entry where the end devices mysteriously disappeared
(without closing the tcp session).
Sonicwall sells their products with 10 user, 25 user, and other limits
that would imply the above nat table size might have limits (or changes)
when that maximum is reached. Are you sure you've not exceeded the
license limit associated with your sonicswall?
Sonicwall also has a problem handling udp packets that are greater in
size then 1458 bytes (I think I have that value correct) when its wan
interface is configured for PPPoE. Packets larger then that value are
simply dropped on the floor, and no log entries are created to hint that
has happened. Are you using PPPoE?
Finally, sonicwall has implemented some sort of sip fixup that attempts
to analyze the contents of a sip packet to determine which udp ports are
to be used for rtp packets. I wouldn't think this function would have
any impact in your case since it sounds like the problem is sip oriented
and not rtp oriented. You could turn that option off just to ensure it
isn't the problem.
To diagnose this any further really requires a packet sniff (eg,
ethereal) from the outside edge of the firewall, along with an asterisk
'sip debug'. That would help determine what might be happening in terms
of port mapping, etc.
_______________________________________________
--Bandwidth and Colocation provided by Easynews.com --
asterisk-users mailing list
To UNSUBSCRIBE or update options visit:
http://lists.digium.com/mailman/listinfo/asterisk-users
