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: CallManager Auto-Registration trick for 1 number
(Nate VanMaren)
2. RTMT alerts about SDL link & nbslogpd messages dropped
(abbas Wali)
3. Re: 9.3.1 , TVS, and IPv6 (Jason Burns)
4. Re: Caller ID restrictions and Unity Connection (Peter Slow)
5. Re: 9.3.1 , TVS, and IPv6 (Tom Piscitell (tpiscite))
6. CUCM v9 (cisco.voip)
7. Re: CUCM v9 (Nicholas Samios)
8. TAPI Client 64bits version for Call Manager 8.5 (Isamar Maia)
9. Re: TAPI Client 64bits version for Call Manager 8.5
(Buchanan, James)
10. Re: TAPI Client 64bits version for Call Manager 8.5 (Isamar Maia)
11. post TAC case survey questions (Lelio Fulgenzi)
12. Re: TAPI Client 64bits version for Call Manager 8.5
(Buchanan, James)
13. Re: post TAC case survey questions (Lelio Fulgenzi)
14. Re: TAPI Client 64bits version for Call Manager 8.5 (Scott Voll)
----------------------------------------------------------------------
Message: 1
Date: Wed, 7 Nov 2012 17:00:02 +0000
From: Nate VanMaren <[email protected]>
To: "Jason Aarons (AM)" <[email protected]>, "cisco-voip
([email protected])" <[email protected]>
Subject: Re: [cisco-voip] CallManager Auto-Registration trick for 1
number
Message-ID:
<[email protected]>
Content-Type: text/plain; charset="us-ascii"
It will only give out extensions that don't exist at all. So you can do 6001
to 6002 and create 6002 manually.
From: [email protected]
[mailto:[email protected]] On Behalf Of Jason Aarons (AM)
Sent: Wednesday, November 07, 2012 7:10 AM
To: cisco-voip ([email protected])
Subject: [cisco-voip] CallManager Auto-Registration trick for 1 number
I have 1 phone want to get 6001 and I want to turn on auto-registration and
ensure I only give out 6001 as that extension.
I don't see a way to set range 6001 to 6001 as that disables auto registration.
If I setup 6001 to 6002 it's possible that phone could get 6002. Is there a
trick/fix for this? Or no?
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<https://puck.nether.net/pipermail/cisco-voip/attachments/20121107/873adfe9/attachment-0001.html>
------------------------------
Message: 2
Date: Wed, 7 Nov 2012 17:03:26 +0000
From: abbas Wali <[email protected]>
To: [email protected]
Subject: [cisco-voip] RTMT alerts about SDL link & nbslogpd messages
dropped
Message-ID:
<CAFdHCp7=_ci1puqos2pgfaiz8t1j1mefmyb0oco5odbdyk5...@mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
Hi all,
earlier we had some phones restarted with calls dropped. RTMT sent the
below alerts
----
At Wed Nov 07 14:10:19 GMT 2012 on node 172.30.213.75, the following
SyslogSeverityMatchFound events generated:
SeverityMatch : Alert
MatchedEvent : Nov 7 14:09:39 CCM-SUB3 local7 1 ccm: 1769835: CCM-SUB3:
Nov 07 2012 14:09:39.509 UTC : %UC_CALLMANAGER-1-SDLLinkOOS:
%[LocalNodeId=4][LocalApplicationID=100][RemoteIPAddress=172.30.213.15][RemoteNodeID=3][RemoteApplicationID=100][LinkID=4:100:3:100][AppID=Cisco
CallManager][ClusterID=StandAloneCluster][NodeID=NCCHQ-CCM-SUB3]: SDL link
to remote application is out of service AppID : Cisco Syslog Agent
ClusterID :
NodeID : CCM-SUB3
TimeStamp : Wed Nov 07 14:09:39 GMT 2012
SeverityMatch : Alert
MatchedEvent : Nov 7 14:09:39 CCM-SUB3 syslog 1 nbslogpd[6237]: 68
messages were dropped
AppID : Cisco Syslog Agent
ClusterID :
NodeID :CCM-SUB3
TimeStamp : Wed Nov 07 14:09:40 GMT 2012
---------
apparently sub3 lost communication with sub2. (we had another alert saying
the reverse -sub2 lost it with sub3). can not find a valid reason of why
this could have happened. checked the sub2 alternative syslogs in the RTMT
but can only find some regular station connection errors and end point
unregistered.
any ideas please!!
thanks
--
@bbas..
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<https://puck.nether.net/pipermail/cisco-voip/attachments/20121107/91936e3d/attachment-0001.html>
------------------------------
Message: 3
Date: Wed, 7 Nov 2012 13:38:43 -0500
From: Jason Burns <[email protected]>
To: Stephen Welsh <[email protected]>, "Tom Piscitell
(tpiscite)" <[email protected]>
Cc: "<[email protected]>" <[email protected]>, Adam
Pawlowski <[email protected]>
Subject: Re: [cisco-voip] 9.3.1 , TVS, and IPv6
Message-ID:
<CAGmgRW_Hhw3h_TY+hrbJ_6yNsvYruQFQMA+sAuZQBct=wxs...@mail.gmail.com>
Content-Type: text/plain; charset="windows-1252"
Adam,
I've seen this exact same thing with some of my customers. Here's what I
think caused the whole IPv6 problem on the phone:
1. CUCM cluster was upgraded.
2. Pub and TFTP servers were rebooted.
3. Backup subs were rebooted.
4. Primary subs were rebooted.
5. Phones reset and try to get a TFTP file from the TFTP server.
Here's where the problem is. The phones tried to get a TFTP file, but the
TFTP server hadn't completed database replication yet. The phones
downloaded a non complete config file, or a non complete ITL file. This ITL
or config file (i never did figure out which) put the phone into a mode
where for every single TVS request it tried to use the IPv6 stack on the
phone. You'd see on the phone console logs that the phone tried to connect
to TVS and it timed out. You'd never see any packets leave the phone to TCP
2445 in a packet capture.
I believe we fixed the problem by shutting down the primary TFTP server and
letting the phones use the backup TFTP server. This worked because the
phones had an ITL that was signed by the backup TFTP server so they trusted
the backup TFTP server's key. The ITL file they had though, or the config
file wouldn't let TVS work.. we needed to find the server that signed the
phone's file and get the phone to go BACK to that original server so it
could get a complete config file.
Either do that or erase the ITL manually from the phone (or use an
automated tool). I'm including Tom here because he worked on this problem
and may remember the details more accurately. I don't know if we ever found
a bug for this.
There are automated tools that make erasing the ITL easier, but for your
case if you have more than one TFTP server try either:
1. Shutting down the primary TFTP service and resetting the phones so they
go to backup.
2. Changing the DHCP scope so they go to the backup.
3. Change the TFTP address manually in a phone to point to another server.
Hope that points you in the right direction.
-Jason
On Mon, Nov 5, 2012 at 11:46 AM, Stephen Welsh
<[email protected]>wrote:
> Absolutely correct Dennis ;)
>
> That is a valid approach as long as the phone 'trusts' the
> callmanager.pem certificate used by the TFTP service, however if it does
> not you need to get the phones ITL file updated before you can remove it.
> There are two main ways to do that:
>
> 1) Get the TVS service to update the phones ITL File (sometimes a
> restart of the TVS Service, or regenerating the Callmanager.pem cert works)
> 2) Delete the ITL file on the phone
>
> Option 1 doesn't always work and can cause further issues that need to
> be considered/managed (Catch-22)
> Option 2 generally always works
>
> It's too easy to get stuck in a catch-22 with SBD related issues, the
> combination of certificates, phone configuration and TVS service all lead
> back to each other in a nasty loop, from our experience the easiest way to
> break the look is delete the ITL file on the phone's user interface.
>
> I'm not stating that remotely deleting the ITL file from all your phones
> is the ideal solution to the problem, just that in reality it is the best
> solution that is proven to work when other approaches can fail at points.
>
> Thanks
>
> Stephen
>
> On 5 Nov 2012, at 16:30, "Heim, Dennis" <[email protected]>
> wrote:
>
> The article also talks about setting the rollback parameter to true,
> which will erase the ITL on the phones. Obviously this requires that your
> phones can still register.****
>
> *Dennis Heim | Sr. UC Engineer***
> World Wide Technology | 314.212.1814 | [email protected]**
> ?Creating Impact, Ignition & Scalability?****
>
> *From:* [email protected] [mailto:cisco-
> [email protected]] *On Behalf Of *Stephen Welsh
> *Sent:* Monday, November 05, 2012 11:06 AM
> *To:* Adam Pawlowski
> *Cc:* <[email protected]>
> *Subject:* Re: [cisco-voip] 9.3.1 , TVS, and IPv6****
> ** **
> Hi Adam,****
> ** **
> As you stated (very nicely :), everyone that upgrades to (or between)
> UCM 8 & 9 versions needs to understand SBD. Unfortunately even if you do
> everything right you can still get hit by a SBD/ITL problems, there are
> several different ways to get caught out even if you go 100% by the book.*
> ***
> In our experience the best way to handle almost any SBD issue is
> deleting the ITL File, there are some steps to prevent issues, but they are
> never 100% fool-proof, the best thing to do is be prepared to 'easily'
> manage/delete those pesky ITL files ;)****
> ** **
> If you haven't already found this, the best information on Security by
> Default is by Jason Burns:****
> ** **
> https://supportforums.cisco.com/docs/DOC-17679****
> ** **
> I completely appreciate your point of view that the last thing you
> should "have" to do is delete the ITL file, if you read Jason's document
> this will give you the best understanding and chance to eliminate (or
> minimise) this likely hood. However I always recommend that you have a
> Plan-B, Unified FX has devised an approach (a way to configure your
> cluster) that will ensure that you will never need to physically go to a
> phone to delete an ITL files even in the worst and most rare SDB Issues.
> Believe me the issue you have at the moment is nothing compared to some of
> the SBD problems we have had to solve, at least your phones are still
> registered ;)****
> ** **
> Thanks****
> ** **
> Stephen Welsh, CCIE #12345****
> CTO****
> Unified FX****
> http://www.unifiedfx.com****
> ** **
> On 5 Nov 2012, at 15:37, Adam Pawlowski <[email protected]>****
> wrote:****
>
>
> ****
> Stephen,****
> ****
> Removing the ITL file from the phone does seem to allow it to grab
> a new one, since it doesn?t need to verify it. When the phone is booting
> up, it lists, from a file on its flash, that it has no TVS servers, until
> it has read the configuration file and established the CM nodes from that
> device pool. TVS is running on all hosts in the cluster, including the
> TFTP, which it seems to want to fall back to, to verify its configuration
> and ITL initially. For whatever reason it insists on using the TFTP, yet,
> it wants to connect via IPv6 which just can?t work and doesn?t. It?s placed
> me into a situation where I want to turn off V6 but, have to do so in the
> phone?s config, and can?t change the phone?s config until I turn off V6 (or
> erase the ITL).****
> ****
> I will inspect the ITL on the phone again to see what?s going on ?
> the nodes should all be listed but the ITLs hash has changed. I?d love to
> understand just what is going on with this. As we were talking earlier
> about here, the license documentation for the 8 upgrades should have come
> with a singing telegram or at least a stack of bright red paper drawing our
> attention to this feature. There?s a lot that?s new in the UCM and it seems
> easy to get underwater on the everything that comes up, but this just seems
> too easy to run afoul of bugs or problems which can hose over your cluster.
> If we have to erase, we have to erase, but, I don?t want to get into the
> habit of planning to or having to erase security certificates if there?s a
> way to correct the issue.****
> ****
> Thanks much though for your time and reply****
> ****
> Adam****
> ****
> *From:* Stephen Welsh [mailto:[email protected]]
> *Sent:* Monday, November 05, 2012 9:09 AM
> *To:* Pawlowski, Adam
> *Cc:* [email protected]
> *Subject:* Re: [cisco-voip] 9.3.1 , TVS, and IPv6****
> ****
> Hi Adam,****
> ****
> Are you sure the ipv6 thing is not a red herring?****
> ****
> Have you tried removing the ITL File from the phone and/or restarting
> the TVS service?****
> ****
> If you are not aware the choice of TVS service (node IP Address) is
> based on the Call Manager Group configured on the phone, you could try
> adding all nodes to the phones CM Group to see if that helps the phone to
> contact a TVS service it has a matching ITL entry for.****
> ****
> If you are still stuck I'm happy to host a WebEx session to share my
> SDB & ITL experiences, I'm the original author of PhoneView (
> http://www.unifiedfx.com), it's been used to help a LOT of people with
> SBD related issues, never-mind countless UCM installations and upgrades.**
> **
> ****
> In-case you do need to delete/manage your ITL Files, or even just get a
> proper view/handle on the phone firmware version of your estate you should
> give PhoneView a try:****
> ****
> http://www.unifiedfx.com/phoneview/trial****
> ****
> Thanks****
> ****
> Stephen****
> ****
> On 5 Nov 2012, at 13:51, "Pawlowski, Adam" <[email protected]>****
> wrote:****
>
>
>
> ****
> Morning list,****
> ****
> From what I can read, TVS has been a thrill ride for those of us
> lucky enough to run afoul of SBD. I?m hoping we haven?t run into such a
> situation here but I have a question. We just pushed 9.3.1 out to devices
> from 9.1.1SR1, with peer firmware sharing enabled. This went miserably and
> left a lot of devices stranded at 9.1.1 or at an ?Upgrading? screen.
> Working with TAC on that but so far nothing. We began receiving reports
> from end users that their directories were missing, they can?t change
> ringers, etc. Last time this happened we had phones that had picked up a
> bum ITL from a partial rollout, and we had to erase them by hand.****
> ****
> This time that shouldn?t have been the case ? it was just a
> firmware upgrade. However, it looks like some of the phones that have gone
> to 9.3.1 have decided that they want to use IPv6 when talking to the TFTP
> to verify their initial configurations, when they have no TVS server list
> built on the device. In looking at the phone console logs, you can see that
> the device is in ?IP mode 1? and tries to connect to TFTP, say ?192.168.0.1
> :: ? which is obviously not a V6 address. We?re not running V6 so it has no
> address bound. No traffic leaves the phone, but, the phone says it timed
> out (EAGAIN) connecting to the TFTP and won?t verify the ITL/CFG/etc.****
> ****
> What I?m looking at it is setting V6 to off at the cluster, but,
> I don?t see any way to repair this on affected devices (could be a large
> amount) other than erasing the ITL, or deploying IPv6. Given the leg work
> that could go into identifying and taking care of these devices, it?s
> arguable as to which one would be harder at this point.****
> ****
> Any comment on this with this firmware? Anyone else run into this
> miserable trouble?****
> ****
> Adam Pawlowski****
> SUNYAB Network and Classroom Services****
> _______________________________________________
> 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/20121107/5d8658aa/attachment-0001.html>
------------------------------
Message: 4
Date: Wed, 7 Nov 2012 15:49:47 -0500
From: Peter Slow <[email protected]>
To: Kenneth Hayes <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [cisco-voip] Caller ID restrictions and Unity Connection
Message-ID: <[email protected]>
Content-Type: text/plain; charset="utf-8"
Seems like overkill and like there ought to be another way, but you should be
able to modify anything in your inbound sip signaling with a LUA script as the
SIP call is being received by your cluster.
Sent from my iPhone
On Nov 6, 2012, at 12:49, Kenneth Hayes <[email protected]> wrote:
> Translation Rule and label it as private or unknown I think?
>
> Sent from my iPhone
> Thanks,
> Kenneth W. Hayes
>
>
> On Nov 6, 2012, at 12:48 PM, "Heim, Dennis" <[email protected]> wrote:
>
>> Couldn?t you do a translation profile on the SIP gateway so it doesn?t say
>> anonymous.
>>
>> Dennis Heim | Sr. UC Engineer
>> World Wide Technology | 314.212.1814 | [email protected]
>> ?Creating Impact, Ignition & Scalability?
>>
>> From: [email protected]
>> [mailto:[email protected]] On Behalf Of Kenneth Hayes
>> Sent: Tuesday, November 06, 2012 12:35 PM
>> To: Eric Pedersen
>> Cc: [email protected]
>> Subject: Re: [cisco-voip] Caller ID restrictions and Unity Connection
>>
>> I know on the hunt pilot you can play around with Caller ID stuff but I
>> don't know if that's helpful or not.
>>
>> Sent from my iPhone
>> Thanks,
>> Kenneth W. Hayes
>>
>>
>> On Nov 6, 2012, at 12:26 PM, Eric Pedersen <[email protected]>
>> wrote:
>>
>> They are calls from the PSTN into CUCM and route to the Unity hunt list so
>> there is no route list involved.
>>
>> From: Kenneth Hayes [mailto:[email protected]]
>> Sent: 06 November 2012 10:17 AM
>> To: Eric Pedersen
>> Cc: [email protected]
>> Subject: Re: [cisco-voip] Caller ID restrictions and Unity Connection
>>
>> Do have the restriction set on the route list?
>>
>> Sent from my iPhone
>> Thanks,
>> Kenneth W. Hayes
>>
>>
>> On Nov 6, 2012, at 12:13 PM, Eric Pedersen <[email protected]>
>> wrote:
>>
>> Is there a way to get calls to Unity Connection to obey calling line ID
>> presentation restrictions? We're setting a dummy calling number of
>> 999-999-9999 on our gateways (SIP) for calls coming in on our PRIs with no
>> calling number. I did this because we need to filter calls in CUCM based on
>> calling number, and the SIP gateways by default seem to set the caller to
>> "anonymous" when there is no calling number. Without the gateway translation
>> to set this dummy number, these calls were not making it through the calling
>> number translation patterns.
>>
>> On the matching calling number translation pattern I set the calling line ID
>> presentation to Restricted and it correctly shows Private on phones but the
>> voicemail shows the dummy calling number. The CUCM logs show that it is
>> sending the calling number to CUCX.
>>
>> The dummy number translations on the gateway are a bit convoluted to me so
>> if there is a better way to do this, please let me know.
>>
>> This is CUCM and CUCX 8.6 with a SCCP integration.
>>
>> Thanks,
>> Eric
>>
>>
>>
>> The contents of this message may contain confidential and/or privileged
>> subject matter. If this message has been received in error, please contact
>> the sender and delete all copies. Like other forms of communication,
>> e-mail communications may be vulnerable to interception by unauthorized
>> parties. If you do not wish us to communicate with you by e-mail, please
>> notify us at your earliest convenience. In the absence of such
>> notification, your consent is assumed. Should you choose to allow us to
>> communicate by e-mail, we will not take any additional security measures
>> (such as encryption) unless specifically requested.
>>
>> _______________________________________________
>> cisco-voip mailing list
>> [email protected]
>> https://puck.nether.net/mailman/listinfo/cisco-voip
>> The contents of this message may contain confidential and/or privileged
>> subject matter. If this message has been received in error, please contact
>> the sender and delete all copies. Like other forms of communication,
>> e-mail communications may be vulnerable to interception by unauthorized
>> parties. If you do not wish us to communicate with you by e-mail, please
>> notify us at your earliest convenience. In the absence of such
>> notification, your consent is assumed. Should you choose to allow us to
>> communicate by e-mail, we will not take any additional security measures
>> (such as encryption) unless specifically requested.
> _______________________________________________
> 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/20121107/abf62196/attachment-0001.html>
------------------------------
Message: 5
Date: Wed, 7 Nov 2012 21:21:54 +0000
From: "Tom Piscitell (tpiscite)" <[email protected]>
To: Jason Burns <[email protected]>
Cc: "<[email protected]>" <[email protected]>, Adam
Pawlowski <[email protected]>
Subject: Re: [cisco-voip] 9.3.1 , TVS, and IPv6
Message-ID:
<[email protected]>
Content-Type: text/plain; charset="Windows-1252"
Hey Adam,
This does sounds like the situation me and Jason have ran into a couple times.
Unfortunately we were never able to reproduce it so we never understood exactly
what happened to put the phones in this situation.
However, more specific to your situation, a phone will only need to use TVS to
verify its configuration file if it is using a TFTP server that it did not get
its ITL file from. In the ITL file there is only one CallManager.pem (the
certificate that signs the config files). So if you have an ITL from Server A,
and then try and use Server B for TFTP, you will need to use TVS. However, as
long as you use Server A for TFTP, there will be no need for TVS.
So with that said, it sounds like the phones have an ITL file from some server
other than their primary TFTP server (192.168.0.1??). Alternatively, they may
have an older version of the ITL from the primary TFTP server because the
CallManager.pem was recently regenerated. Let's assume its the former since the
only change was a firmware upgrade. To find out what server the ITL file came
from, we need to compare the hash that shows up in the phone UI (Settings >
Security Settings > Trust List > ITL). You will then need to compare that to
the ITL file on the servers. Here is a quick one-liner to get the hash of the
current ITL on CUCM:
tpiscite-mac:CUCMFolder tompiscitell$ curl http://14.48.30.101:6970/ITLFile.tlv
2>/dev/null | md5
48bf091242356d56dcdbb4aca5d9095e
Note: If you want to do the same for the CTL just replace "ITLFile.tlv" with
"CTLFile.tlv".
Once you find the TFTP server that the ITL file came from, you just need to
point the phones at that (Alternate TFTP, DHCP Option 150, shutting down the
other TFTP server, etc), and have it register. If you cannot find a matching
ITL file on any of the servers, then the phones probably have an old ITL file
and SBD was "broken" for quite a while, but the firmware upgrade uncovered it.
Hope this helps.
Tom Piscitell
Customer Support Engineer
Unified Communications Infrastructure
+1-919-574-0081, 9am-5pm EST (GMT -5)
On Nov 7, 2012, at 1:38 PM, Jason Burns <[email protected]> wrote:
> Adam,
>
> I've seen this exact same thing with some of my customers. Here's what I
> think caused the whole IPv6 problem on the phone:
>
> 1. CUCM cluster was upgraded.
> 2. Pub and TFTP servers were rebooted.
> 3. Backup subs were rebooted.
> 4. Primary subs were rebooted.
> 5. Phones reset and try to get a TFTP file from the TFTP server.
>
> Here's where the problem is. The phones tried to get a TFTP file, but the
> TFTP server hadn't completed database replication yet. The phones downloaded
> a non complete config file, or a non complete ITL file. This ITL or config
> file (i never did figure out which) put the phone into a mode where for every
> single TVS request it tried to use the IPv6 stack on the phone. You'd see on
> the phone console logs that the phone tried to connect to TVS and it timed
> out. You'd never see any packets leave the phone to TCP 2445 in a packet
> capture.
>
> I believe we fixed the problem by shutting down the primary TFTP server and
> letting the phones use the backup TFTP server. This worked because the phones
> had an ITL that was signed by the backup TFTP server so they trusted the
> backup TFTP server's key. The ITL file they had though, or the config file
> wouldn't let TVS work.. we needed to find the server that signed the phone's
> file and get the phone to go BACK to that original server so it could get a
> complete config file.
>
> Either do that or erase the ITL manually from the phone (or use an automated
> tool). I'm including Tom here because he worked on this problem and may
> remember the details more accurately. I don't know if we ever found a bug for
> this.
>
> There are automated tools that make erasing the ITL easier, but for your case
> if you have more than one TFTP server try either:
>
> 1. Shutting down the primary TFTP service and resetting the phones so they go
> to backup.
> 2. Changing the DHCP scope so they go to the backup.
> 3. Change the TFTP address manually in a phone to point to another server.
>
> Hope that points you in the right direction.
>
> -Jason
>
>
>
> On Mon, Nov 5, 2012 at 11:46 AM, Stephen Welsh <[email protected]>
> wrote:
> Absolutely correct Dennis ;)
>
> That is a valid approach as long as the phone 'trusts' the callmanager.pem
> certificate used by the TFTP service, however if it does not you need to get
> the phones ITL file updated before you can remove it. There are two main ways
> to do that:
>
> 1) Get the TVS service to update the phones ITL File (sometimes a restart of
> the TVS Service, or regenerating the Callmanager.pem cert works)
> 2) Delete the ITL file on the phone
>
> Option 1 doesn't always work and can cause further issues that need to be
> considered/managed (Catch-22)
> Option 2 generally always works
>
> It's too easy to get stuck in a catch-22 with SBD related issues, the
> combination of certificates, phone configuration and TVS service all lead
> back to each other in a nasty loop, from our experience the easiest way to
> break the look is delete the ITL file on the phone's user interface.
>
> I'm not stating that remotely deleting the ITL file from all your phones is
> the ideal solution to the problem, just that in reality it is the best
> solution that is proven to work when other approaches can fail at points.
>
> Thanks
>
> Stephen
>
> On 5 Nov 2012, at 16:30, "Heim, Dennis" <[email protected]>
> wrote:
>
>> The article also talks about setting the rollback parameter to true, which
>> will erase the ITL on the phones. Obviously this requires that your phones
>> can still register.
>>
>> Dennis Heim | Sr. UC Engineer
>> World Wide Technology | 314.212.1814 | [email protected]
>> ?Creating Impact, Ignition & Scalability?
>>
>> From: [email protected]
>> [mailto:[email protected]] On Behalf Of Stephen Welsh
>> Sent: Monday, November 05, 2012 11:06 AM
>> To: Adam Pawlowski
>> Cc: <[email protected]>
>> Subject: Re: [cisco-voip] 9.3.1 , TVS, and IPv6
>>
>> Hi Adam,
>>
>> As you stated (very nicely :), everyone that upgrades to (or between) UCM 8
>> & 9 versions needs to understand SBD. Unfortunately even if you do
>> everything right you can still get hit by a SBD/ITL problems, there are
>> several different ways to get caught out even if you go 100% by the book.
>> In our experience the best way to handle almost any SBD issue is deleting
>> the ITL File, there are some steps to prevent issues, but they are never
>> 100% fool-proof, the best thing to do is be prepared to 'easily'
>> manage/delete those pesky ITL files ;)
>>
>> If you haven't already found this, the best information on Security by
>> Default is by Jason Burns:
>>
>> https://supportforums.cisco.com/docs/DOC-17679
>>
>> I completely appreciate your point of view that the last thing you should
>> "have" to do is delete the ITL file, if you read Jason's document this will
>> give you the best understanding and chance to eliminate (or minimise) this
>> likely hood. However I always recommend that you have a Plan-B, Unified FX
>> has devised an approach (a way to configure your cluster) that will ensure
>> that you will never need to physically go to a phone to delete an ITL files
>> even in the worst and most rare SDB Issues. Believe me the issue you have at
>> the moment is nothing compared to some of the SBD problems we have had to
>> solve, at least your phones are still registered ;)
>>
>> Thanks
>>
>> Stephen Welsh, CCIE #12345
>> CTO
>> Unified FX
>> http://www.unifiedfx.com
>>
>> On 5 Nov 2012, at 15:37, Adam Pawlowski <[email protected]>
>> wrote:
>>
>>
>> Stephen,
>>
>> Removing the ITL file from the phone does seem to allow it to grab a
>> new one, since it doesn?t need to verify it. When the phone is booting up,
>> it lists, from a file on its flash, that it has no TVS servers, until it has
>> read the configuration file and established the CM nodes from that device
>> pool. TVS is running on all hosts in the cluster, including the TFTP, which
>> it seems to want to fall back to, to verify its configuration and ITL
>> initially. For whatever reason it insists on using the TFTP, yet, it wants
>> to connect via IPv6 which just can?t work and doesn?t. It?s placed me into a
>> situation where I want to turn off V6 but, have to do so in the phone?s
>> config, and can?t change the phone?s config until I turn off V6 (or erase
>> the ITL).
>>
>> I will inspect the ITL on the phone again to see what?s going on ? the
>> nodes should all be listed but the ITLs hash has changed. I?d love to
>> understand just what is going on with this. As we were talking earlier about
>> here, the license documentation for the 8 upgrades should have come with a
>> singing telegram or at least a stack of bright red paper drawing our
>> attention to this feature. There?s a lot that?s new in the UCM and it seems
>> easy to get underwater on the everything that comes up, but this just seems
>> too easy to run afoul of bugs or problems which can hose over your cluster.
>> If we have to erase, we have to erase, but, I don?t want to get into the
>> habit of planning to or having to erase security certificates if there?s a
>> way to correct the issue.
>>
>> Thanks much though for your time and reply
>>
>> Adam
>>
>> From: Stephen Welsh [mailto:[email protected]]
>> Sent: Monday, November 05, 2012 9:09 AM
>> To: Pawlowski, Adam
>> Cc: [email protected]
>> Subject: Re: [cisco-voip] 9.3.1 , TVS, and IPv6
>>
>> Hi Adam,
>>
>> Are you sure the ipv6 thing is not a red herring?
>>
>> Have you tried removing the ITL File from the phone and/or restarting the
>> TVS service?
>>
>> If you are not aware the choice of TVS service (node IP Address) is based on
>> the Call Manager Group configured on the phone, you could try adding all
>> nodes to the phones CM Group to see if that helps the phone to contact a TVS
>> service it has a matching ITL entry for.
>>
>> If you are still stuck I'm happy to host a WebEx session to share my SDB &
>> ITL experiences, I'm the original author of PhoneView
>> (http://www.unifiedfx.com), it's been used to help a LOT of people with SBD
>> related issues, never-mind countless UCM installations and upgrades.
>>
>> In-case you do need to delete/manage your ITL Files, or even just get a
>> proper view/handle on the phone firmware version of your estate you should
>> give PhoneView a try:
>>
>> http://www.unifiedfx.com/phoneview/trial
>>
>> Thanks
>>
>> Stephen
>>
>> On 5 Nov 2012, at 13:51, "Pawlowski, Adam" <[email protected]>
>> wrote:
>>
>>
>>
>> Morning list,
>>
>> From what I can read, TVS has been a thrill ride for those of us lucky
>> enough to run afoul of SBD. I?m hoping we haven?t run into such a situation
>> here but I have a question. We just pushed 9.3.1 out to devices from
>> 9.1.1SR1, with peer firmware sharing enabled. This went miserably and left a
>> lot of devices stranded at 9.1.1 or at an ?Upgrading? screen. Working with
>> TAC on that but so far nothing. We began receiving reports from end users
>> that their directories were missing, they can?t change ringers, etc. Last
>> time this happened we had phones that had picked up a bum ITL from a partial
>> rollout, and we had to erase them by hand.
>>
>> This time that shouldn?t have been the case ? it was just a firmware
>> upgrade. However, it looks like some of the phones that have gone to 9.3.1
>> have decided that they want to use IPv6 when talking to the TFTP to verify
>> their initial configurations, when they have no TVS server list built on the
>> device. In looking at the phone console logs, you can see that the device is
>> in ?IP mode 1? and tries to connect to TFTP, say ?192.168.0.1 :: ? which is
>> obviously not a V6 address. We?re not running V6 so it has no address bound.
>> No traffic leaves the phone, but, the phone says it timed out (EAGAIN)
>> connecting to the TFTP and won?t verify the ITL/CFG/etc.
>>
>> What I?m looking at it is setting V6 to off at the cluster, but, I
>> don?t see any way to repair this on affected devices (could be a large
>> amount) other than erasing the ITL, or deploying IPv6. Given the leg work
>> that could go into identifying and taking care of these devices, it?s
>> arguable as to which one would be harder at this point.
>>
>> Any comment on this with this firmware? Anyone else run into this
>> miserable trouble?
>>
>> Adam Pawlowski
>> SUNYAB Network and Classroom Services
>> _______________________________________________
>> 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
>
>
------------------------------
Message: 6
Date: Thu, 08 Nov 2012 00:16:25 -0500
From: "cisco.voip" <[email protected]>
To: [email protected]
Subject: [cisco-voip] CUCM v9
Message-ID: <[email protected]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
All- I have not been able to install the release version of CCM 9.0 on
VMWare ESXi -
Does anyone know the settings -
CPU required
HD requirements/LSI SCSI (I tried 100GB)
OS (i tried RHEL 64 bit)
Also, what is the licensing manager option, do I have to install this first?
Is CM9 not the same as CM7, where you get 50DLU demo licenses?
Thanks for any tips!
------------------------------
Message: 7
Date: Thu, 8 Nov 2012 09:48:48 +0000
From: Nicholas Samios <[email protected]>
To: "cisco.voip" <[email protected]>,
"[email protected]" <[email protected]>
Subject: Re: [cisco-voip] CUCM v9
Message-ID:
<d96e7b682f2065479ed12359e4756a6c24ec2...@isd-anx-dag1.win2k.iinet.net.au>
Content-Type: text/plain; charset="us-ascii"
>> I have not been able to install the release version of CCM 9.0 on VMWare
>> ESXi - Does anyone know the settings - CPU required HD requirements/LSI SCSI
>> (I tried 100GB) OS (i tried RHEL 64 bit)
Use the OVA templates - it's the exact purpose cisco release them
Downloads Home > Products > Voice and Unified Communications > IP Telephony >
Unified Communications Platform > Cisco Unified Communications Manager
(CallManager) > Cisco Unified Communications Manager Version 9.0 > Unified
Communications Manager Virtual Machine Templates-9.0(1)
>> Is CM9 not the same as CM7, where you get 50DLU demo licenses?
CUCM 9 brings with it a centralised licensing model called 'enterprise
licensing manager'
Michael has a great write up of it on his blog;
http://htluo.blogspot.com.au/2012/09/enterprise-licence-manager.html
--
Nicholas Samios
IT-Voice Operations Manager
CCVP
-----Original Message-----
From: [email protected]
[mailto:[email protected]] On Behalf Of cisco.voip
Sent: Thursday, 8 November 2012 4:16 PM
To: [email protected]
Subject: [cisco-voip] CUCM v9
All- I have not been able to install the release version of CCM 9.0 on VMWare
ESXi - Does anyone know the settings - CPU required HD requirements/LSI SCSI (I
tried 100GB) OS (i tried RHEL 64 bit)
Also, what is the licensing manager option, do I have to install this first?
Is CM9 not the same as CM7, where you get 50DLU demo licenses?
Thanks for any tips!
_______________________________________________
cisco-voip mailing list
[email protected]
https://puck.nether.net/mailman/listinfo/cisco-voip
------------------------------
Message: 8
Date: Thu, 8 Nov 2012 11:16:46 -0300
From: Isamar Maia <[email protected]>
To: [email protected]
Subject: [cisco-voip] TAPI Client 64bits version for Call Manager 8.5
Message-ID:
<capzho3j01cgpyfponvketkbnece9_kalhpfo6opt2rjs3av...@mail.gmail.com>
Content-Type: text/plain; charset=ISO-2022-JP
Hi folks,
We have here a CUCM 8.5. Our CallManager version is 8.5.1.10000-26,
According to the reference, it's necessary to upgrade to SU1 to have
available for downloading the
64bits version of CallManager's TAPI Client.
I would like to avoid to upgrade the whole platfrom just because the
client version moving from 32 to 64bits.
Any tip?
--
Isamar Maia
Cel. VIVO SSA: (55) 71-9146-8575
Cel. TIM SSA: (55) 71-9185-5264
Fixo: (55) 71-4062-8688
??: +81-(0)3-4550-1212
Skype ID: isamar.maia
------------------------------
Message: 9
Date: Thu, 8 Nov 2012 14:39:00 +0000
From: "Buchanan, James" <[email protected]>
To: Isamar Maia <[email protected]>, "[email protected]"
<[email protected]>
Subject: Re: [cisco-voip] TAPI Client 64bits version for Call Manager
8.5
Message-ID:
<12d6a6a157b44348974e5ed93738628c0969e...@hqexchmbx03.presidio.corp>
Content-Type: text/plain; charset="iso-2022-jp"
I understand your hesitation, but would also urge you to read the release notes
for the service releases and see if there are any other benefits.
The other option would be for someone to send you the later TSP executable. It
might or it might not work of course.
James Buchanan | Sr. Network Engineer
Presidio | www.presidio.com
12 Cadillac Drive Suite 130, Brentwood, TN 37027
D: 615.866.5729 | C: 931.797.2326 | F: 615.866.5781 | [email protected]
PRESIDIO
Follow Us: www.twitter.com/presidio
-----Original Message-----
From: [email protected]
[mailto:[email protected]] On Behalf Of Isamar Maia
Sent: Thursday, November 08, 2012 4:17 PM
To: [email protected]
Subject: [cisco-voip] TAPI Client 64bits version for Call Manager 8.5
Hi folks,
We have here a CUCM 8.5. Our CallManager version is 8.5.1.10000-26,
According to the reference, it's necessary to upgrade to SU1 to have available
for downloading the 64bits version of CallManager's TAPI Client.
I would like to avoid to upgrade the whole platfrom just because the client
version moving from 32 to 64bits.
Any tip?
--
Isamar Maia
Cel. VIVO SSA: (55) 71-9146-8575
Cel. TIM SSA: (55) 71-9185-5264
Fixo: (55) 71-4062-8688
??: +81-(0)3-4550-1212
Skype ID: isamar.maia
_______________________________________________
cisco-voip mailing list
[email protected]
https://puck.nether.net/mailman/listinfo/cisco-voip
This message w/attachments (message) is intended solely for the use of the
intended recipient(s) and may contain information that is privileged,
confidential or proprietary. If you are not an intended recipient, please
notify the sender, and then please delete and destroy all copies and
attachments. Please be advised that any review or dissemination of, or the
taking of any action in reliance on, the information contained in or attached
to this message is prohibited.
------------------------------
Message: 10
Date: Thu, 8 Nov 2012 11:46:39 -0300
From: Isamar Maia <[email protected]>
To: "Buchanan, James" <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [cisco-voip] TAPI Client 64bits version for Call Manager
8.5
Message-ID:
<CAPzHo3gNu6eGbz3abmmCTv=4J=t9qcxgvjsnkpykvtnd5bu...@mail.gmail.com>
Content-Type: text/plain; charset=ISO-2022-JP
Yes. I was wondering about the second option. Some good soul from here
to send the executable to me,
so I can give a shot and test.
Otherwise, a procedure of upgrade like that should take how much time
in a maintenance window ?
Isamar
2012/11/8 Buchanan, James <[email protected]>:
> I understand your hesitation, but would also urge you to read the release
> notes for the service releases and see if there are any other benefits.
>
> The other option would be for someone to send you the later TSP executable.
> It might or it might not work of course.
>
>
> James Buchanan | Sr. Network Engineer
> Presidio | www.presidio.com
> 12 Cadillac Drive Suite 130, Brentwood, TN 37027
> D: 615.866.5729 | C: 931.797.2326 | F: 615.866.5781 | [email protected]
>
>
>
> PRESIDIO
>
>
> Follow Us: www.twitter.com/presidio
>
> -----Original Message-----
> From: [email protected]
> [mailto:[email protected]] On Behalf Of Isamar Maia
> Sent: Thursday, November 08, 2012 4:17 PM
> To: [email protected]
> Subject: [cisco-voip] TAPI Client 64bits version for Call Manager 8.5
>
> Hi folks,
>
> We have here a CUCM 8.5. Our CallManager version is 8.5.1.10000-26,
>
> According to the reference, it's necessary to upgrade to SU1 to have
> available for downloading the 64bits version of CallManager's TAPI Client.
>
> I would like to avoid to upgrade the whole platfrom just because the client
> version moving from 32 to 64bits.
>
> Any tip?
>
>
> --
> Isamar Maia
> Cel. VIVO SSA: (55) 71-9146-8575
> Cel. TIM SSA: (55) 71-9185-5264
> Fixo: (55) 71-4062-8688
> ??: +81-(0)3-4550-1212
> Skype ID: isamar.maia
> _______________________________________________
> cisco-voip mailing list
> [email protected]
> https://puck.nether.net/mailman/listinfo/cisco-voip
> This message w/attachments (message) is intended solely for the use of the
> intended recipient(s) and may contain information that is privileged,
> confidential or proprietary. If you are not an intended recipient, please
> notify the sender, and then please delete and destroy all copies and
> attachments. Please be advised that any review or dissemination of, or the
> taking of any action in reliance on, the information contained in or attached
> to this message is prohibited.
>
--
Isamar Maia
Cel. VIVO SSA: (55) 71-9146-8575
Cel. TIM SSA: (55) 71-9185-5264
Fixo: (55) 71-4062-8688
??: +81-(0)3-4550-1212
Skype ID: isamar.maia
------------------------------
Message: 11
Date: Thu, 8 Nov 2012 09:50:04 -0500 (EST)
From: Lelio Fulgenzi <[email protected]>
To: "[email protected]" <[email protected]>
Subject: [cisco-voip] post TAC case survey questions
Message-ID:
<2045848022.136934.1352386204453.javamail.r...@squeaky.cs.uoguelph.ca>
Content-Type: text/plain; charset="utf-8"
does anyone have access to those 5 or 6 questions asked on the post TAC case
survey?
we're looking at doing something similar with our service tickets and we just
wanted a starting point.
thanks!
---
Lelio Fulgenzi, B.A.
Senior Analyst (CCS) * University of Guelph * Guelph, Ontario N1G 2W1
(519) 824-4120 x56354 (519) 767-1060 FAX (ANNU)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Cooking with unix is easy. You just sed it and forget it.
- LFJ (with apologies to Mr. Popeil)
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<https://puck.nether.net/pipermail/cisco-voip/attachments/20121108/25752f37/attachment-0001.html>
------------------------------
Message: 12
Date: Thu, 8 Nov 2012 14:54:38 +0000
From: "Buchanan, James" <[email protected]>
To: Isamar Maia <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [cisco-voip] TAPI Client 64bits version for Call Manager
8.5
Message-ID:
<12d6a6a157b44348974e5ed93738628c0969e...@hqexchmbx03.presidio.corp>
Content-Type: text/plain; charset="iso-2022-jp"
It won't be too bad. You would need to request a window of time in which you
make no changes. Then, you would apply the service release first to the
Publisher. This would be installed in the Inactive partition, meaning you have
no outage. Then, you would do the same on the Subscribers. These installs could
happen even during the day. During your maintenance window, you would make the
inactive version active by doing the Switch Versions procedure. I like to do
this from the CLI because I can see what is happening when. This is when the
servers reboot.
The part to be cautious of is this: when you switch versions and the new
version becomes active, the phones will likely get updated firmware. This will
be a complete outage of the handsets until their firmware is downloaded and
applied. There is a way to avoid this part if you must. You can find the
current version of firmware running then can hardcode the phones to that
version using Bulk Update of the Phones. This can save you a lot of time.
James Buchanan | Sr. Network Engineer
Presidio | www.presidio.com
12 Cadillac Drive Suite 130, Brentwood, TN 37027
D: 615.866.5729 | C: 931.797.2326 | F: 615.866.5781 | [email protected]
PRESIDIO
Follow Us: www.twitter.com/presidio
-----Original Message-----
From: Isamar Maia [mailto:[email protected]]
Sent: Thursday, November 08, 2012 4:47 PM
To: Buchanan, James
Cc: [email protected]
Subject: Re: [cisco-voip] TAPI Client 64bits version for Call Manager 8.5
Yes. I was wondering about the second option. Some good soul from here to send
the executable to me, so I can give a shot and test.
Otherwise, a procedure of upgrade like that should take how much time in a
maintenance window ?
Isamar
2012/11/8 Buchanan, James <[email protected]>:
> I understand your hesitation, but would also urge you to read the release
> notes for the service releases and see if there are any other benefits.
>
> The other option would be for someone to send you the later TSP executable.
> It might or it might not work of course.
>
>
> James Buchanan | Sr. Network Engineer
> Presidio | www.presidio.com
> 12 Cadillac Drive Suite 130, Brentwood, TN 37027
> D: 615.866.5729 | C: 931.797.2326 | F: 615.866.5781 |
> [email protected]
>
>
>
> PRESIDIO
>
>
> Follow Us: www.twitter.com/presidio
>
> -----Original Message-----
> From: [email protected]
> [mailto:[email protected]] On Behalf Of Isamar Maia
> Sent: Thursday, November 08, 2012 4:17 PM
> To: [email protected]
> Subject: [cisco-voip] TAPI Client 64bits version for Call Manager 8.5
>
> Hi folks,
>
> We have here a CUCM 8.5. Our CallManager version is 8.5.1.10000-26,
>
> According to the reference, it's necessary to upgrade to SU1 to have
> available for downloading the 64bits version of CallManager's TAPI Client.
>
> I would like to avoid to upgrade the whole platfrom just because the client
> version moving from 32 to 64bits.
>
> Any tip?
>
>
> --
> Isamar Maia
> Cel. VIVO SSA: (55) 71-9146-8575
> Cel. TIM SSA: (55) 71-9185-5264
> Fixo: (55) 71-4062-8688
> ??: +81-(0)3-4550-1212
> Skype ID: isamar.maia
> _______________________________________________
> cisco-voip mailing list
> [email protected]
> https://puck.nether.net/mailman/listinfo/cisco-voip
> This message w/attachments (message) is intended solely for the use of the
> intended recipient(s) and may contain information that is privileged,
> confidential or proprietary. If you are not an intended recipient, please
> notify the sender, and then please delete and destroy all copies and
> attachments. Please be advised that any review or dissemination of, or the
> taking of any action in reliance on, the information contained in or attached
> to this message is prohibited.
>
--
Isamar Maia
Cel. VIVO SSA: (55) 71-9146-8575
Cel. TIM SSA: (55) 71-9185-5264
Fixo: (55) 71-4062-8688
??: +81-(0)3-4550-1212
Skype ID: isamar.maia
------------------------------
Message: 13
Date: Thu, 8 Nov 2012 09:58:25 -0500 (EST)
From: Lelio Fulgenzi <[email protected]>
To: [email protected]
Subject: Re: [cisco-voip] post TAC case survey questions
Message-ID:
<526401877.137834.1352386705885.javamail.r...@squeaky.cs.uoguelph.ca>
Content-Type: text/plain; charset="utf-8"
Got a reply! thanks everyone.
---
Lelio Fulgenzi, B.A.
Senior Analyst (CCS) * University of Guelph * Guelph, Ontario N1G 2W1
(519) 824-4120 x56354 (519) 767-1060 FAX (ANNU)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Cooking with unix is easy. You just sed it and forget it.
- LFJ (with apologies to Mr. Popeil)
----- Original Message -----
From: "Lelio Fulgenzi" <[email protected]>
To: [email protected]
Sent: Thursday, November 8, 2012 9:50:04 AM
Subject: [cisco-voip] post TAC case survey questions
does anyone have access to those 5 or 6 questions asked on the post TAC case
survey?
we're looking at doing something similar with our service tickets and we just
wanted a starting point.
thanks!
---
Lelio Fulgenzi, B.A.
Senior Analyst (CCS) * University of Guelph * Guelph, Ontario N1G 2W1
(519) 824-4120 x56354 (519) 767-1060 FAX (ANNU)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Cooking with unix is easy. You just sed it and forget it.
- LFJ (with apologies to Mr. Popeil)
_______________________________________________
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/20121108/37458f6f/attachment-0001.html>
------------------------------
Message: 14
Date: Thu, 8 Nov 2012 06:59:57 -0800
From: Scott Voll <[email protected]>
To: "Buchanan, James" <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [cisco-voip] TAPI Client 64bits version for Call Manager
8.5
Message-ID:
<CAHgd+39gd9x3t6F7RK+yPRXX0HTzC3521jJ-pXjEhR=cv_c...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Be cautious doing this during the day. it still take CPU cycles that can
have an effect on your environment.
Do you have other applications, such as UCCx, CER, UC, etc? Make sure an
upgrade will still be compatible after you upgrade.
But I think your only (TAC Supported) solution will be an upgrade.
YMMV
Scott
On Thu, Nov 8, 2012 at 6:54 AM, Buchanan, James <[email protected]>wrote:
> It won't be too bad. You would need to request a window of time in which
> you make no changes. Then, you would apply the service release first to the
> Publisher. This would be installed in the Inactive partition, meaning you
> have no outage. Then, you would do the same on the Subscribers. These
> installs could happen even during the day. During your maintenance window,
> you would make the inactive version active by doing the Switch Versions
> procedure. I like to do this from the CLI because I can see what is
> happening when. This is when the servers reboot.
>
> The part to be cautious of is this: when you switch versions and the new
> version becomes active, the phones will likely get updated firmware. This
> will be a complete outage of the handsets until their firmware is
> downloaded and applied. There is a way to avoid this part if you must. You
> can find the current version of firmware running then can hardcode the
> phones to that version using Bulk Update of the Phones. This can save you a
> lot of time.
>
>
> James Buchanan | Sr. Network Engineer
> Presidio | www.presidio.com
> 12 Cadillac Drive Suite 130, Brentwood, TN 37027
> D: 615.866.5729 | C: 931.797.2326 | F: 615.866.5781 |
> [email protected]
>
>
>
> PRESIDIO
>
>
> Follow Us: www.twitter.com/presidio
>
> -----Original Message-----
> From: Isamar Maia [mailto:[email protected]]
> Sent: Thursday, November 08, 2012 4:47 PM
> To: Buchanan, James
> Cc: [email protected]
> Subject: Re: [cisco-voip] TAPI Client 64bits version for Call Manager 8.5
>
> Yes. I was wondering about the second option. Some good soul from here to
> send the executable to me, so I can give a shot and test.
>
> Otherwise, a procedure of upgrade like that should take how much time in a
> maintenance window ?
>
> Isamar
>
> 2012/11/8 Buchanan, James <[email protected]>:
> > I understand your hesitation, but would also urge you to read the
> release notes for the service releases and see if there are any other
> benefits.
> >
> > The other option would be for someone to send you the later TSP
> executable. It might or it might not work of course.
> >
> >
> > James Buchanan | Sr. Network Engineer
> > Presidio | www.presidio.com
> > 12 Cadillac Drive Suite 130, Brentwood, TN 37027
> > D: 615.866.5729 | C: 931.797.2326 | F: 615.866.5781 |
> > [email protected]
> >
>
> >
> >
> > PRESIDIO
> >
> >
> > Follow Us: www.twitter.com/presidio
> >
> > -----Original Message-----
> > From: [email protected]
> > [mailto:[email protected]] On Behalf Of Isamar Maia
> > Sent: Thursday, November 08, 2012 4:17 PM
> > To: [email protected]
> > Subject: [cisco-voip] TAPI Client 64bits version for Call Manager 8.5
> >
> > Hi folks,
> >
> > We have here a CUCM 8.5. Our CallManager version is 8.5.1.10000-26,
> >
> > According to the reference, it's necessary to upgrade to SU1 to have
> available for downloading the 64bits version of CallManager's TAPI Client.
> >
> > I would like to avoid to upgrade the whole platfrom just because the
> client version moving from 32 to 64bits.
> >
> > Any tip?
> >
> >
> > --
> > Isamar Maia
> > Cel. VIVO SSA: (55) 71-9146-8575
> > Cel. TIM SSA: (55) 71-9185-5264
> > Fixo: (55) 71-4062-8688
> > ??: +81-(0)3-4550-1212
> > Skype ID: isamar.maia
> > _______________________________________________
> > cisco-voip mailing list
> > [email protected]
> > https://puck.nether.net/mailman/listinfo/cisco-voip
> > This message w/attachments (message) is intended solely for the use of
> the intended recipient(s) and may contain information that is privileged,
> confidential or proprietary. If you are not an intended recipient, please
> notify the sender, and then please delete and destroy all copies and
> attachments. Please be advised that any review or dissemination of, or the
> taking of any action in reliance on, the information contained in or
> attached to this message is prohibited.
> >
>
>
>
> --
> Isamar Maia
> Cel. VIVO SSA: (55) 71-9146-8575
> Cel. TIM SSA: (55) 71-9185-5264
> Fixo: (55) 71-4062-8688
> ??: +81-(0)3-4550-1212
> Skype ID: isamar.maia
>
> _______________________________________________
> 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/20121108/1800284b/attachment-0001.html>
------------------------------
_______________________________________________
cisco-voip mailing list
[email protected]
https://puck.nether.net/mailman/listinfo/cisco-voip
End of cisco-voip Digest, Vol 109, Issue 6
******************************************
