[SR-Users] Best approach for TCP/TLS connection re-use for nated Contacts

[Daniel-Constantin Mierla]

Hello,

you can do nat_uac_test() for reply and it will detect is it natted, then
you can call fix_nated_contact() -- this being another option.

Cheers,
Daniel

On Fri, Mar 9, 2012 at 8:56 PM, Giacomo Vacca <Giacomo.Vacca at truphone.com>wrote:

>  Hi all,
>
> I have a scenario where it’s not clear to me what the best approach should
> be (Kamailio 3.2.0 on Squeeze, although I think it’s a matter of routing
> logic only).
>
>
>
> I have a client behind NAT that sends an initial REGISTER request with a
> Contact containing private ip:port (e.g.
>
> Contact: “GV” <sip:12345 at 192.168.1.2:54321;transport=tcp>
>
> )
>
> However, after it’s challenged for authentication with a 401, it sends the
> following REGISTER request with Authorization header and with a Contact
> containing ip:port equal to the ‘received’ SIP URI (with a combination of
> ‘rport’ and ‘received’ parameters (e.g.
>
> Contact: “GV” <sip:12345@[receivedIP]:[rport];transport=tcp>
>
> )
>
> In this case kamailio’s routing logic is not marking the REGISTER as
> natted (no Received field in location and no NAT flags set).
>
>
>
> You can imagine I have a fairly standard NAT handling:
>
>
>
> route[NATDETECT] {
>
>         force_rport();
>
>         if (nat_uac_test("19")) {
>
>                 if (is_method("REGISTER")) {
>
>                         fix_nated_register();
>
>                 } else {
>
>                         fix_nated_contact();
>
>                 }
>
>                 setflag(FLT_NATS);
>
>         }
>
>         return;
>
> }
>
>
>
> FLT_NATS won’t be set, and so it won’t FLB_NATB in the following
> processing.
>
>
>
> This client receives a call: Kamailio relays the INVITE to it using the
> stored Contact. The INVITE is correctly received by the client, because the
> stored Contact refers to the connected socket ([received]:rport).
>
> The trouble starts when then the client replies with a 200 OK containing
> the private ip:port in the Contact header field (again 192.168.1.2:54321).
>
> The ACK will then have that private ip:port in the R-URI, and its relaying
> will fail.
>
>
>
> One of the solutions I’ve found is using *always *add_contact_alias() in
> onreply_route when handling the 200 OK, and then use handle_ruri_alias()
> when defining the destination for the ACK.
>
>
>
> I know that without traces and the full .cfg this is quite a broad
> question, but I wonder if you have already had to deal with this kind of
> client behaviour and can provide advice on the best practices.
>
> This is in particular useful for the re-use of TCP-based connections.
>
>
>
> Thanks in advance,
>
> Giacomo
>
>
>
>
>
>
>
> Truphone Limited is a limited liability company registered in England &
> Wales, registered office: 4 Royal Mint Court, London, EC3N 4HJ. Registered
> No. 04187081. VAT No. GB 851 5278 19.
>
> Tru is a brand name of Truphone and is a Truphone Communications Service.
> Truphone is a trading name for a number of distinct legal entities that
> operate in combination. www.truphone.com.
>
> This e-mail, and any attachment(s), may contain information which is
> confidential and/or privileged, and is intended for the addressee only. If
> you are not the intended recipient, you may not use, disclose, copy or
> distribute this information in any manner whatsoever. If you have received
> this e-mail in error, please contact the sender immediately and delete it.
>
> _______________________________________________
> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
> sr-users at lists.sip-router.org
> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
>
>


-- 
Daniel-Constantin Mierla
  http://www.asipto.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20120310/6bfa9364/attachment.htm>