[Users] Serial forking

[Bogdan-Andrei Iancu]

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