Click here to request a Network Assessment!

William Bell

Live Stream Music on Hold and Cisco UC on UCS


The use case I am going to talk about is one where a customer is using a live audio feed, such as a satellite radio receiver, to play music to parties who are on hold. In Cisco Unified Communications Manager (CUCM) deployments leveraging the MCS platform, Cisco provided an OEM’d USB audio adapter. This adapter would connect to the USB port on a MCS server and accept a 3.5mm TRS connector (like on your iPod).

In CUCM this is called a “fixed audio source”. You assigned the audio source to a device or line and when that device or line placed a remote party on hold, that remote party would be jamming out to whatever satellite radio was playing at the time.

As customers move to a UCS platform (or any approved virtual solution running on VMware ESXi) they discover that their USB adapter won’t work. Basically, the virtual machine on ESXi does not have access to the physical USB compute resource.

There are several options available to the CUCM admin to work around this challenge.

Option 1: Use a MCS Node

You can mix physical CUCM nodes (i.e. running on MCS) with CUCM virtual machines (i.e. running on UCS) in the same cluster. If this fits your design model then you can install the USB audio adapter on one of the MCS servers. The main consideration is network placement for the MCS server. Other than that, it would operate as it would in a pure MCS environment.

Customers who are migrating to a virtual environment and still have MCS compute platforms that can handle CUCM 8.0, 8.5, 8.6, etc. may want to consider this approach as it leverages your existing investment.

Option 2: Use a “Uni-tasker”

The idea here is that you find a device that can accept an audio input, encode that input into G.whatever, packetize it into IP, and multicast it on your network. I did some research on this for one of our customers and I found a product from the Barix Annuncicom line.

Specifically, I believe that the Annuncicom 100 and 200 fit the bill. The latter provides PoE support. The idea is simple enough. You take audio-out from your satellite radio receiver (or whatever) and connect it to the audio-in on the Barix unit. You connect the Barix to your LAN. Then you configure Barix (via a web interface on the system) to tweak audio levels, define IP targets (including multicast addresses), etc.

There is more work to be done to support this integration. We will touch on that later.

I should put a disclaimer here... well actually two disclaimers. First, NetCraftsmen doesn't resell or partner with Barix.
We just came across a possible solution to our customer's problem and thought we would share it. Second,
I have not tested this product yet to confirm it meets the need. I have gone through all of the document and
spoken with Barix reps about the solution. I may be testing this in the January time frame and will post back results.

Option 3: Use an ISR and a Spin on LMR

During my research for a solution to this problem I came across a Cisco Support Community post from one of my fellow CSC Designated VIPs, Jonathan Schulenberg. In the post, Jonathan relayed the idea of leveraging a LMR-like setup to configure an ISR to stream audio input on a FXO or E&M interface to a multicast address. In essence, turning your ISR into an audio streamer.

Let’s break it down:

Physical Layer

You need something between your satellite radio receiver and the ISR router. On the ISR you will need either a FXO or an E&M interface. Using E&M is a little more straight forward. Physically, all you need to do is find an audio cable with a 3.5mm TRS connector on each end. Cut one of the ends off and strip back the shielding to expose the wire. Then crimp the wire into an RJ-48S connector. Plug the 3.5mm end into your audio-out and the RJ-48S end into your E&M.

If you are using FXO, you will need an adapter like this one: MOD-SC adapter. I found this information in a CME guide on streaming from a live audio source (good reference). If you look at the picture of the MOD-SC adapter, it should be obvious how to connect it up.

IOS Configurations

The configuration is like LMR but without the requirement for a LMR license. Essentially, we are going to tell the interface to open and receive input full-time. Then we are going to leverage the PLAR concept to route “the call” to a multicast address.

Sample config:

! voice class
voice class permanent 1
 signal timing idle suppress-voice 1
 signal timing oos timeout disabled
 signal keepalive disabled
 signal sequence oos no-action
! Configure a virtual interface as the source of the multicast 
interface Vif1
 description multicast-source-moh
 ip address
 ip pim sparse-dense-mode
! Configure an E&M port (example as shown)
voice-port 0/1/0
 voice-class permanent 1
 operation 4-wire
 signal immediate
 input gain -6
 no each-cancel enable
 no comfort-noise
 timeouts call-disconnect 3
 connection trunk 1079999
! Configure dial-peer
dial-peer voice 3108 voip
 description multicast-moh-to-net
 destination-pattern 1079999
 session protocol multicast
 session target ipv4:
 codec g711ulaw
 no vad

You will also need to configure PIM on the other router interfaces involved in the audio path. Don’t forget to ensure that upstream routers know how to route to the Vif1 IP address. I should also note that I tested the basics of this approach on a 2800 running 12.4(24)T IOS. I have heard that folks have found the implementation of this method to be finicky. As in, there are several IOS bugs that could throw you. This is actually one reason why I am not currently recommending this approach as a first choice (see the end of this blog).

IP Network Layer

This option and option 2 have similar requirements. We will touch on these in a moment.

CUCM Configs

This option and option 2 have similar requirements. We will touch on these in a moment.

Additional Steps for Option 2 and 3

To integrate this solution in your environment, there are some CUCM configurations to contend with. Before we dive into that, let’s take a moment to understand how MoH works in a “normal” CUCM environment.

  • IPVMS is the service that handles audio streaming for a CUCM node. When you enable a MoH server, it is that server’s IPVMS service that is doing the work.
  • In a Unicast MoH scenario, when Phone A puts Phone B on hold:
    • Phone A sends a SIP/SCCP message to CUCM to clue it in
    • The CUCM media resource manager (MRM) determines the audio source based on Phone A’s configuration
    • MRM also determines the media resource that should provide the MoH stream based on Phone B’s MRGL assignment
    • CUCM instructs the IPVMS services on the MoH server node to send a stream to the IP address of Phone B
    • CUCM instructs Phone B to accept the media stream from the IP address of the MoH server
  • In a multicast MoH scenario, when Phone A puts Phone B on hold:
    • Phone A sends a SIP/SCCP message to CUCM to clue it in
    • The CUCM media resource manager (MRM) determines the audio source based on Phone A’s configuration
    • MRM also determines the media resource that should provide the MoH stream based on Phone B’s MRGL assignment
    • CUCM instructs Phone B to listen for a media stream on the multicast address determined by the MRM process (as per the MoH server configuration)

Hopefully it is apparent from the scenarios described above that we cannot use Option 2 or 3 in a unicast MoH scenario. The CUCM has no way to instruct either the Barix unit or the ISR to direct a media stream to specific device.

So, what we need to do is leverage multicast. In essence, we are playing a shell game on Phone B. We tell it to listen to a specific multicast address. It really doesn’t know or care where that media is sourced from.

So, breaking it down.

Enable Multicast on Your Network

Using this approach, you must enable multicast on your network. Well, at least for the devices you want to receive the live media stream. You’ll need to contend with PIM, IGMP, rendezvous points, IP multicast address ranges, etc. If you are looking for assistance in this area, NetCraftsmen has some stellar network consultants that do this in their sleep.

Configure the Audio Source in CUCM

You can use the Fixed audio source or an audio file. You will need to check the option to enable multicasting of that source. If you have multicast enabled end-to-end in your network, using a Fixed audio source may be preferred. You can’t predict who Phone A will put on hold. So, if you don’t have multicast end-to-end, you may want to use an audio file as the source. This file would be a legit file. Unicast recipients will hear the audio from that file. Multicast receivers would hear the live stream.

Configure the MoH Server

You must enable multicast on your MoH server in CUCM. You will want to identify the appropriate multicast address and you will select the option to increment by address, not port. Configure the network hop counts as appropriate for you environment.

Configure MRG and MRGL

You can assign any MoH server to one or more media resource groups (MRG). You also flag MRGs as multicast-enabled or not. If a device has a multicast enabled audio source, a multicast enabled MoH server, and a multicast-enabled MRG in its MRGL, then that device will open its media receive channel to the multicast address determine by the MoH server config.

Block the CUCM Stream

Time for the shell game. The IPVMS service on your MoH server is going to stream multicast packets to the address configured in CUCM. You have to ensure that stream doesn’t leave the CUCM VLAN. You can do this with ACLs or you can disable PIM on the SVI or router interface used as the CUCM default IP gateway.

Assuming you are allowing multicast from your Barix box (Option 2) or the ISR (Option 3) then your phone will be none the wiser.


We discussed three options to providing a live MoH feed in a UC on UCS environment. The first option is running a mixed-cluster of UCS and MCS nodes. This option is a good choice if you already have compatible MCS servers or you were already planning to run a mixed-cluster.

The second option is leveraging a “uni-tasker” to multicast music across your network. This option is good if you wanted a “set it and forget it” solution using a product that is purpose built for bridging audio between IP networks and audio players/receivers.

The third option is taking a spin on LMR and leveraging a Cisco ISR to multicast music across your network. This option leverages existing investment and is a decent alternative.

At this point in time, I don’t have a specific recommendation. I do lean toward Option 1 or Option 2. With Option 1 only making sense if you were planning to use a MCS anyway. I am not saying Option 3 is a bad approach. Rather, I am saying I don’t have enough data on the operational impact over time. If you use Option 3 you are likely going to leverage your existing PSTN gateway (which may also be a DSP farm) and this means you have one more feature that you have to contend with from an interoperability and software defect (“bug”) perspective.

The NetCraftsmen UC team does have plans to do some additional testing for both options and if anything substantial is discovered, I will update this blog accordingly.

William Bell is the Collaboration Practice Lead for Chesapeake NetCraftsmen. Bill has over 10 years of experience in the IT industry with a focus on communication and collaboration technologies. In addition to blogging on the NetCraftsmen site, Bill also maintains the UC Guerrilla blog: You can follow Bill on Twitter: @ucguerrilla

William Bell

William Bell

Vice President, Solutions and Products

William’s background spans an array of technical disciplines including application development, network infrastructure, protocol analysis, virtualization, and Unified Communications. Bill is certified as a CCIE Voice (CCIE #38914) and possesses a deep understanding of Cisco’s UC and Collaboration portfolio. He leads the Infrastructure Engineering team and also works with customers on architecting solutions that align with core business drivers. Bill is a regular contributor on the Cisco Support Community, a 3 time Cisco Designated VIP, and blogs on the NetCraftsmen and UC Guerrilla sites.

View more Posts


Nick Kelly

Cybersecurity Engineer, Cisco

Nick has over 20 years of experience in Security Operations and Security Sales. He is an avid student of cybersecurity and regularly engages with the Infosec community at events like BSides, RVASec, Derbycon and more. The son of an FBI forensics director, Nick holds a B.S. in Criminal Justice and is one of Cisco’s Fire Jumper Elite members. When he’s not working, he writes cyberpunk and punches aliens on his Playstation.


Virgilio “BONG” dela Cruz Jr.

CCDP, CCNA V, CCNP, Cisco IPS Express Security for AM/EE
Field Solutions Architect, Tech Data

Virgilio “Bong” has sixteen years of professional experience in IT industry from academe, technical and customer support, pre-sales, post sales, project management, training and enablement. He has worked in Cisco Technical Assistance Center (TAC) as a member of the WAN and LAN Switching team. Bong now works for Tech Data as the Field Solutions Architect with a focus on Cisco Security and holds a few Cisco certifications including Fire Jumper Elite.


John Cavanaugh

CCIE #1066, CCDE #20070002, CCAr
Chief Technology Officer, Practice Lead Security Services, NetCraftsmen

John is our CTO and the practice lead for a talented team of consultants focused on designing and delivering scalable and secure infrastructure solutions to customers across multiple industry verticals and technologies. Previously he has held several positions including Executive Director/Chief Architect for Global Network Services at JPMorgan Chase. In that capacity, he led a team managing network architecture and services.  Prior to his role at JPMorgan Chase, John was a Distinguished Engineer at Cisco working across a number of verticals including Higher Education, Finance, Retail, Government, and Health Care.

He is an expert in working with groups to identify business needs, and align technology strategies to enable business strategies, building in agility and scalability to allow for future changes. John is experienced in the architecture and design of highly available, secure, network infrastructure and data centers, and has worked on projects worldwide. He has worked in both the business and regulatory environments for the design and deployment of complex IT infrastructures.