<div dir="ltr">I have a requirement to enable streaming audio for up to 25-30 live audio sources and the unique part is that some DID numbers coming in on PRIs need to automatically be answered and connected to a live audio stream.<div>
<br></div><div>I've used FXO/CME live audio with CUCM via multicast, but don't think this scales to 25-30 sources - atleast I'm thinking there is a better way.  Even if it did, I would need something to answer the call and put it on hold.</div>
<div><br></div><div>So, assuming that I can get the multicast RTP on to the network with a server, I just need the Cisco voice equipment to listen to the stream.</div><div><br></div><div>One way I can think to auto answer and put a call on hold would be with CCX, but that is ugly because I would need alot of CTI port groups so I can map to different CUCM CTI music on hold audio sources, and would quickly eat up alot of ports on CCX due to the requirement to allow multiple callers the ability to listen to the same audio feed.</div>
<div><br></div><div>I noticed in the dial-peer config, there is an option for 'session protocol multicast' and then the associated 'session target ipv4:239.x.x.x:yyyyy'.  I've configured this and when calls come in the PRI they are auto answered but I get just dead silence.    I've ruled out a multicast issue by verifying that when an actual phone puts a PRI caller on hold, the PRI caller can hear the audio.    The weird thing is that when I type 'show voip rtp connection' on the router, the local IP when using the 'session protocol multicast' is 255.255.255.255.   When I look at that same command output when an IP phone places a caller on hold, the local IP shows the proper address assigned to the VG.    Under both scenarios, the remote IP properly shows the correct multicast address (e.g. 239.x.x.x).    I know that the 'session protocol multicast' was made for hoot-n-holler, so I'm thinking it just wasn't designed to do what I am trying.    I've tried several levels of IOS and get the same behavior.</div>
<div><br></div><div>As a plan B, I've created a VXML script and tied it to a POTS dialpeer and had the VXML script request audio from a RTSP server.   This works, but I'd prefer the multicast option.  I've not yet found a RTSP server that seems to fit my requirements of so many live audio feeds.</div>
<div><br></div><div>If someone can think of another option to get 25-30 live feeds tied to a DID number I would appreciate that as well.</div><div><br></div><div>Justin</div></div>