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

[Andrew Pogrebennyk]

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.