[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