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