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