Summary:	ASTERISK-26565: chan_unistim on 11, 13, 14 placing call on hold temporarily locks up set
Reporter:	Ruse (jf-uk)	Labels:
Date Opened:	2016-11-08 04:41:58.000-0600	Date Closed:	2016-11-14 06:38:46.000-0600
Priority:	Major	Regression?
Status:	Closed/Complete	Components:	Channels/chan_unistim
Versions:	11.24.1 13.12.1 14.1.1	Frequency of Occurrence	Constant
Related Issues:	is a clone of ASTERISK-26596 Placing call on hold temporarily locks up set is duplicated by ASTERISK-26588 Unistim Driver Hang
Environment:	Debian Linux x86 Intel, Debian Linux ARMh/ARMl	Attachments:	( 0) ASTERISK-26565-v1.diff
Description:	With a Nortel i2002 (also tested on unknown i2001) places or receives a call, and an audio path is brought up (as in, audio is transmitted and/or received from an application or another channel), eg: a call is established, pressing the hold button properly sets up a bridge of MOH to the other side (they hear music), a caller in this example. At this point, the Nortel set is locked. Icons indicate a call is on hold, but no further buttons effect any function. Looking at debug messages, when the switchhook is pressed, even repeatedly, a message is generated on every press: "WARNING[2075] chan_unistim.c: Close call without sub" Interestingly, when the other end of the call hangs-up, the icon on the Nortel set indicates such, but remains locked. The UDP/RTP ports are still held at this point. But, placing a call to the same locked-up set, from any functioning channel, unlocks the set, and CLID etc are there, and ringing away. Answering the call, (on the Nortel set) it's all back to normal, and after parties hang up, both/all UDP/RTP ports are properly released. (Note: ports being released is dependent on the patch from ASTERISK-26561 which fixed this on 7 November, 2016.) This is repeatable on three Nortel sets, acoss releases.
Comments:	By: Asterisk Team (asteriskteam) 2016-11-08 04:42:00.003-0600 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. 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]. By: Igor Goncharovsky (igorg) 2016-11-11 04:00:42.335-0600 I have attached concept of patch. I am really do not remember why I have such  way of implementing hold feature, but how it should work with at least hold button. If it work for you, it'll be helpful creating list of user stories for using hold/unhold button with pointing desired result of operation. By: Ruse (jf-uk) 2016-11-11 06:59:16.147-0600 I should add I have been applying these to the 11, and 14 strains, but 11 is now so broken, that I think someone should make a decision to either support unistim in 11, or take it out altogether, as it appears it's only supported from 14.1.1 now? warning: implicit declaration of function ‘ast_queue_hold’ -And isn't in main/channel.c   ...ouch. But ooh323 doesn't work with Nortel commercial equipment, whereas the dumped h323 (NuFone) functions perfectly. So.. Drop chan_unistim from 11 and 13? as there's a fork in the road now. Nortel unistim sets and no businss-grade H323, or no Nortel unistim, just sip and others, and functioning H323. I appreciate your work in this, but I'm struggling to keep continuity with the kindly provided patch. ;( Oh what to do. The battle of millions of features that half-work, against fewer which work stably.. Hmnn. By: Joshua C. Colp (jcolp) 2016-11-11 07:09:32.755-0600 The Asterisk 11 branch itself is no longer receiving bug fixes, only security fixes. The only releases from it going forward will be a result of those security fixes. By: Igor Goncharovsky (igorg) 2016-11-11 22:27:55.626-0600 Jason, This patch is made for asterisk 14. When this feature'll ready I can prepare patch that could be applied to asterisk 11. Then you can clone asterisk repository on github and apply any patches needed to 11 branch and have own supported and tested production branch. Also if you have some issues with asterisk chan_ooh323 you can create ticket in Jira and Alexander probable 'll able to help you. By: Mat Jaggard (mjaggard) 2016-11-14 04:37:37.658-0600 Has the patch been accepted into Asterisk 14? If so, which version? By: Joshua C. Colp (jcolp) 2016-11-14 04:58:46.469-0600 When the patch has been merged into the applicable branches this issue will automatically close. It has not yet done so, but will in the next few hours. It will be in the next release of Asterisk. By: Friendly Automation (friendly-automation) 2016-11-14 06:38:47.342-0600 Change 4391 merged by Joshua Colp: Fix closing rtp ports after call finished in chan_unistim. [https://gerrit.asterisk.org/4391|https://gerrit.asterisk.org/4391] By: Mat Jaggard (mjaggard) 2016-11-14 06:42:10.494-0600 I can see that this is merged into master in commit dfb951817f52fa67cda522d957c2db5a09f0ff68 - if I want to try that out do I need to build asterisk myself or is there some automatic build somewhere? By: Igor Goncharovsky (igorg) 2016-11-14 06:46:57.848-0600 Mat, this change is not yet merged to master. Only change, that fix rtp ports assigment is fixed. I'll upload updated patch here. By: Igor Goncharovsky (igorg) 2016-11-14 06:49:03.151-0600 Sorry, but by accident I have missed that wrong Jira issue used in Gerrit. In fact ASTERISK-26561 resolved. By: Friendly Automation (friendly-automation) 2016-11-14 07:35:46.894-0600 Change 4401 merged by Joshua Colp: Fix closing rtp ports after call finished in chan_unistim. [https://gerrit.asterisk.org/4401|https://gerrit.asterisk.org/4401] By: Friendly Automation (friendly-automation) 2016-11-14 08:06:06.508-0600 Change 4402 merged by Joshua Colp: Fix closing rtp ports after call finished in chan_unistim. [https://gerrit.asterisk.org/4402|https://gerrit.asterisk.org/4402] By: Mat Jaggard (mjaggard) 2016-11-15 01:42:01.286-0600 All these patches look like they're fixing ASTERISK-26561 rather than this issue. Is that correct or am I missing something? By: Igor Goncharovsky (igorg) 2016-11-15 02:09:46.825-0600 i have cloned this issue in ASTERISK-26596. this issue closed due to my mistake while creating Gerrit pull request.