Summary:	ASTERISK-25078: sig_pri: Publish progress codes.
Reporter:	Corey Farrell (coreyfarrell)	Labels:
Date Opened:	2015-05-12 02:13:51	Date Closed:	2018-10-16 07:47:34
Priority:	Minor	Regression?
Status:	Closed/Complete	Components:	Channels/chan_dahdi
Versions:	SVN 11.17.1 13.3.2	Frequency of Occurrence
Related Issues:
Environment:		Attachments:	( 0) chan_dahdi.conf ( 1) pridebug.txt
Description:	I'm dealing with a PRI provider who frequently responds to calls with PROGRESS code 127.  These usually timeout, and result in Asterisk reporting NOANSWER.  Over 60% of the NOANSWER calls on one system have progress code 127 (found in logs), so If we have 5000 outbound NOANSWER calls, probably 3000 of them are really 'unknown telco error'. It would be very useful to be able to determine the last progress code received after Dial.  This way if DIALSTATUS is NOANSWER, we can check PRILASTPROGRESS and possibly use it instead of HANGUPCAUSE. Is this something that would be accepted - setting a channel variable from pri_dchannel in sig_pri.c?   It would be done near the code to deal with broken PRI's that send AST_CAUSE_USER_BUSY as progress.  If not is there another work-around that I'm not considering?
Comments:	By: Richard Mudgett (rmudgett) 2015-05-12 11:18:26.352-0500 Please attach a "pri set debug on span x" capture of a call that this happens on.  Also attach chan_dahdi.conf and any included files. By: Corey Farrell (coreyfarrell) 2015-05-27 09:18:02.059-0500 chan_dahdi.conf and log showing pri debug with asterisk debug 6 + verbose 6. When posting chan_dahdi I noticed the 'inband' options.  I would be suspicious of this, but some calls are reporting proper status - a low number of busy and invalid destinations. By: Richard Mudgett (rmudgett) 2015-05-27 16:44:38.723-0500 Cause 127 is a network interworking code that doesn't have a set procedure specifying how it should be used. Unfortunately, your idea of setting a channel variable isn't going to work because it will be set on the wrong channel.  The channel the cause information is available on is the outgoing channel of the Dial when you need that information on the dialing channel.  The HANGUPCAUSE function gets its information from the AST_CONTROL_PVT_CAUSE_CODE frame.  The problem is HANGUPCAUSE only keeps the last value produced by each dialed channel.  You may want to consider a solution based on the AST_CONTROL_PVT_CAUSE_CODE frame such as adding the ability to keep all values from each channel and being able to retrieve specified values. By: Birger "WIMPy" Harzenetter (wimpy) 2015-05-27 17:10:56.741-0500 Just to add the usual obviousness: The Location where the hangup happened would be much more of a necessity. By: Richard Mudgett (rmudgett) 2015-05-27 17:27:41.172-0500 Where the hangup happened for PRI is part of the HANGUPCAUSE(chan,tech) string value returned. PRI PRI_EVENT_PROGRESS (%d) PRI PRI_EVENT_HANGUP (%d) PRI PRI_EVENT_HANGUP_REQ (%d) By: Corey Farrell (coreyfarrell) 2015-06-01 03:04:11.996-0500 I'm not sure how to accomplish this hook into AST_CONTROL_PVT_CAUSE_CODE.  I'll have to look at the HANGUPCAUSE function.  For now I'm thinking of a temporary workaround.  Would it be safe/possible to create a custom AMI event on the outgoing channel: {noformat} Event: PRIProgress Channel: ... UniqueID: ... Code: 127 {noformat} I know this would probably not be accepted to Asterisk but being able to determine when calls had unknown progress then never answered would be very helpful to me.  Once I have that I can look into the ability to accumulate progress codes. By: Richard Mudgett (rmudgett) 2015-06-01 10:03:02.303-0500 I was thinking of extending HANGUPCAUSE to keep all causes reported by a channel in the order that they were reported.  Then you could peruse the cause history as needed.  This would need to adjust how the ast_channel_dialed_causes_xxx() functions operate internally a little bit.  ast_channel_dialed_causes_add() would need to be changed to not remove the previous cause before adding the next cause.  pvt_cause_cmp_fn() should not be using the CMP_STOP flag as it would prevent the use of the OBJ_MULTIPLE flag as below: For existing behavior just get the last cause reported like so: {noformat} ast_channel_dialed_causes_find() {    ao2_iterator causes;    struct ast_control_pvt_cause_code *cause;    struct ast_control_pvt_cause_code *last_cause;    /* Get all causes for the specified channel */    causes = ao2_find(chan->dialed_causes, chan_name, OBJ_KEY | OBJ_MULTIPLE);    last_cause = NULL;    for (; (cause = ao2_iterator_next(&causes)); ao2_cleanup(last_cause), last_cause = cause) {    }    return last_cause; } {noformat} The idea is to take advantage of the hash container's structure.  All objects with the same key get put into the same bucket at the end of the linked list. By: Corey Farrell (coreyfarrell) 2015-06-02 14:53:41.961-0500 This sounds like something that will be master only? By: Richard Mudgett (rmudgett) 2015-06-02 15:12:20.372-0500 It doesn't necessarily have to be master only.  All the infrastructure should be in v11+ to do this.  Should have testsuite tests for func_hangupcause though. By: Corey Farrell (coreyfarrell) 2018-10-16 04:25:22.221-0500 The customer which I opened this bug for is being migrated to a SIP gateway, so I no longer have any interest in this request.  I can leave the bug open if it's of interest to anyone else but I'm fine with this being closed {{Won't Fix}} or {{Suspended}}. By: Richard Mudgett (rmudgett) 2018-10-16 07:47:35.124-0500 Closing as this is more of a feature request without patch and it is no longer needed.