Updating parts of $du results in malformed duri

[brettnem]

So I'm using d9eec58

If I do this:
$du=$ru;
xlog("du->$du");

du looks right: say like this:
sip:15125551212@1.2.3.4:5060;user=phone

** THERE IS NO EXTRA COLON IN THERE, I PROMISE **

However, if I modify $du piece parts like this:
$du=$ru;
$dp=5061;

dp is changed, but du is now malformed
sip:15125551212:@1.2.3.4:5061;user=phone

Note: port 5061 as expected, but a COLON is inserted before the @
Note2: If I make 5061 a string like '5061' it does the exact same thing

Similarly if I change the domain ONLY I get the same weird colon

$du=$ru
$dd='example.com'

gives me:
sip:15125551212:@example.com:5060;user=phone

I have no idea how the colon gets in there

It's always ONE COLON before the @. I haven't see any other case

Now if I change BOTH $dd and $dp:
$du=$ru
$dp=5061
$dd='example.com'

The exact same problem:
sip:15125551212:@example.com:5061;user=phone

I don't doubt the possibility of some dynamic other variable or other part of my script causing this to happen, but I can't; figure out how or why

I've tried to debug on level 6, but because of a different bug, more than half my AVPs are NULL during the script and everything fails.

[liviuchircu]

All three scenarios confirmed. You can even replicate this within a startup route!

[liviuchircu]

Looks like it's printing the password as well. However, the password is obviously NULL, hence the reason why it just seems to be appending a colon.

Nevertheless, the resulting uri "sip:15125551212:@example.com:5061;user=phone" seems valid according to http://www.in2eps.com/fo-abnf/tk-fo-abnf-sipuri.html.

[brettnem]

Even tho this may pass abnf, when all this happens, it appears that t_relay doesn't actually send the call out. Note that I'm manipulating my $du in branch_route

[brettnem]

Also in reviewing the abnf, isn't it suggesting that if you have a : you must have a password?

Also [userinfo] itself is optional. but if you have a [userinfo] you have to have a user.. then user can optionally have :password

But I don't see how : without user info or an actual password would validate?

[liviuchircu]

Because password is defined as * (zero or more) of its specific characters.

Please note how user is defined as 1* (one or more). Which means that empty-string passwords are valid.

[brettnem]

ok I think I see that now.

I still can't get it to t_relay when it does this. And I'm sure people will hate that floating : in the request regardless if it's legit or not.

Actually, this is DURI. Not RURI. So I'm not sure how opensips would handle this under the hood. Either way, t_relay is failing under this circumstance.

[liviuchircu]

Issue fixed in pull request #598 from @jarrodb