Re: [cisco-voip] Very Strange SSL Issue...
When issuing certs with SANS the CN needs to included as a SAN. FYI On Wed, May 27, 2015 at 6:57 AM, Matthew Loraditch mloradi...@heliontechnologies.com wrote: The only SAN was the root of the domain name.. but I removed that and now it works. Oddest thing I’ve seen in a while.. Matthew G. Loraditch – CCNP-Voice, CCNA-RS, CCDA Network Engineer Direct Voice: 443.541.1518 Facebook https://www.facebook.com/heliontech?ref=hl | Twitter https://twitter.com/HelionTech | LinkedIn https://www.linkedin.com/company/helion-technologies?trk=top_nav_home | G+ https://plus.google.com/+Heliontechnologies/posts *From:* Ryan Ratliff (rratliff) [mailto:rratl...@cisco.com] *Sent:* Thursday, May 21, 2015 2:41 PM *To:* Matthew Loraditch *Cc:* cisco-voip voyp list *Subject:* Re: [cisco-voip] Very Strange SSL Issue... Check and see if the CN is also a SAN. I’ve seen recent browsers that ignore CN if any SAN is present. -Ryan On May 20, 2015, at 1:31 PM, Matthew Loraditch mloradi...@heliontechnologies.com wrote: Has anyone ever seen where you put a cert on CUCM/CUCXN/IMP and the Subject name matches but your browser insists it doesn’t? I can’t figure this out. I checked as best I could for spaces like mentioned in Lelio’s recent thread about a CSR and I have no indication of that. I honestly don’t have a clue where to go, it’s not really a server issue as the server is just presenting the cert I installed, but I have it on both UCxn and CCM/IMP. I can’t believe I put an errant space on both servers… Matthew G. Loraditch – CCNP-Voice, CCNA-RS, CCDA Network Engineer Direct Voice: 443.541.1518 Facebook https://www.facebook.com/heliontech?ref=hl | Twitter https://twitter.com/HelionTech | LinkedIn https://www.linkedin.com/company/helion-technologies?trk=top_nav_home | G+ https://plus.google.com/+Heliontechnologies/posts ___ 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] Very Strange SSL Issue...
That makes sense, but I know I’ve done this before w/o issue, albeit I may not have been at precisely the version this server was at in this scenario (single server 10.5.2SU1). Matthew G. Loraditch – CCNP-Voice, CCNA-RS, CCDA Network Engineer Direct Voice: 443.541.1518 Facebookhttps://www.facebook.com/heliontech?ref=hl | Twitterhttps://twitter.com/HelionTech | LinkedInhttps://www.linkedin.com/company/helion-technologies?trk=top_nav_home | G+https://plus.google.com/+Heliontechnologies/posts From: Andrew Grech [mailto:agrec...@gmail.com] Sent: Wednesday, May 27, 2015 6:18 AM To: Matthew Loraditch Cc: Ryan Ratliff (rratliff); cisco-voip voyp list Subject: Re: [cisco-voip] Very Strange SSL Issue... When issuing certs with SANS the CN needs to included as a SAN. FYI On Wed, May 27, 2015 at 6:57 AM, Matthew Loraditch mloradi...@heliontechnologies.commailto:mloradi...@heliontechnologies.com wrote: The only SAN was the root of the domain name.. but I removed that and now it works. Oddest thing I’ve seen in a while.. Matthew G. Loraditch – CCNP-Voice, CCNA-RS, CCDA Network Engineer Direct Voice: 443.541.1518 Facebookhttps://www.facebook.com/heliontech?ref=hl | Twitterhttps://twitter.com/HelionTech | LinkedInhttps://www.linkedin.com/company/helion-technologies?trk=top_nav_home | G+https://plus.google.com/+Heliontechnologies/posts From: Ryan Ratliff (rratliff) [mailto:rratl...@cisco.commailto:rratl...@cisco.com] Sent: Thursday, May 21, 2015 2:41 PM To: Matthew Loraditch Cc: cisco-voip voyp list Subject: Re: [cisco-voip] Very Strange SSL Issue... Check and see if the CN is also a SAN. I’ve seen recent browsers that ignore CN if any SAN is present. -Ryan On May 20, 2015, at 1:31 PM, Matthew Loraditch mloradi...@heliontechnologies.commailto:mloradi...@heliontechnologies.com wrote: Has anyone ever seen where you put a cert on CUCM/CUCXN/IMP and the Subject name matches but your browser insists it doesn’t? I can’t figure this out. I checked as best I could for spaces like mentioned in Lelio’s recent thread about a CSR and I have no indication of that. I honestly don’t have a clue where to go, it’s not really a server issue as the server is just presenting the cert I installed, but I have it on both UCxn and CCM/IMP. I can’t believe I put an errant space on both servers… Matthew G. Loraditch – CCNP-Voice, CCNA-RS, CCDA Network Engineer Direct Voice: 443.541.1518 Facebookhttps://www.facebook.com/heliontech?ref=hl | Twitterhttps://twitter.com/HelionTech | LinkedInhttps://www.linkedin.com/company/helion-technologies?trk=top_nav_home | G+https://plus.google.com/+Heliontechnologies/posts ___ cisco-voip mailing list cisco-voip@puck.nether.netmailto:cisco-voip@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-voip ___ cisco-voip mailing list cisco-voip@puck.nether.netmailto: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] OT: Telemanagement software/IT billing
Tri-Line here no complaints On Wed, May 27, 2015 at 5:16 AM, Ed Leatherman ealeather...@gmail.com wrote: Hello! I was wondering if any edu folks on the list would mind a few out-of-band questions around telemanagement software, IT billing, and the like. We're looking at renewal/upgrade on our current software and the pricing we're getting us is prompting us to do some research into other solutions. Thanks! Ed -- Ed Leatherman ___ 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] LDAP Sync question - adding LDAP sync to existing CM Cluster
Hi Everyone, We've just upgraded to CM 10.5.2, and the next thing I want to do is enable LDAP sync for users. The question I want to ask is what happens to existing users set via CM. Matching users will get data overwritten by LDAP, and account converted to LDAP account. What happens to users that are not matched with LDAP during the initial sync, do they remain as locally administered accounts? The more I read the more conflicting information I get about the 'non matching' users. Thanks, Hefin ___ cisco-voip mailing list cisco-voip@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-voip
Re: [cisco-voip] LDAP Sync question - adding LDAP sync to existing CM Cluster
Hefin, the locally created users are still going to be present, will still use local authentication, and you can also continue to create additional local users. Note: I believe this behavior began with version 10.0. http://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cucm/srnd/collab10/collab10/directry.html#pgfId-1067953 -Dave On Wed, May 27, 2015 at 7:24 AM, Hefin James [ahj] a...@aber.ac.uk wrote: Hi Everyone, We've just upgraded to CM 10.5.2, and the next thing I want to do is enable LDAP sync for users. The question I want to ask is what happens to existing users set via CM. Matching users will get data overwritten by LDAP, and account converted to LDAP account. What happens to users that are not matched with LDAP during the initial sync, do they remain as locally administered accounts? The more I read the more conflicting information I get about the 'non matching' users. Thanks, Hefin ___ 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] MGCP Odd issue
The Mandatory information element missing error states the missing IE is 0x18. That is referring to the fact that the CALL_PROC you sent telco contains no Channel ID IE, which is normally required. Looking further back in the call flow, it seems that after the initial SETUP message was received, you sent telco a SETUP_ACK - which they also complained about receiving (Message not compatible with call state). If this PRI is truly under the control of UCM registered as MGCP, and not under local IOS control, it seems like UCM has gone into overlap receiving mode, where it expects to receive potentially additional digits in INFORMATION messages. I don't think you're going to find any public PRI service providers (at least not in the US) who will use overlap sending; they will send you all the digits in the initial SETUP. Can you look in your Service Parameters for CallManager and check if the Overlap Receiving for PRI Flag is set to True? It is normally False by default (from memory). Keep in mind the setting is cluster-wide, so if you decide to change it, make sure you don't have any UCM-managed PRI interfaces where you actually do need to use overlap receiving. BTW, from what I am able to find, the 5ESS protocol (and presumably 4ESS) has no such message SETUP_ACK that would be used for overlap receiving mode. That is probably why changing the protocol makes the error go away, since UCM is probably not going to send that message telco doesn't like, since doing so would violate the configured protocol. -Dave On Tue, May 26, 2015 at 11:26 PM, Barry Howser bhowser5...@gmail.com wrote: Hi Dave. I have placed the full q931 from a failed call inline below. The mandatory missing IE is at the bottom. Syslog logging: enabled (0 messages dropped, 63 messages rate-limited, 0 flushes, 0 overruns, xml disabled, filtering disabled) No Active Message Discriminator. No Inactive Message Discriminator. Console logging: disabled Monitor logging: level debugging, 0 messages logged, xml disabled, filtering disabled Buffer logging: level debugging, 140 messages logged, xml disabled, filtering disabled Exception Logging: size (4096 bytes) Count and timestamp logging messages: disabled Persistent logging: disabled No active filter modules. Trap logging: level informational, 1381 message lines logged Logging to XXX.XXX.XXX.XXX (udp port 514, audit disabled, link up), 1380 message lines logged, 0 message lines rate-limited, 0 message lines dropped-by-MD, xml disabled, sequence number disabled filtering disabled Logging to XXX.XXX.XXX.XXX (udp port 514, audit disabled, link up), 1381 message lines logged, 0 message lines rate-limited, 0 message lines dropped-by-MD, xml disabled, sequence number disabled filtering disabled Logging Source-Interface: VRF Name: Loopback0 Log Buffer (1000 bytes): May 27 03:21:05.580: ISDN Se0/1/0:23 Q931: RX - SETUP pd = 8 callref = 0x005D Bearer Capability i = 0x8090A2 Standard = CCITT Transfer Capability = Speech Transfer Mode = Circuit Transfer Rate = 64 kbit/s Channel ID i = 0xA18381 Preferred, Channel 1 Facility i = 0x9F8B0100A1110201010201008009485546462C5259414E Protocol Profile = Networking Extensions 0xA1110201010201008009485546462C5259414E Component = Invoke component Invoke Id = 1 Operation = CallingName Name Presentation Allowed Extended Name = HOWSER,BARRY Calling Party Number i = 0x2180, 'DN-INTENTIONALLY-REMOVED' Plan:ISDN, Type:National Called Party Number i = 0xA1, 'DN-INTENTIONALLY-REMOVED' Plan:ISDN, Type:National May 27 03:21:05.632: ISDN Se0/1/0:23 Q931: TX - SETUP_ACK pd = 8 callref = 0x805D Channel ID i = 0xA98381 Exclusive, Channel 1 May 27 03:21:05.656: ISDN Se0/1/0:23 Q931: RX - STATUS pd = 8 callref = 0x005D Cause i = 0x82E50D - Message not compatible with call state Call State i = 0x06 May 27 03:21:09.560: ISDN Se0/1/0:23 Q931: RX - SETUP pd = 8 callref = 0x005D Bearer Capability i = 0x8090A2 Standard = CCITT Transfer Capability = Speech Transfer Mode = Circuit Transfer Rate = 64 kbit/s Channel ID i = 0xA18381 Preferred, Channel 1 Facility i = 0x9F8B0100A1110201010201008009485546462C5259414E Protocol Profile = Networking Extensions 0xA1110201010201008009485546462C5259414E Component = Invoke component Invoke Id = 1 Operation = CallingName Name Presentation Allowed Extended Name = HOWSER,BARRY
[cisco-voip] inbound h.323 calls fail to Expressway
Hi, I’m having issues with inbound h.323 calls to our Expressway deployment. SIP calls work ok both directions. So we have SX10/MX300G2 endpoints registered to call manager if an external user dials the url 123...@ip.addr.of.vcse i can see the call hit the expressway-e, but the call fails with no route to host. Do I need to have a separate Traversal Zone for h.323 and SIP to achieve this? Looking at the Basic setup for Expressway its not clear. On the e i have On the c I have Andy andy.ca...@gmail.com ___ cisco-voip mailing list cisco-voip@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-voip
Re: [cisco-voip] Very Strange SSL Issue...
The requirement of the CN being in the SAN is a browser thing, not a server issue. It’s also going to be a CA requirement going forward if you buy certs from external CAs. -Ryan On May 27, 2015, at 7:29 AM, Matthew Loraditch mloradi...@heliontechnologies.commailto:mloradi...@heliontechnologies.com wrote: That makes sense, but I know I’ve done this before w/o issue, albeit I may not have been at precisely the version this server was at in this scenario (single server 10.5.2SU1). Matthew G. Loraditch – CCNP-Voice, CCNA-RS, CCDA Network Engineer Direct Voice: 443.541.1518 Facebookhttps://www.facebook.com/heliontech?ref=hl | Twitterhttps://twitter.com/HelionTech | LinkedInhttps://www.linkedin.com/company/helion-technologies?trk=top_nav_home | G+https://plus.google.com/+Heliontechnologies/posts From: Andrew Grech [mailto:agrec...@gmail.com] Sent: Wednesday, May 27, 2015 6:18 AM To: Matthew Loraditch Cc: Ryan Ratliff (rratliff); cisco-voip voyp list Subject: Re: [cisco-voip] Very Strange SSL Issue... When issuing certs with SANS the CN needs to included as a SAN. FYI On Wed, May 27, 2015 at 6:57 AM, Matthew Loraditch mloradi...@heliontechnologies.commailto:mloradi...@heliontechnologies.com wrote: The only SAN was the root of the domain name.. but I removed that and now it works. Oddest thing I’ve seen in a while.. Matthew G. Loraditch – CCNP-Voice, CCNA-RS, CCDA Network Engineer Direct Voice: 443.541.1518 Facebookhttps://www.facebook.com/heliontech?ref=hl | Twitterhttps://twitter.com/HelionTech | LinkedInhttps://www.linkedin.com/company/helion-technologies?trk=top_nav_home | G+https://plus.google.com/+Heliontechnologies/posts From: Ryan Ratliff (rratliff) [mailto:rratl...@cisco.commailto:rratl...@cisco.com] Sent: Thursday, May 21, 2015 2:41 PM To: Matthew Loraditch Cc: cisco-voip voyp list Subject: Re: [cisco-voip] Very Strange SSL Issue... Check and see if the CN is also a SAN. I’ve seen recent browsers that ignore CN if any SAN is present. -Ryan On May 20, 2015, at 1:31 PM, Matthew Loraditch mloradi...@heliontechnologies.commailto:mloradi...@heliontechnologies.com wrote: Has anyone ever seen where you put a cert on CUCM/CUCXN/IMP and the Subject name matches but your browser insists it doesn’t? I can’t figure this out. I checked as best I could for spaces like mentioned in Lelio’s recent thread about a CSR and I have no indication of that. I honestly don’t have a clue where to go, it’s not really a server issue as the server is just presenting the cert I installed, but I have it on both UCxn and CCM/IMP. I can’t believe I put an errant space on both servers… Matthew G. Loraditch – CCNP-Voice, CCNA-RS, CCDA Network Engineer Direct Voice: 443.541.1518 Facebookhttps://www.facebook.com/heliontech?ref=hl | Twitterhttps://twitter.com/HelionTech | LinkedInhttps://www.linkedin.com/company/helion-technologies?trk=top_nav_home | G+https://plus.google.com/+Heliontechnologies/posts ___ cisco-voip mailing list cisco-voip@puck.nether.netmailto:cisco-voip@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-voip ___ cisco-voip mailing list cisco-voip@puck.nether.netmailto: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] Caller order when presented to hunt groups
Are the same line group members in both HG1 and HG2? You should have separate line appearances for HG1 and HG2 so that agents will answer HG2 first if there's a call for it. On Wed, May 27, 2015 at 10:45 AM, Nick csv...@googlemail.com wrote: Hi All Anyone come across this scenario before? On 26 May 2015 at 11:51, Nick csv...@googlemail.com wrote: Fruther info on this is that the callers only lose the order of once they have tripped to the secondary line group, new callers ringing n thr first line group get answered first. Scenario as follows Call A arrives at HG1 Call B arrives at HG1 after call A Call A is unanswered and goes to HG 2 Agent answers the next call presented and is presented call B even though total time waiting is shorter than call A On 26 May 2015 at 10:04, Nick csv...@googlemail.com wrote: I have had a query from a customer where we have a small site with 6 channels BRI, single number to a hunt pilot with a hunt list contraining two tiered line groups who claims that when they have multiple calls coming into the hunt group if they are not answered within the 12 seconds set on line group 1 and the calls trip to line group 2 when the first call is answered is will not be the caller who dialled into the hunt group first and the callers will randomly be presented for answer. Its not a sceanrio I have come across before and cannot find any information on this in any documentation, so does anyone know if that is workingcorrectly or if we have an issue here. Anyone come across anything like this before? ___ 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] Changing DNS entries in Call Manager 9.1.2.10000-28
We do have a secondary DNS in place, after further investigation he primary DNS never went fully down, it went unresponsive during a back-up procedure. Is it that since the DNS never went ‘fully’ down the Cisco voice side (the SIP trunks) never knew to switch to the secondary DNS (not as smart as the Microsoft workstations/servers). Thank you From: Jason Aarons (AM) [mailto:jason.aar...@dimensiondata.com] Sent: Tuesday, May 26, 2015 8:03 PM To: Gyrion, Larry; Cisco-voip (cisco-voip@puck.nether.net) Subject: RE: Changing DNS entries in Call Manager 9.1.2.1-28 Everything is hostnames so https works without complaining. Certificates with ip addresses give warnings. 443/TLS/PKI is the future ☺ You can change CUCM back to ip address but applications and websites, clients like Jabber, will give warnings/errors. I think your DNS should be rock solid, maybe you need secondary/tertiary dns entries. From: cisco-voip [mailto:cisco-voip-boun...@puck.nether.net] On Behalf Of Gyrion, Larry Sent: Tuesday, May 26, 2015 5:20 PM To: Cisco-voip (cisco-voip@puck.nether.netmailto:cisco-voip@puck.nether.net) Subject: [cisco-voip] Changing DNS entries in Call Manager 9.1.2.1-28 We had an issue where we lost outbound calling ability when out primary DNS experiencing an unscheduled outage. Our DNS entries are by host-name, not IP address. (it never failed over to the secondary DNS server, other items like computers did and internal and incoming traffic was working fine) We also use UCCE 9 I’m not sure why it was configured by host name rather than IP address when it was configured a long time ago. So my questions are: Is there a valid reason why we use host-names instead of ip addresses? How can we change from host-name to IP address? Will this affect the licensing (ELM)? (The below is reference to pre 9.0 CUCM) From: avhollo...@gmail.commailto:avhollo...@gmail.com [mailto:avhollo...@gmail.com] On Behalf Of Anthony Holloway Sent: Monday, January 26, 2015 8:13 PM To: Gyrion, Larry; Cisco-voip (cisco-voip@puck.nether.netmailto:cisco-voip@puck.nether.net) Subject: Re: [cisco-voip] Changing DNS entries in Call Manager 8.6.2 The easiest way to view the license MAC, is to SSH to the server, and issue the show status command. Also, http://cisco.com/go/license enables you to rehost your own license files without opening a case. Of course, I don't guarantee you'll be successful, but it's nice to know this option exists. [Inline image 1] Another thing to note, you will get 30 days to rehost your license before anything bad happens to your servers, but if you're in a pinch, and you're like on day 28 and you need like 10 more days, you can revert your change, then make the same change again, to restart the 30 day period. If that was confusing, let me use this example. If my primary DNS was 1.1.1.1, and I changed it to 2.2.2.2, I would have 30 days to rehost my licenses. On day 28, I set the primary DNS back to 1.1.1.1, then immediately back to 2.2.2.2, and the 30 days starts over. Last, buy certainly not least, if you are changing DNS settings, it would be imperative for you to consider what might happen if you changed your DNS suffix. I cannot speak to your environment exactly, but suffice it to say, certificates are based on names, and names sometimes contain DNS suffixes. You might start a chain reaction of changes, and as such you should plan that piece out more carefully. If you're only changing DNS server addresses, then you can ignore this last paragraph. Good luck. On Mon Jan 26 2015 at 4:43:19 PM Gyrion, Larry larry.gyr...@deancare.commailto:larry.gyr...@deancare.com wrote: Looking for some guidance on updating the DNS entries on our CUCM cluster. A colleague went through the process, but upon entering the command received a warning stating that the change would invalidate our licenses. Has anybody come across this before, and if so, what was the proper course of action to ensure license preservation? CUCM 8.6.2 Thank you, Larry Gyrion | Telecommunications Analyst | Information Technology Dean Clinic - Corporate offices 1800 W. Beltline Hwy Madison WI. 53713 Phone 608.294.6201tel:608.294.6201 | 5406201| Fax 608.280.6852tel:608.280.6852 larry.gyr...@deancare.commailto:larry.gyr...@deancare.com | www.deancare.comhttp://www.deancare.com/ Partners who care The information contained in this e-mail message and any attachments may be proprietary and is intended only for the confidential use of the designated recipient named above. If the reader of this message is not the intended recipient or an agent responsible for delivering it to the intended recipient, you are hereby notified that you have received this document in error and that any review, dissemination, distribution or copying of this message is strictly prohibited. If you have received this communication in error please notify us immediately at the e-mail address listed above. Thank you.
Re: [cisco-voip] ATA190 Registration Failed
Can you grab the console logs from the ATA and download the config file? On Wed, May 27, 2015 at 1:24 AM, Alessandro Bertacco bertacco.alessan...@alice.it wrote: Hi Brian, thanks for the answer, but this is the only one node in the cluster. -- Da: Brian Meade bmead...@vt.edu Inviato: 26/05/2015 23:06 A: Alessandro Bertacco bertacco.alessan...@alice.it Cc: cisco-voip@puck.nether.net Oggetto: Re: [cisco-voip] ATA190 Registration Failed It looks like these traces are from a backup CCM node in the CM Group. You can see the expires=0 in the Register message and the 200OK so it is instantly un-registering. That's usually how SIP devices keep status on a failover server. Do you have the logs from the primary node? On Tue, May 26, 2015 at 4:57 PM, Alessandro Bertacco bertacco.alessan...@alice.it wrote: Hi all, we have issue with ATA190 (FW version 1.1.2(0.05) that don't register with our CUCM 10.5.x. (Changing the ATA190 device, issue persist) Cluster of one node in mixed mode, but we don’t use encryption to the endpoint. Standard non secure profile are used. The device is already configured from Communication Manager Side, with the mac-address and DN. TFTP server is correctly issued on theATA190 adapter, but from the Web interface I can see registration failed. (Also from CUCM side) From the Communication Manager, I've captured some SDL log regarding the Registration request sent from the ATA90 that the ip address is 192.168.121.52, and primary MAC addres is: 34DBFD186BCA. The trace is attached to this email. Any idea? Thank you for your time Regards -- Alessandro Bertacco ___ 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] Caller order when presented to hunt groups
Hi All Anyone come across this scenario before? On 26 May 2015 at 11:51, Nick csv...@googlemail.com wrote: Fruther info on this is that the callers only lose the order of once they have tripped to the secondary line group, new callers ringing n thr first line group get answered first. Scenario as follows Call A arrives at HG1 Call B arrives at HG1 after call A Call A is unanswered and goes to HG 2 Agent answers the next call presented and is presented call B even though total time waiting is shorter than call A On 26 May 2015 at 10:04, Nick csv...@googlemail.com wrote: I have had a query from a customer where we have a small site with 6 channels BRI, single number to a hunt pilot with a hunt list contraining two tiered line groups who claims that when they have multiple calls coming into the hunt group if they are not answered within the 12 seconds set on line group 1 and the calls trip to line group 2 when the first call is answered is will not be the caller who dialled into the hunt group first and the callers will randomly be presented for answer. Its not a sceanrio I have come across before and cannot find any information on this in any documentation, so does anyone know if that is workingcorrectly or if we have an issue here. Anyone come across anything like this before? ___ cisco-voip mailing list cisco-voip@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-voip
Re: [cisco-voip] Changing DNS entries in Call Manager 9.1.2.10000-28
are you sure that all your CM subscribers have the proper primary and secondary DNS ?Since your outbound is the only think that failed, maybe you have a specific CM sub routing the outbound calls and it didn't have proper redundant DNS. Or maybe you had a MGCP gateway for outbound that didn't have secondary DNS so it unregistered from the CMs when the primary went down.or maybe you hit a bug with regards to DNS failover like you suspect, but it is also possible that there is just a component in the solution that doesn't have redundant DNS and it only affected outbound calls. On Wed, May 27, 2015 at 10:17 AM, Gyrion, Larry larry.gyr...@deancare.com wrote: We do have a secondary DNS in place, after further investigation he primary DNS never went fully down, it went unresponsive during a back-up procedure. Is it that since the DNS never went ‘fully’ down the Cisco voice side (the SIP trunks) never knew to switch to the secondary DNS (not as smart as the Microsoft workstations/servers). Thank you *From:* Jason Aarons (AM) [mailto:jason.aar...@dimensiondata.com] *Sent:* Tuesday, May 26, 2015 8:03 PM *To:* Gyrion, Larry; Cisco-voip (cisco-voip@puck.nether.net) *Subject:* RE: Changing DNS entries in Call Manager 9.1.2.1-28 Everything is hostnames so https works without complaining. Certificates with ip addresses give warnings. 443/TLS/PKI is the future J You can change CUCM back to ip address but applications and websites, clients like Jabber, will give warnings/errors. I think your DNS should be rock solid, maybe you need secondary/tertiary dns entries. *From:* cisco-voip [mailto:cisco-voip-boun...@puck.nether.net cisco-voip-boun...@puck.nether.net] *On Behalf Of *Gyrion, Larry *Sent:* Tuesday, May 26, 2015 5:20 PM *To:* Cisco-voip (cisco-voip@puck.nether.net) *Subject:* [cisco-voip] Changing DNS entries in Call Manager 9.1.2.1-28 We had an issue where we lost outbound calling ability when out primary DNS experiencing an unscheduled outage. Our DNS entries are by host-name, not IP address. (it never failed over to the secondary DNS server, other items like computers did and internal and incoming traffic was working fine) We also use UCCE 9 I’m not sure why it was configured by host name rather than IP address when it was configured a long time ago. So my questions are: Is there a valid reason why we use host-names instead of ip addresses? How can we change from host-name to IP address? Will this affect the licensing (ELM)? (The below is reference to pre 9.0 CUCM) *From:* avhollo...@gmail.com [mailto:avhollo...@gmail.com avhollo...@gmail.com] *On Behalf Of *Anthony Holloway *Sent:* Monday, January 26, 2015 8:13 PM *To:* Gyrion, Larry; Cisco-voip (cisco-voip@puck.nether.net) *Subject:* Re: [cisco-voip] Changing DNS entries in Call Manager 8.6.2 The easiest way to view the license MAC, is to SSH to the server, and issue the show status command. Also, http://cisco.com/go/license enables you to rehost your own license files without opening a case. Of course, I don't guarantee you'll be successful, but it's nice to know this option exists. [image: Inline image 1] Another thing to note, you will get 30 days to rehost your license before anything bad happens to your servers, but if you're in a pinch, and you're like on day 28 and you need like 10 more days, you can revert your change, then make the same change again, to restart the 30 day period. If that was confusing, let me use this example. If my primary DNS was 1.1.1.1, and I changed it to 2.2.2.2, I would have 30 days to rehost my licenses. On day 28, I set the primary DNS back to 1.1.1.1, then immediately back to 2.2.2.2, and the 30 days starts over. Last, buy certainly not least, if you are changing DNS settings, it would be imperative for you to consider what might happen if you changed your DNS suffix. I cannot speak to your environment exactly, but suffice it to say, certificates are based on names, and names sometimes contain DNS suffixes. You might start a chain reaction of changes, and as such you should plan that piece out more carefully. If you're only changing DNS server addresses, then you can ignore this last paragraph. Good luck. On Mon Jan 26 2015 at 4:43:19 PM Gyrion, Larry larry.gyr...@deancare.com wrote: Looking for some guidance on updating the DNS entries on our CUCM cluster. A colleague went through the process, but upon entering the command received a warning stating that the change would invalidate our licenses. Has anybody come across this before, and if so, what was the proper course of action to ensure license preservation? CUCM 8.6.2 Thank you, *Larry Gyrion** | Telecommunications Analyst | Information Technology* Dean Clinic - Corporate offices 1800 W. Beltline Hwy Madison WI. 53713 Phone 608.294.6201 | 5406201| Fax 608.280.6852 larry.gyr...@deancare.com |
Re: [cisco-voip] MGCP Odd issue
[nod to Dave for teaching me much of what I know about ISDN] and adding to what he said.. UCM sends “setup ack” when the inbound call could match multiple destinations. You say this “started suddenly across all gateways”. Was there a change on UCM to CSS or adding new patterns that would generate multiple potential matches for inbound calls? Regards, Wes On May 27, 2015, at 8:25 AM, Dave Goodwin dave.good...@december.netmailto:dave.good...@december.net wrote: The Mandatory information element missing error states the missing IE is 0x18. That is referring to the fact that the CALL_PROC you sent telco contains no Channel ID IE, which is normally required. Looking further back in the call flow, it seems that after the initial SETUP message was received, you sent telco a SETUP_ACK - which they also complained about receiving (Message not compatible with call state). If this PRI is truly under the control of UCM registered as MGCP, and not under local IOS control, it seems like UCM has gone into overlap receiving mode, where it expects to receive potentially additional digits in INFORMATION messages. I don't think you're going to find any public PRI service providers (at least not in the US) who will use overlap sending; they will send you all the digits in the initial SETUP. Can you look in your Service Parameters for CallManager and check if the Overlap Receiving for PRI Flag is set to True? It is normally False by default (from memory). Keep in mind the setting is cluster-wide, so if you decide to change it, make sure you don't have any UCM-managed PRI interfaces where you actually do need to use overlap receiving. BTW, from what I am able to find, the 5ESS protocol (and presumably 4ESS) has no such message SETUP_ACK that would be used for overlap receiving mode. That is probably why changing the protocol makes the error go away, since UCM is probably not going to send that message telco doesn't like, since doing so would violate the configured protocol. -Dave On Tue, May 26, 2015 at 11:26 PM, Barry Howser bhowser5...@gmail.commailto:bhowser5...@gmail.com wrote: Hi Dave. I have placed the full q931 from a failed call inline below. The mandatory missing IE is at the bottom. Syslog logging: enabled (0 messages dropped, 63 messages rate-limited, 0 flushes, 0 overruns, xml disabled, filtering disabled) No Active Message Discriminator. No Inactive Message Discriminator. Console logging: disabled Monitor logging: level debugging, 0 messages logged, xml disabled, filtering disabled Buffer logging: level debugging, 140 messages logged, xml disabled, filtering disabled Exception Logging: size (4096 bytes) Count and timestamp logging messages: disabled Persistent logging: disabled No active filter modules. Trap logging: level informational, 1381 message lines logged Logging to XXX.XXX.XXX.XXX (udp port 514, audit disabled, link up), 1380 message lines logged, 0 message lines rate-limited, 0 message lines dropped-by-MD, xml disabled, sequence number disabled filtering disabled Logging to XXX.XXX.XXX.XXX (udp port 514, audit disabled, link up), 1381 message lines logged, 0 message lines rate-limited, 0 message lines dropped-by-MD, xml disabled, sequence number disabled filtering disabled Logging Source-Interface: VRF Name: Loopback0 Log Buffer (1000 bytes): May 27 03:21:05.580: ISDN Se0/1/0:23 Q931: RX - SETUP pd = 8 callref = 0x005D Bearer Capability i = 0x8090A2 Standard = CCITT Transfer Capability = Speech Transfer Mode = Circuit Transfer Rate = 64 kbit/s Channel ID i = 0xA18381 Preferred, Channel 1 Facility i = 0x9F8B0100A1110201010201008009485546462C5259414E Protocol Profile = Networking Extensions 0xA1110201010201008009485546462C5259414E Component = Invoke component Invoke Id = 1 Operation = CallingName Name Presentation Allowed Extended Name = HOWSER,BARRY Calling Party Number i = 0x2180, 'DN-INTENTIONALLY-REMOVED' Plan:ISDN, Type:National Called Party Number i = 0xA1, 'DN-INTENTIONALLY-REMOVED' Plan:ISDN, Type:National May 27 03:21:05.632: ISDN Se0/1/0:23 Q931: TX - SETUP_ACK pd = 8 callref = 0x805D Channel ID i = 0xA98381 Exclusive, Channel 1 May 27 03:21:05.656: ISDN Se0/1/0:23 Q931: RX - STATUS pd = 8 callref = 0x005D Cause i = 0x82E50D - Message not compatible with call state Call State i = 0x06 May 27 03:21:09.560: ISDN Se0/1/0:23 Q931: RX - SETUP pd = 8 callref = 0x005D Bearer Capability i = 0x8090A2 Standard = CCITT Transfer Capability = Speech Transfer Mode = Circuit
[cisco-voip] 5500 ASA Phone Proxy replacement?
Customer is using CUCM 8.5 with ASA 5500 8.4 with Phone Proxy with certificates with 7965 VPN Configuration http://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cuipph/7975G_7971g-ge_7970g_7965g_7945g/8_0/english/administration/guide/75adm80/7970set.html#wp1271763 I see the ASA Phone Proxy has been depreciated per the release notes in 9.4 http://www.cisco.com/c/en/us/td/docs/security/asa/asa94/release/notes/asarn94.html Is there a replacement product going forward that works with these 7965/SSL? I didn't think VCS-E/Expressway did 7965 SSL VPN setup. Jason Aarons, CCIEx2 No 38564 Consultant Dimension Data 904-338-3245 mobile ___ cisco-voip mailing list cisco-voip@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-voip
Re: [cisco-voip] 5500 ASA Phone Proxy replacement?
Jason, I think you're talking about 2 different things. There's Phone VPN which was released in CUCM 8.0 which uses Anyconnect Phone licensing on the ASA. When that came out, the ASA phone-proxy feature was depricated. CUBE now has SIP line-side proxy if you really need something similar. If you're already using Phone VPN, you should be good to go. Brian On Wed, May 27, 2015 at 5:27 PM, Jason Aarons (AM) jason.aar...@dimensiondata.com wrote: Customer is using CUCM 8.5 with ASA 5500 8.4 with Phone Proxy with certificates with 7965 VPN Configuration http://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cuipph/7975G_7971g-ge_7970g_7965g_7945g/8_0/english/administration/guide/75adm80/7970set.html#wp1271763 I see the ASA Phone Proxy has been depreciated per the release notes in 9.4 http://www.cisco.com/c/en/us/td/docs/security/asa/asa94/release/notes/asarn94.html Is there a replacement product going forward that works with these 7965/SSL? I didn’t think VCS-E/Expressway did 7965 SSL VPN setup. Jason Aarons, CCIEx2 No 38564 Consultant Dimension Data 904-338-3245 mobile ___ 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] callmanager out of compliance behaviour
Reboot used to revive the functionality in previous 8.x as well , as far as I remember Sent from Samsung Mobile Original message From: Lelio Fulgenzi le...@uoguelph.ca Date: 27/05/2015 23:21 (GMT+05:30) To: Lokesh Lal lokesh_...@yahoo.co.in Cc: cisco-voip@puck.nether.net Subject: Re: callmanager out of compliance behaviour Interesting that a reboot gives you an extra day. Thanks. Sent from my iPhone On May 27, 2015, at 12:40 PM, Lokesh Lal lokesh_...@yahoo.co.in wrote: Hi, As per my understanding , you are referring to ELM The demo period is limited to 60 days. Upon expiration, • The system will remain operational with provisioning restrictions • Additional users and phones can not be provisioned • Existing users and phones can not be de-provisioned Reboot can provide extension upto 1 day Kind Regards, Lokesh From: cisco-voip-requ...@puck.nether.net cisco-voip-requ...@puck.nether.net To: cisco-voip@puck.nether.net Sent: Wednesday, 27 May 2015 9:30 PM Subject: cisco-voip Digest, Vol 139, Issue 26 Send cisco-voip mailing list submissions to cisco-voip@puck.nether.net 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 cisco-voip-requ...@puck.nether.net You can reach the person managing the list at cisco-voip-ow...@puck.nether.net When replying, please edit your Subject line so it is more specific than Re: Contents of cisco-voip digest... Today's Topics: 1. callmanager out of compliance behaviour (Lelio Fulgenzi) 2. Re: callmanager out of compliance behaviour (Travis Dennis) 3. Re: callmanager out of compliance behaviour (Lelio Fulgenzi) 4. Re: callmanager out of compliance behaviour (Lelio Fulgenzi) 5. Re: cisco-voip Digest | VG310/320/350 config (Charles Goldsmith) 6. Re: cisco-voip Digest | VG310/320/350 config (Lokesh lal) 7. Re: cisco-voip Digest | VG310/320/350 config (Charles Goldsmith) 8. Re: callmanager out of compliance behaviour (Lelio Fulgenzi) 9. Re: callmanager out of compliance behaviour (Brian Meade) 10. MGCP Odd issue (Barry Howser) 11. OT: Telemanagement software/IT billing (Ed Leatherman) 12. Re: MGCP Odd issue (Wes Sisk (wsisk)) 13. Re: OT: Telemanagement software/IT billing (Travis Dennis) 14. Re: MGCP Odd issue (Barry Howser) 15. Visual Voicemail for Unity Connection (Bryan Anderson) 16. Re: Visual Voicemail for Unity Connection (Brian Meade) 17. ATA190 Registration Failed (Alessandro Bertacco) 18. Re: Very Strange SSL Issue... (Matthew Loraditch) 19. Re: ATA190 Registration Failed (Brian Meade) 20. Changing DNS entries in Call Manager 9.1.2.1-28 (Gyrion, Larry) 21. Re: building lab CUCM cluster from production cluster [update] - FOLLOW UP (Lelio Fulgenzi) 22. Re: MGCP Odd issue (Dave Goodwin) 23. Re: Changing DNS entries in Call Manager 9.1.2.1-28 (Jason Aarons (AM)) 24. Re: MGCP Odd issue (Barry Howser) 25. R: ATA190 Registration Failed (Alessandro Bertacco) 26. Re: OT: Telemanagement software/IT billing (Andrew Grech) 27. Re: Very Strange SSL Issue... (Andrew Grech) 28. LDAP Sync question - adding LDAP sync to existing CM Cluster (Hefin James [ahj]) 29. Re: Very Strange SSL Issue... (Matthew Loraditch) 30. Re: LDAP Sync question - adding LDAP sync to existing CM Cluster (Dave Goodwin) 31. Re: MGCP Odd issue (Dave Goodwin) 32. inbound h.323 calls fail to Expressway (Andy) 33. Re: Very Strange SSL Issue... (Ryan Ratliff (rratliff)) 34. Re: Changing DNS entries in Call Manager 9.1.2.1-28 (Gyrion, Larry) 35. Re: ATA190 Registration Failed (Brian Meade) 36. Re: Caller order when presented to hunt groups (Nick) 37. Re: Caller order when presented to hunt groups (Brian Meade) -- Message: 1 Date: Tue, 26 May 2015 12:19:44 -0400 (EDT) From: Lelio Fulgenzi le...@uoguelph.ca To: Cisco VoIP Group cisco-voip@puck.nether.net Subject: [cisco-voip] callmanager out of compliance behaviour Message-ID: 1907131938.242737.1432657184091.javamail.r...@uoguelph.ca Content-Type: text/plain; charset=utf-8 CAn anyone point me to the details of what happens when CallManager v9 is out of compliance? I had an offline server going, but had to work on some other projects, and I think I passed the sixty days. I want to be able to restart things and make sure there is no communications going on before brining it online and getting it connected to the live network. Gonna open a case with the TAC to see what they might be able to offer. Lelio --- Lelio Fulgenzi, B.A. Senior Analyst, Network Infrastructure Computing and Communications Services (CCS) University of Guelph 519?824?4120 Ext 56354
Re: [cisco-voip] MGCP Odd issue
Hi Wes/Dave, There wasn't any significant change per se; however, this 5 node (4 sub 1 pub) cluster has been onboarding significant amounts of endpoints frequently, for the past 6 months through a variety of methods; bat, hand builds ... etc. It's an 8 month old build with 6 months worth of migrations. In that time, the cluster has never been rebooted. I'm not above chalking this up to memory corruption or the like and prescribing a cluster reboot. Especially since nothing in UCM seems to have changed and this impacted only MGCP gateways and all MGCP gateways at the same time. I will check the Overlap Receiving flag, to see what state it is in. Thanks again! On Wed, May 27, 2015 at 3:38 PM, Wes Sisk (wsisk) ws...@cisco.com wrote: [nod to Dave for teaching me much of what I know about ISDN] and adding to what he said.. UCM sends “setup ack” when the inbound call could match multiple destinations. You say this “started suddenly across all gateways”. Was there a change on UCM to CSS or adding new patterns that would generate multiple potential matches for inbound calls? Regards, Wes On May 27, 2015, at 8:25 AM, Dave Goodwin dave.good...@december.net wrote: The Mandatory information element missing error states the missing IE is 0x18. That is referring to the fact that the CALL_PROC you sent telco contains no Channel ID IE, which is normally required. Looking further back in the call flow, it seems that after the initial SETUP message was received, you sent telco a SETUP_ACK - which they also complained about receiving (Message not compatible with call state). If this PRI is truly under the control of UCM registered as MGCP, and not under local IOS control, it seems like UCM has gone into overlap receiving mode, where it expects to receive potentially additional digits in INFORMATION messages. I don't think you're going to find any public PRI service providers (at least not in the US) who will use overlap sending; they will send you all the digits in the initial SETUP. Can you look in your Service Parameters for CallManager and check if the Overlap Receiving for PRI Flag is set to True? It is normally False by default (from memory). Keep in mind the setting is cluster-wide, so if you decide to change it, make sure you don't have any UCM-managed PRI interfaces where you actually do need to use overlap receiving. BTW, from what I am able to find, the 5ESS protocol (and presumably 4ESS) has no such message SETUP_ACK that would be used for overlap receiving mode. That is probably why changing the protocol makes the error go away, since UCM is probably not going to send that message telco doesn't like, since doing so would violate the configured protocol. -Dave On Tue, May 26, 2015 at 11:26 PM, Barry Howser bhowser5...@gmail.com wrote: Hi Dave. I have placed the full q931 from a failed call inline below. The mandatory missing IE is at the bottom. Syslog logging: enabled (0 messages dropped, 63 messages rate-limited, 0 flushes, 0 overruns, xml disabled, filtering disabled) No Active Message Discriminator. No Inactive Message Discriminator. Console logging: disabled Monitor logging: level debugging, 0 messages logged, xml disabled, filtering disabled Buffer logging: level debugging, 140 messages logged, xml disabled, filtering disabled Exception Logging: size (4096 bytes) Count and timestamp logging messages: disabled Persistent logging: disabled No active filter modules. Trap logging: level informational, 1381 message lines logged Logging to XXX.XXX.XXX.XXX (udp port 514, audit disabled, link up), 1380 message lines logged, 0 message lines rate-limited, 0 message lines dropped-by-MD, xml disabled, sequence number disabled filtering disabled Logging to XXX.XXX.XXX.XXX (udp port 514, audit disabled, link up), 1381 message lines logged, 0 message lines rate-limited, 0 message lines dropped-by-MD, xml disabled, sequence number disabled filtering disabled Logging Source-Interface: VRF Name: Loopback0 Log Buffer (1000 bytes): May 27 03:21:05.580: ISDN Se0/1/0:23 Q931: RX - SETUP pd = 8 callref = 0x005D Bearer Capability i = 0x8090A2 Standard = CCITT Transfer Capability = Speech Transfer Mode = Circuit Transfer Rate = 64 kbit/s Channel ID i = 0xA18381 Preferred, Channel 1 Facility i = 0x9F8B0100A1110201010201008009485546462C5259414E Protocol Profile = Networking Extensions 0xA1110201010201008009485546462C5259414E Component = Invoke component Invoke Id = 1 Operation = CallingName Name Presentation Allowed
Re: [cisco-voip] ATA190 Registration Failed
Alessandro, Based on the firmware it bould be this bug: https://tools.cisco.com/bugsearch/bug/CSCuq99457 Symptom: ATA190 cannot register to CUCM. REGISTER request from ATA190 only get 404 response. ATA190 knows the IP address of CUCM. But it only register to CUCM with 'hostname + domain' in request URL. Conditions: On CUCM, no setting for domain, but host name is configured. This issue is independent of how CUCM server is configured. This defect is applicable even if CUCM server is configured using IP Address. Workaround: 1. SSH to CUCM and configure domain name 2. Reboot CUCM 3. If CUCM works in mixed mode, need to regenerate CTL file with USB token. If don't recreate CTL file, ATA190 cannot register to CUCM. Further Problem Description: Customer visible bug for ATA190 v1.1.2, release notes is at http://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cata/190/1-1/english/release-notes/ata190-rn-112.html?mdfid=286248743 Are use using the latest device pack on UCM? http://www.cisco.com/web/software/282074299/124017/cmterm-devicepack10.5.2_12014-1_Release_Notes.pdf -Gentoo On 2015-05-26 15:57, Alessandro Bertacco wrote: Hi all, we have issue with ATA190 (FW version 1.1.2(0.05) that don't register with our CUCM 10.5.x. (Changing the ATA190 device, issue persist) Cluster of one node in mixed mode, but we don’t use encryption to the endpoint. Standard non secure profile are used. The device is already configured from Communication Manager Side, with the mac-address and DN. TFTP server is correctly issued on theATA190 adapter, but from the Web interface I can see registration failed. (Also from CUCM side) From the Communication Manager, I've captured some SDL log regarding the Registration request sent from the ATA90 that the ip address is 192.168.121.52, and primary MAC addres is: 34DBFD186BCA. The trace is attached to this email. Any idea? Thank you for your time Regards -- Alessandro Bertacco ___ 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
