Juha,
the nat_flag will probably remain a MSG flag and not a UL flag (in the
usrloc set of flags), otherwise you will loose the branch capability.
So, going back to alternatives I listed:
1) already works
2) as the flags will be per contact (not per AOR), a lookup will may
bring several contacts, each with its one UL flags. the registrar module
will push it to the MSG flags to corresponding branch (according to
"use_branch_flags" param).
so, I see no problem in any of the cases.
regards,
bogdan
Juha Heinanen wrote:
> now, going back to the nat_flag :
> 1) if we let it as it is now, there will be problem as there is no
> mixture between the ul and msg flags.
> 2) if you want to have it as dynamic flag (ul flag), the nat_flag
> parameter will have to tell to reg/ul what UL flag should be used as nat
> flag - this is needed internally when fetching only natted records for
> pinging.
> note that the UL flags will be visible only in the route type after
> location() and before save()
there is currently nat_flag and sip_natping_flag. sip_natping_flag is
used internally by usrloc and was not topic of this discussion.
my understanding was that if nat_flag has been selected from branch flag
range, then it will be automatically mapped to corresponding branch
specific message flag when lookup() is called so that it is possible to
check in branch route if contact of that branch is behind nat or not.
if that is true, then the same should be possible also for the new
flags (e.g. the proposed mediaproxy flag).
-- juha
_______________________________________________
Devel mailing list
[email protected]
http://openser.org/cgi-bin/mailman/listinfo/devel
