But what about if 20 or 30 people call in, and it’s firing off 30
copies of mp3Player? Won’t that start to degrade bandwidth?
In an ideal world, I was wondering it there was any way of all callers
"tapping into" the same audio socket, and if there were no callers,
the player would be inactive, and the first “new” caller would kick
the stream into life again.
Does that make any sense at all?
Thanks!
Asterisk 13.7.2 (but excited about 13.8 with bundled PJsip!) on Ubuntu
15.10 Wiley.
For that use case it would be better to use an MOH class that used a stream player instead. Only one stream would be pulled and each channel listening to that music on hold class would get a copy of it.
I have a problem though - it was working fine yesterday, but today there was silence, even though ps -e | grep mpg showed mpg123 running just fine.
As soon as I killed the process, the music started again - presumably Asterisk saw the process killed and started a new one?
Is there any way of monitoring what the audio is doing, or whether the stream is up, or even maybe just killing the process every 5 minutes to make it come alive again? (counter-intuitive, I know!).
Remember, as far as the process went, everything looked fine. It’s possible the remote server also kills streams after a while?
Anyone got any ideas? Thanks!
(Before anyone freaks out about the stream, it’s just for testing - it’s not being used in a commercial environment!)
Sorry to “bump” this, but does anyone have any ideas? I was just going to cron a half-hourly “pkill mpg123” - can anyone see any flaws with that idea? It only seems to halt the stream for about a second.