I am wondering here... Isn't this "Connection Monitor Duration" the time it will take for the phones to ENTER SRST?
I need to prevent the phones from coming out of SRST. In other words, I want it to stay in SRST. I will try now with the ACL. :) *Antonio Emanuel Damasceno* CCNA, CCNA Voice, CCNP Voice, CCIE Voice (written) CompTIA Network+ On Wed, Nov 9, 2011 at 12:44 AM, James Key <j...@jackhenry.com> wrote: > Just add an ACL denying the CUCMBE IP and apply to the WAN interface at > the location you want phones to go into SRST. Another way is to add a > null route to CUCMBE on this gateway. Have to be careful with this > though if you are redistributing statics. ip route x.x.x.x255.255.255.255 > null0 > > > > > > James Key > > > > > > > > ** **** > > ------------------------------ > *From:* ccie_voice-boun...@onlinestudylist.com [ > ccie_voice-boun...@onlinestudylist.com] On Behalf Of Emanuel Damasceno [ > aedamasc...@gmail.com] > *Sent:* Tuesday, November 08, 2011 7:18 PM > *To:* ccie_voice@onlinestudylist.com > > *Subject:* Re: [OSL | CCIE_Voice] SRST keepalive time > > Thanks for the replies. > > It didn't work. The customer has a centralized solution with 2 sites. His > two sites use MGCP, but unfortunately his environment is a screwy solution. > He has EVERYTHING on VLAN 1. I explained to him many times he needed to > segregate his VLANs and use QoS for his WAN. But we have to work with this > CRAPPY solution for the time being... > > This is what he needs (I'll try to be as specific as I can). > > His screwed up WAN link is a 2MBps (I highly doubt this) without any QoS > applied (neither in his side or his SP). The link is very unstable and his > phones on the remote site keeps coming back and forth from SRST. Since it > keeps doing it for so long, the phones keep just being out of its service, > because it registers, then there is a problem with the link and all his > phones in the remote site tries to go to SRST mode, but then all of the > sudden the link is back and the phones try to go back to CUCM. > > He was asking me to put a 12 hour (yes, who doesn't have a customer like > this...) before the phones tried to connect with CUCM again. In other > words, he wanted to let the phones in SRST mode for a few hours until he > fixes his problem with the link. So, I tried the command ccm-manager > switchback uptime-delay "minutes", and we simulate a WAN outage. The > phones entered SRST (well, at least he said it was. I am the remote > support), but when he turned on the CUCM back, the phones registered right > away. Even after setting the time for two hours. > > So, we went on Enterprise Parameters and changed the "connection duration > monitor" but I didn't do it clusterwise. I did it on the device pool on the > remote site. Now, the phones didn't register to SRST so none of the phones > were making any calls or receiving it (that's why I wonder his SRST > solution never worked in the first place). So I rolled back to the standard > settings and I told him I'd study his solution and give him back an answer. > Honestly, knowing what he has, I think this won't work, but can you guys > give me any ideas? > > I appreciate it. > > *Antonio Emanuel Damasceno* > CCNA, CCNA Voice, CCNP Voice, CCIE Voice (written) > CompTIA Network+ > > > > > On Tue, Nov 8, 2011 at 2:44 PM, Emanuel Damasceno > <aedamasc...@gmail.com>wrote: > >> Hello experts, >> >> I currently have a customer who has CUCMBE in his environment with SRST >> enabled. His voice gateway is over a WAN link, and the link is unstable. >> His phones keep registering back and forth, and now he wants to keep his >> phones in SRST mode for a little longer than usual. His configs are >> call-manager-fallback based (no CME as SRST)... How can I achieve this? Is >> it through CUCMBE or his CME? His gateway is MGCP. >> >> Thanks >> *Antonio Emanuel Damasceno* >> CCNA, CCNA Voice, CCNP Voice, CCIE Voice (written) >> CompTIA Network+ >> >> >> > 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 Are you a CCNP or CCIE and looking for a job? Check out www.PlatinumPlacement.com
