[cisco-voip] Media Termination Point

Wed Nov 19 03:53:50 EST 2008

Hi Jason,

On Tue, Nov 18, 2008 at 09:28:54PM -0500, Jason Burns wrote:
> To add to that:
> 
> On your H.323 GW you need to add
> 
> ccm-manager music-on-hold
> 
> (yes - even if it's an H.323 GW. I don't know why this works, but I've used
> it successfully before)

Believe it or not, I found that same thing out by accident yesterday when
doing the testing and was about to notify the list of my findings ;)

Indeed it does the magic - now I have MMoH to a pure H.323 gateway even
without an MTP.

> Sometimes you'll also need to add
> 
> ip multicast-routing
> 
> to the config as well.

The box already had multicast routing enabled. It happens to be the
router between the voice VLAN and a data VLAN for some odd reasons.

> Then when you put the PSTN leg on hold you can run
> 
> show ccm-manager music-on-hold
> 
> and check out the multicast stream packet count.

Yep, looks great:

Current active multicast sessions : 1
 Multicast       RTP port   Packets       Call   Codec    Incoming
 Address         number     in/out        id              Interface
===================================================================
239.1.1.10        16384   460/460          2071 g711alaw  Gi0/1      

I simply did not connect ccm-manager context (which is supposed to be
MGCP gateway stuff only) with operation as a H.323 gateway, but having
fooled around with SRST local MMoH injection lately, where the statement
is necessary as well in a non-MGCP context, I just tried it anyway and
found it to actually work. I assume the statement isn't so much an MGCP
statement as it is a "join MMoH streams no matter where they come from"
option. It actually triggers into multicast routing.

> show ip mroute count
> 
> is also useful there.

When the session above is active, mroutes are established:

(*, 239.1.1.10), 16:00:54/stopped, RP 172.31.1.2, flags: SJCL
  Incoming interface: Null, RPF nbr 0.0.0.0
  Outgoing interface list:
    GigabitEthernet0/1, Forward/Sparse, 00:00:49/00:02:37
    GigabitEthernet0/0, Forward/Sparse, 00:00:49/00:02:35

(192.168.111.254, 239.1.1.10), 00:00:49/00:02:16, flags: LJT
  Incoming interface: GigabitEthernet0/1, RPF nbr 0.0.0.0
  Outgoing interface list:
    GigabitEthernet0/0, Forward/Sparse, 00:00:49/00:02:35, A

(192.168.111.1, 239.1.1.10), 16:00:54/00:02:59, flags: LT
  Incoming interface: GigabitEthernet0/1, RPF nbr 0.0.0.0
  Outgoing interface list:
    GigabitEthernet0/0, Forward/Sparse, 00:00:49/00:02:35

And the forwarded packets count up:

Group: 239.1.1.10, Source count: 2, Packets forwarded: 502, Packets received: 2882851
  RP-tree: Forwarding: 0/0/0/0, Other: 0/0/0
  Source: 192.168.111.254/32, Forwarding: 2/0/88/0, Other: 4/2/0
  Source: 192.168.111.1/32, Forwarding: 500/-50/200/0, Other: 2882855/0/2882355

Finally, the progress can be seen using

debug ccm-manager music-on-hold all 

First, the incoming call:

002346: Nov 19 09:34:11 CET: moh_update_rtp: callID 2078 dstCallID -1
002347: Nov 19 09:34:11 CET: moh_process_ccb: dstadr 192.168.111.159, callid -1, port 29868, 
                codec 6, moh_en 0, moh_addr 0.0.0.0
002348: Nov 19 09:34:11 CET: moh_update_rtp: callID 2078 dstCallID -1
002349: Nov 19 09:34:11 CET: moh_update_rtp: callID 2078 dstCallID -1
002350: Nov 19 09:34:11 CET: moh_process_ccb: dstadr 192.168.111.159, callid 2077, port 29868, 
                codec 6, moh_en 0, moh_addr 0.0.0.0
002351: Nov 19 09:34:11 CET: moh_update_rtp: callID 2078 dstCallID 2077
002352: Nov 19 09:34:11 CET: %ISDN-6-CONNECT: Interface BRI0/0/1:1 is now connected to 3514716466 N/A

Second, the call goes on hold:

002353: Nov 19 09:34:17 CET: moh_update_rtp: callID 2078 dstCallID 2077
002354: Nov 19 09:34:17 CET: moh_update_rtp: callID 2078 dstCallID 2077
002355: Nov 19 09:34:17 CET: moh_update_rtp: callID 2078 dstCallID 2077
002356: Nov 19 09:34:17 CET: moh_update_rtp: callID 2078 dstCallID 2077
002357: Nov 19 09:34:17 CET: moh_process_ccb: dstadr 239.1.1.10, callid 2077, port 16384, 
                codec 6, moh_en 0, moh_addr 0.0.0.0
002358: Nov 19 09:34:17 CET: moh_process_ccb:multicast addr add_ccb
002359: Nov 19 09:34:17 CET: moh_add_ccb: ip addr 239.1.1.10 port 16384 callid 2077
002360: Nov 19 09:34:17 CET: moh_add_ccb: vmccb does not exists - creating a 
                        new one for 239.1.1.10 through IGMP
002361: Nov 19 09:34:17 CET:  moh_join_group_command called for 239.1.1.10
002362: Nov 19 09:34:17 CET: moh_join_group_command: Looking at valid idb's to configure 239.1.1.10
002363: Nov 19 09:34:17 CET: moh_join_group_command: IGMP API on group 239.1.1.10 idb Gi0/0
002364: Nov 19 09:34:17 CET: moh_join_group_command: IGMP API on group 239.1.1.10 idb Gi0/1
002365: Nov 19 09:34:17 CET: moh_create_session: called
002366: Nov 19 09:34:17 CET:  moh_create_session : dstadr 239.1.1.10 does not exist - creating a                        control block
002367: Nov 19 09:34:17 CET: moh_insert_multicast_hashtable:moh_insert_multicast_hashtable buc 11
002368: Nov 19 09:34:17 CET: moh_create_session : Created a new vmccb for 239.1.1.10
002369: Nov 19 09:34:17 CET: moh_send_join: Looking at valid idb's to configure 239.1.1.10
002370: Nov 19 09:34:17 CET: moh_add_ccb: Done inserting CCB for 239.1.1.10
002371: Nov 19 09:34:17 CET: moh_update_rtp: callID 2078 dstCallID 2077

All the stuff happening here is triggered by the "ccm-manager music"
statement. You can see the gateway IGMP-joining the group here as well
as all the internal metadata preparation for that purpose.

Finally, leaving hold:

002372: Nov 19 09:34:24 CET: moh_update_rtp: callID 2078 dstCallID 2077
002373: Nov 19 09:34:24 CET: moh_update_rtp: callID 2078 dstCallID 2077
002374: Nov 19 09:34:24 CET: update_stream_info: stream_flag Reset
002375: Nov 19 09:34:24 CET: moh_update_rtp: callID 2078 dstCallID 2077
002376: Nov 19 09:34:24 CET: update_stream_info: stream_flag Reset
002377: Nov 19 09:34:24 CET: moh_update_rtp: callID 2078 dstCallID 2077
002378: Nov 19 09:34:24 CET: update_stream_info: stream_flag Reset
002379: Nov 19 09:34:24 CET: moh_process_ccb: dstadr 192.168.111.159, callid 2077, port 31186, 
                codec 6, moh_en 1, moh_addr 239.1.1.10
002380: Nov 19 09:34:24 CET: moh_process_ccb:multicast addr delete_ccb call id 2077
                                  moh_call_id 2077
002381: Nov 19 09:34:24 CET: moh_delete_ccb: called dstadr 239.1.1.10, callid 2077
002382: Nov 19 09:34:24 CET: moh_delete_ccb_ext:called dstadr 239.1.1.10, callid 2077
002383: Nov 19 09:34:24 CET: moh_delete_ccb_ext:ipaddr 239.1.1.10 callid 2077
002384: Nov 19 09:34:24 CET: moh_delete_ccb_ext : Deleted the ccb entry
002385: Nov 19 09:34:24 CET: moh_leave_group_command called for 239.1.1.10
002386: Nov 19 09:34:24 CET: moh_remove_group: called for 239.1.1.10
002387: Nov 19 09:34:24 CET: moh_remove_group Leaving 239.1.1.10
002388: Nov 19 09:34:24 CET: moh_remove_group Leaving 239.1.1.10
002389: Nov 19 09:34:24 CET: moh_delete_session : Freed up vmccb for 239.1.1.10
002390: Nov 19 09:34:24 CET: moh_update_rtp: callID 2078 dstCallID 2077

The gateway leaves the group.

So in short, forget my musings about MTPs - they are a cluge to work
around IOS gateways that (operating as H.323 gateways) don't join MMoH
by default. With the help of "ccm-manager music-on-hold" this is not
needed and things are better that way.

Thanks for reassuring me that this option actually is correct to use
in H.323 context. If that only would be documented somewhere. I assume
most people have it in their cut&paste-config collected over the years
from random articles on the 'net as well as their own testing, but I
don't remember I ever found that mentioned in the MMoH related design
guides.

Thanks,
Andre.
-- 
   Real men don't make backups of their mail. They just send it out
    on the Internet and let the secret services do the hard work.

-> Andre Beck    +++ ABP-RIPE +++      IBH IT-Service GmbH, Dresden <-