[asterisk-users] User expected behavior of musiconhold and AGI's "stream file"

[Joshua Colp]

Leif Madsen wrote:
> On 28/09/12 08:23 AM, Joshua Colp wrote:
>> I am your friendly neighborhood developer here with a question that may
>> impact some of you.
>
> You're friendly? :)

<3

>> Right now there is a small discussion occurring on the Asterisk
>> development mailing list about the expected behavior of music on hold
>> and AGI's "stream file". Presently if you start music on hold and then
>> call "stream file" the music on hold will be *stopped* but not
>> *restarted*.
>>
>> Do you think this behavior is correct?
>
> I guess part of the question is; can you trigger it to be re-enabled
> after the stream file?

Sure you can! You can use set music to start it going again as the next 
command.

>> The proposition on the mailing list is to add yet another knob to allow
>> you to control whether it is restarted or not upon completion of the
>> stream file and to change the default behaviour for Asterisk 12 to have
>> it restart music on hold.
>>
>> I look forward to your responses so you can help with the ultimate
>> decision for this discussion.
>
> My question about being able to re-enable it poses an interesting one.
> Since this is a programmatic method of controlling things, do you really
> want to automatically do something that wasn't explicitly defined?

Personally I'm in the camp of "no". Stopping music on hold right now is 
done to ensure that "stream file" can do what you ask it to do.

> As someone who might interface via a program, I'm thinking I would
> prefer things to continue operating as they do now. If my program
> already accounted for this, then I've already triggered MOH to restart
> after the file. Another question might be; is there a way to determine
> if MOH was playing prior to my call to stream file so I can reset the
> previous state?

There is currently no way to get MOH state but as Asterisk will not 
arbitrarily start MOH on channels in this situation you can certainly 
store this information yourself as you would be the one initiating it.

> My gut tells me that if this has been like this for a long time, and is
> how it worked originally, that how it works now be left as the default,
> and if you want to add an option that allows you to turn it on, that be
> the best approach here. Changing this can only make it a backwards
> compatibility issue. Someone who has run into this and needs it to act
> differently will seek out the new option after reading about it in the
> CHANGES file.

Agreed but what I'm having a hard time grasping is the benefit of having 
this be a configuration option you enable. You *have* to be aware of it 
to enable it which is the same as being aware of it when writing your AGI.

Cheers,

-- 
Joshua Colp
Digium, Inc. | Senior Software Developer
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
Check us out at:  www.digium.com  & www.asterisk.org