Summary:	ASTERISK-03445: Forwarding unscreened CLIP and network provided CLIP to the dailplan
Reporter:	Frank Sautter (xylome)	Labels:
Date Opened:	2005-02-07 10:59:11.000-0600	Date Closed:	2005-06-22 06:53:37
Priority:	Minor	Regression?	No
Status:	Closed/Complete	Components:	Core/General
Versions:		Frequency of Occurrence
Related Issues:
Environment:		Attachments:
Description:	When receiving calls from a PRI which has the feature 'CLIP-no sreen' ${CALLERIDNUM} contains the network provided number and not the unscreened number (latter is the standard behaviour on all other PBXs). To achieve this standard behaviour the first sent CLIP must not be overwritten by the following network provided CLIP). But I think both numbers are of interest. I'd like to discuss how this could be implemented within libpri and chan_zap. I would provide a patch after the is consensus on the way doing it. ****** ADDITIONAL INFORMATION ****** * ETSI EN300 089 / EN 300 092-1 [snip] A special arrangement (CLIP-no screen) may exist with a calling user where verification of the user provided number is not performed. In this case, the type of number must be set by the calling user’s terminal to ”national signifi­cant number” or ”international number”, but the number itself is not controlled by the network, so the contents may not be a national or international number. If the type of number is not set as mentioned above, the number will be discarded and the call will proceed as if no user provided infor­mation was received. If a correct type of number is given, the network will set the screening indicator to ”user provided not screened”. The user provided not screened number will be sent as the first number and will be accompanied in the network by a network provided num­ber ( = the default number of the access). [lines omitted] Possible values: - Both the user provided not screened number and the network provided number are delivered to the called user. (see above concerning the order) - Only the user provided not screened number is delivered to the called user. [snap] * excerp from debug pri [snip] Protocol Discriminator: Q.931 (8)  len=55 Call Ref: len= 2 (reference 4122/0x101A) (Originator) Message type: SETUP (5) [04 03 80 90 a3] Bearer Capability (len= 5) [ Ext: 1  Q.931 Std: 0  Info transfer capability: Speech (0) Ext: 1  Trans mode/rate: 64kbps, circuit-mode (16) Ext: 1  User information layer 1: A-Law (35) [18 03 a9 83 81] Channel ID (len= 5) [ Ext: 1  IntID: Implicit, PRI Spare: 0, Exclusive Dchan: 0 ChanSel: Reserved Ext: 1  Coding: 0   Number Specified   Channel Type: 3 Ext: 1  Channel: 1 ] [6c 0c 21 80 31 37 32 39 38 37 36 35 34 33] Calling Number (len=14) [ Ext: 0  TON: National Number (2)  NPI: ISDN/Telephony Numbering Plan (E.164/E.163) (1) Presentation: Presentation permitted, user number not screened (0) '1729876543' ] [6c 0a 21 83 37 30 33 31 34 35 36 37] Calling Number (len=12) [ Ext: 0  TON: National Number (2)  NPI: ISDN/Telephony Numbering Plan (E.164/E.163) (1) Presentation: Presentation allowed of network provided number (3) '70314567' ] [70 08 c1 31 32 33 34 35 36 37] Called Number (len=10) [ Ext: 1  TON: Subscriber Number (4)  NPI: ISDN/Telephony Numbering Plan (E.164/E.163) (1) '1234567' ] [7d 02 91 81] IE: High-layer Compatibility (len = 4) [snap]
Comments:	By: nick (nick) 2005-02-07 19:24:43.000-0600 OK... just rambling here: It seems like the best thing to do would be to make ${NETWORKCALLERID*} and ${USERCALLERID*} (or something similar) and then have a configuration option to choose which to set ${CALLERID*} to.  Obviously, the default should be to use the network number, in order to maintain backward compatibility. What do you think? Nick By: petersv (petersv) 2005-02-07 20:12:35.000-0600 Then we could also provide NETWORKCIDPRES and USERCIDPRES. The CALLERID should remain whichever is sent, with the current behaviour if both are sent. By: nick (nick) 2005-02-07 20:52:46.000-0600 Yup, that's what I'm saying... By: Frank Sautter (xylome) 2005-02-08 02:30:14.000-0600 i think the ${CALLERID} should be set to the value every other PBX, mobile phone or analog handset shows ... which is the unscreened number ... so in my eyes the behaviour of asterisk should change! By: Paul Cadach (pcadach) 2005-02-09 16:49:47.000-0600 There is possible to modify libpri to use first or last calling number to pass it to higher level (chan_zap). Currently libpri parser have ability to transmit and receive multiple instances of the same IE (Progress Indicator, Calling Number, etc.). By: Mark Spencer (markster) 2005-02-27 18:54:32.000-0600 In this case, it might be worthwhile to load one into "ANI" and the other into "CALLERID" (assuming that the ani trust is there). By: Kevin P. Fleming (kpfleming) 2005-02-28 00:10:35.000-0600 This is beginning to get into a larger discussion that I have had with a few people already... Asterisk's handling of the 'party ID' across the board could use some redesign. Note that in this case, the extra CLIP/CNIP information is _not the ANI, ANI could still be provided separately. Also, whether or not to use this information is a "trust issue"; when dealing with this in chan_sip, Olle and I have been working out a way to define whether the peer at the other end is a network (public) peer, a trunk (private) peer, or an endpoint. CLI/CNI presentation and suppression needs to be handled differently in all those situations, and that may be appropriate for chan_zap as well. By: Matt O'Gorman (mogorman) 2005-03-13 01:43:14.000-0600 Any news on this, being able to easily detect ani versus callerid seems like relevant thing to be patched in, and should be fairly easy to add variable ani. Right? By: Kevin P. Fleming (kpfleming) 2005-03-13 09:48:48.000-0600 No, sorry, there hasn't been any progress on this yet. If someone wants to put together a patch to be able to receive the user-provided CLIP information that would be useful for now... but we will eventually need a more complete (and complex) solution. By: Olle Johansson (oej) 2005-06-05 17:17:38 We've been waiting for a patch a while now. The normal way to handle this is to close the bug report and re-open when we have a patch. Ok? By: Frank Sautter (xylome) 2005-06-06 12:19:22 i still think it's a bug/missfeature that has to be fixed and therefore it should remain as an open bug (or am i wrong that this is a bugtracker and not a patchfileuploadrepository) maybe it should be assigned to libpri (where it belongs to) and not zaptel. By: Michael Jerris (mikej) 2005-06-19 13:52:23 Is this bug supersceded by 4537? By: Frank Sautter (xylome) 2005-06-22 05:58:42 this bug can be closed! it's a duplicate to 4537 (which has been closed) By: Michael Jerris (mikej) 2005-06-22 06:53:10 4537 was just the additions to libpri.  4571 actually pulls the data into asterisk.  That being said, there is now a patch on 4571 to do the same thing that we are looking for in here.  I will close this one out and note 4571 to check the notes on this bug in reference to what the different information should be called.