Manipulatin outgoing number

MicF1968 · July 23, 2019, 12:14pm

Hi,

after help from this forum, I was able to change extentions_conf to manipulate incoming calls, so they have international format (+49 …)

I’m struggeling now with the same for outgoing calls, as I want them to integrate into my CRM (Bitrix).
The addin has this option:

In ${EXTEN} there’s the number, as typed in the phones dial pad.
What I need is, to add to all numbers without a leading 0 → +49621 and with one leading 0 ->+49

e. g.
9999 should be +49621 9999
0888 should be +49 888
0077 should be +49 77

But how can I do that?
Is there a way, to use regex?

Any help highly appreciated.
Thanks
Mic

dolesec · July 23, 2019, 3:33pm

you can manipulate that in outbound routes or trunks -

if generalized to a route, modify at the route level; if specific to a trunk, then trunk level

both modules provide dial plan manipulation tabs where you configure this

MicF1968 · July 23, 2019, 4:23pm

Thanks Chris!

Question is how?
I tried this, but didn’t worked!

So I thought I try it directly in the addin.
But I have no glue about the syntax here.

cynjut · July 23, 2019, 6:33pm

You got the fields backwards. <Prepend> is what gets added to the number, <prefix> is the match.

MicF1968 · July 25, 2019, 4:34pm

Hi Dave,

hmmm, that’s what I want.

I dial 12345 and want +49 621 12345
I dial 0555 12345 and I want +49 555 12345

So basicly, I want to replace one 0 to +49 and two 0 to +49 621

Mic

cynjut · July 25, 2019, 4:45pm

Your screenshot says:

If you dial 00[1-9]anything, you get +[1-9]anything.
If you dial 0[1-9]anything. you get +49[1-9]anything.
If you dial [1-9]anything, you get +49621[1-9]anything.

Your screenshot doesn’t yield the result you are saying you’re looking for.

MicF1968 · July 25, 2019, 5:00pm

Let’s focus on this one.
If I dial a number without any leading zeros, it is a local number, so I want to add country code +49 and city code 621.

Isn’t that, what you say?

cynjut · July 25, 2019, 5:30pm

It’s what your outbound dial manipulation pattern says is going to happen.

MicF1968 · July 25, 2019, 5:45pm

So here closes the loop.
It doesn’t work and hence I wanted to change it in the addin (see initial post).

See:

cynjut · July 25, 2019, 5:51pm

The CDR doesn’t tell us what happened, you need to show a call from /var/log/asterisk/full to see what is actually getting sent to the outbound side of your trunk.

cynjut · July 25, 2019, 5:52pm

In Bitrix, you don’t modify the number. You use the ‘generalized’ version of the number you would from your dialpad, then let the outbound route modify and send it.

MicF1968 · July 25, 2019, 6:14pm

Here’s the log with the number part:

[2019-07-25 19:53:05][C-000002fb][1564077185-1612] PHONE_NUMBER => 783568
[2019-07-25 19:54:20][C-000002fc][1564077260-1560] register => telephony.externalcall.register? 
USER_ID=1&PHONE_NUMBER=783568&TYPE=1&CALL_START_DATE=2019-07- 25T19%3A54%3A19%2B02%3A00&CRM_CREATE=1&CRM_SOURCE=%3D%3D+choose+one+%3D%3D&SHOW=1
[2019-07-25 19:54:24][C-000002fc][1564077263-1869] PHONE_NUMBER => 783568

cynjut · July 25, 2019, 7:58pm

Below this, in the log, should be what happens with the call. I’m going to guess it ends up with a message like “All circuits are busy now”.

MicF1968 · July 26, 2019, 7:44am

Well … No, why should it.
The call is going thru.

It’s just a format issue.
Without the internation format it can’t be matched to a contact within bitrix.

[2019-07-26 09:41:28][C-00000301][1564126888-1056][To Bitrix24][14.0.0.7][-Begin-]
[2019-07-26 09:41:28][C-00000301][1564126888-1056] Request => batch
[2019-07-26 09:41:28][C-00000301][1564126888-1056] halt => 0
[2019-07-26 09:41:28][C-00000301][1564126888-1056] register => telephony.externalcall.register?USER_ID=1&PHONE_NUMBER=783568&TYPE=1&CALL_START_DATE=2019-07-26T09%3A41%3A27%2B02%3A00&CRM_CREATE=1&CRM_SOURCE=%3D%3D+choose+one+%3D%3D&SHOW=1
[2019-07-26 09:41:28][C-00000301][1564126888-1056][To Bitrix24][-End-]
[2019-07-26 09:41:29][C-00000301][1564126888-1056][To Bitrix24][14.0.0.7][-Begin-]
[2019-07-26 09:41:29][C-00000301][1564126888-1056] Response => batch
[2019-07-26 09:41:29][C-00000301][1564126888-1056] CALL_ID => externalCall.8287e7446468039616562ed2ec8afd3d.1564126889
[2019-07-26 09:41:29][C-00000301][1564126888-1056] CRM_CREATED_LEAD =>
[2019-07-26 09:41:29][C-00000301][1564126888-1056] CRM_ENTITY_TYPE => LEAD
[2019-07-26 09:41:29][C-00000301][1564126888-1056] CRM_ENTITY_ID => 122
[2019-07-26 09:41:29][C-00000301][1564126888-1056] start => 1564126889.0486
[2019-07-26 09:41:29][C-00000301][1564126888-1056] finish => 1564126889.1697
[2019-07-26 09:41:29][C-00000301][1564126888-1056] duration => 0.12105107307434
[2019-07-26 09:41:29][C-00000301][1564126888-1056] processing => 0.12097001075745
[2019-07-26 09:41:29][C-00000301][1564126888-1056] date_start => 2019-07-26T10:41:29+03:00
[2019-07-26 09:41:29][C-00000301][1564126888-1056] date_finish => 2019-07-26T10:41:29+03:00
[2019-07-26 09:41:29][C-00000301][1564126888-1056] start => 1564126889.0241
[2019-07-26 09:41:29][C-00000301][1564126888-1056] finish => 1564126889.1697
[2019-07-26 09:41:29][C-00000301][1564126888-1056] duration => 0.14556908607483
[2019-07-26 09:41:29][C-00000301][1564126888-1056] processing => 0.121258020401
[2019-07-26 09:41:29][C-00000301][1564126888-1056] date_start => 2019-07-26T10:41:29+03:00
[2019-07-26 09:41:29][C-00000301][1564126888-1056] date_finish => 2019-07-26T10:41:29+03:00
[2019-07-26 09:41:29][C-00000301][1564126888-1056][To Bitrix24][-End-]
[2019-07-26 09:41:41][C-00000301][1564126901-1710][To Bitrix24][14.0.0.7][-Begin-]
[2019-07-26 09:41:41][C-00000301][1564126901-1710] Request => telephony.externalcall.hide
[2019-07-26 09:41:41][C-00000301][1564126901-1710] CALL_ID => externalCall.8287e7446468039616562ed2ec8afd3d.1564126889
[2019-07-26 09:41:41][C-00000301][1564126901-1710] USER_ID => 1
[2019-07-26 09:41:41][C-00000301][1564126901-1710][To Bitrix24][-End-]
[2019-07-26 09:41:41][C-00000301][1564126901-1884][To Bitrix24][14.0.0.7][-Begin-]
[2019-07-26 09:41:41][C-00000301][1564126901-1884] Request => telephony.externalcall.finish
[2019-07-26 09:41:41][C-00000301][1564126901-1884] CALL_ID => externalCall.8287e7446468039616562ed2ec8afd3d.1564126889
[2019-07-26 09:41:41][C-00000301][1564126901-1884] USER_ID => 1
[2019-07-26 09:41:41][C-00000301][1564126901-1884] DURATION =>
[2019-07-26 09:41:41][C-00000301][1564126901-1884] STATUS_CODE => 603-S
[2019-07-26 09:41:41][C-00000301][1564126901-1884] VOTE =>
[2019-07-26 09:41:41][C-00000301][1564126901-1884] ADD_TO_CHAT => 0
[2019-07-26 09:41:41][C-00000301][1564126901-1884][To Bitrix24][-End-]
[2019-07-26 09:41:41][C-00000301][1564126901-1710][To Bitrix24][14.0.0.7][-Begin-]
[2019-07-26 09:41:41][C-00000301][1564126901-1710] Response => telephony.externalcall.hide
[2019-07-26 09:41:41][C-00000301][1564126901-1710] result => 1
[2019-07-26 09:41:41][C-00000301][1564126901-1710] start => 1564126901.5143
[2019-07-26 09:41:41][C-00000301][1564126901-1710] finish => 1564126901.5584
[2019-07-26 09:41:41][C-00000301][1564126901-1710] duration => 0.044135093688965
[2019-07-26 09:41:41][C-00000301][1564126901-1710] processing => 0.015558004379272
[2019-07-26 09:41:41][C-00000301][1564126901-1710] date_start => 2019-07-26T10:41:41+03:00
[2019-07-26 09:41:41][C-00000301][1564126901-1710] date_finish => 2019-07-26T10:41:41+03:00
[2019-07-26 09:41:41][C-00000301][1564126901-1710][To Bitrix24][-End-]
[2019-07-26 09:41:41][C-00000301][1564126901-1884][To Bitrix24][14.0.0.7][-Begin-]
[2019-07-26 09:41:41][C-00000301][1564126901-1884] Response => telephony.externalcall.finish
[2019-07-26 09:41:41][C-00000301][1564126901-1884] CALL_ID => externalCall.8287e7446468039616562ed2ec8afd3d.1564126889
[2019-07-26 09:41:41][C-00000301][1564126901-1884] EXTERNAL_CALL_ID =>
[2019-07-26 09:41:41][C-00000301][1564126901-1884] PORTAL_USER_ID => 1
[2019-07-26 09:41:41][C-00000301][1564126901-1884] PHONE_NUMBER => 783568
[2019-07-26 09:41:41][C-00000301][1564126901-1884] PORTAL_NUMBER => REST_APP:6
[2019-07-26 09:41:41][C-00000301][1564126901-1884] INCOMING => 1
[2019-07-26 09:41:41][C-00000301][1564126901-1884] CALL_DURATION => 0
[2019-07-26 09:41:41][C-00000301][1564126901-1884] CALL_STATUS => 0
[2019-07-26 09:41:41][C-00000301][1564126901-1884] CALL_VOTE => 0
[2019-07-26 09:41:41][C-00000301][1564126901-1884] COST => 0
[2019-07-26 09:41:41][C-00000301][1564126901-1884] COST_CURRENCY =>
[2019-07-26 09:41:41][C-00000301][1564126901-1884] CALL_FAILED_CODE => 603-S
[2019-07-26 09:41:41][C-00000301][1564126901-1884] CALL_FAILED_REASON =>
[2019-07-26 09:41:41][C-00000301][1564126901-1884] REST_APP_ID => 6
[2019-07-26 09:41:41][C-00000301][1564126901-1884] REST_APP_NAME => Asterisk Integration
[2019-07-26 09:41:41][C-00000301][1564126901-1884] CRM_ACTIVITY_ID => 25860
[2019-07-26 09:41:41][C-00000301][1564126901-1884] COMMENT =>
[2019-07-26 09:41:41][C-00000301][1564126901-1884] CRM_ENTITY_TYPE => LEAD
[2019-07-26 09:41:41][C-00000301][1564126901-1884] CRM_ENTITY_ID => 122
[2019-07-26 09:41:41][C-00000301][1564126901-1884] ID => 1812
[2019-07-26 09:41:41][C-00000301][1564126901-1884] start => 1564126901.6384
[2019-07-26 09:41:41][C-00000301][1564126901-1884] finish => 1564126901.9773
[2019-07-26 09:41:41][C-00000301][1564126901-1884] duration => 0.33895206451416
[2019-07-26 09:41:41][C-00000301][1564126901-1884] processing => 0.30484509468079
[2019-07-26 09:41:41][C-00000301][1564126901-1884] date_start => 2019-07-26T10:41:41+03:00
[2019-07-26 09:41:41][C-00000301][1564126901-1884] date_finish => 2019-07-26T10:41:41+03:00
[2019-07-26 09:41:41][C-00000301][1564126901-1884][To Bitrix24][-End-]
[2019-07-26 09:41:42][C-00000301][1564126902-1145][Add recordings][14.0.0.7][-Begin-]
[2019-07-26 09:41:42][C-00000301][1564126902-1145] activity_id => 25846
[2019-07-26 09:41:42][C-00000301][1564126902-1145] file => /var/spool/asterisk/monitor/2019/07/26/
[2019-07-26 09:41:42][C-00000301][1564126902-1145] status => 0
[2019-07-26 09:41:42][C-00000301][1564126902-1145][Add recordings][-End-]

cynjut · July 26, 2019, 1:48pm

I understand completely now. This, then, is not a problem with FreePBX. It’s a problem with Bitrix24. I’m good now - I( use Bitrix24 for similar purposes, and here’s how I solved that.

Here, we use inbound call contexts on the Inbound Route to normalize our numbers so that they are always the same in the face of a myriad of possible formats. There are several examples of these contexts in /etc/asterisk/extensions.conf. Look for “from-pstn-e164-us” to see how we (traditionally, in the NANP) handle these.

There are several reasons to do this, not the least of them being that each provider (and many of us use from than one) will send the data about a call in a different format. The source of the Caller ID information (similarly) could be from multiple sources as well, so normalizing the data into a single format and using that throughout the system is just good database practice.

So, if your CRM system is using Internationalized (E164) numbers, your inbound context needs to convert all of your numbers to that format. From there, you need to manipulate the outbound numbers so they match what your provider is expecting.

The problem, if there is one, is that the phones might balk at the Internationalization. Many phones do not play well with the ‘+’ formats and do not dial them correctly. Cisco phones, for example, do not play well with the “+” format in the Call from History section, and the dial plans in the phones may or may not take this format into consideration.

If it was my installation, I’d start using an “from-pstn-e164-‘yourcountry’” context that strips off everything that makes sure all of the numbers are in a specific format. That format is largely up to you, but it needs to be one your dialers will use and that you have outbound routes set up to handle. After that, go through Bitrix and normalize all of your phone numbers to a strictly numeric format. I’ve never tried to do this (all of my numbers are normalized to NXXNXXXXXX format) but IIRC, there are ways to do that. After that, make sure your Outbound Routes and Trunks manipulate the numbers in such a way that the provider at the other end of the call is happy.

MicF1968 · July 26, 2019, 2:26pm

Hi Dave,

I really appreciate your help.
It’s probably my English, that is the problem

I’ve done all you decribed already.
… and everything is working fine, except outbound calls.

Incomings calls are converted into internation format and bitrix recocgnises the bound customer.
When calling by click2dial from a customers record, it’s working fine.

The only issue is, that when calling manually nobody dials international numbers except calling abroad.
And here comes the problem. The dialed number must be converted into an international format to match.

And that is the whole issue.

Bitrix has an asterisk addin, where you should be able to do this (first post). I’m just not clear about the syntax.

cynjut · July 26, 2019, 3:02pm

Nope - don’t do it that way.

Since Click-to-dial is working, there’s no reason to mess with Bitrix.

So, is the problem that your Bitrix interface isn’t popping the Customer information on outbound manually dialed calls? Or is the problem that the calls do not go through when your people manually dial them?

The answer matters because of what I talked about in my last post. There are several different ways to dial a number in International calling. That makes matching the numbers in Bitrlx a challenge. If all of the numbers in Bitrix are normalized to numbers that can be dialed manually and your Outbound Routes and Trunks know that is how the number is formatted, you can handle that.

On the front-end, the ‘from-pstn-e164-fr’ should be set up to change all of the possible formats to your locally dialed numbers, and the numbers stored in Bitrix should match those.

However, since your system is set up using a format different than what your users are dialing, you are stuck. With SugarCRM (as an example) there are multiple number lookup fields (primary, alternate, fax, cell, and International) that all point to the same number. This way, the disparate numbering schemes are handled through brute force. I’m not sure, but I think that bitrix does allow for something like that as well.

Now, if the problem is that the users are dialing your numbers as ‘8888’ and you want that to send +496218888 to your provider, the Dialed Number Manipulation rules on the outbound route or the trunk (not both, just one) should be configured to do that.

We’ve established that your Dialed Number Manipulation rules are correct, but your CDR is showing that they are not actually getting set according to the rules. I can only think of one reason why that would be happening, and that’s because you aren’t using this trunk for your actual outbound calls. Do you have more than one outbound trunk?

This is perplexing. I need to see a failed call from /var/log/asterisk/full.

MicF1968 · July 26, 2019, 4:15pm

Thanks Dave, we are getting closer

So, is the problem that your Bitrix interface isn’t popping the Customer information on outbound manually dialed calls?

Exactly!
Calls (the voice part) are working all fine no matter if dialed manually or dialed by click2dial.

Incoming calls working all fine and are logged in the customers records.
I got this transformation done in the extensions_custom.conf:

[from-trunk-international]
exten => _X./_ZX.,1,Set(CALLERID(num)=+49621${CALLERID(num)})
exten => _X./_0ZX.,1,Set(CALLERID(num)=+49${CALLERID(num):1})
exten => _X.,n,Goto(from-trunk,${EXTEN},1)
exten => _X.,1,Goto(from-trunk,${EXTEN},1)

Now, if the problem is that the users are dialing your numbers as ‘8888’ and you want that to send +496218888 to your provider, the Dialed Number Manipulation rules on the outbound route or the trunk (not both, just one) should be configured to do that.

I’m fine with, if the number isn’t sent internationalized to the provider, as the call itself is working. I want the internationalized number sent to Bitrix.

But I’m ok with to send the internationalized number to the provider, if it helps.

The reason why I refferred to the Bitrix addin within asterisk is, that it is described to do exactly that.

If I write +49621{$EXTEN} in this field (from screenshot first post), all is correct.
But only, if no other city is called. - obviously

The addin says:

${EXTEN}
modifications of the number that is transferred to Bitrix24. It does not affect the call routing. Modifications are made in the same way as with Asterisk variables.

I would read it as the way to do it and NOT to mess up the call routing.

I need to see a failed call from /var/log/asterisk/full.

There is no failed call.
Calls are going all OK.

Asterisk is working phenomenally fine.

Mic

MicF1968 · July 29, 2019, 10:50am

Any further ideas?

cynjut · July 29, 2019, 1:23pm

That’s why I was saying “you shouldn’t mess with Bitrix”. Since the only thing that isn’t working is local calling matching your Bitrix records, you’re kind of stuck. In order to match your dialed numbers, you’ll need to make sure that ALL of the numbers in Bitrix match your example. This means all - not local, or semi-local.

At this point, I doubt there’s much more you can do. Unless you’ve got another number in the Bitrix system you can match against and put local numbers in there, I think you’re stuck.