[OpenSIPS-Users] SIP URI User Parameters

[Bogdan-Andrei Iancu]

Hi Ben,

The fix is present on trunk (2.4), 2.3 and 2.2 (the currently maintained 
versions). Indeed, the 1.11 does not have the fix. You can easily apply 
the fix onyour 1.11 code via this patch - 
https://github.com/OpenSIPS/opensips/commit/91c14ce679f80c8b4888769004c08039da2fc805.patch 
. It should be 100% compatible.

Otherwise, you can try to get rid of user=phone in the URI by doing 
changes over the full RURI (to avoid its parsing)- like a subst over the 
full RURI.

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 07/05/2017 05:32 PM, Ben Newlin wrote:
>
> 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
>
> **
>
> O+1 317.957.1009
>
> _ben.newlin at genesys.com <mailto:ben.newlin at genesys.com>_
>
>
> <http://www.genesys.com/>
>
> <https://twitter.com/Genesys><http://www.linkedin.com/company/601919?trk=tyah><https://plus.google.com/+Genesyslab?rel=publisher><https://www.facebook.com/Genesys/><https://www.youtube.com/Genesys><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
> * SIP Core ->https://www.ietf.org/mail-archive/web/sipcore/current/msg01783.html
> * voip info ->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
> OpenSIPS Bootcamp 2017, Houston, US
>    http://opensips.org/training/OpenSIPS_Bootcamp_2017.html
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20170705/73e9b08b/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/png
Size: 1242 bytes
Desc: not available
URL: <http://lists.opensips.org/pipermail/users/attachments/20170705/73e9b08b/attachment-0007.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/png
Size: 2054 bytes
Desc: not available
URL: <http://lists.opensips.org/pipermail/users/attachments/20170705/73e9b08b/attachment-0008.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/png
Size: 2041 bytes
Desc: not available
URL: <http://lists.opensips.org/pipermail/users/attachments/20170705/73e9b08b/attachment-0009.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/png
Size: 2044 bytes
Desc: not available
URL: <http://lists.opensips.org/pipermail/users/attachments/20170705/73e9b08b/attachment-0010.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/png
Size: 1920 bytes
Desc: not available
URL: <http://lists.opensips.org/pipermail/users/attachments/20170705/73e9b08b/attachment-0011.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/png
Size: 2057 bytes
Desc: not available
URL: <http://lists.opensips.org/pipermail/users/attachments/20170705/73e9b08b/attachment-0012.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/png
Size: 2071 bytes
Desc: not available
URL: <http://lists.opensips.org/pipermail/users/attachments/20170705/73e9b08b/attachment-0013.png>