i have in config:
setbflag(8); xlog("L_INFO", "bflags are <$bf/$bF>\n"); save("location", "0x02");
and i correctly get to syslog:
Apr 10 19:51:48 wheezy1 /usr/sbin/sip-proxy[6722]: INFO: bflags are <256/00000100>
however, when i look what gets stores in location table, cflags column of the contact has value 384. it is also shown by ul_dump:
Cflag:: 384
384 = 256 + 128. i must be missing something trivial. how is it possible that also flag 7 (which is my nat_bflag) gets set in usrloc?
-- juha
Juha Heinanen writes:
however, when i look what gets stores in location table, cflags column of the contact has value 384. it is also shown by ul_dump:
Cflag:: 384
384 = 256 + 128. i must be missing something trivial. how is it possible that also flag 7 (which is my nat_bflag) gets set in usrloc?
i think i found the answer. in save.c:
/* get received */ if (path_received.len && path_received.s) { ci.cflags |= ul.nat_flag; ci.received = path_received; }
if i understood the above correctly, existence of received param in path header of register request, automatically sets nat bflag that (in my case 7). where is that documented?
anyway, it makes no sense at all to me. if p2 gets register request from another proxy p1, which received it from ua and included the path header, it is responsibility of p1 to handle possible nat pinging. p2 should not have anything to do with it.
can i fix this bug, i.e., remove line
ci.cflags |= ul.nat_flag;
from the above?
-- juha
Juha Heinanen writes:
if i understood the above correctly, existence of received param in path header of register request, automatically sets nat bflag that (in my case 7). where is that documented?
it is documented here:
3.19. path_use_received (integer)
If set to 1, the “received” parameter of the first Path URI of a registration is set as received-uri and the NAT branch flag is set for this contact. This is useful if the registrar is placed behind a SIP loadbalancer, which passes the nat'ed UAC address as “received” parameter in it's Path uri.
it assumes one particular use case and does not support any other.
-- juha
Please don't!
It's usefully to have NAT flag in usrloc if you need in script handle SDP. Also, once used flag (bit) can't be re-used anywhere else.
Seudin
On Wed, Apr 10, 2013 at 8:43 PM, Juha Heinanen jh@tutpro.com wrote:
Juha Heinanen writes:
however, when i look what gets stores in location table, cflags column of the contact has value 384. it is also shown by ul_dump:
Cflag:: 384
384 = 256 + 128. i must be missing something trivial. how is it possible that also flag 7 (which is my nat_bflag) gets set in usrloc?
i think i found the answer. in save.c:
/* get received */ if (path_received.len && path_received.s) { ci.cflags |= ul.nat_flag; ci.received = path_received; }if i understood the above correctly, existence of received param in path header of register request, automatically sets nat bflag that (in my case 7). where is that documented?
anyway, it makes no sense at all to me. if p2 gets register request from another proxy p1, which received it from ua and included the path header, it is responsibility of p1 to handle possible nat pinging. p2 should not have anything to do with it.
can i fix this bug, i.e., remove line
ci.cflags |= ul.nat_flag;
from the above?
-- juha
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
-
Juha Heinanen -
Seudin Kasumovic