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
Now I'm trying to find out why and how to correct this.
Thanks all
Barry
Barry,
First of all, devices like SonicWall drive me (and a lot of other
people) crazy because of all of their "protocol helpers" that seems to
break things more often than fix them. FTP with sonicwall was always a
classic example - their active FTP helper was totally useless for a
while. It seems that if you are totally clueless they offer some degree
of help. If you know what you are doing, they get in the way.
Anyways, as it is now try to enable sip debugging on the Asterisk
console:
"sip debug"
This will show you all of the SIP messages to/from the Asterisk system.
Try to make a call and see if the INVITE makes it to Asterisk (your
console will print it out). If it makes it, look for "found peer xxx"
shortly after the INVITE. It should match the name of your supposed
incoming peer. Then it should match the correct context and do it's thing.
However, your situation probably won't be that simple... My guess is
the INVITE gets there, but the From/To/URI/something else
are being mangled in the SIP request, so Asterisk doesn't know which
peer in sip.conf to match them to.
There was a doc on the WIKI (I can't find it right now) that describes
how Asterisk matches incoming SIP requests to peers, contexts, etc. I'm
pretty sure it works like this:
1) Try to match From: username to user= line in sip.conf
[peer/user/friend] section.
2) Try to match source IP address of SIP request to known peer IP
address. I.e, if you have host=sip.krisk.org in a [peer] section and
the invite comes from 169.207.1.3 (which is sip.krisk.org), it uses that
peer entry and corresponding context, etc.
3) If it doesn't match either, it goes into the context specified in
[general] in sip.conf.
As I said before, my guess is the SonicWall is getting fancy on you and
breaking these otherwise reasonable sane methods. "sip debug" is your
friend here.
--
Kristian Kielhofner
_______________________________________________
--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
