MoH from remote router flash file
Introduction
Document describes how to configure music on hold source to come from the remote site router instead of being streamed from the
centralized CallManager. This saves WAN bandwidth. This also allows each remote site to have its own music on hold file or
announcement message.
CallManager’s MoH server is configured for multicast. Phones and gateways at the central site will join the multicast group when it
needs to receive music on hold. Multicast doesn’t get forwarded by a router unless you configure it to do so—we won’t. Instead,
each remote site will contain a MoH file.
The remote site router will also multicast its MoH file from flash (or form a live source via FXO or E&M). Phones and gateways at
the remote site will gets their music from the router router.
How it works
When a phone is put on hold CallManager stops and closes the voice RTP stream and sets up another RTP stream (MoH). The IP
address and port of the MoH stream will be sent to the phone by CallManager. Since we are using multicast MoH, CallManager uses
the IP address and port that is defined in the MoH server object. For example, 239.1.1.1 port 16384. The phone joins the multicast
group and receives music. Note that the person who pressed the HOLD button doesn’t receive the music—the person they were
talking to receives the hold music.
See figure 1 below:
CallManager SCCP protocol has no mechanism to select sourcing MoH from a router—only from CallManager MoH servers. So we
have to trick the remote site IP Phones into thinking they are getting MoH from CallManager when they are really getting the MoH
stream from the router. This happens by configuring multicast MoH on the remote router with the same multicast IP address and port
that CallManager is using to multicast MoH. So we are spoofing the stream. The IP phone joins multicast group 239.1.1.1 port 16384
(for example) thinking that is also where the multicast stream is coming from. No stream comes over the WAN to the remote router.
Instead the remote router sources the stream with the same IP and port. The phone doesn’t know. Kind of like the old spy movies
where the briefcase with the money is switch for the briefcase with the bomb.
CallManager is multicasting MoH from its server. That stream is not allowed to cross the WAN because multicast routing is not
enabled on the central site WAN router. At the remote site, the remote site router is multicasting a different MoH stream sourced from
the remote site router. It’s stream doesn’t go over the WAN either. Note the multicast IP address and port are the same so the
spoofing works. The remote phone that is holding receives music from the remote site router instead of from CallManager.
Important notes and concepts

No MoH streams cross the WAN. Stream stops at the central site router and stops at the remote site router since we don’t have
multicast routing enabled.

Multicast MoH only works with G.711. CallManager must multicast only in G.711 and the remote router must do the same. The
file in flash must be in G.711 format. You can verify the file is G.711 by configuring the router properly and typing in “show
ephone summary.”
Remote-Bottom#sh ephone sum
Max 1, Registered 0, Unregistered 0, Deceased 0, Sockets 0
ephone_send_packet process switched 0
Max Conferences 8 with 0 active (8 allowed)
Skinny Music On Hold Status
Active MOH clients 0 (max 96), Media Clients 0
File music-on-hold.au type AU Media_Payload_G711Ulaw64k
Moh multicast on 239.1.1.1 port 16384 via 192.168.30.1
via 10.10.30.1
160 bytes

The G.711 for MoH isn’t a problem. There is plenty of bandwidth at the central site LAN and the remote site LAN. No MoH
crosses the WAN. The phones at the remote site can still use G.729 to cross the WAN for voice calls.

We are going to create a region object specifically for MoH (G.711 to every other region,) assign that region to a specific MoH
device pool and assign that MoH device pool to the MoH server object. This will force CallManager to only source G.711 MoH.
If we didn’t set up the region correctly, a G.729 remote site will get blank MoH. G.711 remote sites will work correctly (and get
the proper MoH from the remote site router.) This is because if the region is not setup correctly, CallManager thinks it should
stream G.729 MoH to the remote site since the remote site is a G.729 region. According to the Cisco document mentioned at the
beginning of this document, G.729 stream will be another IP address or Port from what was configured on the remote router. So
the phone ends up spoofing the wrong address and gets blank MoH.

You CAN copy the G.711 MoH file form the CallManager server to the router flash if you want all sites to hear the same music or
announcement and save on WAN bandwidth. Use different music files at first to verify everything is working properly.

If we are using H.323 (or hybrid H.323 / MGCP remember that G711 is only supported for MoH from router. So VOIP dial-peers
must be G711 or we will get tone on hold. Our configuration uses H.323 dial-peers for incoming calls to the remote site so
callerID is supported on FXO interfaces.
Links
Search for the following on the Cisco web site. Links die, so a search is better. Enclosing the text in quotation marks performs an
exact search.
1. Integrating Cisco CallManager and Cisco SRST to Use Cisco SRST as a Multicast MOH Resource
Remote site router config
Only the important config has been given to save space. Remote site in in G.729 region. G.729 will be used for voice calls.
hostname Remote-Bottom
!
! We are using trunk group command to save on number of needed dial-peers. See trunk group LAB.
trunk group FXO
!
We need a loopback interface so music can come from an FXO interface.
interface Loopback0
ip address 192.168.30.1 255.255.255.0
!
interface FastEthernet0/0
ip address 10.10.30.1 255.255.255.0
duplex auto
speed auto
!
Our home-lab used a back-back serial 128K connection.
interface Serial0/1/0
ip address 10.10.20.2 255.255.255.0
no fair-queue
!
!
voice-port 0/2/0
trunk-group FXO 1
timing hookflash-out 50
connection plar 7001
! Our remote-site Phone.
!
voice-port 0/2/1
trunk-group FXO 2
timing hookflash-out 50
connection plar 7001
!
Using MGCP back to CallManager for the analog devices.
ccm-manager fallback-mgcp
ccm-manager mgcp
ccm-manager music-on-hold
ccm-manager config server 10.10.10.10
ccm-manager config
!
mgcp
mgcp call-agent 10.10.10.10 2427 service-type mgcp version 0.1
mgcp dtmf-relay voip codec all mode out-of-band
mgcp rtp unreachable timeout 1000 action notify
mgcp modem passthrough voip mode nse
mgcp package-capability rtp-package
no mgcp package-capability res-package
mgcp package-capability sst-package
no mgcp package-capability fxr-package
mgcp package-capability pre-package
no mgcp timer receive-rtcp
mgcp sdp simple
mgcp rtp payload-type g726r16 static
!
mgcp profile default
!
!
! See Analog CallerID__H323-Inbound, MGCP-Outbound LAB for full explanation. Using H.323 for inbound analog FXO
calls so caller ID is supported. Using MGCP outbound. Dial-peers 1 and 3 are the incoming H.323. Dial-peer 2
is needed to transfer calls to other sites. Need G711ulaw codec because multicast MoH from router only supports
G.711. If configured G.729 here, would get tone on hold. Note if we transfer a call, a transcoder may be
needed.
dial-peer voice 1 pots
incoming called-number .
port 0/2/0
!
dial-peer voice 2 voip
destination-pattern [1-8]...
session target ipv4:10.10.10.10
dtmf-relay h245-alphanumeric
codec g711ulaw
!
!
dial-peer voice 3 pots
incoming called-number .
port 0/2/1
!
dial-peer voice 999020 pots
service mgcpapp
port 0/2/0
!
dial-peer voice 999030 pots
service mgcpapp
port 0/3/0
!
dial-peer voice 999021 pots
service mgcpapp
port 0/2/1
!
! Dial-peer 100 for SRST out dialing.
dial-peer voice 100 pots
trunkgroup FXO
destination-pattern 9[2-9]......
!
! Need the gateway command to invoke H.323.
gateway
timer receive-rtp 1200
!
!
Here is our SRST configuration. Max ephones is 1 to illustrate that we need an ephone and ephone-dn to source
the multicast Moh stream.
call-manager-fallback
secondary-dialtone 9
max-conferences 8 gain -6
ip source-address 10.10.30.1 port 2000
max-ephones 5
max-dn 10
system message primary CM Failed, NOW on SRST
moh music-on-hold.au
Our music file stored in flash.
Here is where the router enabled multicat MoH. Must put the same IP and port as specified in the CallManager
MoH server. The two IP addresses specify where the multicast packets will source from (F0/0 and Loopback 0.) We
need both so IP Phone to IP phone and IP phone to PSTN will receive MoH.
multicast moh 239.1.1.1 port 16384 route 192.168.30.1 10.10.30.1
!
!
End
Helpful Commands
Debug ephone moh
Show ephone summary
CallManager Configuration
1.
Configure a new region object
a. Set codecs to ALL other regions to G.711. HQ_REG is the central site.
2.
Create a new device pool for the MoH object.
a. Important fields are the Region and the MRGL
3.
Configure audio source to use multicast.
a. Check allow multicast
b. Check play continuously so the music doesn’t stop after the end of the music file (doesn’t repeat.)
4.
Enable Multicast on the MOH Server then configure Port Number and IP Address
a. Note the device pool. This is where we are forcing the MoH to only use G.711 since SRST MoH only support G.711.
5.
Media resource group and media resource group list
a. Make sure your MoH server shows up in whatever MRG you are using for your central site or remote site devices. Since
most implementations only have one MoH server object, it will appear in multiple MRGs. Our example has two
MRGs—one for software only resources (such as MoH show below) and one for hardware resources (transcoding and
hardware conferencing. Not shown) Check the Use Multicast for MoH Audio checkbox.
b.
6.
Configure the MGRL to include the MRG with the multicast MoH server object. In our example below, the remote site
devices use hardware transcoders and conference bridge, so the Remote-HW_MRG is listed first to choose those
hardware resources first. MoH is not in the Remote-HW_MRG so CallManager will keep searching the MRGL in order.
It will find an MoH resource in the Remote-SW_MRG.
Assign the MRGL to the appropriate phones, gateways, device pools, etc. In our example, we are using G.729 to remote site
phones. So the remote site phones and gateways will get assigned a remote-site device pool that contains our Remote_MRGL
object.
Verification
In our example, the remote site is a G.729 region so calls from central site to remote site uses G.729 to save on WAN bandwidth. We
are going to make various calls, verify the codec while talking is correct for the type of call, then test HOLD and verify the correct
music file is playing. In our example, the music file on CallManager is LedZeppelin. The music file on the remote router flash is the
sample file that comes with CallManager Express.
1.
2.
3.
Have a remote site phone call another phone at the same remote site R1 calls R2.
a. Press the ? key twice on R1 or R2 to bring up the statistics screen.
b. Verify the RXType and TXType is using G.711.
c. Have R1 press HOLD. Verify R2 hears the sample CCME hold music that you put on the flash.
Have a remote site phone call a central site phone. (R1 calls C1)
a. Press the ? key twice on R1 or R2 to bring up the statistics screen.
b. Verify the RXType and TXType is using G.729 (since our remote site is a G.729 region site to save WAN bandwidth.)
c. If R1 presses the Hold button. C1 should hear MoH from the file on the CallManager server (LedZeppelin)
d. If C1 presses the Hold button, R1 should hear MoH from the flash file on the router (Sample CCME music.)
Have a phone call into the remote site and put it on hold. PSTN caller should hear music from router flash (CCME sample MoH.)
a. Verify with: (Note the Loopback interface is the source for music for PSTN callers.
Remote-Bottom#sh ccm-manager music-on-hold
Current active multicast sessions : 1
Multicast
RTP port
Packets
Call
Codec
Incoming
Address
number
in/out
id
Interface
===================================================================
239.1.1.1
16384
794/794
1
g711ulaw Lo0
Remote-Bottom#
4.
5.
6.
7.
Same works for an analog phone hooked up to an FXS port.
You can hook up a sniffer to the back of a remote site phone. You should only see multicast RTP packets sourced from the
remote router LAN IP address.
You can hook up a sniffer to the back of a central site phone. You should only see multicast RTP packets being sourced from
CallManager’s IP address (if that is where the MoH server is located.)
Make incoming PSTN call to FXO port.
a. PLARs to remote site IP phone 7001. H.323 used for incoming.
b. When IP phone presses HOLD, should get MoH from router flash.
c. Transfer the call to the central site. While transferring, also get music from router flash. Note 7001 to the central site
phone is using G.729 (no transcoder invoked.)
d. After complete transfer note we are using a transcoder while talking. Incoming call to FXO (H.323.) VoIP dial-peer
(G.711) to central site phone.
e. Have central site phone press hold. Should get music from router flash. Transcoder not used.