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
--
_____________________________________________________________________
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
New to Asterisk? Join us for a live introductory webinar every Thurs:
http://www.asterisk.org/hello
asterisk-users mailing list
To UNSUBSCRIBE or update options visit:
http://lists.digium.com/mailman/listinfo/asterisk-users
