10 Apr
2013
10 Apr
'13
8 p.m.
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
10 Apr
10 Apr
9:43 p.m.
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
10:01 p.m.
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
23 Apr
23 Apr
4:03 p.m.
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(a)tutpro.com> wrote:
Juha Heinanen writes:
--
MSC Seudin Kasumovic
Tuzla, Bosnia
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(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
4235
days inactive
4248
days old
3 comments
2 participants
participants (2)
-
Juha Heinanen -
Seudin Kasumovic