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

[Klaus Darilion]

Daniel-Constantin Mierla schrieb:
> 
> 
> On 07/07/2009 08:33 PM, Iñaki Baz Castillo wrote:
>> 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.
>> --------
>>   
> so it duplicated info stored by the usrloc module. It is what I meant by 
> keeping twice information. Nathelper fetches the contact details from 
> usrloc.
> 
>  From what seems here, definitely does not deal with PATH extension.

I think the concept of nat_traversal correctly is focused on using 
outbound proxies - e.g. you have several outbound proxies (multiple SRV 
or A records) which relay the signaling to the core proxies (registrars, 
presence servers ...).

In such a setup there is no need for PATH support as the nat_traversal 
will be done on the outbound proxy. Further, scalability is also not a 
problem. Of course multiple OBPs will be needed for availability and NAT 
traversal load (including media relay) - but this reduces load on the 
core proxies which do not have to deal with NAT traversal.

It just probably a matter of preference if you have multiple 
registrars/presence servers which also do NAT traversal and activation 
of media relay, or if you prefer to have OBPs which deal with all the 
NAT traversal issues and keep the core proxies simple.

regards
klaus