#22 New pseudo variable for route_params

modules (179)

To my big surprise, OpenSIPS is not transparent in regards with route parameters. In route scripts, there is no easy way to copy all the route params from the incoming message into the outgoing ones.

I extended the RR modules in order to give access to rr params in a pseudo variable named $rr_params

So copying route params becomes easy

if (loose_route() )
record_route( $rr_params );

Examining and modifying route params beforehand in script variables or AVPs is also vastly simplified.

Emmanuel BUU


  • Nobody/Anonymous

    RR modules patch

  • Nobody/Anonymous

    FYI: Adding Record-Route header to in-dialog requests is useless, as the route set is built from the initial request and MUST NOT be changed during the dialog. If a client interprets Record-route headers of in-dialog requests than the client is buggy.


  • Emmanuel BUU

    Emmanuel BUU - 2008-09-18

    Fine but then we have an issue here:

    OpenSIPS in its current form drops the route parameters. It is when record_route() is called, previously received params are wiped out ex:


    INVITE --------> challenge
    407 <------------

    INVITE --------> add route param ---------> INVITE with route param
    200 OK + params <---
    200 OK + params <-----------

    re-INVITE + param ---------> if (loose_route())
    ---------------> INVITE but params disapeared !!!

    So I should modify the patch just to copy existing params ?

    I believed route param could be used information which would persist during the dialog ?

  • Nobody/Anonymous

    not sure what you mean: during the first INVITE, if you call record_route(), openser will add the Record-route header with some parameters. If there are already Route headers present, openser will remove the ones pointing to itself and the other will be untouched.

    Further, in-dialog requests will contain the Route added by openser. The Route headers which point to openser will be remove during loose_routing, other route headers will be untouched.

    If you see a different behavior please post an ngrep trace (ngrep -W byline -t -q -P "" -d any port 5060)

  • Emmanuel BUU

    Emmanuel BUU - 2008-10-21

    Ok Klaus, I agree with the comment.
    ROute set should not be modified once established.

    Nevertheless, I use route param to make dialog wide routing decision in my conf scripts and as far as I know, there is no easy way to retreive RR parameter value. There is only a function to check whether a param has a predefined value.

    The new pseudo variable associated with transformation enable easy access to such information. Would the maintainter kindly consider the addition of this PV ?

    Emmanuel BUU

  • Bogdan-Andrei Iancu

    Hi Emmanuel,

    do you need the entire RR param string or typically you are looking for certain parameters (by name) ?


  • Bogdan-Andrei Iancu

    • milestone: --> trunk
    • assigned_to: nobody --> bogdan_iancu
    • status: open --> closed
  • Emmanuel BUU

    Emmanuel BUU - 2008-11-03

    I would need to access the value of some paramter by name.

    If there is way to do this differently, then I am all hears.

    Otherwise, having the whole string is not bad as parameters can be accessed using transformations.


  • Emmanuel BUU

    Emmanuel BUU - 2008-11-03
    • status: closed --> open
  • Bogdan-Andrei Iancu

    I was thinking about re-working the check_route_param() function from RR module (http://www.opensips.org/html/docs/modules/1.4.x/rr.html#check-route-param-id) into a PV to return the whole value (as you said) and to use paam like transformations to break it apart.


  • Emmanuel BUU

    Emmanuel BUU - 2008-11-03

    Ehhh ... that's basically what does the patch that I submitted. So I would not object.

  • Bogdan-Andrei Iancu

    • status: open --> closed-accepted
  • Bogdan-Andrei Iancu

    OK - done!


Log in to post a comment.

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

JavaScript is required for this form.

No, thanks