[OpenSIPS-Users] SIP URI User Parameters
Bogdan-Andrei Iancu
bogdan at opensips.org
Mon Jul 3 11:46:59 EDT 2017
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
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
>
> **
>
> 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: *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”
> <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”
> <sip:+15555551212;npdi at gw1.com%E2%80%9D>.
>
> 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”
> <sip:+15555551212 at gw2.com;npdi%E2%80%9D>. 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/20170703/60d0df69/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/png
Size: 4709 bytes
Desc: not available
URL: <http://lists.opensips.org/pipermail/users/attachments/20170703/60d0df69/attachment-0008.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/png
Size: 7162 bytes
Desc: not available
URL: <http://lists.opensips.org/pipermail/users/attachments/20170703/60d0df69/attachment-0009.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/20170703/60d0df69/attachment-0010.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/20170703/60d0df69/attachment-0011.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/20170703/60d0df69/attachment-0012.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/20170703/60d0df69/attachment-0013.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/20170703/60d0df69/attachment-0014.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/20170703/60d0df69/attachment-0015.png>
More information about the Users
mailing list