A SIP User was able to login using the latest Avaya Workplace client, but unable to login using an older one-X Communicator client. What is the cause of this problem?

Question

Options

• Aone-X Communicator only supports H.323 connections.
• BThe Avaya Aura Session Manager (SM) Minimum Endpoint TLS version is set above 1.0.
• CFor one-X Communicator registrations, Avaya Aura Session Manager (SM) is set to Deny.
• Done-X Communicator does not support SIP.

• A
  2% (1)
• B
  79% (33)
• C
  12% (5)
• D
  7% (3)

Explanation

Option B is correct because Avaya Aura Session Manager (SM) has a configurable Minimum Endpoint TLS version setting. If this is set above TLS 1.0 (e.g., to TLS 1.2), older clients like one-X Communicator - which only support lower TLS versions - will fail to establish a secure connection, while a modern client like Avaya Workplace, which supports newer TLS versions, succeeds without issue. This perfectly explains why the same user account works on one client but not the other.

Why A is wrong: one-X Communicator supports both H.323 and SIP - it is not H.323-only. Eliminating it is easy because the question explicitly frames this as a SIP scenario that one-X Communicator is expected to handle.

Why C is wrong: A "Deny" setting in SM would block all one-X Communicator registrations universally, not just for this user. It also doesn't account for the newer client succeeding, which is the key distinguishing detail.

Why D is wrong: one-X Communicator absolutely supports SIP. This is a factual distractor designed to catch candidates unfamiliar with the product's capabilities.

Memory tip: Use the rule "new works, old fails = TLS version mismatch." Whenever an exam scenario shows two clients with the same credentials but only the newer one connects, your first suspicion should be a minimum TLS version configured higher than the older client can negotiate.

No community discussion yet for this question.