[Kamailio-Users] [SR-Users] force_rtp_proxy() vis-a-vis BYE

Iñaki Baz Castillo ibc at aliax.net
Tue Jul 7 20:33:29 CEST 2009


El Martes, 7 de Julio de 2009, Daniel-Constantin Mierla escribió:
> On 07/07/2009 07:27 PM, Iñaki Baz Castillo wrote:
> > 2009/7/7 Daniel-Constantin Mierla <miconda at gmail.com>:
> >>> I use nat-traversal module and it's MUCH MUCH more powerful than
> >>> nathelper, for sure.
> >>
> >> I do not agree at all with this, when comes to flexibility.
> >> nat_traversal main problem is the relying on dialog module, which adds
> >> lot of overhead to a proxy.
> >
> > Not sure now if dialog module is fully required for all the cases...
> > It's just required if you want to mantain nat keepalive for calls
> > initiated by non registered users.
>
> it does not bind to usrloc, so I think it has no idea who is registered
> or not, unless it is done via some parameters.

--------
REGISTER - called before save_location() or t_relay() (depending on whether 
the proxy that received the REGISTER is also handling registration for that 
subscriber or not). It will determine from either the stateless reply 
generated by save_location() or the TM relayed reply if the registration was 
successful and what is its expiration time. If the registration was successful 
it will mark the given NAT endpoint for keepalive for the registration 
condition using the detected expiration time. If the REGISTER request is 
discarded after nat_keepalive() was called or if it intercepts a negative 
reply it will have no effect and the registration condition will not be 
activated for that endpoint.
--------


The INVITE case uses dialog module, but in order to avoid it, just don't 
invoke "nat_keepalive()" funtion for INVITE (the caller is already being 
pinged id it was registered behind NAT).


> >> For presence, like for registration, the keepalive should be done by the
> >> endpoint (registrar, presence server), otherwise you get into
> >> scalability issues.
> >
> > Imagine a presence agent machine (behind NAT) subscribing to the
> > presence of some users without registering.
>
> First I think that is not a typical use case, but more than that,
> imagine you have 100 000 presence sessions spread across couple presence
> servers and about the same number of calls going through your proxy.
>
> Do you think it will deals nicely doing pings? While for calls, nat
> pinhole is handled by the registrars, same can be done by the presence
> servers.
>
> Architectural point of view, it is even better doing so, as once there
> is no reply, the presence dialog can be destroyed and resources freed on
> server side. With nat_traversal approach, you consume twice resources in
> the server side, as you keep dialog attributes on proxy and presence
> server, therefore you double the scalability issues.

Not true, just *one* keep alive is performed per *source* (public IP:port):

----------
A user agent's NAT entry point may be kept alive for one or multiple of the 
conditions listed above. Even when a NAT endpoint is kept alive for more than 
one condition, only one keepalive message is sent to that NAT endpoint. The 
presence of multiple conditions for a NAT endpoint, only guarantees that the 
network visibility for a user agent based on a certain condition will be 
available while that condition is true, independently of the other conditions. 
When all the conditions to keepalive a NAT endpoint will disappear, that 
endpoint will be removed from the list with the NAT endpoints that need to be 
kept alive.
----------


> >  How to mantain the
> > keepalivee in Kamailio (without using nat_traversal module)? The dirty
> > solution would be decrease the notification interval, that of course
> > would be a wrong choice.
>
> Why would be that more wrong than sending keepalives from a stateful
> proxy? See above, you keep the dialog only once on server side.

------------
SUBSCRIBE - called before handle_subscribe() or t_relay() (depending on 
whether the proxy that received the SUBSCRIBE is also handling subscriptions 
for that subscriber or not). It will determine from either the stateless reply 
generated by handle_subscribe() or the TM relayed reply if the subscription 
was successful and what is its expiration time. If the subscription was 
successful it will mark the given NAT endpoint for keepalive for the 
subscription condition using the detected expiration time. If the SUBSCRIBE 
request is discarded after nat_keepalive() was called or if it intercepts a 
negative reply it will have no effect and the subscription condition will not 
be activated for that endpoint. It should be called for every SUBSCRIBE 
received, not only the ones that start a subscription (do not have a to tag), 
because it needs to update (extend) the expiration time for the subscription.
---------------

I think this is much better than decreasing notifications interval just 
because there could be users registered behind NAT. NAT keepalive should not 
be performed by an application (SIP presence) IMHO.



Also, imagine other typical case:

a) Using nathelper:

- UA behind NAT uses a domain with SRV failover (servers 1.1.1.1 and 2.2.2.2).
- It sends the REGISTER to 1.1.1.1.
- Registration expires in 10 minutes.
- Proxy 1.1.1.1 mantains the keepalive.
- Proxy 1.1.1.1 crashes.
- UA sends an INVITE and since 1.1.1.1 doesn't respond it sends it to 2.2.2.2.
- The call is established.
- After 3 minutes the calleed sends a BYE.
- This BYE wont reach the UA since proxy 2.2.2.2 is not mantaining NAT 
keepalive => Problems


b) Using nat_traversal:

- UA behind NAT uses a domain with SRV failover (servers 1.1.1.1 and 2.2.2.2).
- It sends the REGISTER to 1.1.1.1.
- Registration expires in 10 minutes.
- Proxy 1.1.1.1 mantains the keepalive (REGISTER).
- Proxy 1.1.1.1 crashes.
- UA sends an INVITE and since 1.1.1.1 doesn't respond it sends it to 2.2.2.2.
- The call is established.
- Proxy 2.2.2.2 mantains keepalive for the call duration.
- After 3 minutes the calleed sends a BYE.
- This BYE will reach the UA since proxy 2.2.2.2 is mantaining NAT keepalive 
=> OK.



Other solutions to make the above escenario working with nathelper module 
would be:

1) The UA mantains the keepalive with the registrar server and *with* the 
definitive server it sent the INVITE to (after SRV failover). How many UA's do 
it?

2) The UA mantain the keepalive with the registar. When detecting server 
failure it sends a new REGISTER to the following server (SRV).

3) Decrease the registration expiration in the server (bad idea).




Sincerely, I think nat_traversal provides much better NAT solutions than the 
limited nathelper module. Using dialgo module is not required at all (as I 
explained above), it is required just in the case you want to mantain 
keepalive for calls initiated by non registered users.


Regards.



-- 
Iñaki Baz Castillo <ibc at aliax.net>



More information about the Users mailing list