I don't believe the 7941 is selectable as a configurable phone, by default,
on CM 4.1. In order to set up a 7941, you have to install a device pack
(ciscocm.4-1-DevPack-59.exe) . After you do this, you should be able to go
into CM, see it as a selectable device, and install. The 7940, by
contras
All, I am checking to see if you have had issues with using 7941 phones
connecting to the call managers. I have had issues over the past couple
of runs and finally I swapped out a couple of 7941 phones with 7940/7960
series phones and they worked like a charm. The 7941 phones seem to
work fine r
You are right Stephen...
It didn't work for me either!
So... either this parameter is for other function, or just for Intercluster
truks.. as CallManager help says:
*Stop Routing on Unallocated Number Flag :*
*Stop Routing on Unallocated Number Flag :* This parameter determines
routing behav
Stephen,
I think i have tested it.. dont remember now, i always set this parameter to
false... I still have 1 hour in this lab, will re-test it and let you know.
//r.a.
On Sat, Oct 25, 2008 at 2:22 PM, Stephen Collinson <
[EMAIL PROTECTED]> wrote:
> Thanks Ricardo,
>
>
>
> Have you tested thi
Thanks Ricardo,
Have you tested this scenario?
I did this type of test get different results from you. This scenario does
not seem to be controlled by this particular parameter.
Changing value form TRUE to FALSE and back did not impact the CCM trying GW
after GK fails.
I shut the s
Jonny,
Lets say that you hace an extension 3001 in BR2, BR2 and CCM are registered
to GK, the normal path from 1001 in CCM to 3001 in BR2 y through GK, that
means first RG in the RL.
Now... suddenly the BR2-WAN is down, or BR2 get unregistered from GK for any
reason (no gateway command in br2 for
Michael,
Thanks for the response, much appreciated.
You say it covers ANY scenario where the GW or GK can not complete the call.
Is this correct?
My understanding was it comes into play when the cause code returned for a
call failure is 'unallocated number'. Something like ISDN cause code 0x81.
Everyone uses it. Basically what it does - when call goes to a gateway or
gatekeeper, and the gateway cannot complete the call (for whatever reason -
remote side is down, no bandwidth, etc.), CallManager continues searching for
other Route Grous in the Route List. Without this parameter (when it
It is needed on T1 CAS, FXO and FXS ports, but not on T1 PRI since it is
doing layer3 protocol tunneling.
Balamurugan Singaram wrote:
Hi,
For Cisco IOS Software Release 12.3(7)T or later the Pots dial-peer
configuration for MGCP gateway should like below or even "service
mgcpapp" is not nee
Anyone got scenarios where we would specifically use this param.
Thanks
Only if you are putting analog puts under MGCP control do you need the
POTS peer under service of MGCPAPP.
Cheers!
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Mo
Sent: Saturday, October 25, 2008 5:10 AM
To: [EMAIL PROTECTED]
Cc: ccie_voice@onlinestudylist.com
Subject: R
I had read somewhere you don't need service MGCPAPP under dial-peer
for getting the MGCP to work , I think it was on cisco forum . and the
reason was when MGCP fallback happens . you can do a search on that one , I
tested this in LAB and without "Service MGCPAPP" everything worked fine even
when o
12 matches
Mail list logo