26 May
2008
26 May
'08
8:28 p.m.
Hi
I have two user clients behind separate NAT networks. My OpenSER is directly
connected to the Internet and has it's own external IP address.
Both clients are using STUN to get their external IP address and correct
port for SIP messages.
They successfully register with Openser, which is using Nathelper module and
Mediaproxy.
In this case, since the client is behind NAT, it puts the wrong port in the
Contact field of a SIP message.
As a result, SOME SIP messages from OpenSER are never received by the
client.
But with the help of Nathelper, OpenSER should correct the port in Contact
field, by replacing the NAT port with the src port of a SIP message (UDP
pack).
The problem is, that it looks like OpenSER only corrects the port in Contact
field for client A (The one who initiates the call) but not Client B(The one
who's called).
For a better explaination, please check out my logs from ngrep.
CLIENT A to OPENSER
U 2008/05/26 16:53:26.285586 157.157.78.173:54182 -> 212.50.206.33:5060
INVITE sip:1001@212.50.206.33 <sip%3A1001(a)212.50.206.33> SIP/2.0.
From: 1006<sip:1006@212.50.206.33 <sip%3A1006(a)212.50.206.33>
;tag=10007500-26260f5b.
To:
<sip:1001@212.50.206.33 <sip%3A1001(a)212.50.206.33>>3>>.
Via: SIP/2.0/UDP 157.157.78.173:62356
;branch=z9hG4bKc0a8150a10007e0026261023.
Contact: 1006<sip:1006@157.157.78.173:62356>. !!!NB!!! <-- This is the WRONG
reply port.
OPENSER RELAYS TO CLIENT B
U 2008/05/26 16:53:26.301864 212.50.206.33:5060 -> 130.208.183.251:49211
INVITE sip:1001@130.208.183.251:49208 SIP/2.0.
Record-Route: <sip:212.50.206.33;lr;ftag=10007500-26260f5b;nat=yes>.
From: 1006<sip:1006@212.50.206.33 <sip%3A1006(a)212.50.206.33>
;tag=10007500-26260f5b.
To:
<sip:1001@212.50.206.33 <sip%3A1001(a)212.50.206.33>>3>>.
Via: SIP/2.0/UDP 212.50.206.33;branch=z9hG4bK5db1.ce9aea2.0;rport.
Via: SIP/2.0/UDP 157.157.78.173:62356
;rport=54182;branch=z9hG4bKc0a8150a10007e0026261023.
Contact: 1006<sip:1006@157.157.78.173:54182>. !!!NB!!! <-- OpenSER detects
it and changes it to correct reply port. Works great.
CLIENT B ANSWERS TO OPENSER
U 2008/05/26 16:53:27.301368 130.208.183.251:49211 -> 212.50.206.33:5060
SIP/2.0 200 OK.
From: 1006<sip:1006@212.50.206.33 <sip%3A1006(a)212.50.206.33>
;tag=10007500-26260f5b.
To:
<sip:1001@212.50.206.33 <sip%3A1001(a)212.50.206.33>
;tag=10007900-26261046.
Via: SIP/2.0/UDP
212.50.206.33;branch=z9hG4bK5db1.ce9aea2.0.
Via: SIP/2.0/UDP 157.157.78.173:62356
;branch=z9hG4bKc0a8150a10007e0026261023.
Contact: 1001<sip:1001@130.208.183.251:49208>. !!!NB!!! <-- Now lets try
Client B. Wrong reply port.
OPENSER TO CLIENT A
U 2008/05/26 16:53:27.305241 212.50.206.33:5060 -> 157.157.78.173:54182
SIP/2.0 200 OK.
From: 1006<sip:1006@212.50.206.33 <sip%3A1006(a)212.50.206.33>
;tag=10007500-26260f5b.
To:
<sip:1001@212.50.206.33 <sip%3A1001(a)212.50.206.33>
;tag=10007900-26261046.
Via: SIP/2.0/UDP
157.157.78.173:62356
;branch=z9hG4bKc0a8150a10007e0026261023.
Contact: 1001<sip:1001@130.208.183.251:49208>. !!!NB!!! <-- OpenSER didn't
change the port like before, so now Client B never receives ACK from Client
A.
CLIENT A TO OPENSER
U 2008/05/26 16:53:27.518621 157.157.78.173:54182 -> 212.50.206.33:5060
ACK sip:1001@130.208.183.251:49208 SIP/2.0.
From: 1006<sip:1006@212.50.206.33 <sip%3A1006(a)212.50.206.33>
;tag=10007500-26260f5b.
To:
<sip:1001@212.50.206.33 <sip%3A1001(a)212.50.206.33>
;tag=10007900-26261046.
Via: SIP/2.0/UDP
157.157.78.173:62356
;branch=z9hG4bKc0a8150a10007e0026261505.
Contact: 1006<sip:1006@157.157.78.173:62356>.
Route: <sip:212.50.206.33;lr;ftag=10007500-26260f5b;nat=yes>.
OPENSER TO CLIENT B
U 2008/05/26 16:53:27.519192 212.50.206.33:5060 -> 130.208.183.251:49208
!!!NB!!! <-- OpenSER sends to the WRONG port!
ACK sip:1001@130.208.183.251:49208 SIP/2.0.
Record-Route: <sip:212.50.206.33;lr;ftag=10007500-26260f5b;nat=yes>.
From: 1006<sip:1006@212.50.206.33 <sip%3A1006(a)212.50.206.33>
;tag=10007500-26260f5b.
To:
<sip:1001@212.50.206.33 <sip%3A1001(a)212.50.206.33>
;tag=10007900-26261046.
CSeq: 101 ACK.
Via: SIP/2.0/UDP 212.50.206.33;branch=z9hG4bK5db1.ce9aea2.2;rport.
Via: SIP/2.0/UDP 157.157.78.173:62356
;rport=54182;branch=z9hG4bKc0a8150a10007e0026261505.
This last ACK message is never received by Client B because the client isn't
listening on port 49208.
If I manually use rewriteport("49211") it works, because obviously this last
package is then forced to port 49211 which the client listening on.
Also, the first line in my main route is force_rport(); but that still
doesn't do it.
I've been struggling with this problem for a few weeks now so all comments
and suggestions are very welcome.
My OpenSER config file can be found here: http://hoski.public.is/openser.cfg
Best regards,
Höskuldur
27 May
27 May
9:57 a.m.
New subject: [OpenSER-Users] OpenSER corrects the "Contact" field only one way.
El Monday 26 May 2008 20:28:05 Höskuldur escribió:
Hi
I have two user clients behind separate NAT networks. My OpenSER is
directly connected to the Internet and has it's own external IP address.
Both clients are using STUN to get their external IP address and correct
port for SIP messages.
They successfully register with Openser, which is using Nathelper module
and Mediaproxy.
In this case, since the client is behind NAT, it puts the wrong port in the
Contact field of a SIP message.
As a result, SOME SIP messages from OpenSER are never received by the
client.
But with the help of Nathelper, OpenSER should correct the port in Contact
field, by replacing the NAT port with the src port of a SIP message (UDP
pack).
The problem is, that it looks like OpenSER only corrects the port in
Contact field for client A (The one who initiates the call) but not Client
B(The one who's called).
Try this in onreply_route[2]:
if (status =~ "(180)|(183)|2[0-9][0-9]") {
if (isbflagset(BFLAG_NAT_CALLED) || nat_uac_test("1")) {
xlog("L_INFO", "--- NAT detected\n");
fix_nated_contact();
}
use_media_proxy();
}
Tell me if it works.
--
Iñaki Baz Castillo
ibc(a)in.ilimit.es
10:12 a.m.
New subject: [OpenSER-Users] OpenSER corrects the "Contact" field only one way.
El Tuesday 27 May 2008 09:57:42 Iñaki Baz Castillo escribió:
Try this in onreply_route[2]:
if (status =~ "(180)|(183)|2[0-9][0-9]") {
if (isbflagset(BFLAG_NAT_CALLED) || nat_uac_test("1")) {
xlog("L_INFO", "--- NAT detected\n");
fix_nated_contact();
}
use_media_proxy();
}
Also note that adding "rport" in a response is not valid at all since
"rport"
is just valid to set the "Via" in a request, so your first two lines in
onreply_route[2] are not valid:
onreply_route[2]
{
add_local_rport();
force_rport();
Try also deleting them.
--
Iñaki Baz Castillo
ibc(a)in.ilimit.es
2:06 p.m.
New subject: [OpenSER-Users] OpenSER corrects the "Contact" field only one way.
Thanks for your help.
Since I'm using OpenSER 1.1 I believe that nat_bflag isn't supported in
userloc module for 1.1.
But you got me on the right track:
onreply_route[2]
{
if(status=~"(180)|(183)|2[0-9][0-9]")
{
if (isflagset(6) || nat_uac_test("1"))
{
xlog("L_INFO", "FANN NAT - S=$rs D=$rr F=$fu T=$tu IP=$si
ID=$ci\n");
fix_nated_contact();
}
use_media_proxy();
}
exit;
}
This worked for me. Thank you very much for your help.
On Mon, May 26, 2008 at 6:28 PM, Höskuldur <hoskuldur(a)gmail.com> wrote:
Hi
I have two user clients behind separate NAT networks. My OpenSER is
directly connected to the Internet and has it's own external IP address.
Both clients are using STUN to get their external IP address and correct
port for SIP messages.
They successfully register with Openser, which is using Nathelper module
and Mediaproxy.
In this case, since the client is behind NAT, it puts the wrong port in the
Contact field of a SIP message.
As a result, SOME SIP messages from OpenSER are never received by the
client.
But with the help of Nathelper, OpenSER should correct the port in Contact
field, by replacing the NAT port with the src port of a SIP message (UDP
pack).
The problem is, that it looks like OpenSER only corrects the port in
Contact field for client A (The one who initiates the call) but not Client
B(The one who's called).
For a better explaination, please check out my logs from ngrep.
CLIENT A to OPENSER
U 2008/05/26 16:53:26.285586 157.157.78.173:54182 -> 212.50.206.33:5060
INVITE sip:1001@212.50.206.33 <sip%3A1001(a)212.50.206.33> SIP/2.0.
From: 1006<sip:1006@212.50.206.33 <sip%3A1006(a)212.50.206.33>
--
Kveðja, Höskuldur
;tag=10007500-26260f5b.
To:
<sip:1001@212.50.206.33 <sip%3A1001(a)212.50.206.33>>3>>.
Via: SIP/2.0/UDP 157.157.78.173:62356
;branch=z9hG4bKc0a8150a10007e0026261023.
Contact: 1006<sip:1006@157.157.78.173:62356>. !!!NB!!! <-- This is the
WRONG reply port.
OPENSER RELAYS TO CLIENT B
U 2008/05/26 16:53:26.301864 212.50.206.33:5060 -> 130.208.183.251:49211
INVITE sip:1001@130.208.183.251:49208 SIP/2.0.
Record-Route: <sip:212.50.206.33;lr;ftag=10007500-26260f5b;nat=yes>.
From: 1006<sip:1006@212.50.206.33 <sip%3A1006(a)212.50.206.33>
;tag=10007500-26260f5b.
To:
<sip:1001@212.50.206.33 <sip%3A1001(a)212.50.206.33>>3>>.
Via: SIP/2.0/UDP 212.50.206.33;branch=z9hG4bK5db1.ce9aea2.0;rport.
Via: SIP/2.0/UDP 157.157.78.173:62356
;rport=54182;branch=z9hG4bKc0a8150a10007e0026261023.
Contact: 1006<sip:1006@157.157.78.173:54182>. !!!NB!!! <-- OpenSER detects
it and changes it to correct reply port. Works great.
CLIENT B ANSWERS TO OPENSER
U 2008/05/26 16:53:27.301368 130.208.183.251:49211 -> 212.50.206.33:5060
SIP/2.0 200 OK.
From: 1006<sip:1006@212.50.206.33 <sip%3A1006(a)212.50.206.33>
;tag=10007500-26260f5b.
To:
<sip:1001@212.50.206.33 <sip%3A1001(a)212.50.206.33>
;tag=10007900-26261046.
Via: SIP/2.0/UDP
212.50.206.33;branch=z9hG4bK5db1.ce9aea2.0.
Via: SIP/2.0/UDP 157.157.78.173:62356
;branch=z9hG4bKc0a8150a10007e0026261023.
Contact: 1001<sip:1001@130.208.183.251:49208>. !!!NB!!! <-- Now lets try
Client B. Wrong reply port.
OPENSER TO CLIENT A
U 2008/05/26 16:53:27.305241 212.50.206.33:5060 -> 157.157.78.173:54182
SIP/2.0 200 OK.
From: 1006<sip:1006@212.50.206.33 <sip%3A1006(a)212.50.206.33>
;tag=10007500-26260f5b.
To:
<sip:1001@212.50.206.33 <sip%3A1001(a)212.50.206.33>
;tag=10007900-26261046.
Via: SIP/2.0/UDP
157.157.78.173:62356
;branch=z9hG4bKc0a8150a10007e0026261023.
Contact: 1001<sip:1001@130.208.183.251:49208>. !!!NB!!! <-- OpenSER didn't
change the port like before, so now Client B never receives ACK from Client
A.
CLIENT A TO OPENSER
U 2008/05/26 16:53:27.518621 157.157.78.173:54182 -> 212.50.206.33:5060
ACK sip:1001@130.208.183.251:49208 SIP/2.0.
From: 1006<sip:1006@212.50.206.33 <sip%3A1006(a)212.50.206.33>
;tag=10007500-26260f5b.
To:
<sip:1001@212.50.206.33 <sip%3A1001(a)212.50.206.33>
;tag=10007900-26261046.
Via: SIP/2.0/UDP
157.157.78.173:62356
;branch=z9hG4bKc0a8150a10007e0026261505.
Contact: 1006<sip:1006@157.157.78.173:62356>.
Route: <sip:212.50.206.33;lr;ftag=10007500-26260f5b;nat=yes>.
OPENSER TO CLIENT B
U 2008/05/26 16:53:27.519192 212.50.206.33:5060 -> 130.208.183.251:49208
!!!NB!!! <-- OpenSER sends to the WRONG port!
ACK sip:1001@130.208.183.251:49208 SIP/2.0.
Record-Route: <sip:212.50.206.33;lr;ftag=10007500-26260f5b;nat=yes>.
From: 1006<sip:1006@212.50.206.33 <sip%3A1006(a)212.50.206.33>
;tag=10007500-26260f5b.
To:
<sip:1001@212.50.206.33 <sip%3A1001(a)212.50.206.33>
;tag=10007900-26261046.
CSeq: 101 ACK.
Via: SIP/2.0/UDP 212.50.206.33;branch=z9hG4bK5db1.ce9aea2.2;rport.
Via: SIP/2.0/UDP 157.157.78.173:62356
;rport=54182;branch=z9hG4bKc0a8150a10007e0026261505.
This last ACK message is never received by Client B because the client
isn't listening on port 49208.
If I manually use rewriteport("49211") it works, because obviously this
last package is then forced to port 49211 which the client listening on.
Also, the first line in my main route is force_rport(); but that still
doesn't do it.
I've been struggling with this problem for a few weeks now so all comments
and suggestions are very welcome.
My OpenSER config file can be found here:
http://hoski.public.is/openser.cfg
Best regards,
Höskuldur
2:25 p.m.
New subject: [OpenSER-Users] OpenSER corrects the "Contact" field only one way.
El Tuesday 27 May 2008 14:06:27 Höskuldur escribió:
Thanks for your help.
Since I'm using OpenSER 1.1 I believe that nat_bflag isn't supported in
userloc module for 1.1. But you got me on the right track:
onreply_route[2]
{
if(status=~"(180)|(183)|2[0-9][0-9]")
{
if (isflagset(6) || nat_uac_test("1"))
{
xlog("L_INFO", "FANN NAT - S=$rs D=$rr F=$fu T=$tu IP=$si
ID=$ci\n"); fix_nated_contact();
}
use_media_proxy();
}
exit;
}
This worked for me. Thank you very much for your help.
Nice :)
--
Iñaki Baz Castillo
ibc(a)in.ilimit.es
5836
days inactive
5837
days old
4 comments
2 participants
participants (2)
-
Höskuldur -
Iñaki Baz Castillo