Summary:	ASTERISK-23090: chan_sip fails to transmit BYE request to WebSocket connected peer after a failed attended transfer
Reporter:	Giovanni Bezicheri (gbezicheri)	Labels:
Date Opened:	2014-01-03 04:09:05.000-0600	Date Closed:	2018-01-02 08:30:34.000-0600
Priority:	Major	Regression?
Status:	Closed/Complete	Components:	Channels/chan_sip/WebSocket
Versions:	11.5.0	Frequency of Occurrence	Constant
Related Issues:
Environment:	Linux	Attachments:	( 0) issue_23090_full_log
Description:	This bug involves the SRTP module (websocket with port 8088). The scenario is the following: A (normal phone), B (sipml), C (normal phone). A calls to B, B answers and a conversation is correctly estabilished between A and B. B does an attended transfer to C, C answers and hangs up. The conversation between A and B goes on. A hangs up but B does not receive the hangup event via websocket from asterisk, so it still remains in busy state. In the same scenario but without the transfer the hangup of A causes correctly the hangup of B (with the right communication via websocket). Moreover the hangup event is sent from asterisk to the standard SIP port (5060) but not via websocket.. this odd behaviour make me think about an Asterisk bug.
Comments:	By: Matt Jordan (mjordan) 2014-01-03 10:58:43.439-0600 We require a complete debug log to help triage the issue. This document will provide instructions on how to collect debugging logs from an Asterisk machine for the purpose of helping bug marshals troubleshoot an issue: https://wiki.asterisk.org/wiki/display/AST/Collecting+Debug+Information By: Giovanni Bezicheri (gbezicheri) 2014-01-07 08:18:38.137-0600 I attached the full log of the operations involving this issue. Referring to the description of the issue, in the log case A is 303, B is 202 and C is 203. By: Matt Jordan (mjordan) 2014-01-30 10:52:24.898-0600 It does look like we are hanging up the channel coresponding with the WebRTC peer, but are not transmitting a BYE request for some reason. The place where this occurs within the log is here: {noformat} [2014-01-07 15:11:15] DEBUG[11238][C-0000000b] channel.c: Hanging up channel 'SIP/303-00000018' [2014-01-07 15:11:15] DEBUG[11238][C-0000000b] chan_sip.c: Hangup call SIP/303-00000018, SIP callid 1548218469@192.168.5.188 [2014-01-07 15:11:15] DEBUG[11238][C-0000000b] chan_sip.c: update_call_counter(303) - decrement call limit counter on hangup [2014-01-07 15:11:15] DEBUG[11238][C-0000000b] chan_sip.c: Updating call counter for incoming call [2014-01-07 15:11:15] DEBUG[11238][C-0000000b] chan_sip.c: Call from peer '303' removed from call limit 2147483647 [2014-01-07 15:11:15] DEBUG[11238][C-0000000b] res_rtp_asterisk.c: Setting RTCP address on RTP instance '0xb4e35ef4' [2014-01-07 15:11:15] DEBUG[6148] devicestate.c: No provider found, checking channel drivers for SIP - 303 [2014-01-07 15:11:15] DEBUG[6148] chan_sip.c: Checking device state for peer 303 [2014-01-07 15:11:15] DEBUG[6148] devicestate.c: Changing state for SIP/303 - state 1 (Not in use) [2014-01-07 15:11:15] DEBUG[6148] devicestate.c: device 'SIP/303' state '1' [2014-01-07 15:11:15] DEBUG[6148] devicestate.c: No provider found, checking channel drivers for SIP - 303 [2014-01-07 15:11:15] DEBUG[11182] manager.c: Examining event: Event: Hangup Privilege: call,all Channel: SIP/303-00000018 Uniqueid: 1389103841.28 CallerIDNum: 303 CallerIDName: cristian cordless ConnectedLineNum: 202 ConnectedLineName: cristian po AccountCode: 303 Cause: 16 Cause-txt: Normal Clearing {noformat} I would expect to see a BYE transmission around this point, but one does not occur. By: Joshua C. Colp (jcolp) 2017-12-18 11:11:55.305-0600 Have you had this occur in recent versions of Asterisk? By: Asterisk Team (asteriskteam) 2018-01-02 08:30:34.710-0600 Suspended due to lack of activity. This issue will be automatically re-opened if the reporter posts a comment. If you are not the reporter and would like this re-opened please create a new issue instead. If the new issue is related to this one a link will be created during the triage process. Further information on issue tracker usage can be found in the Asterisk Issue Guidlines [1]. [1] https://wiki.asterisk.org/wiki/display/AST/Asterisk+Issue+Guidelines