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

[Leif Madsen]

On 28/09/12 08:45 AM, Joshua Colp wrote:
> Leif Madsen wrote:
>> 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.

And that makes sense. I kind of knew the answer already, but used it as 
a leader to the rest of the 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.

Which makes sense. No one wants to play a file over MOH :)

>> 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.

OK, so we're on the same page here then. If you were the one initiating 
it, and you call stream file, then you know it's going to stop the MOH, 
and you can check your own programmatic state to determine if you should 
start MOH again. Starting it automatically again might not be the method 
you want.

If you don't want it, now you have to explicitly stop it, which could 
cause a "blip" of music to be played after every file. This is certainly 
a bug which would have to be worked around, and seems like a lot more 
work than it is worth.

>> 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.

That makes sense to me. I was thinking the same thing, but wasn't sure 
if Asterisk would have started MOH due to some hold situation or 
something I hadn't thought of. If the initiation of the MOH was done by 
the program, then it makes perfect sense to me that it should start it 
again as long as it's documented that stream file will stop it (if 
already playing). I think I saw a commit from you today that satisfies 
that part of it.

Based on this discussion, my stance seems to be adding the option just 
seems silly. A sane method of restarting the MOH already exists, and 
control should be in the AGI, not in Asterisk.


-- 
Leif Madsen
http://www.oreilly.com/catalog/asterisk