[OpenSIPS-Users] SIP URI User Parameters
Ben Newlin
Ben.Newlin at genesys.com
Wed Jul 5 10:32:36 EDT 2017
Bogdan,
Thanks for your work to find the issue. I do agree that the usage of the “user=phone” parameter is not well defined and a bit ambiguous. However, I think your action is correct as it should be the responsibility of the end gateway to do any necessary SIP -> Tel conversion, not the proxy. And especially not a partial conversion. :)
Just to clarify, where was the change you made submitted? I know 1.11 is no longer supported, but we are still using it and are not ready to upgrade yet due to the many script changes necessary to use 2.X. If this change cannot be added to 1.11, do you have any suggestions for a workaround? I haven’t found anything yet, but I’ve yet to try using revert_uri in the failure route to remove the user params before any other processing. Do you think this will work?
Ben Newlin
Lead Voice Network Engineer, PureCloud
[cid:image001.png at 01D2F57A.03C1BF50]
O +1 317.957.1009
ben.newlin at genesys.com<mailto:ben.newlin at genesys.com>
[cid:image001.png at 01D2F57A.03C1BF50]
[cid:image002.png at 01D2F57A.03C1BF50]<http://www.genesys.com/>
[cid:image003.png at 01D2F57A.03C1BF50]<https://twitter.com/Genesys>[cid:image004.png at 01D2F57A.03C1BF50]<http://www.linkedin.com/company/601919?trk=tyah>[cid:image005.png at 01D2F57A.03C1BF50]<https://plus.google.com/+Genesyslab?rel=publisher>[cid:image006.png at 01D2F57A.03C1BF50]<https://www.facebook.com/Genesys/>[cid:image007.png at 01D2F57A.03C1BF50]<https://www.youtube.com/Genesys>[cid:image008.png at 01D2F57A.03C1BF50]<http://blog.genesys.com/>
From: Bogdan-Andrei Iancu <bogdan at opensips.org>
Date: Monday, July 3, 2017 at 11:46 AM
To: Ben Newlin <Ben.Newlin at genesys.com>, OpenSIPS users mailling list <users at lists.opensips.org>
Subject: Re: [OpenSIPS-Users] SIP URI User Parameters
Hi Ben,
Thank you for your digging and reporting. Following your leads I found some old strange behavior of the parse_uri() function - the function responsible for parsing the URIs in OpenSISP.
For some ancient and unknown reasons, a SIP URI with user=phone was automatically converted to a TEL URI. Such conversion, automatically done, is dangerous - there is nothing in the RFC3261 stating something like this. Even more, the conversion is not complete - besides moving the username parameters to URI parameters, the domain is not stripped and the TEL not added.
Basically, the existing code was converting:
sip:username;bla=foo at host.com;param1=1;param2=2;user=phone
to
sip:username at host.com;bla=foo
I tried to dig around the subject, but not more - there is no reference or recommendation for such a behavior. If you have the time, see these links:
* SIP implementer -> https://lists.cs.columbia.edu/pipermail/sip-implementors/2013-February/028837.html<https://lists.cs.columbia.edu/pipermail/sip-implementors/2013-February/028837.html>
* SIP Core -> https://www.ietf.org/mail-archive/web/sipcore/current/msg01783.html<https://www.ietf.org/mail-archive/web/sipcore/current/msg01783.html>
* voip info -> https://www.voip-info.org/wiki/view/SIP+URI<https://www.voip-info.org/wiki/view/SIP+URI> (Telephone numbers section)
On voip-info there is a recommendation on how to compare a SIP uri with a TEL uri (in terms of username and parameters parts), but nothing of a "must" conversion.
So, I disabled the guilty code in OpenSIPS, and it should work as expected now.
Best 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/30/2017 10:14 PM, Ben Newlin wrote:
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:image009.png at 01D2F57A.03C1BF50]
O +1 317.957.1009
ben.newlin at genesys.com<mailto:ben.newlin at genesys.com>
[cid:image010.png at 01D2F57A.03C1BF50]
[cid:image011.png at 01D2F57A.03C1BF50]<http://www.genesys.com/>
[cid:image012.png at 01D2F57A.03C1BF50]<https://twitter.com/Genesys>[cid:image013.png at 01D2F57A.03C1BF50]<http://www.linkedin.com/company/601919?trk=tyah>[cid:image014.png at 01D2F57A.03C1BF50]<https://plus.google.com/+Genesyslab?rel=publisher>[cid:image015.png at 01D2F57A.03C1BF50]<https://www.facebook.com/Genesys/>[cid:image016.png at 01D2F57A.03C1BF50]<https://www.youtube.com/Genesys>[cid:image017.png at 01D2F57A.03C1BF50]<http://blog.genesys.com/>
From: Users <users-bounces at lists.opensips.org><mailto:users-bounces at lists.opensips.org> on behalf of Ben Newlin <Ben.Newlin at genesys.com><mailto:Ben.Newlin at genesys.com>
Reply-To: OpenSIPS users mailling list <users at lists.opensips.org><mailto:users at lists.opensips.org>
Date: Friday, June 30, 2017 at 10:47 AM
To: Bogdan-Andrei Iancu <bogdan at opensips.org><mailto:bogdan at opensips.org>, OpenSIPS users mailling list <users at lists.opensips.org><mailto: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><mailto:bogdan at opensips.org>
Date: Thursday, June 29, 2017 at 4:38 AM
To: OpenSIPS users mailling list <users at lists.opensips.org><mailto:users at lists.opensips.org>, Ben Newlin <Ben.Newlin at genesys.com><mailto: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”<sip:+15555551212 at gw1.com%E2%80%9D>, if we modify it this way:
$rU = $rU + “;npdi”;
then we get a new $ru of “sip:+15555551212;npdi at gw1.com”<sip:+15555551212;npdi at gw1.com%E2%80%9D>.
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/20170705/0fa7f14b/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/20170705/0fa7f14b/attachment-0017.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/20170705/0fa7f14b/attachment-0018.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/20170705/0fa7f14b/attachment-0019.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/20170705/0fa7f14b/attachment-0020.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/20170705/0fa7f14b/attachment-0021.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/20170705/0fa7f14b/attachment-0022.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/20170705/0fa7f14b/attachment-0023.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/20170705/0fa7f14b/attachment-0024.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image009.png
Type: image/png
Size: 4125 bytes
Desc: image009.png
URL: <http://lists.opensips.org/pipermail/users/attachments/20170705/0fa7f14b/attachment-0025.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image010.png
Type: image/png
Size: 4125 bytes
Desc: image010.png
URL: <http://lists.opensips.org/pipermail/users/attachments/20170705/0fa7f14b/attachment-0026.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image011.png
Type: image/png
Size: 7163 bytes
Desc: image011.png
URL: <http://lists.opensips.org/pipermail/users/attachments/20170705/0fa7f14b/attachment-0027.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image012.png
Type: image/png
Size: 2055 bytes
Desc: image012.png
URL: <http://lists.opensips.org/pipermail/users/attachments/20170705/0fa7f14b/attachment-0028.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image013.png
Type: image/png
Size: 2042 bytes
Desc: image013.png
URL: <http://lists.opensips.org/pipermail/users/attachments/20170705/0fa7f14b/attachment-0029.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image014.png
Type: image/png
Size: 2045 bytes
Desc: image014.png
URL: <http://lists.opensips.org/pipermail/users/attachments/20170705/0fa7f14b/attachment-0030.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image015.png
Type: image/png
Size: 1921 bytes
Desc: image015.png
URL: <http://lists.opensips.org/pipermail/users/attachments/20170705/0fa7f14b/attachment-0031.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image016.png
Type: image/png
Size: 2058 bytes
Desc: image016.png
URL: <http://lists.opensips.org/pipermail/users/attachments/20170705/0fa7f14b/attachment-0032.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image017.png
Type: image/png
Size: 2072 bytes
Desc: image017.png
URL: <http://lists.opensips.org/pipermail/users/attachments/20170705/0fa7f14b/attachment-0033.png>
More information about the Users
mailing list