Summary:	ASTERISK-30476: Hangup Cause is not passed in ChannelHanguprequest
Reporter:	Karl Gaize (karl.gaize@telxl.com)	Labels:
Date Opened:	2023-03-22 07:07:22	Date Closed:	2023-03-22 09:19:16
Priority:	Minor	Regression?
Status:	Closed/Complete	Components:	Channels/chan_pjsip
Versions:	18.11.2	Frequency of Occurrence	Constant
Related Issues:
Environment:	debian / centos 7	Attachments:
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.
Comments:	By: Asterisk Team (asteriskteam) 2023-03-22 07:07:25.181-0500 Thanks for creating a report! The issue has entered the triage process. That means the issue will wait in this status until a Bug Marshal has an opportunity to review the issue. Once the issue has been reviewed you will receive comments regarding the next steps towards resolution. Please note that log messages and other files should not be sent to the Sangoma Asterisk Team unless explicitly asked for. All files should be placed on this issue in a sanitized fashion as needed. A good first step is for you to review the [Asterisk Issue Guidelines|https://wiki.asterisk.org/wiki/display/AST/Asterisk+Issue+Guidelines] if you haven't already. The guidelines detail what is expected from an Asterisk issue report. Then, if you are submitting a patch, please review the [Patch Contribution Process|https://wiki.asterisk.org/wiki/display/AST/Patch+Contribution+Process]. Please note that once your issue enters an open state it has been accepted. As Asterisk is an open source project there is no guarantee or timeframe on when your issue will be looked into. If you need expedient resolution you will need to find and pay a suitable developer. Asking for an update on your issue will not yield any progress on it and will not result in a response. All updates are posted to the issue when they occur. Please note that by submitting data, code, or documentation to Sangoma through JIRA, you accept the Terms of Use present at [https://www.asterisk.org/terms-of-use/|https://www.asterisk.org/terms-of-use/]. By: Joshua C. Colp (jcolp) 2023-03-22 07:16:47.063-0500 The code in question doesn't directly produce events. What I assume you're referring to is events generated as a result of calling ast_queue_hangup_with_cause and ast_queue_hangup. The reason it only sets the hangup cause if the channel doesn't have one is so it doesn't overwrite an existing one. Functionally calling ast_queue_hangup_with_cause with ast_channel_hangupcause(session->channel) in the already set case should be fine. Changing behavior so that it overwrites the hangup cause in all cases would not be fine, as that would be a behavior change. By: Karl Gaize (karl.gaize@telxl.com) 2023-03-22 08:42:51.355-0500 so, I guess what we're talking about here is the difference between a back-to-back system and not. we're using the "internal" asterisk as a back-to-back agent that generates calls that stay completely inside our network, and the "border" asterisks take care of routing outbound and inbound calls based on routing code prefixes and dialplan. when "fixing" this problem, I implemented the chan_pjsip_session_end() function with a slightly deeper logic tree, which allowed me to see which hangup causes were being used is as follows: <inline patch removed> and this works for all cases we've been able to throw at it so far. This change should probably fall foul of the "change in behaviour" that you mentioned as we're definitively updating the hangup cause, but as I'm still using ast_queue_hangup_with_cause I'm not so sure. By: Joshua C. Colp (jcolp) 2023-03-22 08:49:47.582-0500 That is updating the hangup cause and overwriting an existing one, so I believe it would run foul of the change in behavior. The cases that you would break I'm not certain of. Examining the history of things may shed light on it, or it's old enough that it was done that way just because in which case lots of testing would need to be done in various scenarios if they don't already exist to verify such a change. By: Joshua C. Colp (jcolp) 2023-03-22 08:52:41.200-0500 I have also removed your inline patch. Patches should be attached with a signed contributor license agreement. By: Karl Gaize (karl.gaize@telxl.com) 2023-03-22 09:11:28.990-0500 ok, given your comments then, I think that even if this was submitted as an official patch, it wouldn't be accepted as it would change the stated behaviour (without implementing config/compile time switches). We will have to keep this change separate and re-apply it in future versions when we find we need it. By: Joshua C. Colp (jcolp) 2023-03-22 09:19:17.008-0500 Marking as suspended per last comment.