11 Mar
2013
11 Mar
'13
8:40 a.m.
On 1/7/13 6:32 PM, Andrew Pogrebennyk wrote:
On 01/07/2013 01:29 PM, Andrew Pogrebennyk wrote:
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 -
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.