[cisco-voip] Mcast MOH, H.323, MTP & Cluster (was: Attendant console queue MOH resource)

Andre Beck cisco-voip at ibh.net
Thu Nov 30 10:10:08 EST 2006


Hi,

On Thu, Nov 30, 2006 at 03:13:19PM +0200, Erik Erasmus (E) wrote:
> 
> I am using an H323 gateway at HQ - and not talking about the MOH under
> SRST using branch flash and fooling the phones with the signalling to
> think they are listening to multicast MOH from the HQ site. Simply - a
> case of because we are going that route for branches we enabled
> multicast MOH at HQ and then realised MOH towards PSTN stopped working
> on the h323 gateway. That is when I started looking at the perf mon
> counters for cisco MOH device and plying with the the require MTP tick
> on the ccm gateway.

This triggers a deja vu for me. I have a similar problem at a site that
up to some days ago used a single CCM publisher server (4.1.3) connected
to the PSTN via H.323 Gatekeeper Trunk (registering as default technology
prefix). The customer also has a bunch of remote sites. Multicast routing
is established in the whole WAN and working properly. The H.323 trunk is
configured as "require MTP".

In exactly this combination, MMOH *works*. We have tested to remove the
require MTP check (as I was informed on this list some time ago that
requiring MTP would be superfluous for Cisco IOS gateways), but this
results in MMOH no longer beeing heard at the PSTN side (but at least
hold works, giving the three beeps). So it appears this setup requires
MTPs no matter what.

Things began to rot when we added a second cluster member. This subscriber
server is running essentially all services that can possibly run on a
subscriber, including its own Media Streaming server. It streams the
same files to an alternate range of mcast group IPs (it appears there
is no failover mechanism here but both streaming servers are running
at the same time, so streaming to the same group would wreak havoc and
is consequently prevented by CCM). We then created some CM Groups where
the subscriber is the first CCM and moved part of the phones to this
CM Group. The phones seemed to work properly first, but it appears that
every phone that was assigned to this subscriber lost any feature that
requires an MTP: Neither the Hold nor the Transfer softkeys work any
longer on them. It is the same failure symptom that I already had once
there were insufficient MTP ressources, but they have been increased on
the subscriber as well - without success.

After getting aware of the problem I tried to fail all phones back to
the publisher (first by changing the order of CMs in the group, then
by removing the subscriber from the group), each time resetting the
phones in question. They always came back and registered with the
subscriber again...

The subscriber is now shut down and the system is back to normal. To
me it seems we both have essentially the same problem, with me beeing
also trapped in some additional cluster issues. I don't really know
what to try next, though.

Anyone know for sure whether this should work without MTP? If so, were
should I continue to debug the MMOH issues? Is MMOH supposed to work
at all in a Gatekeeper environment, where all cluster members running
call control register to the gatekeeper as default technology?

TIA,
Andre.
-- 
                  The _S_anta _C_laus _O_peration
  or "how to turn a complete illusion into a neverending money source"

-> Andre Beck    +++ ABP-RIPE +++    IBH Prof. Dr. Horn GmbH, Dresden <-


More information about the cisco-voip mailing list