Are you sip to cuc ab d the pstn? If so, what is your dtmf support in your
trunks?
Thanks,
Ryan
Original Message
From: Jonathan Charles
Sent: Monday, July 6, 2015 04:11 PM
To: cisco-voip@puck.nether.net
Subject: [cisco-voip] Cisco 8841/51 not sending DTMF...
>We have a site
We have a site with new Cisco 8841 and 51 phones (CUCM 10.5.2), running
10.2.2.16, and they are not sending DTMF externally... or internally to
voicemail.
An IP Communicator does send DTMF without issue.
Any known issues with these new phones?
Jonathan
"I'm not sure that an ACL would do the trick though, probably would just show
up in the traces as a time out"
Exactly. The Publisher will simply failover to the next LDAP server in the list
if it cannot establish a connection within 5-seconds to the primary LDAP
server. Regardless, the node rec
Thanks for all your responses.
In our scenario when we lost one of a DC (planned maintenance) that hosted the
CUCM, IM&P, and UCCX Pubs UCCX fineness agents were unable to log in. Had to
resort to a couple of local back up agent accounts.
LDAP authentication wasn't working for any service (Jabb
I'll be interested to hear your results if you try!
I'm not sure that an ACL would do the trick though, probably would just show up
in the traces as a time out. You'd probably have to stop the tomcat service on
the pub (something to tell the cluster not to try and use the PUB as a bind
source),
The worst case scenario, which we ran into, was a scenario where the pub is up
and accepting auth requests but not able to process them. In our case the
cluster was up for almost 300 days, and there were memory error alerts popping
up. It would be nice for the system to understand this issue and
Hi Dan!
Thanks for the clarification/correction I just happen to have a few 3-node
cluster hanging around and I just tried this 5 times in a mix of 9.1.1, 10.0
and 10.5 and here is what I found:
3 times LDAP auth was a seamless failover to the sub
2 times LDAP auth did not work on the s
I did this to our demo domain's webex meeting center deployment and it went
fairly well. I don't have a copy of the document I used but I did find the
document in the Webex knowledge base. It was a 20+ page word doc that told me
exactly how to configure ADFS 2.0 to work as an SSO source for webe
Hi,
most likely you are failing because of the AUTHNContextClassRef. Are
you getting SSO error 13?
if so, change the contextclassref to
urn:oasis:names:tc:SAML:2.0:ac:classes:Password;urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport;urn:oasis:names:tc:SAML:2.0:ac:classes:TLSClient;
“LDAP authentication should still work when the Publisher is offline” This is
not my experience.
From: cisco-voip [mailto:cisco-voip-boun...@puck.nether.net] On Behalf Of
Daniel Pagan
Sent: Monday, July 6, 2015 9:45 AM
To: Lelio Fulgenzi; cisco-voip@puck.nether.net
Subject: Re: [cisco-voip] LDAP
FYI - Just ran a quick test in a lab environment - LDAP user authentication
against a Subscriber node while the Publisher’s network adapter is
disconnected. Works as expected. Also running CUCM 10.5 but this (DirSync
Synchronization vs. Tomcat Security authentication) also applies going back to
So,
Would it make sense to run it on a sub as well since the DB replicates within
the cluster? Just a thought.
I apologize for any typo's!
Sent from my iPhone
> On Jul 6, 2015, at 9:28 AM, Ryan Huff wrote:
>
> My suspicion is it has to do with controlling the number of queries being
> issued
LDAP authentication is used by Tomcat and isn’t just restricted to the
Publisher server - Subscriber nodes handle this as well. DirSync is specific to
synchronization of LDAP attributes and only runs on the Pub, so synchronization
would definitely be affected if the Publisher is offline. I sugge
My suspicion is it has to do with controlling the number of queries being
issued and from where or perhaps and more specifically, tracking the failover
itself.
Once the failover occurred, the identity of the cucm-side ldap sync would
change and AD servers might not handle that gracefully. I
We have been running WebEx hosted in the cloud for years and doing SSO using
ADFS. We are needing to front end our ADFS environment with a Proxy and when
we enable the Proxy our WebEx environment no longer can authenticate our users.
Has anyone successfully configured your WebEx environment us
This has been our experience as well. Glad you started this thread. It's seems
like a huge single point of failure to me for such an integral part of the
process. I suspect hunt group login would also be affected.
Sent from my iPhone
> On Jul 6, 2015, at 5:02 AM, Matthew Collins wrote:
>
>
You are correct about LDAP Authentication, needs the publisher to be up.
I think SAML SSO is just CUCM and CUIM&P and it rides on top of LDAP
syncronization but I could be wrong brcause I don't play with SAML SSO that
often.
Thanks,
Ryan
Original Message
From: Matthew Collin
Hi All,
CUCM 10.5
Just trying to get some conformation, When LDAP Synchronization and
authentication is enabled this is performed by the DirSync process that only
runs on the CUCM Publisher. So If we lose the CUCM Publisher for whatever
reason it would seem that the Authentication also fails d
18 matches
Mail list logo
