I’m trying to use FreePBX with internal phones (and no external phone services) to set up an internal dial-a-stream service, whereby I can access one of several music streams via extensions (i.e., dial 900# for an NPR radio stream, etc).
I’ve figured out how to stream radio stations to music-on-hold, using the link below
but I don’t know how to access music on hold from an extension. My solution right now is to simply call the default parking number (70#), with the “Parking Music Class” set to default (music-on-hold), the default music-on-hold set to a radio stream (from the link above), and the “Parking Timeout” set to a long time. This is great, but I’m limited to listening to only the one stream.
Is it possible to have a virtual extension (or otherwise) end in an arbitrary music on hold (not necessarily the default) for internal calls using FreePBX?
This is one issue that I ran into when moving to FreePBX. The legacy phone system had a “BGM” or Background Music button. It was tied into an analog amplifier which played the local radio station. The easiest method I came up with was to setup Queues. I made specific music queues and specified specific radio streams for that queue. In your case, you would setup a queue that allows the caller to be on unlimited hold.
The downside with this setup are the following:
This will use up an Asterisk channel, so will put more load on your system
The phone will be on a call the whole time, so if you have paging, you will never hear the page
If the queue is set to unlimited, the call will never end and will play constantly.
To work around the paging issue, on the Sangoma and Yealink phones, there is a setting that you enable that will allow Multicast Barge paging to put the call on hold, which will basically put the queued call on hold. But, the users will have to push the button again to resume the music.
I haven’t explored the other option which is to use Multicast to play the music. This is one project I wanted to open with Sangoma and see if you could use priority multi-cast streams. Where you could have a multi-cast stream playing locally that a phone could attach to and play, but allow calls to take priority over it. This would greatly reduce the load on the system, since it would only be sending one stream.
Hopefully this helps with some guidance on what you can do for “Background Music” on FreePBX.
The following is something I use for testing RTP when I need a long stream of arbitrary audio. Add the dialplan to extensions_custom.conf and create a Custom Destination with a dial string of play-musiconhold,s,1. If you need a dialable feature code, create a Misc Application.
[play-musiconhold]
exten => s,1,NoOp(Entering user defined context play-musiconhold in extensions_custom.conf)
exten => s,n,Set(TIMEOUT(absolute)=600) ; set max time channel will stay up in seconds
exten => s,n,Answer
exten => s,n,MusicOnHold(default) ; set moh class as desired
exten => s,n,Hangup()
Neat @dicko, I don’t recall seeing this before. But the sample dialplan on line 24 immediately jumped out at me, it’s using the looooooong deprecated pipe to separate args. It’s been on the shelf for a long time:
I’ll have to read through this more, as that would be cleaner than the queue method.
Is there anything that would allow a multicast stream to be played? Again, these are ongoing calls that will be happening with the phone system. I was trying to see if there was also a way to play a multicast stream on a phone, similar to how paging works, but the phone would join the stream.
Multicast paging is essentially just setting your phone to listen for a multicast, if your phone supports multicasting and you set it to “subscribe” to a multicast address:port. So if the phone is listening on 124.1.2.3:48000 it will be able to hear any stream sent to 124.1.2.3:48000 , the format must be agreeable so g722 is probably the best encapsulation choice for your stream
The issue is that it will be paging forever, and phone calls will not come through. If I set the phone to allow barging, it will break the multicast page, but then the phone will no longer listen to the page, until you start it again.
I haven’t tested this with the Cyberdata paging unit, but I believe it had the ability to priority multicasts, and maybe Polycom units as well? That way you could have one stream go over another.
Maybe there is some way, after another page or phone call, the phone could resume the multicast? That would be helpful in this situation.
That’s the line I have now. I’ll have to test again to see if, after a page, if the multicast resume. From what I tested on the Sangoma phones, it would simply discard the multicast and never resume. You had to page again, so to speak, for it to work.
Basically, similar to the issue we have where someone picks up the phone, hits the page button and didn’t realize they did. Then no one is receiving calls, because it is playing that multicast page.
replace 239.255.255.245:5555 with the ip:port you are listening on and the url with a stream you are legally allowed to rebroadcast , (choose wrong and you might get a big bill)
If a phone won’t interrupt the stream for a call, then perhaps setup a ‘predial hook’ to have iptables add a rule to drop the stream on an incoming call and a ‘hangup handler’ to delete that rule, which should recommence the feed. If you have individual streams for individual extensions, then just stop and restart the ffmpeg stream similarly
That is an intriguing way of handling it. I was under the impression that when a stream starts the phone detects it and starts playing the stream. If you cancel the multicast on the phone (ie, press cancel or dial a phone number), it won’t resume the multicast.
I’ll have to do some testing again and see if I can get a Yealink or Sangoma phone to resume the multicast.
I will say I appreciate the ideas @dicko and @lgaetz. This would be beneficial for my setup, if we can get a multicast streaming sourc(es) to work via multicast. This would put this back to the similar BGM function I had on the previous phone system.
Right, it will, I’m just meaning the phones themselves cancel the stream and won’t resume. At least when I tested it before. I have no doubt that ffmpeg will multicast, I’m meaning the phone that you have suspect or cancel to get another call will not resume.