SIP URI User Parameters

classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

SIP URI User Parameters

Ben Newlin

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:+[hidden email]”, if we modify it this way:

 

$rU = $rU + “;npdi”;

 

then we get a new $ru of “sip:+15555551212;[hidden email]”.

 

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;[hidden email]”.

 

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:+[hidden email];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
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: SIP URI User Parameters

Bogdan-Andrei Iancu-2
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 "<a class="moz-txt-link-freetext" href="sip:+15555551212@gw2.com;npdi">sip:+15555551212@...;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 “<a class="moz-txt-link-freetext" href="sip:+15555551212@gw1.com”">sip:+15555551212@...”, if we modify it this way:

 

$rU = $rU + “;npdi”;

 

then we get a new $ru of “<a class="moz-txt-link-freetext" href="sip:+15555551212;npdi@gw1.com”">sip:+15555551212;npdi@...”.

 

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 “<a class="moz-txt-link-freetext" href="sip:+15555551212;npdi@gw1.com”">sip:+15555551212;npdi@...”.

 

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 “<a class="moz-txt-link-freetext" href="sip:+15555551212@gw2.com;npdi”">sip:+15555551212@...;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
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users


_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: 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:+[hidden email];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 <[hidden email]>
Date: Thursday, June 29, 2017 at 4:38 AM
To: OpenSIPS users mailling list <[hidden email]>, Ben Newlin <[hidden email]>
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 "<a href="sip:&#43;15555551212@gw2.com;npdi">sip:+15555551212@...;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 “<a href="sip:&#43;15555551212@gw1.com”">sip:+15555551212@...”, if we modify it this way:

 

$rU = $rU + “;npdi”;

 

then we get a new $ru of “<a href="sip:&#43;15555551212;npdi@gw1.com”">sip:+15555551212;npdi@...”.

 

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 “<a href="sip:&#43;15555551212;npdi@gw1.com”">sip:+15555551212;npdi@...”.

 

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 “<a href="sip:&#43;15555551212@gw2.com;npdi”">sip:+15555551212@...;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
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users




_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: SIP URI User Parameters

Ben Newlin

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=[hidden email];transport=udp;user=phone

 

After call to route_to_carrier:

 

sip:+[hidden email];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=[hidden email];transport=udp;user=phone

 

Perform this action:

 

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

 

Resultant $ru:

 

sip:+15555551212;rn=+[hidden email];npdi=yes

 

 

Ben Newlin

Lead Voice Network Engineer, PureCloud

 

O +1 317.957.1009

[hidden email]

 

From: Users <[hidden email]> on behalf of Ben Newlin <[hidden email]>
Reply-To: OpenSIPS users mailling list <[hidden email]>
Date: Friday, June 30, 2017 at 10:47 AM
To: Bogdan-Andrei Iancu <[hidden email]>, OpenSIPS users mailling list <[hidden email]>
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:+[hidden email];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 <[hidden email]>
Date: Thursday, June 29, 2017 at 4:38 AM
To: OpenSIPS users mailling list <[hidden email]>, Ben Newlin <[hidden email]>
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 "<a href="sip:&#43;15555551212@gw2.com;npdi">sip:+15555551212@...;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 “<a href="sip:&#43;15555551212@gw1.com”">sip:+15555551212@...”, if we modify it this way:

 

$rU = $rU + “;npdi”;

 

then we get a new $ru of “<a href="sip:&#43;15555551212;npdi@gw1.com”">sip:+15555551212;npdi@...”.

 

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 “<a href="sip:&#43;15555551212;npdi@gw1.com”">sip:+15555551212;npdi@...”.

 

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 “<a href="sip:&#43;15555551212@gw2.com;npdi”">sip:+15555551212@...;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
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users





_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: SIP URI User Parameters

Bogdan-Andrei Iancu-2
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:
	<a class="moz-txt-link-freetext" href="sip:username;bla=foo@host.com;param1=1;param2=2;user=phone">sip:username;bla=foo@...;param1=1;param2=2;user=phone
to
	<a class="moz-txt-link-freetext" href="sip:username@host.com;bla=foo">sip:username@...;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:

 

<a class="moz-txt-link-freetext" href="sip:+15555551212;npdi=yes@gw2.com;transport=udp;user=phone">sip:+15555551212;npdi=yes@...;transport=udp;user=phone

 

After call to route_to_carrier:

 

<a class="moz-txt-link-freetext" href="sip:+15555551212@gw2.com;npdi=yes">sip:+15555551212@...;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:

 

<a class="moz-txt-link-freetext" href="sip:+15555551212;npdi=yes@gw2.com;transport=udp;user=phone">sip:+15555551212;npdi=yes@...;transport=udp;user=phone

 

Perform this action:

 

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

 

Resultant $ru:

 

<a class="moz-txt-link-freetext" href="sip:+15555551212;rn=+15555550000@gw2.com;npdi=yes">sip:+15555551212;rn=+15555550000@...;npdi=yes

 

 

Ben Newlin

Lead Voice Network Engineer, PureCloud

 

O +1 317.957.1009

[hidden email]

 

From: Users [hidden email] on behalf of Ben Newlin [hidden email]
Reply-To: OpenSIPS users mailling list [hidden email]
Date: Friday, June 30, 2017 at 10:47 AM
To: Bogdan-Andrei Iancu [hidden email], OpenSIPS users mailling list [hidden email]
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:
“<a class="moz-txt-link-freetext" href="sip:+15555551212@gw2.com;npdi=yes”">sip:+15555551212@...;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 [hidden email]
Date: Thursday, June 29, 2017 at 4:38 AM
To: OpenSIPS users mailling list [hidden email], Ben Newlin [hidden email]
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 "<a moz-do-not-send="true" href="sip:+15555551212@gw2.com;npdi"><a class="moz-txt-link-freetext" href="sip:+15555551212@gw2.com;npdi">sip:+15555551212@...;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 “<a moz-do-not-send="true" href="sip:+15555551212@gw1.com%E2%80%9D">sip:+15555551212@...”, if we modify it this way:

 

$rU = $rU + “;npdi”;

 

then we get a new $ru of “<a moz-do-not-send="true" href="sip:+15555551212;npdi@gw1.com%E2%80%9D">sip:+15555551212;npdi@...”.

 

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 “<a moz-do-not-send="true" href="sip:+15555551212;npdi@gw1.com%E2%80%9D"><a class="moz-txt-link-freetext" href="sip:+15555551212;npdi@gw1.com”">sip:+15555551212;npdi@...”.

 

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 “<a moz-do-not-send="true" href="sip:+15555551212@gw2.com;npdi%E2%80%9D"><a class="moz-txt-link-freetext" href="sip:+15555551212@gw2.com;npdi”">sip:+15555551212@...;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
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users






_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: SIP URI User Parameters

Ben Newlin

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

[hidden email]

 

From: Bogdan-Andrei Iancu <[hidden email]>
Date: Monday, July 3, 2017 at 11:46 AM
To: Ben Newlin <[hidden email]>, OpenSIPS users mailling list <[hidden email]>
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:
        <a href="sip:username;bla=foo@host.com;param1=1;param2=2;user=phone">sip:username;bla=foo@...;param1=1;param2=2;user=phone
to
        <a href="sip:username@host.com;bla=foo">sip:username@...;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:

 

<a href="sip:&#43;15555551212;npdi=yes@gw2.com;transport=udp;user=phone">sip:+15555551212;npdi=yes@...;transport=udp;user=phone

 

After call to route_to_carrier:

 

<a href="sip:&#43;15555551212@gw2.com;npdi=yes">sip:+15555551212@...;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:

 

<a href="sip:&#43;15555551212;npdi=yes@gw2.com;transport=udp;user=phone">sip:+15555551212;npdi=yes@...;transport=udp;user=phone

 

Perform this action:

 

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

 

Resultant $ru:

 

<a href="sip:&#43;15555551212;rn=&#43;15555550000@gw2.com;npdi=yes">sip:+15555551212;rn=+15555550000@...;npdi=yes

 

 

Ben Newlin

Lead Voice Network Engineer, PureCloud

 

O +1 317.957.1009

[hidden email]

 

From: Users [hidden email] on behalf of Ben Newlin [hidden email]
Reply-To: OpenSIPS users mailling list [hidden email]
Date: Friday, June 30, 2017 at 10:47 AM
To: Bogdan-Andrei Iancu [hidden email], OpenSIPS users mailling list [hidden email]
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:
“<a href="sip:&#43;15555551212@gw2.com;npdi=yes”">sip:+15555551212@...;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 [hidden email]
Date: Thursday, June 29, 2017 at 4:38 AM
To: OpenSIPS users mailling list [hidden email], Ben Newlin [hidden email]
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 "<a href="sip:&#43;15555551212@gw2.com;npdi">sip:+15555551212@...;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 “<a href="sip:&#43;15555551212@gw1.com%E2%80%9D">sip:+15555551212@...”, if we modify it this way:

 

$rU = $rU + “;npdi”;

 

then we get a new $ru of “<a href="sip:&#43;15555551212;npdi@gw1.com%E2%80%9D">sip:+15555551212;npdi@...”.

 

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 “<a href="sip:&#43;15555551212;npdi@gw1.com”">sip:+15555551212;npdi@...”.

 

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 “<a href="sip:&#43;15555551212@gw2.com;npdi”">sip:+15555551212@...;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
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users








_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: SIP URI User Parameters

Bogdan-Andrei Iancu-2
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 on your 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

[hidden email]


 

From: Bogdan-Andrei Iancu [hidden email]
Date: Monday, July 3, 2017 at 11:46 AM
To: Ben Newlin [hidden email], OpenSIPS users mailling list [hidden email]
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:
        <a moz-do-not-send="true" href="sip:username;bla=foo@host.com;param1=1;param2=2;user=phone">sip:username;bla=foo@...;param1=1;param2=2;user=phone
to
        <a moz-do-not-send="true" href="sip:username@host.com;bla=foo">sip:username@...;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



_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: SIP URI User Parameters

Ben Newlin

Bogdan,

 

Thanks for your suggestion to modify the whole RURI. While this will work for our modifications, we have no control over how modules like Dynamic Routing access the RURI and that module’s functions are also causing the error to occur. So this will not work.

 

However, I have found that using revert_uri within failure_route will remove the user params prior to performing routing and so prevents the issue. We can then add the user params back before sending out the next branch. This workaround is of course specific to our current use case, where we are always injecting the user params ourselves. It would not work if the user params were present in the original received RURI.

 

We will continue with this workaround until we can upgrade to version 2. Thanks again for your help.

 

Ben Newlin

 

From: Bogdan-Andrei Iancu <[hidden email]>
Date: Wednesday, July 5, 2017 at 10:46 AM
To: Ben Newlin <[hidden email]>, OpenSIPS users mailling list <[hidden email]>
Subject: Re: [OpenSIPS-Users] SIP URI User Parameters

 

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 on your 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

[hidden email]


 

From: Bogdan-Andrei Iancu [hidden email]
Date: Monday, July 3, 2017 at 11:46 AM
To: Ben Newlin [hidden email], OpenSIPS users mailling list [hidden email]
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:
        <a href="sip:username;bla=foo@host.com;param1=1;param2=2;user=phone">sip:username;bla=foo@...;param1=1;param2=2;user=phone
to
        <a href="sip:username@host.com;bla=foo">sip:username@...;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

 




_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: SIP URI User Parameters

Bogdan-Andrei Iancu-2
Ben,

Exploring the "whole RURI modification" option - once you get rid of the user=phone param, you are safe for the rest of the processing. My idea was to strip that parameter in the very beginning of the processing. After that, any DR processing will be safe.

Something like:

subst_uri('/^(.+);user=phone([^@]*)$/\1\2/i');


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 08:16 PM, Ben Newlin wrote:

Bogdan,

 

Thanks for your suggestion to modify the whole RURI. While this will work for our modifications, we have no control over how modules like Dynamic Routing access the RURI and that module’s functions are also causing the error to occur. So this will not work.

 

However, I have found that using revert_uri within failure_route will remove the user params prior to performing routing and so prevents the issue. We can then add the user params back before sending out the next branch. This workaround is of course specific to our current use case, where we are always injecting the user params ourselves. It would not work if the user params were present in the original received RURI.

 

We will continue with this workaround until we can upgrade to version 2. Thanks again for your help.

 

Ben Newlin

 

From: Bogdan-Andrei Iancu [hidden email]
Date: Wednesday, July 5, 2017 at 10:46 AM
To: Ben Newlin [hidden email], OpenSIPS users mailling list [hidden email]
Subject: Re: [OpenSIPS-Users] SIP URI User Parameters

 

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 on your 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?

 




_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Loading...