Re: [cisco-voip] CUCM 10.5 and OpenText 10.6

Ed-- (Troy too) Thanks for posting the fix. That was perfect for our upgrade too!! Scott On Fri, May 1, 2015 at 12:48 PM, Countryman, Edward < edward.country...@presencehealth.org> wrote: > This turned out to be a setting in Rightfax. Now working again! > > Many thanks to Troy Putnam for

Re: [cisco-voip] UnifiedFX Gurus

Seconded brilliant product. Pity it can't fix the responsiveness of the 8945/9951's On Wed, Sep 30, 2015 at 12:44 AM, Terry Oakley wrote: > For those of you looking at UnifiedFX I will add my experience. First it > is limited experience as we have only been using the

Re: [cisco-voip] UnifiedFX Gurus

to clarify the product works fine with 9971's and 8945's the phones are just slow to respond. like in real life. On Tue, Oct 6, 2015 at 7:32 AM, Nick Britt wrote: > Seconded brilliant product. Pity it can't fix the responsiveness of the > 8945/9951's > > On Wed,

[cisco-voip] Odd call behavior CME,CUBE,CUCM

I have CME that has a SIP phone registered to it and a SCCP phone registered to it. SIP=4002 SCCP=4001 I have a call path that looks like: CUCM->SIPTrunk->CUBE->SIPTrunk->CME When I dial the SIP phone (on CME) from call manager the call completes and goes fine. When I dial the skinny phone

Re: [cisco-voip] Odd call behavior CME,CUBE,CUCM

Make sure you don't have any of these on the dial-peer: voice-class sip pass-thru headers unsupp voice-class sip pass-thru content unsupp voice-class sip pass-thru content sdp http://www.dslreports.com/forum/r27144625-Config-CME-8-Help-with-Incoming-calls-on-SIP On Mon, Oct 5, 2015 at 11:00 PM,

Re: [cisco-voip] Odd call behavior CME,CUBE,CUCM

HA! Thanks Brian ... orphaned passthru this was the 28th (seriously) time I reviewed the config ... finally spotted it. Is this because CUBE is presenting DTMF as part of the INVITE? Thanks, Ryan Date: Mon, 5 Oct 2015 23:14:07 -0400 Subject: Re: [cisco-voip] Odd call behavior

Re: [cisco-voip] Understanding a Defect's Affected Versions

Some bugs, like CSCuu58142 effecting single number reach doesn't seem to follow higher versions contain the fix methodology. Bug toolkit says this is fixed in 10.5.2.12028-1 but 10.5.2 SU2, SU2a (10.5.2.12900 and 10.5.2.12901) don't contain the bug fix per TAC and going over the release notes for

Re: [cisco-voip] Odd call behavior CME,CUBE,CUCM

I think it might just be having the SDP passthrough on at all on a SIP to non-SIP call will do this. You could try some of the more intensive CCSIP debugs to see if there's a certain line it has a problem with but I think it's just the fact that it knows there will be SDP at one point and it won't

Re: [cisco-voip] Understanding a Defect's Affected Versions

10.5.2.12028-1 is an Engineering Special which uses a different numbering scheme. I thought the ReadMe used to show what ES the SU was built off of but having trouble finding it. SU2/SU2a were most likely built off of older engineering specials than 10.5.2.12028-1. The higher release thing

Re: [cisco-voip] Understanding a Defect's Affected Versions

I'm also not a fan of the newer release notes not including a list of the Resolved Bugs, but a link to bug search tool... That leaves it up to us to find what bugs were fixed or hoping bug search tool returns them all, plus not a nice list/summary to glance through. On Mon, Oct 5, 2015 at 10:47

Re: [cisco-voip] ldaps authentication

Ed, You may need to make sure that the common name of the ldap server also appears in the subject alternative name (SAN) of the certificate. ldap dirsync will come from the cucm publisher node but ldap auth could potentially come from any cucm node. My other thoughts besides a cert issue

Re: [cisco-voip] ldaps authentication

Thanks Ryan those are good suggestions. CN is not in the cert, that much I can see from the trace files: impl.Certificates - getCNs : impl.LDAPHostnameVerifier - check : cns = [*.wvu.edu] impl.Certificates - getDNSSubjectAlts : impl.LDAPHostnameVerifier - check : subjectAlts = [*.wvu.edu,

Re: [cisco-voip] ldaps authentication

When it comes to ssl integrations with CCM, I tend to subscribe to the idea that the "integrators" should play by the same safety rules that I use for CCM; CN in the SAN, no UPPER case letters or non alphanumeric characters ... etc However, I'd be cautious to call that the smoking gun because

[cisco-voip] ldaps authentication

Hello! We turned up directory sync on cucm yesterday, and ran into some issues with authentication; I ran out of maintenance window so we ended up converting the small number of end users that were synced back into local accounts for now. Our LDAP is front-ended by a load balancer that uses a

Re: [cisco-voip] ldaps authentication

Going beyond putting the CN in the SAN, based on many experiences, wildcards (while technically legal in a csr or signed cert) cause all kinds of havoc exactly like this. If there's any way to remove the wildcard, I'd suggest doing that. Sent from my iPhone On Oct 5, 2015, at 9:18 AM, Ryan

Re: [cisco-voip] Phantom tomcat-trust cert

Maybe this? https://tools.cisco.com/bugsearch/bug/CSCun33173 Try manually stopping the Cisco Intercluster Sync Agent Service and deleting the certificate. On Sun, Oct 4, 2015 at 10:45 PM, James Andrewartha < jandrewar...@ccgs.wa.edu.au> wrote: > On 02/10/15 02:57, Brian Meade wrote: > > You can