they advised you call from the pstn On Sun, Mar 28, 2010 at 7:56 PM, James Key <j...@jackhenry.com> wrote:
> 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. > > > > 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] > *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 [ > ccie_voice-boun...@onlinestudylist.com] On Behalf Of Matthew Berry [ > 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. > > > _______________________________________________ > For more information regarding industry leading CCIE Lab training, please > visit www.ipexpert.com > >
<<moz-screenshot-9.png>>
_______________________________________________ For more information regarding industry leading CCIE Lab training, please visit www.ipexpert.com
