[cisco-voip] AutoDialer
Does anyone have any recommendations for an autodialer for CUCM 8.x+ TIA ___ cisco-voip mailing list cisco-voip@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-voip
[cisco-voip] Visual Voicemail on 88XX phones
Has anyone had any luck getting visual voicemail working using the new xml service as outlined in the 88XX admin guide? http://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cuipph/8811_8841_8851_8861/10_5/english/adminguide/P881_BK_A92A3B94_00_adminguide-8811_41_51_61-10_5/P881_BK_A92A3B94_00_adminguide-8811_41_51_61-10_5_chapter_01011.html#P881_TK_SC40B712_00 Thanks in advanced Ted ___ cisco-voip mailing list cisco-voip@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-voip
[cisco-voip] Bullhorn CRM integration
Has anyone had any success integrating UCCX with Bullhorn CRM? Any tips or issues you might share? TIA Ted ___ cisco-voip mailing list cisco-voip@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-voip
Re: [cisco-voip] what do i lose with the publisher being down?
Also I've run into a problem with EM where users attempted to logout from sub service URL and could not however that may have been a bug with version we were on so it may be a good idea to test that if that's a concern. On Fri, Jul 11, 2014 at 3:50 PM, Brian Meade bmead...@vt.edu wrote: With internal services provisioning, phones now reach out to their subscriber for things such as Directories. Make sure the publisher isn't the only MTP/MOH/CFB resource for any MRGLs. Make sure the gateways are set to send calls to the subscriber primarily if using H.323/SIP. On Fri, Jul 11, 2014 at 2:27 PM, Lelio Fulgenzi le...@uoguelph.ca wrote: I'm hoping I can get some real world comments here... I need to take the publisher down in order to move it. From what I understand, for the most part, service will continue to operate. However, some things will not be available. From what I gather: - CUCMUser pages will not be available - CUCMAdmin pages will not be available - Services Subscription listing when Services URL pointing to the publisher What else will be unavailable? We are not using extension mobility. If I program the service URL of a phone to point to a different server, will the phone continue to call that separate server? Or does it need the publisher to get that information first? Thoughts? --- Lelio Fulgenzi, B.A. Senior Analyst, Network Infrastructure Computing and Communications Services (CCS) University of Guelph 519‐824‐4120 Ext 56354 le...@uoguelph.ca www.uoguelph.ca/ccs Room 037, Animal Science and Nutrition Building Guelph, Ontario, N1G 2W1 ___ cisco-voip mailing list cisco-voip@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-voip ___ cisco-voip mailing list cisco-voip@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-voip ___ cisco-voip mailing list cisco-voip@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-voip
Re: [cisco-voip] Intermittent phone resets
Just went through something similar with a client, however it was only happening to newly installed 8961s, which replaced their old 7940/60s. Extremely odd but for them it turned out to be patch cables between the patch panel and the switch. They worked fine on the 7940/60 but would intermittently drop for the new phones. They replaced their patch cables and the problem disappeared.??!!??!! On Thu, Jun 5, 2014 at 3:24 PM, AbdusSaboor Khan saboor.k...@gmail.com wrote: Hi, We had this issue so many time and found out every time different Solution: 1- We had the issue CUCM and need to upgrade it, for temp fix we had made the thsi change on Device Detect Unified CM Connection Failuremake it Delayed so the heartbeat can go after a while. 2- Second time it was cable issue on Switch and we have changed the cable on switch port for to be on safe side put changed the port as well as. 3- Third time it was the load not support so I made it a bit backward and phones works ok. Regards, Abdus Saboor On Thu, Jun 5, 2014 at 2:41 PM, Brian Meade bmead...@vt.edu wrote: I had a case where the guy had his CUCM server switch ports SPANed to some dedicated capture gear. He was able to get me captures from all his CUCM servers up to a week back. That was a pretty nice thing to have. Unfortunately, you're limited on the phone side in that you'll need to set it up for quite a few phones to increase your chances of catching it. On Thu, Jun 5, 2014 at 2:29 PM, Lelio Fulgenzi le...@uoguelph.ca wrote: Just to add, we too are experiencing the same issue. Although I don't think we've had complaints of dropped calls. We first saw the issue when upgrading from v4.1 to v7.1 around two years ago, but because we didn't get complaints we had to prioritize. We're now seeing many more dropped phones. I'm not sure if the alerts were there in v4.1 and we just didn't have the alerts set up to come to us or not. It was a long time ago. We opened a TAC case, but unfortunately, we have not been able to work on it due to other pressing issues. I have to go back to our team to co-ordinate getting this going again. I'd like to resolve this. There should be no reason to have such a large number of de-registration events. We are primarily 7940/60 7912 phones with a number of 7911s, 7942, 7962 interspersed. I too am of the thought that it's not CUCM version dependent, but more so either switch configuration (loop detection) or firewall issues. The case owner said the only real way to figure things out is to get a packet capture from both the callmanager and the phones when it happens. Unfortunately, it's difficult to do so, since how do you guess where the phones are going to un-register from? We might have to do some sort of multi-vlan capture, but that is gonna be tough too. --- Lelio Fulgenzi, B.A. Senior Analyst, Network Infrastructure Computing and Communications Services (CCS) University of Guelph 519‐824‐4120 Ext 56354 le...@uoguelph.ca www.uoguelph.ca/ccs Room 037, Animal Science and Nutrition Building Guelph, Ontario, N1G 2W1 -- *From: *Tashi Mar t...@align.com *To: *Terry Oakley terry.oak...@rdc.ab.ca, Dennis Heim dennis.h...@wwt.com, cisco-voip@puck.nether.net *Sent: *Thursday, June 5, 2014 2:10:17 PM *Subject: *Re: [cisco-voip] Intermittent phone resets Hi all, appreciate the feedback. There are some SCCP phones (along with SIP) that reset too; TAC could not pinpoint any phone firmware or CUCM bugs either. Will find out the switch OS, but environment is all stacked 3750s at the core and access layers in both locations. Any chance you recall the bug ID? Definitely will check into: - Switch bug related to spanning tree and excessive Topology Change Notifications (TCN). They actually replaced some access switches, but that doesn’t mean the configuration was modified. - Circular buffer packet captures We did verify that the ASAs are not doing any SIP or SCCP inspection; voice traffic on this network does not pass through firewalls anyway. Thanks! Tashi Mar | IP Telephony Engineer *From:* Terry Oakley [mailto:terry.oak...@rdc.ab.ca] *Sent:* Thursday, June 05, 2014 2:02 PM *To:* Heim, Dennis; Mar, Tashi; cisco-voip@puck.nether.net *Subject:* RE: Intermittent phone resets What version of switches and OS were you using? Thanks Terry *From:* cisco-voip [mailto:cisco-voip-boun...@puck.nether.net cisco-voip-boun...@puck.nether.net] *On Behalf Of *Heim, Dennis *Sent:* June-05-14 11:50 AM *To:* Mar, Tashi; cisco-voip@puck.nether.net *Subject:* Re: [cisco-voip] Intermittent phone resets I had this awhile back, and it ended up being a bug on the switches related to spanning tree and excessive Topology Change Notifications (TCN). *Dennis Heim | Collaboration Solutions Architect* World Wide Technology, Inc. | +1 314-212-1814 [image: twitter]
Re: [cisco-voip] UC 9 licensing
Good Info, Thanks Scott. I have to do 2 this week I'll reply back if that speeds things up. On Fri, May 30, 2014 at 3:54 PM, Scott Voll svoll.v...@gmail.com wrote: in case anyone finds this thread I just wanted to add that at cisco live they said that if you put: Drive to Coloaborate Pre or Post Migration it will get routed to the Correct team to get the switch done more quickly. Sorry for the late post, I'm sure your done. Scott On Mon, May 12, 2014 at 7:23 AM, Brian Meade bmead...@vt.edu wrote: My understanding is license migrations to CUWL from DLUs have been taking much longer since they're now reviewing on a case by case basis rather than letting you do your own migration. I believe I've heard 10 days is pretty normal right now. Brian On Mon, May 12, 2014 at 8:07 AM, Ted Nugent tednugen...@gmail.com wrote: Migrations to CUWL always take longer but in most cases they have you something within 3-4 days, stay on them. There isn't much TAC can do once they kick it to the PMs. On Sun, May 11, 2014 at 10:52 PM, Lelio Fulgenzi le...@uoguelph.ca wrote: Same here. Mine have all been within 24 hours. Sent from my iPhone On 2014-05-11, at 9:59 PM, Tim Smith tim.sm...@enject.com.au wrote: Hey mate, Usually only a couple of days in my experience. I would complain and try and escalate it further. Cheers, Tim. *From:* cisco-voip [mailto:cisco-voip-boun...@puck.nether.net cisco-voip-boun...@puck.nether.net] *On Behalf Of *Dana Tong *Sent:* Monday, 12 May 2014 11:50 AM *To:* cisco-voip@puck.nether.net (cisco-voip@puck.nether.net) *Subject:* [cisco-voip] UC 9 licensing Good day all, I did an upgrade to UCM 9.1(2)SU1 last week. (Monday night) I provided the Global Licensing team the following information: UCSS / ESW contract Original Sales order # (original BOM was for 3 years UCSS / ESW on xxx CUWLBE Standard plus xxx analogue devices) Product Upgrade Tool – confirmation order License Count Utility output Original License count How long does it take for the “Product Manager” to review and provide the ELM license? It’s now been a week. I am having very little response with the lady in the states. Does the Global Licensing Team work in the APJC region? Cheers Dana ___ cisco-voip mailing list cisco-voip@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-voip ___ cisco-voip mailing list cisco-voip@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-voip ___ cisco-voip mailing list cisco-voip@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-voip ___ cisco-voip mailing list cisco-voip@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-voip ___ cisco-voip mailing list cisco-voip@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-voip
Re: [cisco-voip] Unity Connection Cluster Port usage for MWI
Thanks Anthony, That is basically what we're seeing. We are sending a message to a large PDL and the cluster is only using the Publisher port group when sending MWI. Based on what is documented If no dial-out ports on the publisher server are available, the subscriber server will dial out for MWIs and notifications I would expect that once all the publisher dial out ports are consumed it would start rolling over to the subscribers dialout ports but this does not appear to be happening. I'm curious if this is a defect or WAD? Unity Connection 8.5 On Fri, May 30, 2014 at 9:14 AM, Anthony Holloway avhollo...@gmail.com wrote: Dial-out ports (for MWIs and notifications) Beginning with the dial-out port that has the lowest number in its display name, assign half the dial-out ports to the primary server so that the primary server will handle MWIs and notification calls. Assign the remaining dial-out ports to the subscriber server. Under normal conditions, the Cisco Unity Connection cluster will handle calls in the following manner: •The subscriber server will answer most incoming calls. If no answering ports on the subscriber server are available, the publisher server will answer calls. •The publisher server will dial out for MWIs and notifications If no dial-out ports on the publisher server are available, the subscriber server will dial out for MWIs and notifications. Source: http://www.cisco.com/c/en/us/td/docs/voice_ip_comm/connection/7x/integration/cucm_sccp/guide/cucintcucmskinny/cucintcucmskinny205.html#wpxref92198 On Thursday, May 29, 2014, Ted Nugent tednugen...@gmail.com wrote: I can't believe I've not run across this previously and I can't seem to find an answer in the docs. When you have a Unity Connection Cluster what determines which port group is used for MWI assuming you have a separate port group for each server within the same integration? TIA -- Anthony Holloway ___ cisco-voip mailing list cisco-voip@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-voip
Re: [cisco-voip] Unity Connection Cluster Port usage for MWI
I need to confirm this to be 100% certain but from what I'm being told they are looking at the the port activity report from the serviceability page, assuming the report is correct none of the subscriber dialout ports are being used. They are sending to a large distribution list, with many more members than there are dialout ports and the activity report shows the calls hitting the Pub ports about 48+ times and the subscriber ports are not being touched. On Fri, May 30, 2014 at 12:44 PM, Anthony Holloway avholloway+cisco-v...@gmail.com wrote: When you say that it does not appear to be happening, how are you checking that all of the publisher dial out ports are in use or unavailable? The MWI activity takes only a very short amount of time, so is it possible that your publisher is not 100% utilized. They only real way to test this, with 100% certainty, is to drop the publisher's ability to use the ports for MWI down to only a single port. If what you are describing is a large amount of MWI status updates at once, then this would surely force you into using subscriber ports. On Fri, May 30, 2014 at 9:48 AM, Ted Nugent tednugen...@gmail.com wrote: Thanks Anthony, That is basically what we're seeing. We are sending a message to a large PDL and the cluster is only using the Publisher port group when sending MWI. Based on what is documented If no dial-out ports on the publisher server are available, the subscriber server will dial out for MWIs and notifications I would expect that once all the publisher dial out ports are consumed it would start rolling over to the subscribers dialout ports but this does not appear to be happening. I'm curious if this is a defect or WAD? Unity Connection 8.5 On Fri, May 30, 2014 at 9:14 AM, Anthony Holloway avhollo...@gmail.com wrote: Dial-out ports (for MWIs and notifications) Beginning with the dial-out port that has the lowest number in its display name, assign half the dial-out ports to the primary server so that the primary server will handle MWIs and notification calls. Assign the remaining dial-out ports to the subscriber server. Under normal conditions, the Cisco Unity Connection cluster will handle calls in the following manner: •The subscriber server will answer most incoming calls. If no answering ports on the subscriber server are available, the publisher server will answer calls. •The publisher server will dial out for MWIs and notifications If no dial-out ports on the publisher server are available, the subscriber server will dial out for MWIs and notifications. Source: http://www.cisco.com/c/en/us/td/docs/voice_ip_comm/connection/7x/integration/cucm_sccp/guide/cucintcucmskinny/cucintcucmskinny205.html#wpxref92198 On Thursday, May 29, 2014, Ted Nugent tednugen...@gmail.com wrote: I can't believe I've not run across this previously and I can't seem to find an answer in the docs. When you have a Unity Connection Cluster what determines which port group is used for MWI assuming you have a separate port group for each server within the same integration? TIA -- Anthony Holloway ___ cisco-voip mailing list cisco-voip@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-voip
Re: [cisco-voip] Unity Connection Cluster Port usage for MWI
Confirmed, I pulled the usage report and I can see many many MWI hits on the Pub during the timeframe that the PDL was called and zero MWI on the subscriber. It appears to just be queuing MWI on the Pub ports as opposed to them overflowing to the sub. If that's a WAD, I'm fine with it, it just seems strange why its not overflowing. On Fri, May 30, 2014 at 2:15 PM, Ted Nugent tednugen...@gmail.com wrote: I need to confirm this to be 100% certain but from what I'm being told they are looking at the the port activity report from the serviceability page, assuming the report is correct none of the subscriber dialout ports are being used. They are sending to a large distribution list, with many more members than there are dialout ports and the activity report shows the calls hitting the Pub ports about 48+ times and the subscriber ports are not being touched. On Fri, May 30, 2014 at 12:44 PM, Anthony Holloway avholloway+cisco-v...@gmail.com wrote: When you say that it does not appear to be happening, how are you checking that all of the publisher dial out ports are in use or unavailable? The MWI activity takes only a very short amount of time, so is it possible that your publisher is not 100% utilized. They only real way to test this, with 100% certainty, is to drop the publisher's ability to use the ports for MWI down to only a single port. If what you are describing is a large amount of MWI status updates at once, then this would surely force you into using subscriber ports. On Fri, May 30, 2014 at 9:48 AM, Ted Nugent tednugen...@gmail.com wrote: Thanks Anthony, That is basically what we're seeing. We are sending a message to a large PDL and the cluster is only using the Publisher port group when sending MWI. Based on what is documented If no dial-out ports on the publisher server are available, the subscriber server will dial out for MWIs and notifications I would expect that once all the publisher dial out ports are consumed it would start rolling over to the subscribers dialout ports but this does not appear to be happening. I'm curious if this is a defect or WAD? Unity Connection 8.5 On Fri, May 30, 2014 at 9:14 AM, Anthony Holloway avhollo...@gmail.com wrote: Dial-out ports (for MWIs and notifications) Beginning with the dial-out port that has the lowest number in its display name, assign half the dial-out ports to the primary server so that the primary server will handle MWIs and notification calls. Assign the remaining dial-out ports to the subscriber server. Under normal conditions, the Cisco Unity Connection cluster will handle calls in the following manner: •The subscriber server will answer most incoming calls. If no answering ports on the subscriber server are available, the publisher server will answer calls. •The publisher server will dial out for MWIs and notifications If no dial-out ports on the publisher server are available, the subscriber server will dial out for MWIs and notifications. Source: http://www.cisco.com/c/en/us/td/docs/voice_ip_comm/connection/7x/integration/cucm_sccp/guide/cucintcucmskinny/cucintcucmskinny205.html#wpxref92198 On Thursday, May 29, 2014, Ted Nugent tednugen...@gmail.com wrote: I can't believe I've not run across this previously and I can't seem to find an answer in the docs. When you have a Unity Connection Cluster what determines which port group is used for MWI assuming you have a separate port group for each server within the same integration? TIA -- Anthony Holloway ___ cisco-voip mailing list cisco-voip@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-voip
[cisco-voip] Unity Connection Cluster Port usage for MWI
I can't believe I've not run across this previously and I can't seem to find an answer in the docs. When you have a Unity Connection Cluster what determines which port group is used for MWI assuming you have a separate port group for each server within the same integration? TIA ___ cisco-voip mailing list cisco-voip@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-voip
Re: [cisco-voip] so I was wrong on the documentation is wrong
Last time I setup IMP for 9.1 the xml file didn't appear to have any effect and Jabber was pulling everything from the Service Profile. I even got TAC engaged and he agreed it didn't appear to be doing anything at least for the info we were trying to map. So that may be accurate. On Thu, May 15, 2014 at 3:09 PM, Jason Aarons (AM) jason.aar...@dimensiondata.com wrote: CUCM 10.0.1 and IMP 10.0.01 Which wins? The Jabber-config.xml or the Service Profile? I’ve heard different feedback from various TAC engineers. http://www.cisco.com/c/en/us/td/docs/voice_ip_comm/jabber/Windows/9_7/JABW_BK_C4C679C9_00_cisco-jabber-for-windows-97.pdf Note: In instances where a Service Profile and the configuration file are present, settings in the Service Profile take priority. ___ cisco-voip mailing list cisco-voip@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-voip ___ cisco-voip mailing list cisco-voip@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-voip
Re: [cisco-voip] UC 9 licensing
Migrations to CUWL always take longer but in most cases they have you something within 3-4 days, stay on them. There isn't much TAC can do once they kick it to the PMs. On Sun, May 11, 2014 at 10:52 PM, Lelio Fulgenzi le...@uoguelph.ca wrote: Same here. Mine have all been within 24 hours. Sent from my iPhone On 2014-05-11, at 9:59 PM, Tim Smith tim.sm...@enject.com.au wrote: Hey mate, Usually only a couple of days in my experience. I would complain and try and escalate it further. Cheers, Tim. *From:* cisco-voip [mailto:cisco-voip-boun...@puck.nether.netcisco-voip-boun...@puck.nether.net] *On Behalf Of *Dana Tong *Sent:* Monday, 12 May 2014 11:50 AM *To:* cisco-voip@puck.nether.net (cisco-voip@puck.nether.net) *Subject:* [cisco-voip] UC 9 licensing Good day all, I did an upgrade to UCM 9.1(2)SU1 last week. (Monday night) I provided the Global Licensing team the following information: UCSS / ESW contract Original Sales order # (original BOM was for 3 years UCSS / ESW on xxx CUWLBE Standard plus xxx analogue devices) Product Upgrade Tool – confirmation order License Count Utility output Original License count How long does it take for the “Product Manager” to review and provide the ELM license? It’s now been a week. I am having very little response with the lady in the states. Does the Global Licensing Team work in the APJC region? Cheers Dana ___ cisco-voip mailing list cisco-voip@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-voip ___ cisco-voip mailing list cisco-voip@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-voip ___ cisco-voip mailing list cisco-voip@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-voip
Re: [cisco-voip] Recording Proiles
Perhaps a CSS bug? Makes little sense but is the recording pilot in a reachable PT for the device as opposed to just the Recording CSS? On Thu, Mar 27, 2014 at 8:31 PM, Leslie Meade leslie.me...@lvs1.com wrote: Every line has a recording profile on it. If I select the speed dial it will select the primary line. If I make a call from the primary line it records that call. It's only speed dial that's not functional. *Leslie Meade* .. * Mobile:778.228.4339 778.228.4339* | *Main:* *604.676.5239 604.676.5239* *Email:* leslie.me...@lvs1.com *From:* Pavan K [mailto:pav.c...@gmail.com] *Sent:* Thursday, March 27, 2014 5:29 PM *To:* Erick *Cc:* Leslie Meade; cisco-voip (cisco-voip@puck.nether.net) *Subject:* Re: [cisco-voip] Recording Proiles Leslie, When the speed dial is depressed, which line is being used to make the call ? Perhaps that line does not have a. Recording profile. What happens when you dial the same number manually on the same line ? I am reasonably sure that speed dials do not have anything to do with recording profiles. On Mar 27, 2014 7:18 PM, Erick erick...@gmail.com wrote: Is there only one line (dn) on the phone or multiple? If multiple maybe the speed dial is using a line without a recording profile. I don't have a 88xx handy but will try from a speed dial on a 99xx if I get a chance tomorrow. Sent from my iPhone On Mar 27, 2014, at 5:33 PM, Leslie Meade leslie.me...@lvs1.com wrote: I have a client that is using the 88XX model of phone with KEM's. They also have a recording profile configured and working with no issues. However when there is a speed dial configured(either on the device or the KEM) the call is not being recorded. When we place a packet capture on the Nice software we do not see and packets hitting it. Use a line and we see traffic being sent to the server. Now is it due to we can not a recording profile on a speed dial that is causing this ? or the BIB is not firing up when the speed dial is selected. I have not checked on the server as of yet. If we span the recording the call gets recorded. Leslie ___ cisco-voip mailing list cisco-voip@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-voip ___ cisco-voip mailing list cisco-voip@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-voip ___ cisco-voip mailing list cisco-voip@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-voip ___ cisco-voip mailing list cisco-voip@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-voip
Re: [cisco-voip] CUPC - Unable to go into deskphone control mode and unable to chat
Is the a reason you're using CUPC as opposed to Jabber? I'm not sure CUPC is support on CUCM and IMP 9.x? If you were to use Jabber here is the JFW guide http://www.cisco.com/c/en/us/td/docs/voice_ip_comm/jabber/Windows/9_6/InstallConfig/JABW_BK_CDFE9752_00_installation-and-configuration/JABW_BK_CDFE9752_00_installation-and-configuration_chapter_010.html On Fri, Mar 14, 2014 at 6:11 PM, Jeffrey Girard jeffrey.gir...@girardinc.com wrote: Home Lab - learning Presence CUCM 9 CUPS 9 (not 8.6 as virtually all of the help and discussion forums, documents, etc are for) CUPC 8.6 (3 copies running on 3 different laptops) 4 users configured in CUCM for Presence capabilities No LDAP integration Current status: Presence indicators for phones works fine, no issues 3 users can log into their CUPC clients and Presence information from their own associated deskphone displays correctly (ie if User 1 takes his deskphone offhook, the CUPC for User 1 shows as On the Phone Users can place phone calls with each other by typing the DN in the Search for name or number field I have two different issues that I have not been able to solve all day - they may be related to each other. The first issue: I am unable to go into deskphone mode. Although the checkbox is visible - it appears to be greyed out and clicking in it does nothing. The second issue: I am unable to start a chat session. I highlite a contact (that I manually entered), right click, and select chat. I get an error message that says Failed to start conversation. Invalid parameter I have scoured the Cisco site for docs and most of them pertain to CUPS 8.6 and not 9. There is a difference in that v9 does not have the Application - IP Phone Messenger selection. My current configs: CUCM 4 application users - CUPS-AXL (with Stand CCM SuperUsers permissions), CUPS-Deskphone, CUPS-CTIGW, and CUPS-PhoneMSG (all with Standard CTI Allow control of all devices). 3 end users - From top to bottom, all users have passwords and digest credentials. Under Service Settings, all users have the Enable user for Unified CM IM and Presence checked. This is the replacement for the assigning license capabilities from version 8.6. Also under Service Settings, all users have a UC Service Profile assigned. The UC Service Profile has two UC service settings - a Presence and IM Profile and a CTI Profile. Under Device Information - all user have been associated to two different devices (their hardphone and the CUPC client). Under the Directory Number Association portion - each user has their own primary line selected from the drop down box. Under the Permissions Information section - each user has Standard CCM End Users and Standard CTI Enabled permissions. Devices - each user has a 7960 hard phone and a CUPC. For each device (both types) at the Device Level - Owner User ID, Protocol Specific Information - BLF Presence Group, SUBSCRIBE CSS are all set. Under the line for each device (both types) - Allow control of device from CTI is checked, in the Associated Devices window is the MAC and UPCname of the devices, Under Users Associated with Line is the correct user Under System - Application Server, the CUP server is configured. Under System - Licensing, all users and devices are licensed. There is no Capabilities Assignment in version 9 CUPS Under Diagnostics - System Troubleshooter - all green except for the things not configured, LDAP, 3rd party, etc User Management - End User - are licensed for IM and Presence and have Microsoft RCC enabled. They also show 2 devices Under Application - this is where its different from v8 to v9. Application - Legacy Clients - Settings. I have set the TFTP server IP to the CUCM Application - Legacy Clients - CCMCIP Profile. I created a new profile, set the Primary and Secondary CCMCIP Host to be the IP Address of the CUCM Publisher. For Server Certification Verfication, I selected Any Certificate from the drop down. I assigned this profile to all 4 of my users. Application - Microsoft RCC settings. Application status = on. For Application Username and password, I have tried using CUPS-Deskphone and CUPS-CTIGW with their appropriate passwords. There is not difference in using either one of them. CUCM address is address of my Pub. I assigned this Microsoft RCC service to all 4 of my users. So, as I said, I have been working on this all day today burning my fingers and my mouse up on Google. To no avail. Any ideas anyone? Jeff ___ cisco-voip mailing list cisco-voip@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-voip ___ cisco-voip mailing list cisco-voip@puck.nether.net
Re: [cisco-voip] Estimated time to setup a brand new UCCX box
I'm assuming you're planning for a quote from a partner or attempting to justify one? That being said... As a partner quoting this for a client it would be about 8-16 hours with HA, just basic AA answering functionality, this would not include scripting, resource/skill groups or teams etc. Reason being, half of this time would be my travel, documentation for a design and finals hand over docs, all of these would be built into the project cost. It may seems a bit high but for what you're asking but it's not large enough to be considered a project with risk cost built in etc. For something this basic I would typically position a small TM engagement which will eliminate any risk or overhead on either side, also if it's TM on UCS this could all be handled remotely eliminating travel costs etc. HTH Ted On Mon, Mar 10, 2014 at 5:37 PM, Ryan Burtch rburt...@gmail.com wrote: I need a good estimate of the time that it should take an experienced engineer to setup and configure a UCCX box in an existing environment. I also need to know the time that it should take to setup a UCCX HA box. This is just the barebones config in order to get things up and running. I don't need an estimate for scripting or anything like that. Sincerely, Ryan Burtch ___ cisco-voip mailing list cisco-voip@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-voip ___ cisco-voip mailing list cisco-voip@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-voip
[cisco-voip] Migrate Unity Connection 8.5 Cluster to VMware-then upgrade to 9.1
I'd like to run this by some of you that might have gone through this before or have investigated it. I'm upgrading a Unity Connection 8.5 cluster (currently on MCS) to 9.1 on VMware without a loss of service. Here's the plan Take a DRS backup of the system reorder CUCM RLs so calls hit the subscriber node first (if needed) take down the publisher node rebuild the publisher node on VMware using the Cisco OVA Install the publisher with the same settings (hopefully this won't alter the License MAC so we won't need to rehost?) DRS restore the Publisher only Take down the Sub rebuild the Sub node on VMware using the Cisco OVA Install the Sub with the same settings, joining it to the cluster Question: (Assuming we don't need to rehost the licenses etc) is it necessary to restore the subscriber from DRS at that point? or will replication take over (only self signed certs in use) The remaining steps seem fairly straight forward upgrading from 8.5 to 9.1 screen shots of licensing pages to send to Licensing for 9.x license etc for ELM rehost. Thoughts? Anything I'm missing, anything way to make it easier? Thanks in advance for any suggestions Ted ___ cisco-voip mailing list cisco-voip@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-voip
Re: [cisco-voip] Migrate Unity Connection 8.5 Cluster to VMware-then upgrade to 9.1
Thanks for the feedback Matt I haven't upgraded anything newer than 8.5 that was on MCS so I was under the impression that the licensing MAC was used exclusively on 8.5+ as opposed to the MCS MAC, if that assumption is inaccurate, so be it, we will just need to rehost, not the end of the world. Regarding the loss of messages, this was something that I was concerned about however I thought I had read a post on the support forums (trying to find it now) where messages from the subscriber would be copied to the publisher after rebuilding the publisher server from DRS? This is actually less of a concern than loosing AAs and Call Tree functionality for the duration of the migration but it's definitely a concern. I understand that building a test bed is the ideal way of handling this but unfortunately finding the hardware to handle this has been a challenge and building a shadow network on the customer VM environment has not been blessed as of yet. Thanks again for your feedback. Ted On Mon, Feb 24, 2014 at 5:50 PM, Matthew Ballard mball...@otis.edu wrote: I can't speak to the subscriber part of the restore itself, but had a couple comments on this: 1. The license MAC will absolutely change. On physical boxes the license MAC is the MAC address of the NIC, on VMware, it is based on a bunch of settings, and so you will need to rehost the license. 2. Your process will likely create a data problem, as the DRS backup will only be accurate as of when you took the backup. Since you are intending system uptime between taking down the publisher and bring the new one online, any messages/other changes between when you take it down and bring the new one up will be lost. This is much more of a problem for Unity Connection than it is for UCM, as for UCM you mostly need an admin freeze on any changes (plus a couple things like mobility), but any data lost is minimal and easily fixed. For Unity Connection, you will just lose any messages left or greetings changed between backup and restore. The official way to do what you want with minimal downtime would be to build in a separate dev environment with the same IP/other structure, so that you can build the new 8.5 VM Servers, and then do a backup and restore (bringing down the existing system immediately after the backup with a downtime window scheduled). I ended up doing a partial method, where I used to firewall to simulate the same environment (providing the minimal services needed through a double NAT), so that the new servers saw just what they needed from the production environment, without conflicting. Matthew Ballard Network Manager Otis College of Art and Design mball...@otis.edu *From:* cisco-voip [mailto:cisco-voip-boun...@puck.nether.net] *On Behalf Of *Ted Nugent *Sent:* Monday, February 24, 2014 2:34 PM *To:* Cisco VoIPoE List *Subject:* [cisco-voip] Migrate Unity Connection 8.5 Cluster to VMware-then upgrade to 9.1 I'd like to run this by some of you that might have gone through this before or have investigated it. I'm upgrading a Unity Connection 8.5 cluster (currently on MCS) to 9.1 on VMware without a loss of service. Here's the plan Take a DRS backup of the system reorder CUCM RLs so calls hit the subscriber node first (if needed) take down the publisher node rebuild the publisher node on VMware using the Cisco OVA Install the publisher with the same settings (hopefully this won't alter the License MAC so we won't need to rehost?) DRS restore the Publisher only Take down the Sub rebuild the Sub node on VMware using the Cisco OVA Install the Sub with the same settings, joining it to the cluster Question: (Assuming we don't need to rehost the licenses etc) is it necessary to restore the subscriber from DRS at that point? or will replication take over (only self signed certs in use) The remaining steps seem fairly straight forward upgrading from 8.5 to 9.1 screen shots of licensing pages to send to Licensing for 9.x license etc for ELM rehost. Thoughts? Anything I'm missing, anything way to make it easier? Thanks in advance for any suggestions Ted ___ cisco-voip mailing list cisco-voip@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-voip
Re: [cisco-voip] Migrate Unity Connection 8.5 Cluster to VMware-then upgrade to 9.1
Here we go... This is what the support forum post was eluding to http://www.cisco.com/c/en/us/td/docs/voice_ip_comm/connection/9x/upgrade/guide/9xcucrugx/9xcucrug040.html#wp1052015 and I think this answers my question about adding the sub... nuke it and readd to the cluster before you rebuild http://www.cisco.com/c/en/us/td/docs/voice_ip_comm/connection/9x/upgrade/guide/9xcucrugx/9xcucrug040.html#wp1087854 On Mon, Feb 24, 2014 at 6:13 PM, Matthew Ballard mball...@otis.edu wrote: AFAIK physical MAC is still used in all scenarios when deploying on physical (vs virtual) hardware, certainly in the 8.x train (and I believe the 9.x train, although things change when you move to ELM which I can't speak to). I'm thinking the scenario you read about would be: 1. DRS backup publisher. 2. Take down publisher and configure network to not allow devices to talk to publisher (there may be a time after taking down the publisher and bringing up the new one that devices may try to communicate with the new one causing problems). 3. Install/bring up new publisher on virtual. 4. Restore publish. 5. Link new publisher with existing subscriber and allow them to sync (which is probably where the reference you found previously comes into play). 6. Remove prior traffic restrictions and make sure things are working on the new publisher. 7. Repeat process with subscriber (I can't speak as to whether DRS would be required or note for the subscriber). Hope that helps/makes sense. Note I not speaking from experience with this type of situation, but what I believe to be a situation that should work/makes sense based on your comments. I get the issues with hardware, I ended up doing the shadow environment I described due to a lack of hardware, but fortunately since I run the network here, I didn't need approval to do what I did. J Matthew Ballard Network Manager Otis College of Art and Design mball...@otis.edu *From:* rot...@gmail.com [mailto:rot...@gmail.com] *On Behalf Of *Ted Nugent *Sent:* Monday, February 24, 2014 3:03 PM *To:* Matthew Ballard *Cc:* Cisco VoIPoE List *Subject:* Re: [cisco-voip] Migrate Unity Connection 8.5 Cluster to VMware-then upgrade to 9.1 Thanks for the feedback Matt I haven't upgraded anything newer than 8.5 that was on MCS so I was under the impression that the licensing MAC was used exclusively on 8.5+ as opposed to the MCS MAC, if that assumption is inaccurate, so be it, we will just need to rehost, not the end of the world. Regarding the loss of messages, this was something that I was concerned about however I thought I had read a post on the support forums (trying to find it now) where messages from the subscriber would be copied to the publisher after rebuilding the publisher server from DRS? This is actually less of a concern than loosing AAs and Call Tree functionality for the duration of the migration but it's definitely a concern. I understand that building a test bed is the ideal way of handling this but unfortunately finding the hardware to handle this has been a challenge and building a shadow network on the customer VM environment has not been blessed as of yet. Thanks again for your feedback. Ted On Mon, Feb 24, 2014 at 5:50 PM, Matthew Ballard mball...@otis.edu wrote: I can't speak to the subscriber part of the restore itself, but had a couple comments on this: 1. The license MAC will absolutely change. On physical boxes the license MAC is the MAC address of the NIC, on VMware, it is based on a bunch of settings, and so you will need to rehost the license. 2. Your process will likely create a data problem, as the DRS backup will only be accurate as of when you took the backup. Since you are intending system uptime between taking down the publisher and bring the new one online, any messages/other changes between when you take it down and bring the new one up will be lost. This is much more of a problem for Unity Connection than it is for UCM, as for UCM you mostly need an admin freeze on any changes (plus a couple things like mobility), but any data lost is minimal and easily fixed. For Unity Connection, you will just lose any messages left or greetings changed between backup and restore. The official way to do what you want with minimal downtime would be to build in a separate dev environment with the same IP/other structure, so that you can build the new 8.5 VM Servers, and then do a backup and restore (bringing down the existing system immediately after the backup with a downtime window scheduled). I ended up doing a partial method, where I used to firewall to simulate the same environment (providing the minimal services needed through a double NAT), so that the new servers saw just what they needed from the production environment, without conflicting. Matthew Ballard Network Manager Otis
Re: [cisco-voip] Upgrades prohibited... *sigh*
That would be helpful, thanks. I personally don't see a way around it, supported or otherwise, either that or building a new SUB and updating CM Groups, MGRLs etc... Same amount of work and a couple resets but no downtime. On Tue, Feb 11, 2014 at 8:22 PM, Matthew Loraditch mloradi...@heliontechnologies.com wrote: Ted What you want to do with rebuild the sub is technically unsupported. I have done it myself and it seems to work ok as long as you remember custom tftp files and moh. However there are a lot of other possible gotchas that I heard straight from one of the BU folks during a session when they introduced Jump. Supposedly they were working on documenting the steps necessary to avoid these issues but I have heard of no progress. The gotchas mostly involved things having to do with service activation. I will try to see if I can find the recorded session tomorrow. Sent from my iPad On Feb 11, 2014, at 7:13 PM, Ted Nugent tednugen...@gmail.com wrote: I have a similar upgrade coming up next week.. 7.1.5 to 9.1.2 MCS to B200 M3 blades. Only question I really have is... are there any potential issues with just restoring the PUB and rebuilding the SUB from scratch, other than TFTP files etc? We're having to do it in production without an official maintenance window because it's a hospital with allot of moving parts. The idea is to take down the PUB, build the PUB on the same IP, restore just the PUB and then upgrade. Failover to the new PUB and rebuild the Sub from scratch, move over the MOH files etc. Thoughts one that? BTW.. thanks for updating on your progress Lelio, very helpful in seeing the gotcha I've not hit previously. On Tue, Feb 11, 2014 at 4:59 PM, Lelio Fulgenzi le...@uoguelph.ca wrote: lol. thanks Matthew. I think I'm going to have to engage our partner for an official answer this week, while I try out some scenarios. Bottom line is, if Cisco isn't going to officially support this or help out, then I have to go to management and let them know, and they can raise the roof. ;) It would be nice to at least get a no, sorry, the COP refresh file does not properly disable upgrade restrictions on MCS hardware - or something like that. I can't believe I'm the only one out here that doesn't have the money to go to VM just yet, and has enough hardware to do an off-line install with supported hardware. I guess if the supported way to is to get licenses rehosted, than I'm OK with that, as long as our partner will support us when the requests go to licensing. Interestingly enough, I was reading the main page ( https://supportforums.cisco.com/docs/DOC-35163) and found the following bug listed there (https://tools.cisco.com/bugsearch/bug/CSCtb86875) which states that I need install the license after the DRS restore. So this would make the correct order: 1. install v7 2. install COP/refresh 3. do DRS 4. reboot servers 5. perform dbreplicate fixes if required 6. upload license 7. perform upgrades We'll have to see how my next test goes. Funny thing is, the license reporting page shows no problem with the licenses. Weird. Oh well, tomorrow's another day. --- Lelio Fulgenzi, B.A. Senior Analyst, Network Infrastructure Computing and Communications Services (CCS) University of Guelph 519‐824‐4120 Ext 56354 le...@uoguelph.ca www.uoguelph.ca/ccs Room 037, Animal Science and Nutrition Building Guelph, Ontario, N1G 2W1 -- *From: *Matthew Loraditch mloradi...@heliontechnologies.com *To: *Lelio Fulgenzi le...@uoguelph.ca *Cc: *cisco-voip cisco-voip@puck.nether.net *Sent: *Tuesday, February 11, 2014 4:37:50 PM *Subject: *RE: [cisco-voip] Upgrades prohibited... *sigh* Yes you are technically correct about the refresh file. The original version was designed to allow the OS upgrades that happened with 8.6 to 8.6+. They then added the removal of the license check with v1.2 and 1.3 of the refresh solely for the Jump upgrade. So yes you will need the refresh file to install 9.1.2 but you won’t have to deal with the licensing crud if you rehost. The jump upgrade is the recommended path because VMWare is the recommended path what you are doing is what every cisco partner, TAC and sales employee doesn’t want you to do, but technically still supports. We all still love you Lelio, but I know the PM in charge of the OS stuff and he’d cringe knowing you were doing this :) I would install your licenses before the refresh file but I’d guess it won’t matter. image001.jpg Matthew G. Loraditch – CCNP-Voice, CCNA-RS, CCDA 1965 Greenspring Drive Timonium, MD 21093 direct voice. 443.541.1518 fax. 410.252.9284 Twitter http://twitter.com/heliontech | Facebookhttp://www.facebook.com/#!/pages/Helion/252157915296 | Website http://www.heliontechnologies.com/ | Email Supportsupp...@heliontechnologies.com?subject=Technical%20Support%20Request
Re: [cisco-voip] Upgrades prohibited... *sigh*
Thanks Ryan The plan was to get the PUB 100% on 9.1.2, kill the old sub forcing the phones to the Pub (reordering CM group to make PUB primary just in case) and then rebuild the Sub from scratch on the same IP/host and/or build a second SUB and reorder the CM groups etc. The problem is we've been given strict guidelines of no more than 5 minutes down time and unfortunately there's no time or equipment to rebuild in a siloed network and just spin them up. I'm curious what are the ramifications? Perhaps I'm overlooking something but how is this much different then having to rebuild a sub from scratch if it fails? Any feedback is appreciated. Thanks On Wed, Feb 12, 2014 at 12:17 PM, Ryan Ratliff (rratliff) rratl...@cisco.com wrote: You shouldn't have to delete any subscribers. In order to do so you'll have to go through a lot of pain removing them from CM groups, etc. What you want to do will save time assuming everything works perfectly and no phone touches the new cluster until all the subs are installed and replication is 100% ok. Off the top of my head you will lose: - Any firmware, ringlists, or other TFTP files on your subs. - Any custom MOH files on your subs - All certificates on the subs. If any one of those things is important enough for your customer that it can't go wrong then take the time to do the full documented jump procedure. -Ryan On Feb 11, 2014, at 8:39 PM, Bill Talley btal...@gmail.com wrote: In other words, you're saying delete the subscriber BEFORE upgrading? i.e. move the pub to an isolated network, delete the sub, upgrade, backup, install new instance to align partitions, restore pub, add new sub to cluster, etc etc etc? Sent from an Apple iOS touchscreen device with very tiny touchscreen input keys. Please excude my typtos. On Feb 11, 2014, at 7:25 PM, Matthew Loraditch mloradi...@heliontechnologies.com wrote: Ted What you want to do with rebuild the sub is technically unsupported. I have done it myself and it seems to work ok as long as you remember custom tftp files and moh. However there are a lot of other possible gotchas that I heard straight from one of the BU folks during a session when they introduced Jump. Supposedly they were working on documenting the steps necessary to avoid these issues but I have heard of no progress. The gotchas mostly involved things having to do with service activation. I will try to see if I can find the recorded session tomorrow. Sent from my iPad On Feb 11, 2014, at 7:13 PM, Ted Nugent tednugen...@gmail.com wrote: I have a similar upgrade coming up next week.. 7.1.5 to 9.1.2 MCS to B200 M3 blades. Only question I really have is... are there any potential issues with just restoring the PUB and rebuilding the SUB from scratch, other than TFTP files etc? We're having to do it in production without an official maintenance window because it's a hospital with allot of moving parts. The idea is to take down the PUB, build the PUB on the same IP, restore just the PUB and then upgrade. Failover to the new PUB and rebuild the Sub from scratch, move over the MOH files etc. Thoughts one that? BTW.. thanks for updating on your progress Lelio, very helpful in seeing the gotcha I've not hit previously. On Tue, Feb 11, 2014 at 4:59 PM, Lelio Fulgenzi le...@uoguelph.ca wrote: lol. thanks Matthew. I think I'm going to have to engage our partner for an official answer this week, while I try out some scenarios. Bottom line is, if Cisco isn't going to officially support this or help out, then I have to go to management and let them know, and they can raise the roof. ;) It would be nice to at least get a no, sorry, the COP refresh file does not properly disable upgrade restrictions on MCS hardware - or something like that. I can't believe I'm the only one out here that doesn't have the money to go to VM just yet, and has enough hardware to do an off-line install with supported hardware. I guess if the supported way to is to get licenses rehosted, than I'm OK with that, as long as our partner will support us when the requests go to licensing. Interestingly enough, I was reading the main page ( https://supportforums.cisco.com/docs/DOC-35163) and found the following bug listed there (https://tools.cisco.com/bugsearch/bug/CSCtb86875) which states that I need install the license after the DRS restore. So this would make the correct order: 1. install v7 2. install COP/refresh 3. do DRS 4. reboot servers 5. perform dbreplicate fixes if required 6. upload license 7. perform upgrades We'll have to see how my next test goes. Funny thing is, the license reporting page shows no problem with the licenses. Weird. Oh well, tomorrow's another day. --- Lelio Fulgenzi, B.A. Senior Analyst, Network Infrastructure Computing and Communications Services (CCS) University of Guelph 519‐824‐4120 Ext 56354 le...@uoguelph.ca www.uoguelph.ca
