Summary:	ASTERISK-01035: Caller ID info does not distinguish between international and national
Reporter:	timrobinson (timrobinson)	Labels:
Date Opened:	2004-02-16 10:24:10.000-0600	Date Closed:	2011-06-07 14:05:21
Priority:	Major	Regression?	No
Status:	Closed/Complete	Components:	Core/General
Versions:		Frequency of Occurrence
Related Issues:
Environment:		Attachments:	( 0) dutch_CLI.txt ( 1) q931.c.diff ( 2) UK_caller_ID.txt
Description:	Inbound caller ID here in the UK is presented without the dial prefix.  e.g. '1256790472' flagged as 'National Numbering'. International calls are reported as '31592015887' with the number flagged as 'International Number'. Ideally we should have a couple of settings in zaptel.conf or zapata.conf as per below ****** ADDITIONAL INFORMATION ****** nationalcalleridprefix = 0 internationalcalleridprefix = 00
Comments:	By: timrobinson (timrobinson) 2004-02-16 10:36:17.000-0600 temporary fix for UK will be attached to this file. Needs internationalising as per additional config parameters above. By: timrobinson (timrobinson) 2004-02-16 11:08:01.000-0600 q931.c.diff contains hard-coded fixes that are applicable to the UK implementation with the E100 PRI card. this gives examples of how we want it to work.  There should probably a more generic fix that includes more options, with config set in zapata or a special callerid.conf file :-) By: Paul Cadach (pcadach) 2004-02-25 01:00:46.000-0600 May be just to add '+' sign before CID for international calls? At least this will try to follow ITU's conventions about phone numbers representaion (like +<country code> <zone code> <phone number>). By: zoa (zoa) 2004-02-25 03:58:06.000-0600 PCadach: thats a bad solution. If i use 32486103235 as caller id, and i call my cell phone, it will show up as +32486103235 By: zoa (zoa) 2004-02-25 04:05:58.000-0600 Could you give a bit more info on exactly what your problem with the current implementation is ? I just enter an international format when i want international format and national when i want a national caller id. Don't see any problem with that ? Or is it for the caller ID when doing native zap bridging ? By: Paul Cadach (pcadach) 2004-02-25 04:40:10.000-0600 Regular convention (at least for cellular networks) is to provide universal dialing rules independedly on country's rules where phone owner located. For example, '+' sign treaded as "international dialling prefix", i.e. "00" for UK, "8-10" for Kazakhstan and Russia, etc. Also, now I've gets all calling numbers to my cell phone at international format, with leading '+' sign followed by country code (for example, +73272588255, where +7 is the country code, 327 is zonal code for Almaty's region, 2 is code/filler for Almaty city because it uses 6-digit numbering plan and 588255 is Almaty's phone number). When I dials from my cell phone any number started with '+', GSM operator translates this number to local presentation, i.e. if I dials +7-xxx-xxxxxxx, then operator really dials to public network with 8-xxx-xxxxxxx (where 8 is "long-distance prefix" for Kazakhstan), but if I dials, for example, +1-xxx-xxxxxxx, then GSM operator dials with 8-10-1-xxx-xxxxxxx (8-10 is "international prefix", and 1 is USA/Canada country code). Better you could have a configuration option with your country code, zone code, long-distance prefix and international prefix for each span/group, so Asterisk/Zaptel could treat dialing/incoming number with right way (i.e. convert incoming number to international format and strip country code/zone code at outgoing calls if required). Also, your PSTN operator should translate numbers with such rules, so if you dials 32-486103235 (this is Belgium, if believe to E.164)and specifies that this number is international, than PSTN should treat this situation like you dialled 00-32-486103235 (i.e. international call), but if you dials 125-6790472 and specifies that this number is national, that PSTN should mean you skip leading 0 for long-distance calls. But if you dials any number and specifies number type as unspecified or network-level, than you must provide any prefixes required by your PSTN operator. So, as I understand, the problem is to handle phone numbers in Asterisk with it's types, or to convert all numbers to international form and allow channel driver (for example, Zap, or H.323, etc.) to manipulate with those numbers (if such manipulations are required by public network). But best way is to use fully-specified international numbers and allow PSTN to re-write them as required by national standards. By: Paul Cadach (pcadach) 2004-02-25 04:43:04.000-0600 Also, attached patch is just provides national standarded dialing prefixes for long-distance and international numbers, so if you translate all numbers to single form you will not have any problems to distinguish local/long-distance/international calls (just by using standard prefix analisys). By: Paul Cadach (pcadach) 2004-02-25 04:49:06.000-0600 FYI: Cisco uses number translation rules technique which could be used for any direction and call leg. May be this is the solution? By: timrobinson (timrobinson) 2004-02-25 05:01:21.000-0600 PCadach - I think you have the right approach.  My suggestion was to have some parameters in zapata.conf :  e.g. internationalprefix=00 ;or + or 810 (in the case of Khazakstan!) nationalprefix=0       ;or 1 in the case of the US I think this will be the simplest way of overcoming the current problem in the current way.  Using a + or other alphanumeric character in the 'number' field will break other things in Asterisk, like 'say digits' and so on.  This overcomes compatibility issues. We have also added some text fields in the CALLERIDNAME field to say 'WITHHELD' or 'UNAVAILABLE' if the caller ID is not available. If interested I can add this patch to this bug... By: Paul Cadach (pcadach) 2004-02-25 11:24:14.000-0600 As I remember Asterisk have two fields at the channel structure for CID - ANI and callerid. So, if caller ID presentation is blocked by caller, callerid field sets to empty but ANI presents real caller's number. Your sugesstion will block "transparency" of interconnection through asterisk (for example, you want to forward PSTN's caller to another PSTN's number, and want to provide original caller ID, so you must store caller number somewhere, not just replace it with pre-defined phrase). Also, when CID isn't available callerid field (and ANI field too) must be empty. Mark could explain a bit more about callerid, ani, dnis, rdnis fields on channel structure... By: Olle Johansson (oej) 2004-04-10 08:26:20 Where is this bug? Waiting for Mark or something else? By: twisted (twisted) 2004-04-29 09:45:52 Second request for update..  it's been 19 days. By: Mark Spencer (markster) 2004-05-01 23:45:36 I believe this is a feature request, not a bug report. By: Brian West (bkw918) 2004-05-01 23:49:45 Mark, I was thinking that also. bkw By: twisted (twisted) 2004-06-16 23:15:12 Closed due to the fact that this is a feature request and has had no action since 5-01-04.  Also note that this could break 'transparancy' of interconnection through asterisk as PCadach noted.   This can be revisited later if need be.