16 Aug
2004
16 Aug
'04
7:46 a.m.
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)
16 Aug
16 Aug
4:36 p.m.
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(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers
6:27 p.m.
Hi Andres,
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:
>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. >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
6:32 p.m.
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:
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
>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 
8:18 p.m.
New subject: [Serusers] Voicemail ????
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(a)livevoip.com
17 Aug
17 Aug
7:09 a.m.
New subject: [Serusers] Voicemail ????
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(a)livevoip.com
_______________________________________________
Serusers mailing list
serusers(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers
--
Soren Davidsen,
Univ: AUE department of computer science, room H302, +45-20676081
Home: http://tanesha.net/, +45-36947805 or +1-3602266324
Ring billigt med IP-telefoni: http://musimi.dk/, http://GratisSip.dk/
7273
days inactive
7274
days old
6 comments
5 participants
participants (5)
-
Andres -
Juha Heinanen -
Linus Surguy -
Soren (Home) -
VOIP Operations