[OpenSIPS-Users] SIP URI User Parameters

Fri Jun 30 15:14:55 EDT 2017

Bogdan,

I have been able to reproduce this locally now. The piece that was missing is that the Request URI must already have URI parameters on it. If it has both URI and user parameters, the call to route_to_carrier (and possibly do_routing) replaces all of the URI parameters with the user parameter(s).

Original $ru:

sip:+15555551212;npdi=yes at gw2.com;transport=udp;user=phone

After call to route_to_carrier:

sip:+15555551212 at gw2.com;npdi=yes

After further testing, it appears this behavior is not restricted to the Dynamic Routing module after all. Simply modifying $ru while both user and URI parameters are present causes the issue.

Original $ru:

sip:+15555551212;npdi=yes at gw2.com;transport=udp;user=phone

Perform this action:

$rU = $rU + “;rn=+15555550000”;

Resultant $ru:

sip:+15555551212;rn=+15555550000 at gw2.com;npdi=yes

Ben Newlin
Lead Voice Network Engineer, PureCloud
[cid:image001.png at 01D2F1B3.A0646620]

O +1 317.957.1009
ben.newlin at genesys.com<mailto:ben.newlin at genesys.com>
[cid:image001.png at 01D2F1B3.A0646620]
[cid:image002.png at 01D2F1B3.A0646620]<http://www.genesys.com/>
[cid:image003.png at 01D2F1B3.A0646620]<https://twitter.com/Genesys>[cid:image004.png at 01D2F1B3.A0646620]<http://www.linkedin.com/company/601919?trk=tyah>[cid:image005.png at 01D2F1B3.A0646620]<https://plus.google.com/+Genesyslab?rel=publisher>[cid:image006.png at 01D2F1B3.A0646620]<https://www.facebook.com/Genesys/>[cid:image007.png at 01D2F1B3.A0646620]<https://www.youtube.com/Genesys>[cid:image008.png at 01D2F1B3.A0646620]<http://blog.genesys.com/>

From: Users <users-bounces at lists.opensips.org> on behalf of Ben Newlin <Ben.Newlin at genesys.com>
Reply-To: OpenSIPS users mailling list <users at lists.opensips.org>
Date: Friday, June 30, 2017 at 10:47 AM
To: Bogdan-Andrei Iancu <bogdan at opensips.org>, OpenSIPS users mailling list <users at lists.opensips.org>
Subject: Re: [OpenSIPS-Users] SIP URI User Parameters

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

OpenSIPS Bootcamp 2017, Houston, US

  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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20170630/515e5067/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 1242 bytes
Desc: image001.png
URL: <http://lists.opensips.org/pipermail/users/attachments/20170630/515e5067/attachment-0008.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image002.png
Type: image/png
Size: 7162 bytes
Desc: image002.png
URL: <http://lists.opensips.org/pipermail/users/attachments/20170630/515e5067/attachment-0009.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image003.png
Type: image/png
Size: 2054 bytes
Desc: image003.png
URL: <http://lists.opensips.org/pipermail/users/attachments/20170630/515e5067/attachment-0010.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image004.png
Type: image/png
Size: 2041 bytes
Desc: image004.png
URL: <http://lists.opensips.org/pipermail/users/attachments/20170630/515e5067/attachment-0011.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image005.png
Type: image/png
Size: 2044 bytes
Desc: image005.png
URL: <http://lists.opensips.org/pipermail/users/attachments/20170630/515e5067/attachment-0012.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image006.png
Type: image/png
Size: 1920 bytes
Desc: image006.png
URL: <http://lists.opensips.org/pipermail/users/attachments/20170630/515e5067/attachment-0013.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image007.png
Type: image/png
Size: 2057 bytes
Desc: image007.png
URL: <http://lists.opensips.org/pipermail/users/attachments/20170630/515e5067/attachment-0014.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image008.png
Type: image/png
Size: 2071 bytes
Desc: image008.png
URL: <http://lists.opensips.org/pipermail/users/attachments/20170630/515e5067/attachment-0015.png>