<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<tt>Hi Ben,<br>
<br>
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. <br>
</tt><br>
<pre wrap="">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@host.com;param1=1;param2=2;user=phone</a>
to
<a class="moz-txt-link-freetext" href="sip:username@host.com;bla=foo">sip:username@host.com;bla=foo</a>
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 -> <a class="moz-txt-link-freetext" href="https://lists.cs.columbia.edu/pipermail/sip-implementors/2013-February/028837.html">https://lists.cs.columbia.edu/pipermail/sip-implementors/2013-February/028837.html</a>
* SIP Core -> <a class="moz-txt-link-freetext" href="https://www.ietf.org/mail-archive/web/sipcore/current/msg01783.html">https://www.ietf.org/mail-archive/web/sipcore/current/msg01783.html</a>
* voip info -> <a class="moz-txt-link-freetext" href="https://www.voip-info.org/wiki/view/SIP+URI">https://www.voip-info.org/wiki/view/SIP+URI</a> (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.
</pre>
<tt><br>
Best regards,<br>
<br>
</tt>
<pre class="moz-signature" cols="72">Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
<a class="moz-txt-link-freetext" href="http://www.opensips-solutions.com">http://www.opensips-solutions.com</a>
OpenSIPS Bootcamp 2017, Houston, US
<a class="moz-txt-link-freetext" href="http://opensips.org/training/OpenSIPS_Bootcamp_2017.html">http://opensips.org/training/OpenSIPS_Bootcamp_2017.html</a>
</pre>
<div class="moz-cite-prefix">On 06/30/2017 10:14 PM, Ben Newlin
wrote:<br>
</div>
<blockquote
cite="mid:EB953E5A-4584-4307-AD15-B9F0B1EBFA23@genesys.com"
type="cite">
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<meta name="Title" content="">
<meta name="Keywords" content="">
<meta name="Generator" content="Microsoft Word 15 (filtered
medium)">
<!--[if !mso]><style>v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}
</style><![endif]-->
<style><!--
/* Font Definitions */
@font-face
{font-family:"Courier New";
panose-1:2 7 3 9 2 2 5 2 4 4;}
@font-face
{font-family:Wingdings;
panose-1:5 0 0 0 0 0 0 0 0 0;}
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:Calibri;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:#0563C1;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:#954F72;
text-decoration:underline;}
pre
{mso-style-priority:99;
mso-style-link:"HTML Preformatted Char";
margin:0in;
margin-bottom:.0001pt;
font-size:10.0pt;
font-family:"Courier New";}
p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph
{mso-style-priority:34;
margin-top:0in;
margin-right:0in;
margin-bottom:0in;
margin-left:.5in;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:Calibri;}
span.HTMLPreformattedChar
{mso-style-name:"HTML Preformatted Char";
mso-style-priority:99;
mso-style-link:"HTML Preformatted";
font-family:Courier;}
span.EmailStyle20
{mso-style-type:personal;
font-family:Calibri;
color:windowtext;}
span.EmailStyle21
{mso-style-type:personal;
font-family:Calibri;
color:windowtext;}
span.EmailStyle22
{mso-style-type:personal-reply;
font-family:Calibri;
color:windowtext;}
span.msoIns
{mso-style-type:export-only;
mso-style-name:"";
text-decoration:underline;
color:teal;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
/* List Definitions */
@list l0
{mso-list-id:1878198596;
mso-list-type:hybrid;
mso-list-template-ids:1154257720 67698689 67698691 67698693 67698689 67698691 67698693 67698689 67698691 67698693;}
@list l0:level1
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:Symbol;}
@list l0:level2
{mso-level-number-format:bullet;
mso-level-text:o;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:"Courier New";}
@list l0:level3
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:Wingdings;}
@list l0:level4
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:Symbol;}
@list l0:level5
{mso-level-number-format:bullet;
mso-level-text:o;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:"Courier New";}
@list l0:level6
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:Wingdings;}
@list l0:level7
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:Symbol;}
@list l0:level8
{mso-level-number-format:bullet;
mso-level-text:o;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:"Courier New";}
@list l0:level9
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:Wingdings;}
ol
{margin-bottom:0in;}
ul
{margin-bottom:0in;}
--></style>
<div class="WordSection1">
<p class="MsoNormal"><span style="font-size:11.0pt">Bogdan,<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">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).<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">Original
$ru: <o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"><a class="moz-txt-link-freetext" href="sip:+15555551212;npdi=yes@gw2.com;transport=udp;user=phone">sip:+15555551212;npdi=yes@gw2.com;transport=udp;user=phone</a><o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">After call
to route_to_carrier:<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"><a class="moz-txt-link-freetext" href="sip:+15555551212@gw2.com;npdi=yes">sip:+15555551212@gw2.com;npdi=yes</a><o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">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.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">Original
$ru: <o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"><a class="moz-txt-link-freetext" href="sip:+15555551212;npdi=yes@gw2.com;transport=udp;user=phone">sip:+15555551212;npdi=yes@gw2.com;transport=udp;user=phone</a><o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">Perform this
action:<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">$rU = $rU +
“;rn=+15555550000”;<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">Resultant
$ru:<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"><a class="moz-txt-link-freetext" href="sip:+15555551212;rn=+15555550000@gw2.com;npdi=yes">sip:+15555551212;rn=+15555550000@gw2.com;npdi=yes</a><o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
<div>
<p class="MsoNormal" style="text-autospace:none"><span
style="color:#FC3619">Ben Newlin</span><span
style="font-family:"Times New Roman""><o:p></o:p></span></p>
<p class="MsoNormal" style="text-autospace:none"><span
style="font-size:10.0pt;color:#838487">Lead Voice Network
Engineer, PureCloud</span><span
style="font-family:"Times New Roman""><o:p></o:p></span></p>
<p class="MsoNormal" style="text-autospace:none"><span
style="font-size:10.0pt"><img id="_x0000_i1033"
src="cid:part1.F42737B1.09B85FA1@opensips.org"
height="9" width="291"></span><span
style="font-family:"Times New Roman""><o:p></o:p></span></p>
<p class="MsoNormal" style="text-autospace:none"><b><span
style="font-size:6.0pt;color:#FC3619"> </span></b><span
style="font-family:"Times New Roman""><o:p></o:p></span></p>
<p class="MsoNormal" style="text-autospace:none"><span
style="font-size:6.0pt;color:#FC3619">O</span><span
style="font-size:10.0pt">
<span style="color:#838487">+1 317.957.1009</span></span><span
style="font-family:"Times New Roman""><o:p></o:p></span></p>
<p class="MsoNormal" style="text-autospace:none"><u><span
style="font-size:10.0pt;color:#0B4CB4"><a
moz-do-not-send="true"
href="mailto:ben.newlin@genesys.com"><a class="moz-txt-link-abbreviated" href="mailto:ben.newlin@genesys.com">ben.newlin@genesys.com</a></a></span></u><span
style="font-family:"Times New Roman""><o:p></o:p></span></p>
<p class="MsoNormal" style="text-autospace:none"><span
style="font-size:10.0pt"><img id="_x0000_i1032"
src="cid:part1.F42737B1.09B85FA1@opensips.org"
border="0" height="9" width="291"></span><span
style="font-family:"Times New Roman""><o:p></o:p></span></p>
<p class="MsoNormal" style="text-autospace:none"><a
moz-do-not-send="true" href="http://www.genesys.com/"><span
style="color:#838487;text-decoration:none"><img
id="_x0000_i1031"
src="cid:part4.15650E38.2B739FCB@opensips.org"
border="0" height="53" width="143"></span></a><span
style="font-family:"Times New Roman""><o:p></o:p></span></p>
</div>
<p class="MsoNormal"><a moz-do-not-send="true"
href="https://twitter.com/Genesys"><span
style="color:#838487;text-decoration:none"><img
id="_x0000_i1030"
src="cid:part6.722C0E66.29ABBA93@opensips.org"
border="0" height="23" width="25"></span></a><a
moz-do-not-send="true"
href="http://www.linkedin.com/company/601919?trk=tyah"><span
style="color:#838487;text-decoration:none"><img
id="_x0000_i1029"
src="cid:part8.E6FE6CFF.DBBCAC87@opensips.org"
border="0" height="23" width="25"></span></a><a
moz-do-not-send="true"
href="https://plus.google.com/+Genesyslab?rel=publisher"><span
style="color:#838487;text-decoration:none"><img
id="_x0000_i1028"
src="cid:part10.798A52BD.E008331C@opensips.org"
border="0" height="23" width="23"></span></a><a
moz-do-not-send="true"
href="https://www.facebook.com/Genesys/"><span
style="color:#838487;text-decoration:none"><img
id="_x0000_i1027"
src="cid:part12.3FB3CFFF.8344785A@opensips.org"
border="0" height="23" width="25"></span></a><a
moz-do-not-send="true"
href="https://www.youtube.com/Genesys"><span
style="color:#838487;text-decoration:none"><img
id="_x0000_i1026"
src="cid:part14.F12AE0C4.5648678E@opensips.org"
border="0" height="23" width="25"></span></a><a
moz-do-not-send="true" href="http://blog.genesys.com/"><span
style="color:#838487;text-decoration:none"><img
id="_x0000_i1025"
src="cid:part16.2AC2E18A.984B34CA@opensips.org"
border="0" height="23" width="23"></span></a><span
style="font-size:11.0pt"><o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
<div style="border:none;border-top:solid #B5C4DF
1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b><span style="color:black">From: </span></b><span
style="color:black">Users
<a class="moz-txt-link-rfc2396E" href="mailto:users-bounces@lists.opensips.org"><users-bounces@lists.opensips.org></a> on behalf of Ben
Newlin <a class="moz-txt-link-rfc2396E" href="mailto:Ben.Newlin@genesys.com"><Ben.Newlin@genesys.com></a><br>
<b>Reply-To: </b>OpenSIPS users mailling list
<a class="moz-txt-link-rfc2396E" href="mailto:users@lists.opensips.org"><users@lists.opensips.org></a><br>
<b>Date: </b>Friday, June 30, 2017 at 10:47 AM<br>
<b>To: </b>Bogdan-Andrei Iancu
<a class="moz-txt-link-rfc2396E" href="mailto:bogdan@opensips.org"><bogdan@opensips.org></a>, OpenSIPS users mailling list
<a class="moz-txt-link-rfc2396E" href="mailto:users@lists.opensips.org"><users@lists.opensips.org></a><br>
<b>Subject: </b>Re: [OpenSIPS-Users] SIP URI User
Parameters<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-family:"Times New
Roman""><o:p> </o:p></span></p>
</div>
<p class="MsoNormal"><span style="font-size:11.0pt">Bogdan,</span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> </span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt">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:</span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> </span><o:p></o:p></p>
<p class="MsoListParagraph"
style="text-indent:-.25in;mso-list:l0 level1 lfo2"><!--[if !supportLists]--><span
style="font-family:Symbol"><span style="mso-list:Ignore">·<span
style="font:7.0pt "Times New Roman"">
</span></span></span><!--[endif]--><span
style="font-size:11.0pt">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.<br>
<br>
<br>
</span><o:p></o:p></p>
<p class="MsoListParagraph"
style="text-indent:-.25in;mso-list:l0 level1 lfo2"><!--[if !supportLists]--><span
style="font-family:Symbol"><span style="mso-list:Ignore">·<span
style="font:7.0pt "Times New Roman"">
</span></span></span><!--[endif]--><span
style="font-size:11.0pt">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.<br>
<br>
<br>
</span><o:p></o:p></p>
<p class="MsoListParagraph"
style="text-indent:-.25in;mso-list:l0 level1 lfo2"><!--[if !supportLists]--><span
style="font-family:Symbol"><span style="mso-list:Ignore">·<span
style="font:7.0pt "Times New Roman"">
</span></span></span><!--[endif]--><span
style="font-size:11.0pt">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.<br>
<br>
<br>
</span><o:p></o:p></p>
<p class="MsoListParagraph"
style="text-indent:-.25in;mso-list:l0 level1 lfo2"><!--[if !supportLists]--><span
style="font-family:Symbol"><span style="mso-list:Ignore">·<span
style="font:7.0pt "Times New Roman"">
</span></span></span><!--[endif]--><span
style="font-size:11.0pt">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:<br>
“<a class="moz-txt-link-freetext" href="sip:+15555551212@gw2.com;npdi=yes”">sip:+15555551212@gw2.com;npdi=yes”</a></span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> </span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt">Also, I
should have mentioned that we are running 1.11.11. I’m still
working to try to reproduce locally.</span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> </span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt">Ben Newlin</span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> </span><o:p></o:p></p>
<div style="border:none;border-top:solid #B5C4DF
1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b><span style="color:black">From: </span></b><span
style="color:black">Bogdan-Andrei Iancu
<a class="moz-txt-link-rfc2396E" href="mailto:bogdan@opensips.org"><bogdan@opensips.org></a><br>
<b>Date: </b>Thursday, June 29, 2017 at 4:38 AM<br>
<b>To: </b>OpenSIPS users mailling list
<a class="moz-txt-link-rfc2396E" href="mailto:users@lists.opensips.org"><users@lists.opensips.org></a>, Ben Newlin
<a class="moz-txt-link-rfc2396E" href="mailto:Ben.Newlin@genesys.com"><Ben.Newlin@genesys.com></a><br>
<b>Subject: </b>Re: [OpenSIPS-Users] SIP URI User
Parameters</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-family:"Times New
Roman""> </span><o:p></o:p></p>
</div>
<p class="MsoNormal">Hello Ben<br>
<br>
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.<br>
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.
<br>
<br>
So far so good. And now you do use_next_gw() in failure route
and you get "<span style="font-size:11.0pt"><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@gw2.com;npdi</a></a>"
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).<br>
<br>
Could you also do an<br>
xlog("DR ruris are <$(avp(___dr_ruri__)[*])>\n");<br>
right after do_routing() ?<br>
<br>
Regards,<br>
<br>
<br>
</span><o:p></o:p></p>
<pre>Bogdan-Andrei Iancu<o:p></o:p></pre>
<pre> OpenSIPS Founder and Developer<o:p></o:p></pre>
<pre> <a moz-do-not-send="true" href="http://www.opensips-solutions.com">http://www.opensips-solutions.com</a><o:p></o:p></pre>
<pre> <o:p></o:p></pre>
<pre>OpenSIPS Bootcamp 2017, Houston, US<o:p></o:p></pre>
<pre> <a moz-do-not-send="true" href="http://opensips.org/training/OpenSIPS_Bootcamp_2017.html">http://opensips.org/training/OpenSIPS_Bootcamp_2017.html</a><o:p></o:p></pre>
<div>
<p class="MsoNormal">On 06/28/2017 11:41 PM, Ben Newlin wrote:<o:p></o:p></p>
</div>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<p class="MsoNormal"><span style="font-size:11.0pt">Hi,</span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> </span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt">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. </span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> </span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt">For
example, starting with $ru of “<a moz-do-not-send="true"
href="sip:+15555551212@gw1.com%E2%80%9D">sip:+15555551212@gw1.com”</a>,
if we modify it this way:</span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> </span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt">$rU = $rU
+ “;npdi”;</span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> </span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt">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@gw1.com”</a>.
</span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> </span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt">We send
this call out and if it returns an error we want to use
the next available gateway.</span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> </span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt">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@gw1.com”</a></a>.
</span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> </span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt">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.</span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> </span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt">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@gw2.com;npdi”</a></a>.
This is not correct.</span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> </span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt">Is there
some other way to properly manipulate SIP URI user
parameters or is this a bug?</span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> </span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> </span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt">Thanks,</span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> </span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt">Ben Newlin</span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-family:"Times New
Roman""><br>
<br>
<br>
<br>
</span><o:p></o:p></p>
<pre>_______________________________________________<o:p></o:p></pre>
<pre>Users mailing list<o:p></o:p></pre>
<pre><a moz-do-not-send="true" href="mailto:Users@lists.opensips.org">Users@lists.opensips.org</a><o:p></o:p></pre>
<pre><a moz-do-not-send="true" href="http://lists.opensips.org/cgi-bin/mailman/listinfo/users">http://lists.opensips.org/cgi-bin/mailman/listinfo/users</a><o:p></o:p></pre>
</blockquote>
<p class="MsoNormal"><span style="font-family:"Times New
Roman""><br>
<br>
<br>
</span><o:p></o:p></p>
</div>
</blockquote>
<br>
</body>
</html>