Send cisco-voip mailing list submissions to
[email protected]
To subscribe or unsubscribe via the World Wide Web, visit
https://puck.nether.net/mailman/listinfo/cisco-voip
or, via email, send a message with subject or body 'help' to
[email protected]
You can reach the person managing the list at
[email protected]
When replying, please edit your Subject line so it is more specific
than "Re: Contents of cisco-voip digest..."
Today's Topics:
1. Re: Analyzing registration failures after the fact (Ryan Ratliff)
2. Re: Analyzing registration failures after the fact (Daniel Clark)
3. CUEAC conference limitation (Jefflin Choi)
4. Re: CUEAC conference limitation
(Jamie Gale -X (jamgale - Arc Solutions at Cisco))
----------------------------------------------------------------------
Message: 1
Date: Mon, 15 Jul 2013 12:25:34 -0400
From: Ryan Ratliff <[email protected]>
To: Domain Admin <[email protected]>
Cc: cisco-voip voyp list <[email protected]>
Subject: Re: [cisco-voip] Analyzing registration failures after the
fact
Message-ID: <[email protected]>
Content-Type: text/plain; charset="iso-8859-1"
When the phones register back they will send an alarm to the server with text
indicating the unregistration reason from their previous server. That alarm
will be in the syslogs as Erick noted.
Do you require all endpoints to use vpn to get access to the CUCM servers or is
the fact that the phones were trying to vpn what you are trying to figure out?
Which node(s) run TFTP and how is your DHCP option 150 configured?
-Ryan
On Jul 15, 2013, at 11:31 AM, Erick Wellnitz <[email protected]> wrote:
Registration issues usually show up in the syslog or alternate syslog.
On Mon, Jul 15, 2013 at 10:07 AM, Domain Admin <[email protected]> wrote:
Hey folks,
In short, how can I troubleshoot IP phones failing to register to CallManager
over a day after the issue was resolved? Background below. CallManager
version is 8.6.
I just started following this mailing list last week. I've been learning UCM
administration for about a year, and I inherited a 5-node cluster to worry
about around six months ago. I'm doing okay with the day-to-day stuff, but
there's still a lot of maintenance and administration stuff that really need to
learn more about.
Our cluster runs on two ESX clusters (1 publisher and 2 subs on 1; 2 subs on
the other for DR), and our engineer asked for my help to bring down the side
with the publisher so he could upgrade ESX from 4.1 to 5.0.
ICM and CVP (also my responsibility...whoo...) were on the same cluster, and I
was mainly worried about those coming back up, so I didn't pay enough attention
to the CM nodes to make sure the phones re-registered. Luckily, the call
center, which runs off the first subscriber came up fine.
I didn't find out until Sunday afternoon that all except for a handful of
phones at HQ failed to register. A developer who came in to work on the
weekend noticed that the phones were displaying, "VPN Authentication Failed".
Sure enough, I could see the phones' IP addresses from the publisher, but they
were listed as Unregistered. I checked the status messages on one of the
phones' web interfaces, and it reported, "All Concentrators Failed." This
occurred on all except 2 of about 200 on-site phones. The phones that DO
connect via VPN all appeared to be registered by the time I took a look.
I went in to the office on Sunday and manually reset all the phones (**#**) in
order to make sure there was no service disruption on Monday morning, but now
my manager is asking me to find the root cause as-to why this issue occurred,
and I'm not sure where to start. The logs on the individual phones don't
appear to go back far enough, and I'm not versed enough with RTMT to know where
to look.
Do you guys know where I can look to try and find out what happened here? I
suspect that it was the Auto-Network Detect feature in the VPN profile that got
me. I turned it off in one of my troubleshooting steps, but I'd like to be
able to say for sure when I present it to the company.
What sucks is that the CM groups are configured so that Subscriber 1 on the
first cluster should failover to Sub 3 on the second, and Sub 2 (the one that
should have registered the HQ phones) should have failed over to Sub 4, also on
the second cluster. I do not know why the phones would have failed to register
in the first place.
Thanks!
Daniel
_______________________________________________
cisco-voip mailing list
[email protected]
https://puck.nether.net/mailman/listinfo/cisco-voip
_______________________________________________
cisco-voip mailing list
[email protected]
https://puck.nether.net/mailman/listinfo/cisco-voip
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<https://puck.nether.net/pipermail/cisco-voip/attachments/20130715/3b4737e6/attachment-0001.html>
------------------------------
Message: 2
Date: Mon, 15 Jul 2013 15:01:30 -0400
From: Daniel Clark <[email protected]>
To: Ryan Ratliff <[email protected]>
Cc: cisco-voip voyp list <[email protected]>
Subject: Re: [cisco-voip] Analyzing registration failures after the
fact
Message-ID:
<cajties_m-lg_xxprgwad9ufz710ryw0sbmdxmje9hdamjbu...@mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
Thanks for the responses guys.
I'm trying to use the SysLog Viewer in RTMT, and it keeps telling me, "File
does not exist". Any idea what might cause that?
If I do a Collect File action, which file(s) am I pulling down exactly?
For your questions, the configuration when I inherited the system was that
all phones had the VPN profile assigned, but all except for a handful are
on the local network, and should never need to look for the VPN server
(which doesn't resolve while on-site). I guess the thought was that users
could take them home if they ever needed to, but I'd prefer to know when
they want to do that, so I think I'll create a new Common Phone Profile and
remove that option on the HQ phones.
TFTP is turned on for the Publisher, and subscribers 2 (the one the phones
failed to register to), and 4 (which is on the DR side). That is odd,
because I thought it was only supposed to run on the publisher, or on a
dedicated node. As for Option 150, I'll get back to you on that. We've
got Dell switches in most of our environment, and we had to co-exist with
the legacy system for a long time, so I think we've got some funky configs
there. Our Call Center has the same infrastructure, though, and they came
back up normally. They register to Subscriber 1.
On Mon, Jul 15, 2013 at 12:25 PM, Ryan Ratliff <[email protected]> wrote:
> When the phones register back they will send an alarm to the server with
> text indicating the unregistration reason from their previous server. That
> alarm will be in the syslogs as Erick noted.
>
> Do you require all endpoints to use vpn to get access to the CUCM servers
> or is the fact that the phones were trying to vpn what you are trying to
> figure out?
>
> Which node(s) run TFTP and how is your DHCP option 150 configured?
>
> -Ryan
>
> On Jul 15, 2013, at 11:31 AM, Erick Wellnitz <[email protected]>
> wrote:
>
> Registration issues usually show up in the syslog or alternate syslog.
>
>
> On Mon, Jul 15, 2013 at 10:07 AM, Domain Admin <[email protected]>wrote:
>
>> Hey folks,
>>
>> In short, how can I troubleshoot IP phones failing to register to
>> CallManager over a day after the issue was resolved? Background below.
>> CallManager version is 8.6.
>>
>> I just started following this mailing list last week. I've been learning
>> UCM administration for about a year, and I inherited a 5-node cluster to
>> worry about around six months ago. I'm doing okay with the day-to-day
>> stuff, but there's still a lot of maintenance and administration stuff that
>> really need to learn more about.
>>
>> Our cluster runs on two ESX clusters (1 publisher and 2 subs on 1; 2 subs
>> on the other for DR), and our engineer asked for my help to bring down the
>> side with the publisher so he could upgrade ESX from 4.1 to 5.0.
>>
>> ICM and CVP (also my responsibility...whoo...) were on the same cluster,
>> and I was mainly worried about those coming back up, so I didn't pay enough
>> attention to the CM nodes to make sure the phones re-registered. Luckily,
>> the call center, which runs off the first subscriber came up fine.
>>
>> I didn't find out until Sunday afternoon that all except for a handful of
>> phones at HQ failed to register. A developer who came in to work on the
>> weekend noticed that the phones were displaying, "VPN Authentication
>> Failed". Sure enough, I could see the phones' IP addresses from the
>> publisher, but they were listed as Unregistered. I checked the status
>> messages on one of the phones' web interfaces, and it reported, "All
>> Concentrators Failed." This occurred on all except 2 of about 200 on-site
>> phones. The phones that DO connect via VPN all appeared to be registered
>> by the time I took a look.
>>
>> I went in to the office on Sunday and manually reset all the phones
>> (**#**) in order to make sure there was no service disruption on Monday
>> morning, but now my manager is asking me to find the root cause as-to why
>> this issue occurred, and I'm not sure where to start. The logs on the
>> individual phones don't appear to go back far enough, and I'm not versed
>> enough with RTMT to know where to look.
>>
>> Do you guys know where I can look to try and find out what happened here?
>> I suspect that it was the Auto-Network Detect feature in the VPN profile
>> that got me. I turned it off in one of my troubleshooting steps, but I'd
>> like to be able to say for sure when I present it to the company.
>>
>> What sucks is that the CM groups are configured so that Subscriber 1 on
>> the first cluster should failover to Sub 3 on the second, and Sub 2 (the
>> one that should have registered the HQ phones) should have failed over to
>> Sub 4, also on the second cluster. I do not know why the phones would have
>> failed to register in the first place.
>>
>> Thanks!
>> Daniel
>>
>> _______________________________________________
>> cisco-voip mailing list
>> [email protected]
>> https://puck.nether.net/mailman/listinfo/cisco-voip
>>
>>
> _______________________________________________
> cisco-voip mailing list
> [email protected]
> https://puck.nether.net/mailman/listinfo/cisco-voip
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<https://puck.nether.net/pipermail/cisco-voip/attachments/20130715/4136a6b2/attachment-0001.html>
------------------------------
Message: 3
Date: Tue, 16 Jul 2013 14:43:54 +0800
From: Jefflin Choi <[email protected]>
To: "[email protected]" <[email protected]>
Subject: [cisco-voip] CUEAC conference limitation
Message-ID:
<CAOadGQOyffXTOzdfnwU+UjebK7Fi120fN=8mjew0ngpofqq...@mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
Hi All,
Getting problem from on of our operator console users that they can only
make 4 participant calls. Other operators doesn't have this problem at all.
comparing settings, i don't see any difference at all.
line 4 and busy trigger 2.
While testing on my PC, i could not make any conference call at all using
the attendant console software. The conference button is greyed out when i
click an active call.
Using the phone itself i can make a conference call but not with the
attendant console software. Any ideas where i should look?
TIA,
Jeff
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<https://puck.nether.net/pipermail/cisco-voip/attachments/20130716/4dfeb15d/attachment-0001.html>
------------------------------
Message: 4
Date: Tue, 16 Jul 2013 13:20:06 +0000
From: "Jamie Gale -X (jamgale - Arc Solutions at Cisco)"
<[email protected]>
To: Jefflin Choi <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [cisco-voip] CUEAC conference limitation
Message-ID:
<[email protected]>
Content-Type: text/plain; charset="iso-8859-1"
Jefflin,
I would suggest taking a look at the link below to see how to conference using
the console, this should help:
https://www.youtube.com/channel/UC3jC1gmgsRWPR4PLR2VWBhA?feature=CCQQwRs?
Kind Regards
Jamie Gale
Technical Marketing Engineer, Cisco Unified Attendant Consoles
Arc Solutions, onsite at Cisco
[email protected]<mailto:[email protected]>
D +1 919 392 4671
M +1 919 699 4910
Find our new Cisco Unified Attendant Console End User training videos at
https://www.youtube.com/channel/UC3jC1gmgsRWPR4PLR2VWBhA?feature=CCQQwRs%3D
Join the Cisco Unified Attendant Console Forum at Arc Solutions!
http://forum.arcsolutions.com/forumdisplay.php?f=4
On Jul 16, 2013, at 2:43 AM, Jefflin Choi
<[email protected]<mailto:[email protected]>> wrote:
Hi All,
Getting problem from on of our operator console users that they can only make 4
participant calls. Other operators doesn't have this problem at all.
comparing settings, i don't see any difference at all.
line 4 and busy trigger 2.
While testing on my PC, i could not make any conference call at all using the
attendant console software. The conference button is greyed out when i click an
active call.
Using the phone itself i can make a conference call but not with the attendant
console software. Any ideas where i should look?
TIA,
Jeff
_______________________________________________
cisco-voip mailing list
[email protected]<mailto:[email protected]>
https://puck.nether.net/mailman/listinfo/cisco-voip
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<https://puck.nether.net/pipermail/cisco-voip/attachments/20130716/a92157b0/attachment-0001.html>
------------------------------
Subject: Digest Footer
_______________________________________________
cisco-voip mailing list
[email protected]
https://puck.nether.net/mailman/listinfo/cisco-voip
------------------------------
End of cisco-voip Digest, Vol 117, Issue 13
*******************************************
