Hi,
I just committed serial proper forking support into core - it was
migrated from LCR module. I mean proper, since it has q value support
and it can be used by any module without any inter-module dependencies.
The idea behind was to allow to all module that performs parallel
forking to do also serial forking - exec, enum, registrar, etc.
There are two new script functions :
*serialize_branches(n)* : it inherits the functionality of
load_contacts() from LCR; gets all parallel branches and convert them
into AVPs for serial forking; numerical parameter 'n' says if any
previous AVP should be removed (if non-0) or not (if 0). Returns true is
no error (even if no serialization happened).
*next_branches()* : it inherits the functionality of
next_contacts() from LCR; get (based on q value) the next contact(s) to
be used in sequential forking. Returns true only if a new contact was
got to be used.
The AVP containing the branches is accessible only via alias - its ID is
not configurable or visible; the alias (automatically exported by core)
is "serial_branch" - it is visible from any module that uses the avp
core aliasing system.
here are some examples of how to uses this new functionality:
1) enum doing serial forking:
{
.....
enum_query("e164.arpa.","voice");
serialize_branches(1);
if (!next_branches()) {
sl_send_reply(...no enum found...);
exit;
}
t_on_failure("1");
t_relay();
}
failure_route[1] {
if (next_branches()) {
t_relay();
}
}
2) same for registrar, just replace enum_query() with
lookup("location"). NOTE that this will not work yet if there are nated
contacts: there is no support to save also the flags and the dst_uri in
order to perform proper nat traversal.
The code was not yet heavily tested, so any help on this is highly
appreciated.
On the TO-DO list, related to this subject are:
1) SRV lookup to use this functionality to provide any additional
entries.
2) full support for registrar for nat traversal
3) remove load/next_contacts() from LCR (once this new functions
prove to be stable).
regards,
bogdan