[OpenSER-Users] NEW FEATURE: local route for internally generated requests

Bogdan-Andrei Iancu bogdan at voice-system.ro
Fri Jun 6 14:33:56 CEST 2008


Hi,

OpenSER has a new type of route: local route. This route is to be 
executed when a brand new request is internally generated (openser being 
the UAC) ; such requests are result of :
    - t_uac_dlg MI command
    - msilo, sms, presence, cpl-c, dialog (and others) modules


Purpose
========

This need route was added to meet the need to do dynamic manipulation 
(do some checking, adding headers, logging, etc) of the internally 
generated requests; without this new route, these requests were totally 
transparent for the openser script.

Some strong cases there were debated for a long time on the lists:

   - adding new headers into internally generated requests - so far all 
kind of hacks were used to do it (like defining module parameters with 
predefined headers to be added in the request - see presence modules)

   - logging (log or xlog) information about the outgoing requests - see 
the discussion about the presence internal logging

   - accounting - there was no way to account these requests (as 
accounting can be triggered only from script) - see the discussion 
around the dialog module for how to account the BYEs generated by this 
module



How to use
===========

there is a single instance of this route allowed in the configuration:
    local_route {
       ......
    }

Note that not all the functions are allowed to be called from this route 
(better check the docs before)

Example:

    local_route {
       ....
       if (is_method("NOTIFY")) {
          xlog("new $rm sent out for $ru via $du\n");
       }
       ....
       if (is_method("BYE")) {
          acc_log_request("internal bye");
          append_hf("X-note: terminated by dialog module");
       }
       ....
    }



Limitations
============

- you can access RURI and destination uri ($ru and $du), but any change 
of these value will be discarded - you cannot change the destination of 
the request

- there is no transaction persistence (yet) - you cannot set onreply or 
failure routes, flags are not pushed into transaction ; this will be 
probably available in the next version.

- accounting via flags do not work - as this requires transaction 
persistence (see above)



Regards,
Bogdan








More information about the sr-users mailing list