[asterisk-bugs] [JIRA] Commented: (ASTERISK-20198) Store hangup cause information on the callee channels in addition to the calling channels

Matt Jordan (JIRA) noreply at issues.asterisk.org
Mon Aug 13 10:10:08 CDT 2012


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

Matt Jordan commented on ASTERISK-20198:
----------------------------------------

I think so.  Obviously if the local channel optimizes away, then whatever is the resulting channel should have that information.

If the local channel doesn't optimize away, I'm not sure how its hang up cause is handled.  I'd assume it would have *something*, however.

> Store hangup cause information on the callee channels in addition to the calling channels
> -----------------------------------------------------------------------------------------
>
>                 Key: ASTERISK-20198
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-20198
>             Project: Asterisk
>          Issue Type: Improvement
>      Security Level: None
>          Components: Functions/func_hangupcause
>    Affects Versions: 11
>            Reporter: Matt Jordan
>            Assignee: Kinsey Moore
>
> Currently, hang up cause information is stored on the calling channel.  Hence, in a parallel dial situations, you have to use the HANGUPCAUSE_KEYS function to get the list of channels that have hangup cause information, and then parse that list and look up each individual channel using the HANGUPCAUSE function.
> This is perfectly valid and acceptable.
> On the other hand, pre-dial and hangup handlers potentially make this situation much easier.  If the hangup cause information was stored on the callee channels in addition to the calling channel, then a hangup handler could be attached to each callee channel and the information queried there.
> {noformat}
> [default]
> exten => borked,1,NoOp()
> same => n,Dial(SIP/foo&SIP/bar,10,b(default^set_handler^1))
> same => n,Hangup()
> exten => set_handler,1,NoOp()
> same => n,Set(CHANNEL(hangup_handler_push)=default,outbound_handler,1)
> same => n,Return()
> exten => outbound_handler,1,NoOp()
> ; This will get run for both SIP/foo and SIP/bar when each of them
> ; is hung up.  Ideally, we'd be able to get our own information out
> ; of HANGUPCAUSE_KEYS... but sadly, no bueno
> same => n,Set(HANGUPCAUSE_STRING=${HANGUPCAUSE_KEYS()})
> ; HANGUPCAUSE_STRING is an empty string :-(
> same => n,Return()
> {noformat}

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira



More information about the asterisk-bugs mailing list