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. OT: BBC News - Telegrams STOP: End of service delivering joy
and heartache (Lelio Fulgenzi)
2. Re: SIP between CUCM clusters (Russell Chaseling)
3. Analyzing registration failures after the fact (Domain Admin)
4. Re: Analyzing registration failures after the fact
(Erick Wellnitz)
----------------------------------------------------------------------
Message: 1
Date: Sun, 14 Jul 2013 17:27:23 -0400 (EDT)
From: Lelio Fulgenzi <[email protected]>
To: cisco-voip voyp list <[email protected]>
Subject: [cisco-voip] OT: BBC News - Telegrams STOP: End of service
delivering joy and heartache
Message-ID: <[email protected]>
Content-Type: text/plain; charset=us-ascii
hmmmm, was the telegram the predecessor or email? or FoIP? ;)
http://www.bbc.co.uk/news/magazine-23271384
Sent from my iPhone
------------------------------
Message: 2
Date: Mon, 15 Jul 2013 09:13:41 +0100
From: Russell Chaseling <[email protected]>
To: Carlo Calabrese <[email protected]>, "'Erick
Wellnitz'" <[email protected]>
Cc: 'Cisco-voip' <[email protected]>
Subject: Re: [cisco-voip] SIP between CUCM clusters
Message-ID:
<[email protected]>
Content-Type: text/plain; charset="us-ascii"
Thank very much Carlo....think I'll try the SIP trunk and see how I go. I'll
reply to this and let all know whether the CUEAC BLF works between clusters as
expected
From: Carlo Calabrese [mailto:[email protected]]
Sent: 12 July 2013 19:43
To: Russell Chaseling; 'Erick Wellnitz'
Cc: 'Ryan Ratliff'; 'Cisco-voip'
Subject: RE: [cisco-voip] SIP between CUCM clusters
I only noticed it for endpoints. Don't think we had any problems with gateways.
For PSTN I have as SIP. ICT which are H323 based and I have several MGCP QSIG
trunks
So my path is
PSTN -> SIP -> CUCM -> ICT -> CUCM -> QSIG -> PBX
I haven't had a problem with the QSIG gateway only phones when one is a SIP and
the other is SCCP.
When we started having problems, most of the complaints were about dropped
calls or not hearing the other end. Found that the call would connect but the
RTP path would not get built.
From: Russell Chaseling [mailto:[email protected]]
Sent: Friday, July 12, 2013 9:33 AM
To: Carlo Calabrese; 'Erick Wellnitz'
Cc: 'Ryan Ratliff'; 'Cisco-voip'
Subject: RE: [cisco-voip] SIP between CUCM clusters
Excellent tips. Thanks guys
When you say SIP to H323 back to SIP are you talking about endpoints? My other
concern is that one of these CUCM clusters already has a H323 ICT to a 3rd 8.X
cluster. Calls need to be able to traverse through all of them but presence
only shared between the 1st two and there are MGCP QSIG and H323 ISDN gateways
hanging off all of them - I suspect I will run into more problems that will out
way any possible benefits like presence sharing.
for the simple reason that I believe that presence status can be shared between
the two ie IP Phone BLF and CUEAC BLF (particularly CUEAC BLF)
1) First questions is have I heard this right? Will BLF work between 2 x
CUCM clusters?
2) Has anyone deployed SIP trunks between clusters in production? If so is
it worth the pain?
Cheers
Russell
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<https://puck.nether.net/pipermail/cisco-voip/attachments/20130715/9c83d2fd/attachment-0001.html>
------------------------------
Message: 3
Date: Mon, 15 Jul 2013 11:07:50 -0400
From: Domain Admin <[email protected]>
To: cisco-voip <[email protected]>
Subject: [cisco-voip] Analyzing registration failures after the fact
Message-ID:
<CAJtieS-08nyU-N-hW4BO87Vg=sn4imsukkpqmjfwhbdb+79...@mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<https://puck.nether.net/pipermail/cisco-voip/attachments/20130715/a9ad9363/attachment-0001.html>
------------------------------
Message: 4
Date: Mon, 15 Jul 2013 10:31:09 -0500
From: Erick Wellnitz <[email protected]>
To: Domain Admin <[email protected]>
Cc: cisco-voip <[email protected]>
Subject: Re: [cisco-voip] Analyzing registration failures after the
fact
Message-ID:
<cak0wosar_yzeny_jf-ubcsvwv_d-7gxfqtwf2k_arljq1fe...@mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<https://puck.nether.net/pipermail/cisco-voip/attachments/20130715/12dcd576/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 12
*******************************************
