[5.841] Does SIP Proxy work?

Yes, SIP should work in Beta (also logging). If you have a NAT you might bypass the proxy. To use the proxy you should not need a NAT and also you should not need a packet filter rule. But you have to configure your SIP application to use the proxy. Or just set the SIP proxy to transparent mode. In transparent mode there's no need to configure your SIP application to use the proxy. But you have to remove the NAT you created.

Xeno

Yes, SIP should work in Beta (also logging). If you have a NAT you might bypass the proxy. To use the proxy you should not need a NAT and also you should not need a packet filter rule. But you have to configure your SIP application to use the proxy. Or just set the SIP proxy to transparent mode. In transparent mode there's no need to configure your SIP application to use the proxy. But you have to remove the NAT you created.

Xeno

Hi there, 

on top of that, there are many different VoIP protocol.
Even if the phone uses SIP, there are sub-protocols like STUN that make the phone work over NAT, 
without needing or using the SIP proxy.

regards
Gert

I shut down the NAT rules and the Packet Filter rules for the VOIP device and I enabled the Transparent SIP Proxy.  I then rebooted both the Astaro box and the VOIP device.  Everything still works, but again, there still appears to be no SIP Proxy activity.

I've also enabled the SIP Proxy Debug Logging.  I assume the log activity will be sent to the SIP Log, but there is nothing there regarding debug.

I can find no indication that the device (Motorola VT1000) uses the STUN sub-protocol, but that doesn't necessarily mean that it does not.

So... since NAT and Packet Rules to the device are disabled, and since the SIP Proxy is not showing any activity, then shall I assume the device is using some sub-protocol?  Shouldn't the lack of NAT/Packet Rules prevent its operation?

Something doesn't smell right.

 [:S]

Hmm, let's try to following. Just disable the SIP proxy and try to make a call. Does it work? If yes, the used application makes it way through the packetfilter of ASL. Just disable all packetfilter or add a drop packetfilter rule for that special client to the top of the packetfilter framework. Now the client should not be able to make a call. Now enable the SIP Proxy. Try to make a call. If now a call works, you can be sure that the call makes his way through the proxy. If the proxy still does not log, you might have found a bug. Otherwise adjust the settings of the SIP proxy and the application. Maybe some port settings are wrong or something like that which prevents the application from using the proxy.

Are you familiar with iptables? If yes, you could check the packetcounter for the SIP related rules to check, if your application sends packets on the correct ports.

cheers
Xeno

Don't get me wrong... the VOIP works through the Astaro Firewall.  I've already tried most of those things that you mentioned except for a full firewall block on the VOIP device to see if it then starts using the Proxy.  I will try that today.  Thanks for the suggestion.

This is a VOIP device (a Motorola VT1000), it's not an application running on a PC.  As such, the device is more like a cable-modem on a network than anything else.  There is a web-accessed Admin Page built into it, but there are no specific detailed settings as per protocols or ports.  The VOIP service that I subscribe to is Vonage, and they only state in their manual to enable ports 5060, 5061, and 10000 thru 20000.  But I noted that the device still works whether or not I forward those ports, which is a GOOD THING actually, but it is definitely confusing.

Doesn't this imply that the device uses STUN?.  I have not been able to determine that it does, and neither Vonage nor Motorola indicate any usage of STUN.  Still, I have blocked the STUN service port 3478 on ALL interfaces (as per the little Help popup on the SIP Proxy) and the Packet Filter shows no packets being dropped when I reboot the device, and the SIP Proxy still shows no activity.

I'll try your experiment today and repost the results.

Thanks
 

Okay, I tried your suggestion.  I set a Packet Rule to drop ports 5060 and 5061 from ANY and the VOIP stopped working even though I had the SIP Proxy running.

With it set like this, I ran the SIP Proxy with and without Transparent Mode, with and without Debug enabled, I rebooted the VOIP device after each change.  Still, there was no proxy activity, nothing logged, and the Packet Filter Live Log showed port-packets being dropped.

I even tried changing the listen-port on the SIP Proxy from 5060 to 5061.  Still no deal.

So I turned off the SIP Proxy, and even though it appears that I don't need them, I reenabled my NAT Rules and my Packet Rules for port-forwarding of 5060 and 5061 like a good little boy, because that's what the Vonage user's manual says to do.

Everything works fine, so I must subscribe to the adage "If it works, don't MESS with it!"

Accordingly, I have to declare that the SIP Proxy doesn't work.  At least not for the sort of device-based VOIP service that is rapidly becoming the norm here in the United States.  I don't know what you guys use over there.

So maybe there is a bug in the SIP Proxy, or maybe it's just not yet fully implemented.

Thanks for all of your help.

 

P.S.  I would be nice to have a live-log button to show all packets being "Allowed" though the firewall instead of just those that are dropped.  Then I can easily see what's going on between two connections.  It could have a timeout to auto-disable it because I would think it would add a certain amount of unnecessary packet-lag.