User Expected Behavior Of Musiconhold And AGI’s “stream File”

Home » Asterisk Users » User Expected Behavior Of Musiconhold And AGI’s “stream File”
Asterisk Users 3 Comments

Hi everyone,

I am your friendly neighborhood developer here with a question that may impact some of you.

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?

Do you depend on this behavior knowingly?

Do you depend on this behavior without knowing it?

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

Cheers,

3 thoughts on - User Expected Behavior Of Musiconhold And AGI’s “stream File”

  • You’re friendly? 🙂

    I guess part of the question is; can you trigger it to be re-enabled after the stream file?

    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?

    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?

    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.

    In an ideal scenario, a system upgrade should require the least amount of knob turning.

  • Leif Madsen wrote:

    <3

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

    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.

    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.

    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,

  • And that makes sense. I kind of knew the answer already, but used it as a leader to the rest of the discussion 🙂

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

    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.

    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.