News: This forum is now permanently frozen.
Pages: [1]
Topic: Problems with SIP Proxy in 1.3b5  (Read 4060 times)
« on: December 13, 2007, 03:05:26 »
triphius *
Posts: 4

Here's what I have going:  I have two seperate networks, both with m0n0wall-based systems as border-routers. One network has an Asterisk VoIP server. Everything works fine internally.  The second network has a VoIP phone that is set to connect to the Asterisk VoIP server on the first network.

While running 1.231 on both m0n0walls, I was able to register the standalone VoIP phone; however I did not get audio in either direction. So I upgrade to 1.3b5 to take advantage of the SIP Proxy function. When enabled using UDP Port 5060 and RTP 27000-27999 as the settings... I can no longer register with the Asterisk server.  The m0n0wall does not show any indication (in SIP Proxy status) that a phone is trying to register.

The m0n0wall on the first network (hosting the Asterisk server) is still running 1.231. The second network is the only one upgraded to 1.3b5.

I should also add that I have attempted to configure the phone with and without specifying a value for Outgoing Proxy.  When I did specify a value, it was the IP address of the LAN interface.

Any ideas and/or suggestions would be greatly appreciated.
« Last Edit: December 13, 2007, 03:12:14 by triphius »
« Reply #1 on: December 13, 2007, 03:38:10 »
triphius *
Posts: 4

So I've now tried to monitor packets with Wireshark and use X-Lite to connect (instead of a hard-phone)...

I have also tried downgrading to 1.3b4 and back to 1.3b5.

What I've noticed is that with 1.3b4 registration works fine (but RTP does not). With 1.3b5 (with SIP Proxy enabled AND disabled), the registration times out with SIP error 408 - Request Timeout.

« Reply #2 on: December 13, 2007, 09:11:50 »
mwiget *
Posts: 38

Can you show or explain the topology regarding the location of the phone and asterisk regarding NAT and firewall? SIP proxy helps when the SIP registrar (in your case I assume Asterisk) is on the public side of the firewall/NAT/WAN and the SIP phone on the private/LAN side. As you have two m0n0wall's here, this isn't clear yet to me.
« Reply #3 on: December 13, 2007, 17:22:18 »
triphius *
Posts: 4

Sure.

Asterisk [192.168.6.70] --- m0n0wall [192.168.6.1] // --- (Internet) --- \\ m0n0wall [172.16.1.1] --- VoIP Phone [172.16.1.x DHCP]

Both the Asterisk and VoIP phones are behind a m0n0wall NAT/Firewall.

The Asterisk server is the SIP Registrar for the VoIP phone in question.

The m0n0wall at 192.168.6.1 is running 1.231 and the m0n0wall at 172.16.1.1 is running 1.3b5.

All the upgrading/downgrading tests between 1.3b4 and 1.3b5 were run on the m0n0wall at 172.16.1.1.

Also, UDP port 5060 is NAT forwarded to the Asterisk box on the 192.168.6.1 m0n0wall (as that is required for the SIP trunk to my outbound provider).

Hopefully that helps to paint the picture better.  Smiley
« Last Edit: December 13, 2007, 17:25:44 by triphius »
« Reply #4 on: December 13, 2007, 18:55:38 »
mwiget *
Posts: 38

Well, this explains it. At least one of the SIP endpoints (Asterisk or phone) must be on a public IP address. You're looking at a double-nat scenario in your set up, which I'm not sure there is any other solution than actually build a VPN connection between both m0n0wall boxes, so that the phone and asterisk can reach each other without any NAT. Have you looked into that?
« Reply #5 on: December 13, 2007, 19:33:14 »
triphius *
Posts: 4

I've tried using the IPsec functionality in the m0n0wall to create a tunnel, but I was still unable to pass RTP packets between the phone and the Asterisk server.  Not sure why.

The Asterisk box can easily handle the NAT on it's own side.  If I were able to connect the VoIP phone on a public IP (outside the NAT), the Asterisk box would be able to talk with it (I'm 99% sure on that).

The problem that is occurring is that the RTP packets aren't making it back to the phone though the 172.16.1.1 m0n0wall.  Either the NAT port mapping is expiring before they come back (or some other unknown reason).  I assumed that enabling the SIP proxy on the 172.16.1.1 m0n0wall would be the fix for that.  It just appears that the SIP proxy isn't accepting traffic from the local subnet (thus being unable to register).
 
Pages: [1]
 
 
Powered by SMF 1.1.20 | SMF © 2013, Simple Machines