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.
Any thoughts? Is this a configuration item I've missed, or is this a current issue with SER?
Linus
(* The other reason for using port 5062 is that it 'SIP aware' but possibily broken NAT routers won't rewrite the traffic if its not on port 5060)
Linus Surguy wrote:
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.
The code snippet would look like:
# Check if caller is on the rtp_proxy group if ((is_user_in("From", "rtp_proxy"))) { setflag(2); force_rport(); fix_nated_contact(); . . };
# Check if called user is on the rtp_proxy group if ((is_user_in("To", "rtp_proxy")) & !(isflagset(2))) { setflag(2); force_rport(); . }; .
This would greatly reduce the number of problems you are having. For our part, if we keep on finding more and more of these broken SIP Aware NAT implementations we might just have to switch all our network to a port different from 5060. This is getting pretty ridiculous, every day we seem to find more and more of these bad NATs.
Ricardo.
Any thoughts? Is this a configuration item I've missed, or is this a current issue with SER?
Linus
(* The other reason for using port 5062 is that it 'SIP aware' but possibily broken NAT routers won't rewrite the traffic if its not on port 5060)
Serusers mailing list serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
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
Sorry, I should have added that
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
this of course now means that SER always responds from the right port number!
I don't know if this is something I should have known already, but also keep the size of the INVITEs down, if they exceed 1480 bytes things start going horridly wrong as well - we had to ensure that SER stripped out some of the unrequired headers one of our Cisco boxes was putting in.
Linus
Hey everybody.
Thanks for you help on my last voice mail error. I'm having another issue though. I'm using aliases on my subscribers. If another subscriber dials the alias number, they don't get redirected to voicemail. They have to dial the subscribers "normal" number to get proper redirection to voicemail.
What am I missing here? I do a lookup("aliases"); and calls terminate. I'm guessing I'm missing a step in there having to rewrite the user portion of the uri?
Thanks in advance for your help.
Cheers,
CJ cto@livevoip.com
Try using revert_uri() before you send to voicemail.
It would be great though if sems could be configured to use To: header instead of userpart of request-uri.
Cheers, Soren
Hey everybody.
Thanks for you help on my last voice mail error. I'm having another issue though. I'm using aliases on my subscribers. If another subscriber dials the alias number, they don't get redirected to voicemail. They have to dial the subscribers "normal" number to get proper redirection to voicemail.
What am I missing here? I do a lookup("aliases"); and calls terminate. I'm guessing I'm missing a step in there having to rewrite the user portion of the uri?
Thanks in advance for your help.
Cheers,
CJ cto@livevoip.com
Serusers mailing list serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
-
Andres -
Juha Heinanen -
Linus Surguy -
Soren (Home) -
VOIP Operations