Caller ID lookup and phonebook entries

Hi,

I have an issue using the phonebook and (internal source) caller ID lookup.
The CDR shows the caller ID in international format (eg +31phonenumber).
So does the cli. So all number are using the countrycode for caller id.

The phonebook entries are not allowed to have a leading +, so there never is a match to a phonebook entry.

Is there a fix to allow the + char in the phonebook entry or any other solutions (maybe lookup can skip the first char).
Or am i doing something wrong (could well be as with dozens of asterisk setups i never used the phonebook).

any help/solution much appriciated.

EDIT: I know i can edit the configs and have it remove/replace the leading +.
But i’d rather keep it there as every other system used here is using the + sign in the phone number.
The CMS that provides the contacts to be imported into the phonebook uses it and also exports to csv that way. And every other system, phone (cell), fax etc uses the + in front of the phone number.
And if possible i prefer to change one system (asterisk in this case) then a dozen others.

Regards,
Jeroen

Set your trunk to go to context from-pstn-e164-us:

;-------------------------------------------------------------------------------
; from-pstn-e164-us:
;
; The context is designed for providers who send calls in e164 format and is
; biased towards NPA calls, callerid and dialing rules. It will do the following:
;
;  DIDs in an NPA e164 format of +1NXXNXXXXXX will be converted to 10 digit DIDs
;
;  DIDs in any other format will be delivered as they are, including e164 non NPA
;  DIDs which means they will need the full format including the + in the inbound
;  route.
;
;  CallerID(number) presented in e164 NPA format will be trimmed to a 10 digit CID
;
;  CallerID(number) presented in e164 non-NPA (country code other than 1) will be
;  reformated from: +<CountryCode><Number> to 011<CountryCode><Number>
;

thnx for that solution.

As we don’t have country code 1 over here … we get an caller ID of 01131xxxxxxxxxx
So that’s not usuable either.
Just need 0031xxxxxx or 31xxxxxxxx

So i think i’ll just have to create the conversion rule myself.