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

[Daniel-Constantin Mierla]

On 07/07/2009 10:30 PM, Iñaki Baz Castillo wrote:
> First of all, I love these kind of discussions, the best way to learn :)
>   
:-)
> [...]
> Ok, I get you now.
> However, if you don't use db_mode=0 in usrloc, then there is a MySQL query 
> retrieving the natted contacts from usrloc table.
>   
This happens only on db mode only. Otherwise, usrloc records are stored 
in memory and sync'ed to db from time to time. A restart of same 
instance or a start of another one on a different server, will get 
up-to-date data.


> nat_traversal store them always in memory (not sure if it's a better 
> approach).
>
>
>
>   
>>  From what seems here, definitely does not deal with PATH extension.
>>     
>
> Not 100% sure, but I read this in the doc:
>
> ----------------
> 1.7.1. $keepalive.socket(nat_endpoint)
>   
the 'socket' column in usrloc table.

>> As you won't use nathelper, nat pings are performed only by
>> nat_traversal, so if to cope with crashes of the box, you need a
>> replication mechanism to a backup, so registered users are reachable
>> when backup becomes alive, in the case of shared IP HA.
>>
>> With usrloc and nathelper, that is solved, as data is stored in db or
>> replicated with t_replicate().
>>     
>
> With nat_traversal there is other approach:
> Use nat_keepalive() for REGISTER and INVITE. When the server 1 crashes and 
> server 2 begin running, it has no NAT keepalive information, but if it's 
> receives a call from a natted UA, it will keepalive it (INVITE).
>   
.. right, if destination is not behind nat, otherwise won't do it since 
the call does not complete.

> However, it's true that it couldn't receive calls from server 2... hum...
>   
>> Also, note that you need to do nat pinging from the presence server only
>> when you allow subscriptions from non-registered UA (again, very corner
>> case). Otherwise, just having it done only by registrar is enough.
>>     
>
> Perhaps I miss something, but how could a presence server (running behind the 
> proxy) perform nat keepalive just for natted users? note that SIP signalling 
> is NAT fixed on the proxy. Perhaps using a custom header or paremter 
> "nat=yes"? In any case, how would Kamailio presence server mantain the 
> keepalive for non registered natted subscribers?
>   

presence server has anything needed to rich the UA within the subscribe 
dialog. It uses it for sending notifies. It needs to send some messages 
periodically.


>>>  NAT keepalive should not
>>> be performed by an application (SIP presence) IMHO.
>>>       
>> SIP is an application level protocol. So the special handling should be
>> done by the end point that understands the message. What happens if I
>> send a custom request? Should the proxy perform pinging? If it is not
>> creating a dialog, the case of MESSAGE? Or it does, case of SUBSCRIBE?
>>     
>
> IMHO it's clear that the only requests requiring NAT keepalive are:
> - REGISTER: to receive calls.
> - INVITE: to receive in-dialog requests.
> - SUBSCRIBE: to receive in-dialog requests.
>   
but these are application level decisions. You can use REGISTER to 
publish a CPL documents(cpl-c support it), in that case you don't need 
keepalive.


>> IMO, it is totally broken to assume things in a router/proxy. Do it on
>> endpoints, like it is now with registrar.
>>     
>
> Well, I can assume that there will not appear a new SIP method creating a 
> dialog in the next 5 years XD
>
>
>
>   
>>> [...]
>>>       
>> What happens if someone calls that UA right now?
>>     
>
> (note that in this case I mean using "nathelper").
> UA wouldn't receive that call even if it arrives to server 2 since server 2 (a 
> different IP) has no way to communicate with UA.
>   

I was refering to the cases when you have shared IP HA or a load 
balancer in front with path extension.


> [...]
>> It is not clear to me that it supports proxy restart -- I admit I havent
>> investigated the code nor used the module.
>>     
>
> Yes, it does.
>   
OK, probably still limited in a way. usrloc does immediate or periodic 
db updates (depending on parameter value), so if there is "unexpected" 
crash, none or very limited data is lost. And you have path support.


>> I simply fail to see the reason of one extra place to store data to be
>> able to do to nat pings.
>>     
>
> Well, it extends the cases in which keepalive could be required (not just 
> registration).
>   
ok, then should do it only for those cases.

>>> Sincerely, I think nat_traversal provides much better NAT solutions than
>>> the limited nathelper module.
>>>       
>> Just your opinion. I think it is the opposite. nat_traversal limits you
>> to one box for good servicing, otherwise no scalability and no HA for
>> proper voip servicing.
>>     
>
> Well, I promise to investigate more about it. Most probably I needed this 
> thread :)
>   
I think with next next stable release, we need some order in the nat 
handling. Right now there are too many things that bring confusion due 
to poor documentation or overlapping functionality.

Over the years I used only the nathelper module, without hitting some 
limitation, the only annoying thing from my point of view is the complex 
config, issue addressed earlier in this thread, which can be solved nicely.

Cheers,
Daniel

-- 
Daniel-Constantin Mierla
http://www.asipto.com/