Unable to put "+" in front of DID numbers or outdial prefix

Version 2.1.3 not current SVN.

Found part of the problem. In page.trunk.php, at the end the line

if ( !isDialDigitChar(c) && (c != "w") && (c != "W") && (c != "q") && (c != "Q") (c != "+")) return false;

Should be

if ( !isDialDigitChar(c) && (c != "w") && (c != "W") && (c != "q") && (c != "Q") && (c != "+")) return false;

How can I make this not remove the "+" in the number?

$directdid = preg_replace("/[^{0-9._XxNnZz\[\]\-]/" ,"", trim($directdid));}

This is definately fixed in 2.2.. If you wanted to add a plus to that line (but that line is saying 'strip out those characters'), put a \+ in there.

--Rob

can't put \+ either as outbound dial prefix. -> "Invalid Outbound Dial Prefix"

I saw yet another person having a problem with this just today. As a test, I tried placing the following rule in one of my trunks:

\++1700.

What this should have meant (if I understand Rob's post) is that if I dialed a number starting with 1700 and it got to this trunk (actually the ENUM trunk), it should have a + prepended (since the first plus is escaped but the second one isn't). However, when I tried to save it, I got a popup box that said "Invalid Dial Rules." Since it would not let me add the rule in the first place, I was unable to test whether the rule itself would actually work, had I been allowed to save it. I don't know if this is a case of error checking that doesn't allow the \ character, or the \+ actually not being valid in a trunk dial rule. For that reason I'm reopening this ticket, and updating the version to 2.5 since that is where I am seeing the problem.

A little more research shows that it's not jsut the input chech that is causing the problem. If I temporarily comment out these two lines in page.trunk.php:

// if (!isDialrule(theForm.dialrules.value))

// return warnInvalid(theForm.dialrules, msgInvalidDialRules);

I can then enter the pattern \++1700. and save it, but the \ just gets ignored and the CLI prints out this message:

fixlocalprefix: Could not understand pattern ++1700. (++1700.)

So... I'm not sure what Rob was talking about, but a \+ does not have the intended effect in a trunk dial rule, even if you do bypass the javascript sanity check.

That should have read, "it's not just the input check that is causing the problem."

One other thought... I was looking at /var/lib/asterisk/agi-bin/fixlocalprefix (which, admittedly, did not make a whole lot of sense to me) but the feeling I got was that it might be easier to define a substitute character that would be allowed in a pattern and then, at the very end of processing, converted that substitute character to a + character. So, for example, you could define the "convert to +" character as a tilde (~) - the pattern for what I was attempting to test might then look like this:

~+1700.

So if the number you called was 17005554242, it would get converted to +17005554242 - all you would then need to do is define the ~ as a valid character (and add it to the various lists of valid characters in fixlocalprefix and in page.trunk.php) and then at the exit point of fixlocalprefix just add a line of code to replace any ~ characters with + characters. It may seem a bit kludgey, but then so is \+, and I suspect that the substitute character approach would be a whole lot easier to implement at this point. Note you could just as easily use a P or p instead of a tilde (since P is not a currently recognized character) - basically any character that has no current meaning could serve the purpose.

I probably could have actually tested this approach except that I don't know PHP, so can't write the line to actually do the replacement, and more to the point, I can't figure out where it would actually be inserted into fixlocalprefix - I'm assuming somewhere in the fixNumber function but just can't figure out exactly what that function is doing internally.