[SR-Users] Nathelper module, FLT_NATS, FLT_NATB
Daniel-Constantin Mierla
miconda at gmail.com
Fri Jun 22 10:10:27 CEST 2012
Hello,
On 6/22/12 1:33 AM, Richard Brady wrote:
> Hi folks
>
> I've configured Kamailio as a simply multi-homed proxy offering NAT
> traversa, TCP connection management, etc to FreeSWICH behind it.
> FreeSWITCH acts as the registrar.
>
> I'm trying to understand the default config and the following things
> don't make sense to me (I can't find documentation on these):
>
> 1. The nat=yes flag. What does it mean exactly and why is it on the RR
> and not on the Contact/R-URI? Also, when double RR is enabled, why
> does it get added to both headers?
it used to be in contact, but some times can get in troubles if the UA
does not recognize it's address in the r-uri. Having it in record-/route
headers does not interact with UAs, is just proxy's job. The parameter
is used to detect if a call is natted, used mainly for re-INVITEs, where
the destination user may not be present in r-uri.
>
> 2. The FLT_NATS and FLB_NATB flags. I'd like to know what this stands
> for, I guess "flag for transaction - NAT" and "flag for branch - NAT"
> but what do the S and the B stand for? More importantly what do these
> flags mean? Is it correct to say that the first indicates the UAC /
> A-leg / requester is behind NAT and the second that the UAS / B-leg /
> responder is behind NAT?
yes, for initial invite is the case.
>
> 3. In the the NATMANAGE route of the default config we have:
>
> if (is_request()) {
> if(has_totag()) {
> if(check_route_param("nat=yes")) {
> setbflag(FLB_NATB);
> }
> }
> }
>
> Which to me means "if the message is a request inside an existing
> dialog ..." and I'm thinking, isn't this a bit late in the dialog to
> be setting NAT flags? I would expect to set the flag for the A-leg on
> the incoming request, and the flag for the B-leg on the incoming
> reply. I can't point in waiting for the ACK to try and work out
> whether this leg is behind NAT. And also it seem this set of if
> statements will also match incoming requests from the A-leg, so why
> are we setting a brach flag? Does that leg also also get the
> properties of a branch?
B-leg behind the nat is detected based on location record. When B
registers, it is detected being behind nat and FLB_NATB is saved in
location and restored upon lookup(...).
>
> 4. When I get a 200 OK coming from behind NAT it is not subjected to
> fix_nated_contact(), and this seems to be because it doesn't have the
> FLB_NATB flag set:
>
> if (is_reply()) {
> if(isbflagset(FLB_NATB)) {
> fix_nated_contact();
> }
> }
>
The contact does not need a fix when it is a public address. When it is
behind a nat, the fix will replace it with the ip and port of the nat
router. There is another option for this, adding a parameter to the
contact with the ip/port of the nat.
Cheers,
Daniel
> Any help clarifying would be much appreciated.
>
> Thanks,
> Richard
>
> --
> Richard Brady
>
>
> _______________________________________________
> 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
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
Kamailio Advanced Training, Seattle, USA, Sep 23-26, 2012 - http://asipto.com/u/katu
Kamailio Practical Workshop, Netherlands, Sep 10-12, 2012 - http://asipto.com/u/kpw
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20120622/743f0cc1/attachment.htm>
More information about the sr-users
mailing list