We have a customer who would like to play radio music through their phones while the phones are otherwise idle (yes, I’m aware of the licensing issues with radio music-on-old - we’re not going anywhere near there). This seems to be a potentially ugly rabbit hole with all sorts of compatibility issues. It seems to me that the easiest approach would be to have a conference room they can dial into and put on speakerphone with the music source playing through it via some sort of ATA-type extension dialed into it. Has anyone here come up with a clever hack for this (or is there an obvious thing that I’ve missed)?
UPDATE - I eventually gave up on doing this through the phones (very long story that I won’t bore everyone with), and installed an FFPLAY script/icon on the end-user desktops to let them listen to a multicast stream. There is too much weirdness involved unless the phones have an explicit feature to allow this. On the plus side, it should be an extremely easy feature to add from a software perspective. We put in a feature request with Yealink.
The lowest impact solution if your phones support it , would be to multicast the audio from “whatever” and arrange for the phones that want to be annoyed/enchanted by that stream to listen to the multicast,
Possibly https://sbkb.cisco.com/CiscoSB/GetArticle.aspx?docid=4f4ece87b56043a1b51a70dc984a7d3a_Streaming_Audio_Server_Configuration_on_the_SPA2102_Phone_Ad.xml&pid=2&converted=0 is one piece of the puzzle.
However, on most phones with a call in progress, a new incoming call will play a wimpy ‘call waiting’ beep and maybe flash a light. They generally can’t be made to play a normal ring.
You might have better luck with multicast paging, but that’s device dependent, too.
Or, you might have some fancy dialplan that knocks the music call down before sending the real call.
Sorry, but I don’t see an easy path to the cheese.
Yeah, I think multicast paging will be the solution if we decide to go through with this. There are actually specifically-made “line in-to-multicast” devices for this application (like the Algo 8301). This leaves us with a potential mess of phone model-specific configuration template changes. There’s only one model at this site right now, but that never lasts forever…
VLC-nox is a much cheaper solution but takes some R’ing of TFM
(you probably need to choose an audio only source)
Multicast streaming is obviously by definition “Connection-less” each phone hardware you need to “hand massage” the multicast address to your server, there is no way to easily script that universally, so “roll up your sleeves” if necessary probably just a line or two in each phone model template if you are “provisioning” them with a service and multcast a generic audio stream that they can all decode (likely slin mono 8k), but your $350+ solution would need the same considerations
Yeah, I’m pretty sure I could put something together in Linux or BSD, but it’d likely cost far more than $350 worth of my time (and then it has to be maintained, and then other techs would have to figure it out, etc.). For us, simple is usually cheaper in the long run.
Then just figure out the needs for each hardware phone you need to provision for, they are all remarkably similar, and as I said just the network and the streaming format, it is unlikely that the multicast can broadcast outside any very tightly controlled networks you have though.
So what is the plan for handling incoming calls with this feature running? As it was pointed out earlier, once you open a line on the phone to listen to this radio music (why?) you basically put your line in an “In Use” state. That means anyone BLF’ing that user will see them “In Use/Busy”. Maybe you’re not using BLF (at least now) so that won’t impact you but it will if you ever decide to use it.
Just keep in mind that the moment an “idle” phone picks up a line and dials in somewhere to stream that music that phone is no longer idle. That phone is now In Use and will be treated as such by the system for any rules/dialplan that check the state of the phone and do something based on that state.
Again, as it was pointed out, a phone doing this will be considered “on a call” so any real incoming calls they are supposed to be answering will be treated as Call Waiting and either just “beep” and/or “blink” the line button to show there is a new call. You might be able to get the LCD to fill up and change when that new call comes in but that would require them to watch the LCD screen and hope that they can hear the call waiting beep over their music stream when calls come in.
For reference, Toshiba and Panasonic PBX systems (and a couple others) could do this without tying up the phone BUT that is a proprietary phone and PBX. Duplicating that functionality is really, really hard with SIP phones.
This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.