[nat_traversal] Replacement of bflag(NAT_CALLED) ?

classic Classic list List threaded Threaded
12 messages Options
Reply | Threaded
Open this post in threaded view
|

[nat_traversal] Replacement of bflag(NAT_CALLED) ?

Iñaki Baz Castillo
Hi, usually (with nathelper module) a bflag(NAT_CALLED) is enabled when the
user is registered behind NAT, so when "lookup(location)" gets the user
information, that bflag is set to 1 and we can decide to use RtpProxy or
whatever.

AFAIK this mechanism (using bflag(NAT_CALLED)) is still necessary when
using "nat_traversal" since it's the only way we can know if the caller user
location is behind NAT. Is it?

Thanks.

--
Iñaki Baz Castillo

_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: [nat_traversal] Replacement of bflag(NAT_CALLED) ?

Dan Pascu
On Wednesday 12 November 2008, Iñaki Baz Castillo wrote:
> Hi, usually (with nathelper module) a bflag(NAT_CALLED) is enabled when
> the user is registered behind NAT, so when "lookup(location)" gets the
> user information, that bflag is set to 1 and we can decide to use
> RtpProxy or whatever.
>
> AFAIK this mechanism (using bflag(NAT_CALLED)) is still necessary when
> using "nat_traversal" since it's the only way we can know if the caller
> user location is behind NAT. Is it?

Yes, however that mechanism is provided by usrloc, so it has nothing to do
with either nat_traversal or nathelper. It was just a means to help other
modules (like nathelper or mediaproxy) to take a decision per contact.

There seems to be some confusion here about the role of this module. The
nat_traversal module is there to provide help with NAT traversal for SIP
signaling purposes (that means NAT tests, fixing contacts and keeping
devices behind NAT alive). You will use both nat_traversal and nathelper
or mediaproxy. The only thing that changed, is that SIP signaling NAT
traversal functionality has been moved to nat_traversal, while nathelper
and mediaproxy will only provide NAT traversal for media. That and the
fact that nat_traversal implements a much more flexible and complete
solution to keepalive devices behind NAT than either nathelper or
mediaproxy ever did.

As a side note, nat_traversal itself doesn't need that mechanism because
it can figure out itself if a destination device is behind NAT and it
needs to keep it alive during a call. So you only call nat_traversal()
when you have a caller behind NAT that you want to keep reachable (for
either REGISTER, SUBSCRIBE or INVITE sessions).

--
Dan

_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: [nat_traversal] Replacement of bflag(NAT_CALLED) ?

Iñaki Baz Castillo
2008/11/12 Dan Pascu <[hidden email]>:

> As a side note, nat_traversal itself doesn't need that mechanism because
> it can figure out itself if a destination device is behind NAT and it
> needs to keep it alive during a call. So you only call nat_traversal()
> when you have a caller behind NAT that you want to keep reachable (for
> either REGISTER, SUBSCRIBE or INVITE sessions).

Could you explain it more? "nat_keepalive()" can be called just from
REQUEST_ROUTE, not in ON_REPLY_ROUTE.
If alice calls bob (who is registered behind NAT) the nat_traversal
was alreading mantaining the keepalive to bob after the REGISTER, but
anyway I need to fix the CONTACT in the 200 OK from bob (this can be
detected in ON_REPLY_ROUTE based on BFLAG_NAT_CALLED set or not during
bob registration, by doing "nat_test", by adding a Record-Route
paramenter in INVITE....).

But as far as I understand, nat_keepalive() has nothing to do in the
above, *except* mantaining the keepalive for bob since it is
registered behind NAT, but no more, did you mean other something
different?

Thanks.


--
Iñaki Baz Castillo
<[hidden email]>
_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: [nat_traversal] Replacement of bflag(NAT_CALLED) ?

Klaus Darilion
In reply to this post by Dan Pascu


Dan Pascu schrieb:
>...
> As a side note, nat_traversal itself doesn't need that mechanism because
> it can figure out itself if a destination device is behind NAT and it
> needs to keep it alive during a call. So you only call nat_traversal()
> when you have a caller behind NAT that you want to keep reachable (for
> either REGISTER, SUBSCRIBE or INVITE sessions).

Hi Dan!

I think for testing if the callee is behind NAT, the nattraversal module
can not help me, I still have to use the nat_bflag - is this correct?

klaus

_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: [nat_traversal] Replacement of bflag(NAT_CALLED) ?

Dan Pascu
In reply to this post by Iñaki Baz Castillo
On Wednesday 12 November 2008, Iñaki Baz Castillo wrote:
> 2008/11/12 Dan Pascu <[hidden email]>:
> > As a side note, nat_traversal itself doesn't need that mechanism
> > because it can figure out itself if a destination device is behind
> > NAT and it needs to keep it alive during a call. So you only call
> > nat_traversal() when you have a caller behind NAT that you want to
> > keep reachable (for either REGISTER, SUBSCRIBE or INVITE sessions).
>
> Could you explain it more? "nat_keepalive()" can be called just from
> REQUEST_ROUTE, not in ON_REPLY_ROUTE.

Because nat_keepalive() is for keeping alive the source of the call. The
destination (for INVITE sessions) is automatically kept alive if behind
NAT without you doing anything.

> If alice calls bob (who is registered behind NAT) the nat_traversal
> was alreading mantaining the keepalive to bob after the REGISTER, but
> anyway I need to fix the CONTACT in the 200 OK from bob (this can be
> detected in ON_REPLY_ROUTE based on BFLAG_NAT_CALLED set or not during
> bob registration, by doing "nat_test", by adding a Record-Route
> paramenter in INVITE....).

You can use fix_contact wherever you want. This has nothing to do with
nat_keepalive()

> But as far as I understand, nat_keepalive() has nothing to do in the
> above, *except* mantaining the keepalive for bob since it is
> registered behind NAT, but no more,

exactly. call keep_alive() for each REGISTER/SUBSCRIBE/INVITE without a
to_tag and for which the caller is found to be behind NAT. It will figure
out the rest automatically. For INVITE will keep all NATed destinations
alive without you doing anything (will see if a destination is registered
to be kept alive for a REGISTER and if so will also add the INVITE
condition to it, in case it stops registering or moves the registration
to a different proxy in the cluster, in mid-call).

> did you mean other something
> different?

No, I didn't.

--
Dan

_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: [nat_traversal] Replacement of bflag (NAT_CALLED) ?

Dan Pascu
In reply to this post by Klaus Darilion
On Wednesday 12 November 2008, Klaus Darilion wrote:

> Dan Pascu schrieb:
> >...
> > As a side note, nat_traversal itself doesn't need that mechanism
> > because it can figure out itself if a destination device is behind
> > NAT and it needs to keep it alive during a call. So you only call
> > nat_traversal() when you have a caller behind NAT that you want to
> > keep reachable (for either REGISTER, SUBSCRIBE or INVITE sessions).
>
> Hi Dan!
>
> I think for testing if the callee is behind NAT, the nattraversal
> module can not help me, I still have to use the nat_bflag - is this
> correct?

Yes. For your own purposes you need to use a bflag per contact.

What I meant, is that for its internal purposes when it comes to keepalive
endpoints, the nat_traversal module does figure out automatically without
you doing anything, if the destination of an INVITE needs to be kept
alive during the call.

--
Dan

_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: [nat_traversal] Replacement of bflag(NAT_CALLED) ?

Klaus Darilion


Dan Pascu schrieb:

> On Wednesday 12 November 2008, Klaus Darilion wrote:
>> Dan Pascu schrieb:
>>> ...
>>> As a side note, nat_traversal itself doesn't need that mechanism
>>> because it can figure out itself if a destination device is behind
>>> NAT and it needs to keep it alive during a call. So you only call
>>> nat_traversal() when you have a caller behind NAT that you want to
>>> keep reachable (for either REGISTER, SUBSCRIBE or INVITE sessions).
>> Hi Dan!
>>
>> I think for testing if the callee is behind NAT, the nattraversal
>> module can not help me, I still have to use the nat_bflag - is this
>> correct?
>
> Yes. For your own purposes you need to use a bflag per contact.
>
> What I meant, is that for its internal purposes when it comes to keepalive
> endpoints, the nat_traversal module does figure out automatically without
> you doing anything, if the destination of an INVITE needs to be kept
> alive during the call.

I still do not understand. The callee has to be registered - otherwise
it is not reachable at all. Thus, keep-alive for the callee will be done
once it registers based on nat tests during REGISTER. Thus, when calling
the callee, the session is implicitly keep-alive'd by the the keep-alive
  triggered by registration. What do I miss?

regards
klaus

_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: [nat_traversal] Replacement of bflag(NAT_CALLED) ?

Iñaki Baz Castillo
2008/11/12 Klaus Darilion <[hidden email]>:

> I still do not understand. The callee has to be registered - otherwise it is
> not reachable at all. Thus, keep-alive for the callee will be done once it
> registers based on nat tests during REGISTER. Thus, when calling the callee,
> the session is implicitly keep-alive'd by the the keep-alive  triggered by
> registration. What do I miss?

In case the callee ends its registration during the call,
nat_traversal *still* sends NOTITY/OPTIONS to the callee until the
call ends, even if the callee is not registered anymore.


--
Iñaki Baz Castillo
<[hidden email]>
_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: [nat_traversal] Replacement of bflag(NAT_CALLED) ?

Klaus Darilion


Iñaki Baz Castillo schrieb:

> 2008/11/12 Klaus Darilion <[hidden email]>:
>
>> I still do not understand. The callee has to be registered - otherwise it is
>> not reachable at all. Thus, keep-alive for the callee will be done once it
>> registers based on nat tests during REGISTER. Thus, when calling the callee,
>> the session is implicitly keep-alive'd by the the keep-alive  triggered by
>> registration. What do I miss?
>
> In case the callee ends its registration during the call,
> nat_traversal *still* sends NOTITY/OPTIONS to the callee until the
> call ends, even if the callee is not registered anymore.

Ok. I see. And if the callee is still registered? Will it be keep-alived
twice?

klaus

_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: [nat_traversal] Replacement of bflag(NAT_CALLED) ?

Iñaki Baz Castillo
2008/11/12 Klaus Darilion <[hidden email]>:
> Ok. I see. And if the callee is still registered? Will it be keep-alived
> twice?

No, it will be keep-alived just once, since keep-aliving depends on
destination address (a client could sends a SUBSCRIBE without
registering before, and it will be keepalived also, and if later it
registers then it won't have double pinging, but in case the
subscription ends then it will be pinged since it's registered behind
NAT, it's funy! )


--
Iñaki Baz Castillo
<[hidden email]>
_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: [nat_traversal] Replacement of bflag(NAT_CALLED) ?

Dan Pascu
In reply to this post by Iñaki Baz Castillo
On Wednesday 12 November 2008, Iñaki Baz Castillo wrote:

> 2008/11/12 Klaus Darilion <[hidden email]>:
> > I still do not understand. The callee has to be registered -
> > otherwise it is not reachable at all. Thus, keep-alive for the callee
> > will be done once it registers based on nat tests during REGISTER.
> > Thus, when calling the callee, the session is implicitly keep-alive'd
> > by the the keep-alive  triggered by registration. What do I miss?
>
> In case the callee ends its registration during the call,
> nat_traversal *still* sends NOTITY/OPTIONS to the callee until the
> call ends, even if the callee is not registered anymore.

In addition to that, there are also more complex cases involving networks
having topologies with multiple proxies handling a given domain, which
also need such a behavior. In short, not only can a registration end
during a call, but also the NAT entry point used to renew a registration
may change during a call.

All of this stuff is explained in pretty much detail in the README.

--
Dan

_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: [nat_traversal] Replacement of bflag (NAT_CALLED) ?

Dan Pascu
In reply to this post by Klaus Darilion
On Wednesday 12 November 2008, Klaus Darilion wrote:

> Iñaki Baz Castillo schrieb:
> > 2008/11/12 Klaus Darilion <[hidden email]>:
> >> I still do not understand. The callee has to be registered -
> >> otherwise it is not reachable at all. Thus, keep-alive for the
> >> callee will be done once it registers based on nat tests during
> >> REGISTER. Thus, when calling the callee, the session is implicitly
> >> keep-alive'd by the the keep-alive  triggered by registration. What
> >> do I miss?
> >
> > In case the callee ends its registration during the call,
> > nat_traversal *still* sends NOTITY/OPTIONS to the callee until the
> > call ends, even if the callee is not registered anymore.
>
> Ok. I see. And if the callee is still registered? Will it be
> keep-alived twice?

No. It's one keepalive message per endpoint (IP:port), no matter how many
SIP accounts that device uses with a given proxy, or for how many
conditions the endpoint is kept alive (REGISTER/SUBSCRIBE/INVITE)

--
Dan (who keeps repeating here the things he already wrote in the README)

_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users