[asterisk-bugs] [JIRA] (ASTERISK-30476) Hangup Cause is not passed in ChannelHanguprequest

[Karl Gaize (JIRA)]

     [ https://issues.asterisk.org/jira/browse/ASTERISK-30476?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Karl Gaize updated ASTERISK-30476:
----------------------------------

    Description: 
We are using Asterisk in two ways, as an internal call management API, and as an external facing routing mechansim. We initiate an outbound call using ARI (on the internal asterisk) which prefixes the dialled number with some routing codes and calls the "border" asterisk. the "border" asterisk then interprets the routing codes and places a new call on the correct outbound trunk, then connects up the call from the "internal" asterisk to the new outbound call.
When one of these calls is hung up, or rejected, the "border" asterisk correctly gets the hangup cause, and sends it via SIP packets to the "internal" asterisk along with the hangup.
When the "internal" asterisk receives the hangup request, it should generate a "channelHangupRequest" event to the ARI application controlling the call, however, the "cause" value is omitted from this event.
Inspecting the "chan_pjsip_session_end" function in chan_pjsip, we find that the hangup cause is only to be added to the outgoing event, if the "ast_channel_hangupcause" returns zero.
in all cases where a valid cause was returned from the "border" asterisk, the hangup cause was communicated from the border to the internal asterisk, "ast_channel_hangupcause" returned NON-ZERO, and the cause was NOT added to the event data.

we could see no other option than to modify "chan_pjsip_session_end" to allow it to put the cause value in the event data, if cause data was found.

modified code to handle this scenario can be produced if required, but what we're really after is a definitive declaration of whether this functionality is considered to be a bug, or by design.


  was:
We are using Asterisk in two ways, as an internal call management API, and as an external facing routing mechansim. We initiate an outbound call using ARI (on the internal asterisk) which prefixes the dialled number with some routing codes and calls the "border" asterisk. the "border" asterisk then interprets the routing codes and places a new call on the correct outbound trunk, then connects up the call from the "internal" asterisk to the new outbound call.
When one of these calls is hung up, or rejected, the "border" asterisk correctly gets the hangup cause, and sends it via SIP packets to the "internal" asterisk along with the hangup.
When the "internal" asterisk receives the hangup request, it should generate a "channelHangupRequest" event to the ARI application controlling the call, however, the "cause" value is omitted from this event.
Inspecting the "chan_pjsip_session_end" function in chan_pjsip, we find that the hangup cause is only to be added to the outgoing event, if the "ast_channel_hangupcause" returns zero.
in all cases where a valid cause was returned from the "border" asterisk, the hangup cause was communicated, "ast_channel_hangupcause" returned NON-ZERO, and the cause was NOT added to the event data.

we could see no other option than to modify "chan_pjsip_session_end" to allow it to put the cause value in the event data, if cause data was found.

modified code to handle this scenario can be produced if required, but what we're really after is a definitive declaration of whether this functionality is considered to be a bug, or by design.



> Hangup Cause is not passed in ChannelHanguprequest
> --------------------------------------------------
>
>                 Key: ASTERISK-30476
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-30476
>             Project: Asterisk
>          Issue Type: Bug
>      Security Level: None
>          Components: Channels/chan_pjsip
>    Affects Versions: 18.11.2
>         Environment: debian / centos 7
>            Reporter: Karl Gaize
>
> We are using Asterisk in two ways, as an internal call management API, and as an external facing routing mechansim. We initiate an outbound call using ARI (on the internal asterisk) which prefixes the dialled number with some routing codes and calls the "border" asterisk. the "border" asterisk then interprets the routing codes and places a new call on the correct outbound trunk, then connects up the call from the "internal" asterisk to the new outbound call.
> When one of these calls is hung up, or rejected, the "border" asterisk correctly gets the hangup cause, and sends it via SIP packets to the "internal" asterisk along with the hangup.
> When the "internal" asterisk receives the hangup request, it should generate a "channelHangupRequest" event to the ARI application controlling the call, however, the "cause" value is omitted from this event.
> Inspecting the "chan_pjsip_session_end" function in chan_pjsip, we find that the hangup cause is only to be added to the outgoing event, if the "ast_channel_hangupcause" returns zero.
> in all cases where a valid cause was returned from the "border" asterisk, the hangup cause was communicated from the border to the internal asterisk, "ast_channel_hangupcause" returned NON-ZERO, and the cause was NOT added to the event data.
> we could see no other option than to modify "chan_pjsip_session_end" to allow it to put the cause value in the event data, if cause data was found.
> modified code to handle this scenario can be produced if required, but what we're really after is a definitive declaration of whether this functionality is considered to be a bug, or by design.



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