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@212.50.206.33 SIP/2.0. From: 1006<sip:1006@212.50.206.33 sip%3A1006@212.50.206.33
;tag=10007500-26260f5b.
To: <sip:1001@212.50.206.33 sip%3A1001@212.50.206.33>. Via: SIP/2.0/UDP 157.157.78.173:62356 ;branch=z9hG4bKc0a8150a10007e0026261023. Contact: 1006sip: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@212.50.206.33
;tag=10007500-26260f5b.
To: <sip:1001@212.50.206.33 sip%3A1001@212.50.206.33>. 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: 1006sip: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@212.50.206.33
;tag=10007500-26260f5b.
To: <sip:1001@212.50.206.33 sip%3A1001@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: 1001sip: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@212.50.206.33
;tag=10007500-26260f5b.
To: <sip:1001@212.50.206.33 sip%3A1001@212.50.206.33
;tag=10007900-26261046.
Via: SIP/2.0/UDP 157.157.78.173:62356 ;branch=z9hG4bKc0a8150a10007e0026261023. Contact: 1001sip: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@212.50.206.33
;tag=10007500-26260f5b.
To: <sip:1001@212.50.206.33 sip%3A1001@212.50.206.33
;tag=10007900-26261046.
Via: SIP/2.0/UDP 157.157.78.173:62356 ;branch=z9hG4bKc0a8150a10007e0026261505. Contact: 1006sip: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@212.50.206.33
;tag=10007500-26260f5b.
To: <sip:1001@212.50.206.33 sip%3A1001@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
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.
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.
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@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@212.50.206.33 SIP/2.0. From: 1006<sip:1006@212.50.206.33 sip%3A1006@212.50.206.33
;tag=10007500-26260f5b.
To: <sip:1001@212.50.206.33 sip%3A1001@212.50.206.33>. Via: SIP/2.0/UDP 157.157.78.173:62356 ;branch=z9hG4bKc0a8150a10007e0026261023. Contact: 1006sip: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@212.50.206.33
;tag=10007500-26260f5b.
To: <sip:1001@212.50.206.33 sip%3A1001@212.50.206.33>. 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: 1006sip: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@212.50.206.33
;tag=10007500-26260f5b.
To: <sip:1001@212.50.206.33 sip%3A1001@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: 1001sip: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@212.50.206.33
;tag=10007500-26260f5b.
To: <sip:1001@212.50.206.33 sip%3A1001@212.50.206.33
;tag=10007900-26261046.
Via: SIP/2.0/UDP 157.157.78.173:62356 ;branch=z9hG4bKc0a8150a10007e0026261023. Contact: 1001sip: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@212.50.206.33
;tag=10007500-26260f5b.
To: <sip:1001@212.50.206.33 sip%3A1001@212.50.206.33
;tag=10007900-26261046.
Via: SIP/2.0/UDP 157.157.78.173:62356 ;branch=z9hG4bKc0a8150a10007e0026261505. Contact: 1006sip: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@212.50.206.33
;tag=10007500-26260f5b.
To: <sip:1001@212.50.206.33 sip%3A1001@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
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 :)
-
Höskuldur -
Iñaki Baz Castillo