Add - ccm-manager music-on-hold.au --- On Wed, 3/4/09, Cliff McGlamry <cl...@mcglamry.net> wrote:
From: Cliff McGlamry <cl...@mcglamry.net> Subject: [OSL | CCIE_Voice] MOH problem - but I managed to figure it out....but useful info To: ccie_voice@onlinestudylist.com Date: Wednesday, March 4, 2009, 10:36 AM Running into a strange issue this evening on the rack. Streaming multicast MOH from HQ to BR1. Performace counters show the MOH source active on the server, but PSTN caller into BR1 doesn't get music. I've done the ip pim sparse-dense on the Loopback, Vlan, and on the virtual-template interface (this is MLPoFR) for BR1. On BR1, sh ip mroute returns the info you'd expect: (*, 239.2.1.1), 00:05:37/stopped, RP 0.0.0.0, flags: D Incoming interface: Null, RPF nbr 0.0.0.0 Outgoing interface list: Virtual-Access3, Forward/Dense, 00:05:37/00:00:00 (10.21.201.1, 239.2.1.1), 00:05:36/00:00:24, flags: T Incoming interface: Vlan410, RPF nbr 0.0.0.0 Outgoing interface list: Virtual-Access3, Forward/Dense, 00:02:32/00:00:00 (172.21.101.1, 239.2.1.1), 00:05:37/00:00:32, flags: T Incoming interface: Loopback0, RPF nbr 0.0.0.0 Outgoing interface list: Virtual-Access3, Forward/Dense, 00:02:33/00:00:00 (*, 224.0.1.40), 01:19:01/00:02:24, RP 0.0.0.0, flags: DCL Incoming interface: Null, RPF nbr 0.0.0.0 Outgoing interface list: Virtual-Access1, Forward/Dense, 01:19:01/00:00:00 Virtual-Access3, Forward/Dense, 01:19:12/00:00:00 So the router KNOWS about it. But when the call goes on hold, the stream isn't coming across. I'm really not seeing any packets across the WAN while the caller is on hold, so I don't think it's actually sending it across. But callers into HQ DO get multicast MOH, but of course, they are on the same VLAN so it's easy. So I start wondering....where the heck is it getting stuck? I've got the BR1 router set up with the no mgcp timer receive-rtcp ip pim-dense no ip igmp snooping I'm thinking....this isn't the problem. So, I back up and start looking at HQ router. It also sees the PIM info...: Pod21-HQ-RTR#sh ip mroute IP Multicast Routing Table Flags: D - Dense, S - Sparse, B - Bidir Group, s - SSM Group, C - Connected, L - Local, P - Pruned, R - RP-bit set, F - Register flag, T - SPT-bit set, J - Join SPT, M - MSDP created entry, X - Proxy Join Timer Running, A - Candidate for MSDP Advertisement, U - URD, I - Received Source Specific Host Report, Z - Multicast Tunnel, z - MDT-data group sender, Y - Joined MDT-data group, y - Sending to MDT-data group Outgoing interface flags: H - Hardware switched, A - Assert winner Timers: Uptime/Expires Interface state: Interface, Next-Hop or VCD, State/Mode (*, 239.2.1.1), 00:04:33/00:01:26, RP 0.0.0.0, flags: D Incoming interface: Null, RPF nbr 0.0.0.0 Outgoing interface list: Virtual-Access3, Forward/Dense, 00:04:33/00:00:00 (*, 239.2.1.3), 00:00:16/stopped, RP 0.0.0.0, flags: D Incoming interface: Null, RPF nbr 0.0.0.0 Outgoing interface list: Virtual-Access3, Forward/Dense, 00:00:16/00:00:00 (162.21.101.2, 239.2.1.3), 00:00:17/00:02:42, flags: PT Incoming interface: Virtual-Access3, RPF nbr 0.0.0.0 Outgoing interface list: Null (*, 224.0.1.40), 05:50:11/00:02:45, RP 0.0.0.0, flags: DCL Incoming interface: Null, RPF nbr 0.0.0.0 So...I wonder....it couldn't be that simple.... I go in and apply the following command onto the fas 0/0.410 interface: ip pim dense Make a test call....and we have audio. While this allows it to flow correctly, I'm still not clear on how it could KNOW it was there but not flow...but at least I won't get killed by this situation again. Cliff