Hi Andrew, this looks like an error with CRL checking. You say you can access the service from Postman. Try executing this line from the CLI: "echo | openssl s_client -showcerts -servername <URL you are trying to access> -connect gnupg.org:443 2>/dev/null | openssl x509 -inform pem -noout -text" I you should be able to determine the URL of the revocation server from the displayed information. I wonder if that URL is inaccessible from the Breeze server. It might be interesting to try a wget from the Breeze CLI on that URL to see what happens.

Hi Maksim, this is provisioned on System Manager on the Entity Link page.

Hi, I was just scanning back through the forum posts and noticed that you never got a response on this query. Sorry about that! Are you still experiencing this problem or have you resolved it?

Unfortunately not, sorry. A custom snap-in could be created to do so.

Hello. Is the destination here a Communication Manager VDN or are you sending it directly to a user's endpoint? If it's going to a VDN which answers the dialog right away and then to the actual user endpoint, you won't get any indication of the user answering unless you use AES or Engagement Call Control (which uses AES under the covers).

If you are sending the call directly to the end user's endpoint, this is actually fairly easy to implement. The steps are:
- In callIntercepted, invoke CallPolicies.setCallTerminationPolicy to set the policy to NO_PARTICIPANT_REMAINS. This ensures that the call won't drop if it goes down to one party.
- In callIntercepted, create an EJB timer for your desired wait time for answer. Store any timer reference you need in an attribute on the call
- If you get a callAnswered callback before your timer expires, cancel the timer
- If your timer expires, invoke dropParticipant to drop the participant that never answered.
- You can then play media if you want to, and/or offer the call to somebody else by invoking addParticipant().

Note that you need an AMS for this flow, even if you don't explicitly play any announcement files.

Unfortunately not. Older versions of snap-ins can be installed on newer versions of Breeze, but not the other way around.

You could get a transferred event if you use the Engagement Call Control Snap-in (which in turn uses AES) or if you directly use an AES Java API such as DMCC. I _think_ your strategy would work but I'm not 100% certain. I can't think of other approaches.

Hi, you can use an Implicit User for this, which is nothing more than a digit pattern. Our administration document specifies details.

Can you please clarify whether you want to use one of the existing SMS connectors (for Zang SMS or WEBTEXT SMS) or if you want to create a new SMS connector for a different provider?

We think this will be difficult to resolve without logs. Please open a Siebel Service Request and we'll get you sorted out.

Hi Michael, we're looking into this. Stay tuned.

Hi, the "Participant" object in the Breeze API could perhaps more accurately be described as a "Participation". These are transient objects, associated only with a single call. After the call is over, the Participant state will forevermore be "Idle", because that user's participation in the call is done.

For your use case, there are a few paths you might consider:
* If Presence Services is part of the deployment, you could use PS APIs to see an agent's real-time telephony state (though not their real-time agent state such as ready, after-call work, etc)
* You could use ECC or an AES API to get the station's call events and derive telephony state from those events. Again, agent state is not available (there is no way for you to get that information)

In response to your question, by the way, changing the presented handle would indeed change the actual phone number seen on the INVITE that goes out of Breeze back to CM.

Great! Thanks for letting us know. Sorry that I didn't see your initial response back on the 4th.

I see. You should select a SIP Entity type of "Avaya Breeze".