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


_______________________________________________
Devel mailing list
[email protected]
http://openser.org/cgi-bin/mailman/listinfo/devel

Reply via email to