[OpenSER-Users] OpenSER corrects the "Contact" field only one way.

[Höskuldur]

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 at 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 at 212.50.206.33 <sip%3A1001 at 212.50.206.33> SIP/2.0.
> From: 1006<sip:1006 at 212.50.206.33 <sip%3A1006 at 212.50.206.33>
> >;tag=10007500-26260f5b.
> To: <sip:1001 at 212.50.206.33 <sip%3A1001 at 212.50.206.33>>.
> Via: SIP/2.0/UDP 157.157.78.173:62356
> ;branch=z9hG4bKc0a8150a10007e0026261023.
> Contact: 1006<sip:1006 at 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 at 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 at 212.50.206.33 <sip%3A1006 at 212.50.206.33>
> >;tag=10007500-26260f5b.
> To: <sip:1001 at 212.50.206.33 <sip%3A1001 at 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: 1006<sip:1006 at 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 at 212.50.206.33 <sip%3A1006 at 212.50.206.33>
> >;tag=10007500-26260f5b.
> To: <sip:1001 at 212.50.206.33 <sip%3A1001 at 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 at 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 at 212.50.206.33 <sip%3A1006 at 212.50.206.33>
> >;tag=10007500-26260f5b.
> To: <sip:1001 at 212.50.206.33 <sip%3A1001 at 212.50.206.33>
> >;tag=10007900-26261046.
> Via: SIP/2.0/UDP 157.157.78.173:62356
> ;branch=z9hG4bKc0a8150a10007e0026261023.
> Contact: 1001<sip:1001 at 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 at 130.208.183.251:49208 SIP/2.0.
> From: 1006<sip:1006 at 212.50.206.33 <sip%3A1006 at 212.50.206.33>
> >;tag=10007500-26260f5b.
> To: <sip:1001 at 212.50.206.33 <sip%3A1001 at 212.50.206.33>
> >;tag=10007900-26261046.
> Via: SIP/2.0/UDP 157.157.78.173:62356
> ;branch=z9hG4bKc0a8150a10007e0026261505.
> Contact: 1006<sip:1006 at 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 at 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 at 212.50.206.33 <sip%3A1006 at 212.50.206.33>
> >;tag=10007500-26260f5b.
> To: <sip:1001 at 212.50.206.33 <sip%3A1001 at 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
>



-- 

Kveðja, Höskuldur
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20080527/2a647752/attachment.htm>