Summary:	ASTERISK-23397: AMI Park when not specifying TimeoutChannel causes announcement and call back to channel specified in Channel argument
Reporter:	Denis (den159)	Labels:
Date Opened:	2014-02-28 09:54:41.000-0600	Date Closed:	2014-05-02 11:10:30
Priority:	Minor	Regression?
Status:	Closed/Complete	Components:	Features/Parking
Versions:	12.0.0 12.1.0	Frequency of Occurrence
Related Issues:
Environment:		Attachments:	( 0) call_101_102_cel.xls ( 1) call_101_102_cli_messages.txt ( 2) call_101_102_events.txt ( 3) debug ( 4) t_conf.xls ( 5) t_extensions.xls ( 6) t_sippeus.xls
Description:	I`ve seen fixed issue with this header on ASTERISK-15127, but absolutely the same bug in 12.1.0-rc1 release. MOH and parkslot number announcment goes to one channel.
Comments:	By: Rusty Newton (rnewton) 2014-02-28 10:26:24.222-0600 Thank you for taking the time to report this bug and helping to make Asterisk better. Unfortunately, we cannot work on this bug because your description did not include enough information. You may find it helpful to read the Asterisk Issue Guidelines http://www.asterisk.org/developers/bug-guidelines. We would be grateful if you would then provide a more complete description of the problem. At a minimum, we need: 1. the specific steps or actions you took that caused you to encounter the problem, 2. the behavior you expected, and 3. the behavior you actually encountered (in as much detail as possible). This likely includes output from the console with debug level logging, a SIP trace (if this is SIP related), and configuration information such as dialplan (e.g. extensions.conf) and channel configuration (e.g. sip.conf). Thanks! By: Rusty Newton (rnewton) 2014-02-28 10:28:54.447-0600 Also helpful:  https://wiki.asterisk.org/wiki/display/AST/Collecting+Debug+Information By: Denis (den159) 2014-02-28 12:19:21.246-0600 I`ve attached 6 files with detailed information. t_conf.xls - sip and other configurations in realtime table t_extensions.xls - actual dialplan in realtime table t_sippeus.xls - sip users and friends in realtime table, in this table users 101 and 102 who will participate in the test call call_101_102_cel.xls - test call CEL messages call_101_102_cli_messages.txt - test call CLI messages call_101_102_events.txt - test call events So to get detailed info I`ve made test call between sip peers 101 and 102, 101 call to 102 and 102 answered him, then 101 tried to park his callee using AMI action Park: Action: Park Channel: SIP/102-00000003 parking executed, but 101 had not heard number to call parked callee back. Behavior i expected: parkslot number announcment sounds to 101, MOH sounds to 102, 101 hangups Behavior i actually encountered: parkslot number announcment and MOH sounds to 102, 101 have heard nothing, 101 hangups By: Denis (den159) 2014-03-01 02:53:23.148-0600 Sorry I forgot to attach debug file, now it is attached By: Rusty Newton (rnewton) 2014-03-27 16:17:49.017-0500 So, because you referenced a bug with behavior in an older version of Asterisk,  a little comparison of behavior between the AMI Park commands in Asterisk 11 and Asterisk 12 may be due. This is only specifying the Channel, Channel2 and TimeoutChannel arguments and avoiding specifying anymore to avoid too many permutations. First, it is helpful to know that the argument Channel2 was changed to TimeoutChannel between Asterisk 11 and 12. From the CHANGES file in 12: {noformat} * The AMI command 'Park' field 'Channel2' has been deprecated and replaced   with 'TimeoutChannel'. If both 'Channel2' and 'TimeoutChannel' are   specified, 'TimeoutChannel' will be used. The field 'TimeoutChannel' is no   longer a required argument. {noformat} h3. Asterisk 11 * Attempting parking with only *Channel* reports back an error that *Channel2* was not specified * Parking with *Channel* and *Channel2* specified results in ** *Channel* being parked and hearing MOH ** At the same time the specified *Channel2* ends abruptly and eventually gets the call back , neither receives an announcement of parking slot h3. Asterisk 12 * Parking with only *Channel* and no *TimeoutChannel* results in: ** The *Channel* specified getting  parked, plus the slot announcement and MOH, as well as eventually the call back. * parking with *Channel* and *TimeoutChannel* specified results in ** The *Channel* specified getting parked and MOH ** and the *TimeoutChannel* specified ending abruptly, then eventually getting the call back, but neither gets a slot announcement With both Asterisk 11 and 12, you are specifying a *Channel* to be parked, and a channel to receive the call back upon timeout (*Channel2*/*TimeoutChannel*). Additional arguments allow you to specify the *Timeout* and the *Parkinglot*. bq. Behavior i expected: parkslot number announcment sounds to 101, MOH sounds to 102, 101 hangups Knowing what I described above, I wouldn't expect either channel specified to receive an announcement of parking slot, as really there is no channel parking the call, you are initiating the call parking via AMI. You might ask, why wouldn't the Channel2/TimeoutChannel receive the announcement? Well, there is no guarantee that channel is even connected to the Channel being parked, or any guarantee that they are not on the phone already. That being said, the documentation for the Park command in both 11 and 12 could be made clearer to set expectations for someone using it. Additionally I think that a behavior here is that is not described in documentation and is unexpected is that in 12 we do play the announcement of parking slot to the *Channel* being parked. However there were a lot of changes to parking in 12 and maybe this is the desired outcome? I'll check with the developers that worked on those recent changes to figure it out. By: Rusty Newton (rnewton) 2014-03-27 18:07:12.486-0500 Talked with Jonathan Rose and Matt Jordan. It was decided that * The fact that when *Channel* is specified but not *TimeoutChannel* the Parker Dial String(as shown in "parking show default") gets set to the *Channel*  parked is likely a bug or at least behavior that really should be changed. If *TimeoutChannel* is not specified, then the user likely does not want anything to be dialed upon a timeout. * Where should the channel announcement go? Right now it is only sent anywhere when you specify a *Channel* with no *TimeoutChannel*, and in that case is sent to the *Channel*. That doesn't make a whole lot of sense - what is the person being parked going to do with information? Unless they are the ones parking themself and need to communicate it to someone, which may not be a common scenario. Instead it would be nice to provide a third option, something like *AnnounceChannel* to allow the user to configure where they want the announcement to be sent. * Documentation - we need to make the documentation for AMI Park in both 11 and 12 as explicit as possible. The description for each should detail the expected call flow as I did above where appropriate and taking into consideration any new behavior from the fix and modification. By: Jonathan Rose (jrose) 2014-04-09 14:08:28.991-0500 I've also been doing some comparison between the 1.8-11 behaviors of parking against 12's. For the most part, it's behaving as I would expect.  The only real discrepency is that as Rusty noted, in Asterisk 12 the Parked channel in a manager park action gets an announcement.  It shouldn't and I'll fix that. With regard to the channel attempting to dial itself... this isn't really a bug or a change from 11.  There is no way to test the equivalent manager action of a channel being parked without a timeout channel against versions prior to 12. What can be said about this though is that this is the same behavior as what happens when a channel parks itself using the park extension (700@parkedcalls by default). It might be more ideal to say that this channel was parked by no channel rather than itself, but to implement such a behavior would require a significant amount to change parking so that a call can be parked without having a channel that was responsible for parking it. I'd be very loathe to try and eliminate that requirement on account of possible ripple effects that extend to Stasis and timeouts. It's probably possible to just deal with the timeout dial while still having the channel be considered as its own parker though. Right now, in keeping with the historical behavior (or at least the historical behavior since r334840 was pushed back in 2011), AnnounceChannel would be more of a new feature request. Really, it's hard to say how such a thing would even work since playing audio to an active channel is something that may or may not be possible at any given time.  It was pulled from 1.8 because the method used at the time was causing crashes that would have been quite difficult to mitigate. What we could do is something similar to how the park and announce application handles announcements... instead of having a channel that you announce to, you could specify a dial string to announce to, and if that dial string is successfully dialed then the announcement is made. By: Jonathan Rose (jrose) 2014-04-14 17:36:09.623-0500 AnnounceChannel ended up becoming a thing after all.  There is currently a patch that deals with all the announcement behaviors on reviewboard. By: Denis (den159) 2014-05-16 04:14:48.383-0500 Can you say in which release this function will be implemented? i tried in 12.2.0 it still dont works.