Live Stream Music on Hold and Cisco UC on UCS

Background

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 10.3.254.249 255.255.255.252
 ip pim sparse-dense-mode
!
! Configure an E&M port (example as shown)
voice-port 0/1/0
 auto-cut-through
 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:239.1.1.10:16384
 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.

Conclusion

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: http://ucguerrilla.com. You can follow Bill on Twitter: @ucguerrilla