dslreports logo
site
 
    All Forums Hot Topics Gallery
spc

spacer




how-to block ads


Search Topic:
uniqs
1546
share rss forum feed

Jeff Gilliam

join:2011-05-19

[General] SIP ALG

We are having issues with some of our customers who do not have an option to disable SIP ALG in their routers. In most cases customer won't be able to receive incoming calls and in some instances they can't make outgoing calls as well. Even the routers that have option to disable SIP ALG, it's hard for the non-technical customer to log on to router and disable it. I have seen that some providers like Vonage work perfectly on same router with which we are having problems. Is there an option/setting in VoIP adapters to take care of SIP ALG instead of tweaking the router? We basically want a work around to avoid having SIP ALG problems.

Stewart

join:2005-07-13
kudos:26

1 edit
For the vast majority of routers, but not all, simply avoiding port 5060 (or sometimes port 5061) will bypass the ALG. This means that your server needs to listen on an alternate port, e.g. 5080, and that the adapter must also use a different port, e.g. 5090 as its local port. The latter setting is often called SIP Port or UDP Listen Port.

In many of the remaining cases, setting up NAT mapping in the adapter (so it doesn't put its private IP address in the SIP headers, except perhaps for Call-ID).


vanon

@144.188.69.x
reply to Jeff Gilliam
Have you tried using a port other then 5060 for sip signaling? Some (most) routers will not ALG sip traffic on alternate ports (such as 10000, which is what Vonage uses)

Jeff Gilliam

join:2011-05-19
reply to Stewart
We have hundreds of users using port 5060 so changing it to 5080 is not an option. Since we are using Linux we tried port forwarding from port 5080 to port 5060 but that seems to create another issue. i.e. outgoing calls drop after 20 seconds, actually there's no voice. We are using the following iptables rule.
-A PREROUTING -p udp -m udp --dport 5080 -j REDIRECT --to-ports 5060
We tried other rules also but only this one seems to work with no voice after after 20 seconds. With other rules the ATAs don't even register. The reason for dropped calls I believe is that RTP/SIP packets don't find their way back and timeout after 20 seconds. However, incoming calls work perfectly. I'd appreciate if you could suggest another iptables rule that fixes this issue or another work around.

Stewart

join:2005-07-13
kudos:26
Sorry, I don't know the answer. I believe that the first order problem is that when Asterisk receives a request sent to port 5080, it thinks it got it on port 5060, so the 200 OK will have port 5060 in the Contact header. The client will then send the ACK to port 5060 and it gets butchered by the ALG. The server keeps retransmitting the 200, during which time conversation can take place, but it never gets the ACK and when the retries are exhausted, the call gets dropped. You should be able to confirm this with Wireshark.

If you Google "Asterisk listen on multiple SIP ports", there are some posts essentially saying that the NAT code in Asterisk can deal with the above issue, but I don't know enough to confirm or refute that.

This thread »asterisk.inmte.com/viewtopic.php?t=15829 suggests an alternate approach: running a proxy on the same or different server that forwards to Asterisk. I would expect that to be a robust solution, but there are obviously many subtle details to be worked out.

I'm pretty sure that VoIP.ms and PBXes, among others, are Asterisk-based and successfully support connections on multiple ports. The methods used are probably trade secrets

Stewart

join:2005-07-13
kudos:26
reply to Jeff Gilliam
I had another thought. Using your iptables entry, and on a client that supports it, such as a Linksys ATA, try setting Outbound Proxy to e.g. yourserver.com:5080 and set both Use Outbound Proxy and Use OB Proxy in Dialog to yes. That should force ACKs, BYEs, etc. to go to port 5080.

voip_wire

join:2010-07-02
kudos:1
reply to Jeff Gilliam
Would you mind providing an overview of the setup that is causing issues? The brand/model of the router in question would be useful to community at large.

If you have control over the sip clients, switching them to TLS could bypass the troublesome ALG. See »wiki.freeswitch.org/wiki/ALG#Other_Options it's freeswitch, but should be equally applicable.

Could you expand the no voice comment? I was under the impression that SIP ALG leaves the RTP packets alone, so a bit surprising if a 2way call is established but gets dropped after 20s. Don't mean to imply it is not possible, just surprised that a specific implementation would be that bad ...

Cheers,
-m