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.va...@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@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@lists.sip-router.org > http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users > > -- Daniel-Constantin Mierla http://www.asipto.com
_______________________________________________ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users