[OpenSIPS-Devel] loose routing params embedded in username

[Phil Vandry]

Hello,

OpenSIPS (via the rr module) provides a framework for placing parameters
in Record-Route URIs for later retrieval during loose-routing. Several
modules make use of this functionality:

- rr stuffs the From tag into a parameter and uses is for is_direction()
- dialog uses it to match subsequent requests to an existing dialog
- uac uses it to remember the original From: URI that needs to be
  restored later
- the user may add custom parameters in the script and retrieve them
  using loose routing.
- etc...

Unfortunately, in integration testing, I found that storing these
parameters in URI parameters was not reliable. I found two devices
that mangle the parameters from a Record-Route header that passes
through them. One is a high-end desktop SIP (hard) phone and the
other is the application server SIP container from a major commercial
IMS vendor. Interestingly, they both seem to have the same problem:
the first parameter from the top route is transposed to the RURI and
subsequent parameters are discarded. Visually:

METHOD ruri SIP/2.0
Route: uri;lr;p1;p2

becomes:

METHOD ruri;p1 SIP/2.0
Route: uri;lr

I did not spend much time trying to fix the broken devices. Instead, I
chose to change the way OpenSIPS's rr works for increased robustness.

There is another place besides URI parameters where private data like this
can be stored: the SIP username, which is otherwise not very useful in a
lr URI. Storing opaque data in the URI username is a common technique
and I can quickly think of at least two implementations that I work with
that use it (an SBC and a CSCF, both commercial products).

Instead of:

sip:opensips.server;lr;p1=value1;p2=value2;p3=value3

I use:

sip:p1=value1.p2=value2.p3=value3 at opensips.server;lr

I have a patch to the rr module which implements this as a configurable
option:

modparam("rr", "param_in_username", ".")

(the value of the parameter is the delimiter that should be used.)

I would like to know if a patch like this would be considered for inclusion
in OpenSIPS.

-Phil