Hi Andres,
I've configured ser to listen on two ports, in the ser.cfg:
listen=a.b.c.d:5060 listen=a.b.c.d:5062
The idea is that 'normal' public traffic and traffic that can be handled
by
normal 'nat' detectors will be directed to port 5060, but traffic that I know is difficult is directed to register and use a.b.c.d:5062 as the SIP server.
This all works great in the NAT (inside) -> SER -> somewhere direction,
but
I've discovered that when any device which registers to the 5062 port,
the
fact that it arrived on an alternative port doesnt seem to be remembered.
Therefore, when I have a somewhere -> SER -> NAT (inside) call, (on a
5062
registered device) although SER remembers the port on the NAT device to forward the INVITE to, it sends it from port 5060 - which at least on my test nat router is enough for it to reject the packet and not pass it inside.
Hi Linus,
I can confirm your observations. We suffer the same problem. The only difference is that we use the "alternate" port only for the broken SIP Aware NAT implementations. For everybody else, we use port 5060. We deal with the "difficult" NAT traffic by creating a special SER group called rtpproxy and inserting these special users in it. Outgoing/Incoming calls from these users will be handled by rtpproxy.
As an update, I've changed everything around today and got a much better result although it still needs some tweaking as it is not working perfectly. Instead of using:
listen=a.b.c.d:5060 listen=a.b.c.d:5062
I've actually started two different invocations of ser on the same machine with two different ser.cfg, each with a single listen statement. We then run two different location databases, save("location") on port 5060, and save ("locationnat") on 5062. Then, on port 5060 we can do something similar to if (!lookup(location)) rewriteport(5062) to try it on the other server.
I'd really like to redirect the traffic rather than forward it, but I havnt worked out how to configure that in our specific requirement yet.
Linus