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

Corey Farrell (JIRA) noreply at issues.asterisk.org
Mon Jun 1 03:04:33 CDT 2015


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

Corey Farrell commented on ASTERISK-25078:
------------------------------------------

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.

> 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)



More information about the asterisk-bugs mailing list