Summary:	ASTERISK-04537: [request] RDNIS not working properly - Reports LAST redirect instead of the ORIGINAL redirect
Reporter:	tracy ing (usatracy)	Labels:
Date Opened:	2005-07-08 03:30:09	Date Closed:	2011-06-07 14:03:01
Priority:	Major	Regression?	No
Status:	Closed/Complete	Components:	Core/General
Versions:		Frequency of Occurrence
Related Issues:
Environment:		Attachments:
Description:	RDNIS should ALWAYS report the ORIGINALLY Redirected DNIS and NOT the LAST Redirected DNIS. It makes no sense for someone to want to know the LAST redirect, we need to know to WHOM the calling party was trying to call, not the LAST redirect in a long chain of redirects. Example Caller calls 703 555 1111 that number is busy forwarded to a cell phone at 703 555 2222 The cell is busy call forwarded to a home phone at 703 555 3333 The home number is busy call forwarded to another cell at 703 555 4444 Assuming all but the last cell is busy, the Asterisk RDNIS reports 703 555 3333 as the RDNIS, it SHOULD report the ORIGINAL RDNIS which was 703 555 1111, that after all is what the caller was trying to call and is the ONLY non-variable we would know about consistenly. The redirection header will continue to populate with a chain of redirects with the newest on the left side, Asterisk should always get the RDNIS from the FAR RIGHT side of the diversion header, otherwise, errors in call processing will occur. Here is a real example of how this BUG is creating a problem. Broadvoice SIP trunks 703 555 1111 belongs to user 1 (they busy call forward to 703 666 1111) 703 555 2222 belongs to user 2 (they busy call forward to 703 666 1111) 703 666 1111 busy call forwards to 2222, which bcf to 3333, and so on to 9999 So these are 9 lines in hunt User 1 and User 2 busy call forward there lines (555 1111 and 555 2222) to the pilot hunt number 703 666 1111 RDNIS should allow routing of the 555 1111 and 555 2222 calls up the hunt chain and to the CORRECT extension in asterisk. But it does not. It will work for the FIRST RDNIS call, only because it is the leftmost diversion header data, but subsequent calls will not route properly because the diversion header is being interpreted incorrectly, a third call will report 703 666 1111. Since that number is being used as a shared hunt chain, and the caller actually dialed 703 555 1111 or 2222, we no longer know who the call was for because RDNIS is not telling us who they dialed, but what the LAST diversion number was. This makes no sense in ANY implementation, why I would want to know the RDNIS diversion of the number 65'th number in a long chain of diversions is not logical, the only logical non-variable data one can use the RDNIS for is the ORIGINALLY DIALED NUMBER which is the FIRST diversion header which is always pushed out to the RIGHT of the diversion header as diversion events increase.
Comments:	By: Michael Jerris (mikej) 2005-07-08 09:19:07 Can you provide a patch to correct this issue? By: Brian West (bkw918) 2005-07-08 09:56:58 No it should always provide the last redirect. /b By: Michael Jerris (mikej) 2005-07-08 16:29:18 Isn't the original calling number called somthing else?  Can we have both? By: Joe Antkowiak (antkojm1) 2005-07-08 17:21:24 The behaviour really *should* be the last redirect.  What if a cell phone forwards to a home phone that forwards to a home phone voicemail.  If we changed this, the home phone voicemail system would get an rdnis for the cell phone, and that just won't work. I think this should be a feature request, if you want to see the rdnis chain By: Michael Jerris (mikej) 2005-07-12 16:32:46 This is being marked as a feature request based upon feedback.  If anyone would like to create a patch for this it will need to be against head, and configurable (or a second variable) defaulting to the current behavior.  The best way to get an issue such as this fixed is to post a bounty on the wiki or contract the work to get done if you are unable to do it yourself. By: Kevin P. Fleming (kpfleming) 2005-07-12 18:26:26 Bug marshals: let's please try to get these incorrectly-categorized bugs recategorized as soon as possible... this one had been SIP/Code formatting for over four days :-( By: Michael Jerris (mikej) 2005-07-20 18:44:49 bug suspended due to lack of response.  As this seems to be in disagreement about how the behavior should be, we should put it in a seperate variable so that both behaviors are doable.  Feel free to reopen this bug when there is a patch ready to be reviewed.  If you are unable to create a patch, the best thing to do would be to create a bounty for this on the wiki or to contract for this code to be written.  Thanks for the report.