Some Fritzbox devices don't accept the OPTIONS ping generated by kamailio with RURI: sip:11.22.3.4:5060. In the location table we have: received: sip:11.22.3.4:5060 contact: sip:user@11.22.3.4:5060;uniq=6633BC1386F4D4CC4EBD64DC7E967 path: sip:lb@127.0.0.1;lr;received='sip:11.22.3.4:5060'
Kamailio version is 3.3.2 and the nathelper config is nothing fancy: modparam("nathelper", "natping_interval", 15) modparam("nathelper", "ping_nated_only", 1) modparam("nathelper", "sipping_bflag", FLB_NATSIPPING) modparam("nathelper", "sipping_from", "sip:pinger@sipwise.local") modparam("nathelper", "received_avp", "$avp(s:received)")
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), ((unsigned int)(unsigned long)timer_idx)*natping_interval+iteration, natping_processes*natping_interval); if (rval != 0) { pkg_free(buf); goto done; } } if (buf == NULL) goto done; cp = buf; while (1) { memcpy(&(c.len), cp, sizeof(c.len)); if (c.len == 0) break; c.s = (char*)cp + sizeof(c.len); cp = (char*)cp + sizeof(c.len) + c.len; memcpy( &send_sock, cp, sizeof(send_sock)); cp = (char*)cp + sizeof(send_sock); memcpy( &flags, cp, sizeof(flags)); cp = (char*)cp + sizeof(flags); memcpy( &(path.len), cp, sizeof(path.len)); path.s = path.len ? ((char*)cp + sizeof(path.len)) : NULL ; cp = (char*)cp + sizeof(path.len) + path.len; /* determin the destination */ if ( path.len && (flags&sipping_flag)!=0 ) { /* send to first URI in path */ if (get_path_dst_uri( &path, &opt) < 0) { LM_ERR("failed to get dst_uri for Path\n"); continue; } /* send to the contact/received */ if (parse_uri(opt.s, opt.len, &curi) < 0) { LM_ERR("can't parse contact dst_uri\n"); continue; } } else {
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.
Hello,
When outbound is fully supported the use of received parameters on URIs and the received column in the location table will (in theory at least) be able to be deprecated. This is because all of the information that would previously have been stored in these is now in the flow-tokens in Record-Route:/Route: and Path: headers.
The biggest thing in the way of this right now is that the current outbound on Kamailio does not contain everything it requires for single-server proxy/registrar support. What is required is:
* In configuration you must use add_path() even if you are a single-server. add_path() works on lumps so this needs to be applied before the registrar:save() function is called (I think msg_apply_changes() should do this). * The registrar module needs to be updated so that lookup(), when running as a single-server with outbound, it adds the Path: header from the location table as a Record-Route:. If there are multiple matching contacts (that is parallel forking is in use) then a different Record-Route: must be added for each parallel branch. registrar must also set $du for each branch based on the flow-token from the Path: header stored for that contact. The t_*_contacts() functions in the tm module probably require changes for this too. * This also means that, even though there is a single proxy/registrar here, there will be two Record-Routes:. The first will have been added to the dialog forming request when it arrived and will contain a flow-token pointing to the originator of the request. The second is the one added by the registrar:lookup() function which contains a flow-token pointing to the destination of the call. This means that the dialog will use a form of double-RR which the rr:loose_route() function needs to be modified to handle.
There are some distinct advantages to the above over contact aliasing, mainly that it should help with interoperability issues (especially with SBCs which strip and do no restore parameters they do not recognise) and it should be easier for non-Kamailio users to understand as it is standards based.
If/when the above changes have been made I would also like to see nat_uac_test() moved out of the nathelper module and into another (perhaps siputils). This makes it easier for people to have a clear choice of NAT traversal mechanisms, SIP outbound or contact aliasing.
Regards,
Peter
On Mon, 2013-01-07 at 18:32 +0100, 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.
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Peter Dunkley writes:
* In configuration you must use add_path() even if you are a single-server. add_path() works on lumps so this needs to be applied before the registrar:save() function is called (I think msg_apply_changes() should do this).
would it be possible for registrar:save() to check is some avp or var has been set that includes the path info?
-- juha
Peter Dunkley writes:
The biggest thing in the way of this right now is that the current outbound on Kamailio does not contain everything it requires for single-server proxy/registrar support. What is required is:
* In configuration you must use add_path() even if you are a single-server. add_path() works on lumps so this needs to be applied before the registrar:save() function is called (I think msg_apply_changes() should do this).
according to my tests, i don't see any need to add the path header.
* The registrar module needs to be updated so that lookup(), when running as a single-server with outbound, it adds the Path: header from the location table as a Record-Route:. If there are multiple matching contacts (that is parallel forking is in use) then a different Record-Route: must be added for each parallel branch. registrar must also set $du for each branch based on the flow-token from the Path: header stored for that contact. The t_*_contacts() functions in the tm module probably require changes for this too.
same here, i don't see a need to update registrar module.
* This also means that, even though there is a single proxy/registrar here, there will be two Record-Routes:. The first will have been added to the dialog forming request when it arrived and will contain a flow-token pointing to the originator of the request. The second is the one added by the registrar:lookup() function which contains a flow-token pointing to the destination of the call. This means that the dialog will use a form of double-RR which the rr:loose_route() function needs to be modified to handle.
again, i don't see the need.
There are some distinct advantages to the above over contact aliasing, mainly that it should help with interoperability issues (especially with SBCs which strip and do no restore parameters they do not recognise) and it should be easier for non-Kamailio users to understand as it is standards based.
there is no need to do contact aliasing or store the info in r-r header if the outbound capable ua also supports gruu.
-- juha
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
-
Andrew Pogrebennyk -
Daniel-Constantin Mierla -
Juha Heinanen -
Peter Dunkley