I think you are running into the same PL "mutlicast not working over VPN".  It 
is been quite awhile since I have used the PL racks for voice, but remember 
they had a reccomended way for testing mutlicast.  Just cant remember.

James
________________________________
From: Matthew Berry [ciscovoiceg...@gmail.com]
Sent: Sunday, March 28, 2010 1:49 PM
To: James Key
Cc: OSL
Subject: Re: [OSL | CCIE_Voice] Discrepancy between Mark Snow's VoD and Lab 
Results?

James -

The command is not in my config.  I attached it for reference.

When I run a "debug ephone moh" I can see the MoH routes being used.  However, 
if I run a "show ccm-manager music-on-hold" while the PSTN caller is on hold, I 
do not see the session count increment from 0 to 1.

This seems off.

[cid:part1.09070307.05010307@gmail.com]


Matthew Berry

A+, CCENT, CCNA, CCNA Voice, CCVP, CCIE Written



Gmail: ciscovoiceguru

Skype: ciscovoiceguru

Twitter: ciscovoiceguru

1st Lab Attempt: Aug 16, 2010

On 3/28/2010 1:38 PM, James Key wrote:
Do you currently have multicast MOH streaming from flash?  If so, make sure the 
no mgcp timer receive-rtcp  is NOT in your config.  If it is, remove (don't 
forget no mgcp/mgcp ;-) ).  Place a call in from pstn and place on hold.  Your 
call should disconnect after the given time.

James Key
________________________________
From: Matthew Berry [ciscovoiceg...@gmail.com<mailto:ciscovoiceg...@gmail.com>]
Sent: Sunday, March 28, 2010 12:45 PM
To: James Key
Cc: OSL
Subject: Re: [OSL | CCIE_Voice] Discrepancy between Mark Snow's VoD and Lab 
Results?

James,

I see what you're saying here.  Could you recommend a good test scenario to see 
this 30 sec disconnect?

Right now, my phones are looking at 239.1.1.1 for their MOH, the CUCM Sub is 
setup to send MMOH out over that IP, but I am blocking multicast from 
traversing the WAN.  I also have SRST setup with the proper MOH commands.

I thought that was enough to test this scenario.  Is there something I am 
missing?


Matthew Berry

A+, CCENT, CCNA, CCNA Voice, CCVP, CCIE Written



Gmail: ciscovoiceguru

Skype: ciscovoiceguru

Twitter: ciscovoiceguru

1st Lab Attempt: Aug 16, 2010

On 3/28/2010 12:17 PM, James Key wrote:
Mark is correct here.  The command is needed when sourcing MOH from flash on am 
mgcp gateway.  As soon as call is placed on hold, mgcp traffic stops traversing 
the wan and the call will drop at 30 seconds.  When multicasting across the WAN 
as you are doing, no issues. Was able to reproduce this in the lab during my 
studies.

James Key

________________________________
From: 
ccie_voice-boun...@onlinestudylist.com<mailto:ccie_voice-boun...@onlinestudylist.com>
 
[ccie_voice-boun...@onlinestudylist.com<mailto:ccie_voice-boun...@onlinestudylist.com>]
 On Behalf Of Matthew Berry 
[ciscovoiceg...@gmail.com<mailto:ciscovoiceg...@gmail.com>]
Sent: Sunday, March 28, 2010 11:13 AM
To: OSL
Subject: [OSL | CCIE_Voice] Discrepancy between Mark Snow's VoD and Lab Results?

The following is an excerpt from Mark Snow's V3 VoD released late last year.


•         If on an MGCP gateway: “no mgcp timer receive-rtcp” – If you have an 
MGCP gateway at a remote site and the requirement is to have a no-WAN MoH 
solution, you must enter this command.

o    You will be sourcing the MoH locally on a SCCP “server” (SRST gateway) and 
no MGCP traffic will be traversing the WAN.

o    Otherwise, you will be on hold for exactly 30 seconds.  When testing, stay 
on hold for at least 1 minute.

I just went through Vol 1 Lab 7 Question 7.2, where you setup MMOH over the WAN 
to BR1.  I did some testing and verified that this command was not needed to 
maintain a connection between the PSTN phone and BR1 Phone 2.

Has anyone else seen this?

--

Matthew Berry

A+, CCENT, CCNA, CCNA Voice, CCVP, CCIE Written



Gmail: ciscovoiceguru

Skype: ciscovoiceguru

Twitter: ciscovoiceguru

1st Lab Attempt: Aug 16, 2010

NOTICE: This electronic mail message and any files transmitted with it are 
intended
exclusively for the individual or entity to which it is addressed. The message,
together with any attachment, may contain confidential and/or privileged 
information.
Any unauthorized review, use, printing, saving, copying, disclosure or 
distribution
is strictly prohibited. If you have received this message in error, please
immediately advise the sender by reply email and delete all copies.


NOTICE: This electronic mail message and any files transmitted with it are 
intended
exclusively for the individual or entity to which it is addressed. The message,
together with any attachment, may contain confidential and/or privileged 
information.
Any unauthorized review, use, printing, saving, copying, disclosure or 
distribution
is strictly prohibited. If you have received this message in error, please
immediately advise the sender by reply email and delete all copies.

NOTICE: This electronic mail message and any files transmitted with it are 
intended
exclusively for the individual or entity to which it is addressed. The message, 
together with any attachment, may contain confidential and/or privileged 
information.
Any unauthorized review, use, printing, saving, copying, disclosure or 
distribution 
is strictly prohibited. If you have received this message in error, please 
immediately advise the sender by reply email and delete all copies.

<<inline: moz-screenshot-9.png>>

_______________________________________________
For more information regarding industry leading CCIE Lab training, please visit 
www.ipexpert.com

Reply via email to