How to Setup up trunkprefix. country code and numberprefix

[wucherpfennig]

Dear all

Thanks again for helping setting things up. We receive calls now in Zammad which is great. There is just one little problem: the phone numbers formatting.

Currently we are using the configuration as follows:

                "countrycode": "41",
                "trunkprefix": "0",
                "numberprefix": ""

which result in nicely formatted Swiss numbers. But since we are receiving a lot of calls from outside Switzerland those numbers look somewhat clunky:

Does anybody have an idea how we should setup the parameters above in order to receive always nicely formatted phone numbers?

BR wucherpfennig

[costela]

Innovaphone's reporting of phone numbers is a bit difficult to predict (I'd gladly be pointed to some docs on their side), so we try some limited heuristics to deduce the "full" (E123) number as expected by Zammad.

These are apparently not enough in your case. If you enable debugging, the logs should show the original number as sent by the PBX. This should help us find the issue with the heuristics.

[costela]

Also: I assume the first "+4141..." is the correct number, not a duplicated country-prefix?

[costela]

Also note: the heuristics we use are very simple and can't deal with all international number formats. There's for instance an issue with Italian phone numbers: 0 XXXX is a valid local Italian number and our heuristics assume any number starting with a 0 is non-local. Is this also the case for Swizerland?

Ideally we'd build this sort of "localized knowledge" into our heuristics, but I don't think we have the manpower to implement a full solution by ourselves and are kinda counting on other users to help us out with this task 😉

[wucherpfennig]

Innovaphone's reporting of phone numbers is a bit difficult to predict (I'd gladly be pointed to some docs on their side), so we try some limited heuristics to deduce the "full" (E123) number as expected by Zammad.

These are apparently not enough in your case. If you enable debugging, the logs should show the original number as sent by the PBX. This should help us find the issue with the heuristics.

debugging in innovazammad? According to the Readme there is only an option for the variables?

Also: I assume the first "+4141..." is the correct number, not a duplicated country-prefix?

Yes, this is actually a swiss number like (+41 41 123 45 67)

Also note: the heuristics we use are very simple and can't deal with all international number formats. There's for instance an issue with Italian phone numbers: 0 XXXX is a valid local Italian number and our heuristics assume any number starting with a 0 is non-local. Is this also the case for Swizerland?

Ideally we'd build this sort of "localized knowledge" into our heuristics, but I don't think we have the manpower to implement a full solution by ourselves and are kinda counting on other users to help us out with this task 😉

Well if we stay with the sample from above a valid swiss local number would look like: 041 123 45 67

Since I am dealing with a similar issue (CRM exports) I would recommend to integrate such a library? https:/ttacon/libphonenumber

Generally I am really happy of your work. If you tell me how to help (like sending you a log) please tell me :-)

[costela]

debugging in innovazammad? According to the Readme there is only an option for the variables?

Starting with --loglevel debug should to the trick.

I would recommend to integrate such a library? https:/ttacon/libphonenumber

We did look into libphonenumber when development started, but AFAIR it wasn't able to help with the main problem: the fact that we sometimes got numbers with a local prefix and a leading zero, sometimes without (multiple?) leading zero(s). All depending on the context, e.g. if a call was being forwarded internally, or maybe to a user-configured external number. And all undocumented.
But maybe it's worth a second look. That would at least support more country formats.

On an unrelated note: are you intentionally not setting numberprefix? If there's any chance your calls might be forwarded internally, this could be necessary to turn your internal extension numbers into E123 and push them to Zammad. Otherwise innovazammad cannot turn an internal extension number (e.g. 567) into its E123 version (e.g. 41 1234 567).

[wucherpfennig]

debugging in innovazammad? According to the Readme there is only an option for the variables?

Starting with --loglevel debug should to the trick.

I will try that the next days and maybe this will clarify things.

I would recommend to integrate such a library? https:/ttacon/libphonenumber

We did look into libphonenumber when development started, but AFAIR it wasn't able to help with the main problem: the fact that we sometimes got numbers with a local prefix and a leading zero, sometimes without (multiple?) leading zero(s). All depending on the context, e.g. if a call was being forwarded internally, or maybe to a user-configured external number. And all undocumented.
But maybe it's worth a second look. That would at least support more country formats.

On an unrelated note: are you intentionally not setting numberprefix? If there's any chance your calls might be forwarded internally, this could be necessary to turn your internal extension numbers into E123 and push them to Zammad. Otherwise innovazammad cannot turn an internal extension number (e.g. 567) into its E123 version (e.g. 41 1234 567).

Honestly I did this because I got "better" results this way.
Additional to tell the truth: I do not understand a lot about pbx at all since an external service setup up the whole installation... But just by digging around I have to second your statement that the documentation is lacking (usually I can read at least).

Our setup is simple I guess: All calls come through into (I guess one trunk) line and then are spread to 2 groups. First group "office", second "ringruf" ;-) (multiply this approach by the N numbers we have). But as you can see in my screenshots below the taking side is always the main number.

I attached you an call log from Zammad maybe this helps:

[wucherpfennig]

Sorry about the delay but the numbers especially the ones from outside switzerland seem to be the problem. Do you have an idea about that?

[costela]

@wucherpfennig I have an idea, but to be sure it would be nice to have the logs collected with --loglevel debug, as mentioned above.

[wucherpfennig]

Dear @costela
Sorry for the delay... I did not send a log file because of some internal hiccups.
Since this log file contains a lot of phone numbers (and therefore might be a potential privacy issue) I would like you to ask for which lines / phrases you are looking for specifically (in order to post a reduced version)?
BR wucherpfenngi

[wucherpfennig]

Bump