[asterisk-bugs] [JIRA] (ASTERISK-25078) sig_pri: Publish progress codes.

[Richard Mudgett (JIRA)]

    [ https://issues.asterisk.org/jira/browse/ASTERISK-25078?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=226412#comment-226412 ] 

Richard Mudgett commented on ASTERISK-25078:
--------------------------------------------

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.

> sig_pri: Publish progress codes.
> --------------------------------
>
>                 Key: ASTERISK-25078
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-25078
>             Project: Asterisk
>          Issue Type: Bug
>      Security Level: None
>          Components: Channels/chan_dahdi
>    Affects Versions: SVN, 11.17.1, 13.3.2
>            Reporter: Corey Farrell
>            Assignee: Rusty Newton
>            Severity: Minor
>         Attachments: chan_dahdi.conf, pridebug.txt
>
>
> 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?



--
This message was sent by Atlassian JIRA
(v6.2#6252)