[OpenSIPS-Users] SIP URI User Parameters

[Ben Newlin]

Bogdan,

Sorry for the delayed response, I am having some trouble reproducing this in a local test environment. Currently it is only occurring in our live environment. I do have some clarifications and answers to your questions:


·         The npdi parameter is not present in $ru in the failure route when the response is 500. It is present when the response is 503 or 408. I haven’t tested any other responses. This is not terribly important to my issue, simply an observation.


·         We are sometimes using do_routing to populate a list of carriers, but other times we get the list from our own DB query. We use route_to_carrier to send the call to each carrier in sequence. This is because we don’t always use do_routing, but also because we wish to skip to the next carrier, not just the next gateway, on certain response codes and the normal do_routing mechanism doesn’t allow that.


·         The issue actually does not happen when use_next_gw is called. I was wrong about that. You were right that seems to be a straight URI copy. The issue occurs when we skip use_next_gw or there are no gateways left and we call route_to_carrier for the next carrier with the parameter present in $ru.


·         I printed out the dr_ruri avp after the call to route_to_carrier and it shows the npdi parameter moved to the end, not after the user:
“sip:+15555551212 at gw2.com;npdi=yes”

Also, I should have mentioned that we are running 1.11.11. I’m still working to try to reproduce locally.

Ben Newlin

From: Bogdan-Andrei Iancu <bogdan at opensips.org>
Date: Thursday, June 29, 2017 at 4:38 AM
To: OpenSIPS users mailling list <users at lists.opensips.org>, Ben Newlin <Ben.Newlin at genesys.com>
Subject: Re: [OpenSIPS-Users] SIP URI User Parameters

Hello Ben

I understand you add the npdi useraname parameter after performing the initial do_routing() - if you do it in request or branch route is not relevant (for RURI changes) as RURI is anyhow a per-branch value.
In failure route, when resuming, you will get the RURI of the winning branch ( the one which was selected to be sent back to caller), so you see the npdi param.

So far so good. And now you do use_next_gw() in failure route and you get "sip:+15555551212 at gw2.com;npdi" directly, without any another npdi addition ? I'm asking, as use_next_gw() does a full RURI replacement (it doesn;t care what is the existing RURI).

Could you also do an
    xlog("DR ruris are <$(avp(___dr_ruri__)[*])>\n");
right after do_routing() ?

Regards,


Bogdan-Andrei Iancu

  OpenSIPS Founder and Developer

  http://www.opensips-solutions.com<http://www.opensips-solutions.com>



OpenSIPS Bootcamp 2017, Houston, US

  http://opensips.org/training/OpenSIPS_Bootcamp_2017.html<http://opensips.org/training/OpenSIPS_Bootcamp_2017.html>
On 06/28/2017 11:41 PM, Ben Newlin wrote:
Hi,

We have run into an issue with OpenSIPs’ handling of user parameters in SIP URIs with Dynamic Routing module. When a parameter is added to a SIP URI user part, any subsequent modification of the URI by DR module results in the parameter being moved to be a URI parameter.

For example, starting with $ru of “sip:+15555551212 at gw1.com”, if we modify it this way:

$rU = $rU + “;npdi”;

then we get a new $ru of “sip:+15555551212;npdi at gw1.com”.

We send this call out and if it returns an error we want to use the next available gateway.

The Request URI in the failure route is still “sip:+15555551212;npdi at gw1.com”.

Note: this is the case even when the “;npdi” parameter was added in a branch route, which I didn’t expect. I thought changes made in a branch route were isolated to that branch.

Now from the failure route when we call use_next_gw the npdi parameter is moved and the URI is now “sip:+15555551212 at gw2.com;npdi”. This is not correct.

Is there some other way to properly manipulate SIP URI user parameters or is this a bug?


Thanks,

Ben Newlin




_______________________________________________

Users mailing list

Users at lists.opensips.org<mailto:Users at lists.opensips.org>

http://lists.opensips.org/cgi-bin/mailman/listinfo/users<http://lists.opensips.org/cgi-bin/mailman/listinfo/users>


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20170630/cf981ca8/attachment-0001.html>