[SR-Users] why use received as RURI for nathelper OPTIONS ping?

[Daniel-Constantin Mierla]

On 1/7/13 6:32 PM, Andrew Pogrebennyk wrote:
> On 01/07/2013 01:29 PM, Andrew Pogrebennyk wrote:
>> What I don't understand is why kamailio sets RURI of the OPTIONS message
>> to value of "received" instead of the contact. I suspect a bug in the
>> parser somewhere along these lines:
>>
>>>>                  rval = ul.get_all_ucontacts(buf,cblen,(ping_nated_only?ul.nat_flag:0),
> This needs some overhaul. The get_all_mem_ucontacts prefers received
> over contact. So what nathelper does is set Path as $du and Received as
> $ru, then send it. But in case home proxy which generated the NAT ping
> is sitting behind the edge proxy and the user is behind NAT, we need to
> pass both Contact and Received to the edge proxy.
>
> It looks like we (Sipwise) need to introduce a few modparams so the user
> choose what to put into $ru and $du (like 1 - Contact, 2 - Received, 3 -
> Path). I'm just wondering if there is anything speaking against that or
> missing in the light of SIP-Outbound implementation.
actually the r-uri has to be the contact to be safer. The implementation 
was probably done long time ago, when even registrar was using received 
to build the r-uri. The goal of those pings was to trigger a reply, 
based on the fact that each request has to be replied, even if it you be 
404 not found is good. The one for registrar was a first hit, because a 
404 for an invite sent there is not good.

Cheers,
Daniel

-- 
Daniel-Constantin Mierla - http://www.asipto.com
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
Kamailio World Conference, April 16-17, 2013, Berlin
  - http://conference.kamailio.com -