7 Jan
2013
7 Jan
'13
7:29 a.m.
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 {