CRM might do it as well, or CallFiles maybe? The phone should never send anything that isn’t in the “approved” list, but there are so many ways to send calls now (between CRM and browser-based TAPI Call Widgets) that it’s something that should be dealt with, I suppose…
Copy paste out of a google search. Copy paste out of an email.
Copy paste out of… you get the picture.
My PSA and my CRM both properly strip crap out before dialing.
Bria, Jitsi, X-Lite, every other softphone I’ve used just strips the whitespace and parens out.
All of them, except Zulu.
No, no it shouldn’t. CRM and TAPI software should be using the standard Telephony rules for the country (or countries) they are built to support. PBX and other voice system manufacturers aren’t going to go out of their way to support improper number formats because some TAPI software doesn’t follow standards.
As the poster pointed out, all other softphones and his CRM system strip the improper stuff before sending out the digits and the call request. That is the proper way to do it.
If Zulu is the only one that isn’t doing it then that is a bug in Zulu or in the dialplan to support Zulu. Because if Zulu is going to allow the sending of these improper characters and formats then the FreePBX generated dialplan should support those patterns being sent. Users shouldn’t be having to find “kludges” for their commercial software to work.
Numbers dialed edited for privacy concerns.
My response follows.
His final response.
After that, I came here and @billsimon spearheaded a fix for me. Many thanks all 
P.S. I agree with @BlazeStudios - this is something that Sangoma should address. If I didn’t really want the callpop feature Zulu has, I’d’ve spent money somewhere else, with a different company.
Interesting that they claim it is a configuration issue on your end but don’t provide any material or information on what the correct settings should or shouldn’t be.
You’ve checked your settings against all the documents for Zulu and the softphone?
Indeed.
After he said that, I went back over the Zulu installation directions. Nothing about configuring dialplans for it.
It’s all supposed to be automated by their commercial module installation.
I’m not familiar with Zulu, but could it be a difference in browser that made it work for him and not for you?
Nope, the popup/browser doesn’t matter. Those only apply on inbound calls. (I also tried leaving those features turned off)
These were outbound calls. Data entered directly into the softphone(Zulu) and then the dial button clicked.
Can’t hardly thank you guys enough, but if you’re ever in midwest wisconsin, south of tomah/north of the dells look me up. I’ll treat you to my home made coffee liqueur. 80~120proof, distilled from high end coffee 
Main reason for switching to zulu was so I could have it look up data in my CRM/PSA with a webbrowser popup.
Amazing feature, and well worth the hassle. Had to code the lookup bridge myself (PHP & SQL based stuff, comparatively simple to dialplans) but once that was done, it works like a charm.
Anyone calling in that we’ve got in the database, the call itself generates a list of tickets/activities that we’ve got outstanding with the client.
Now if only I could tie it in to my billing system so we can see if they owe us money too…
Hi there.
I am the lead developer on both FreePBX and Zulu server. We run any and all strings we get from the originate command through a regular expression parser. We do not however, pass what is sent to the softphone through the parser.
I looked at what you provided to Robert Keller and I can see that he was using originate but you were using the softphone.
We should address parsing of values in the softphone. There is no need for you to have all of this crazy dialplan.
1 Like
I’ve checked some typical numbers to see the parsing result with Zulu:
012345678 works
0 12345678 works (1 space)
0 12 34 56 78 only sends out 0 12, so only the first space is allowed in the parser
same issue for 01/23/45/67 : only first / is removed and then parser stops :0123 is sent out
but for 01-23-45-67 then the parser continues and removes all -
3 more questions :
-
could “+” dialing be added (+ by international prefix substitution)? e.g. +3212345678 to become 003212345678 this would require a ZUlu client setting to substitute + by 00 or other string
-
could brackets be removed including the spaces and the number(s) between the brackets ? e.g. +32 (0) 12345678 to become +3212345678 (followed by the + substitution above)
-
could PBX prefix (0 or 9 depending US or Europe) be added ?
With all this the click to dial would become very handy and powerfull as it covers then most number formats.