Can we setup a time to talk about this? I can be reached at aprokop@convergeone.com to setup a time to talk.

The problem is that this is the customer's system and I have to go through all sorts of complications to get on it and get someone lined up to make a call.

I really don't think this is a bug. I simply need to understand how to get UUI from Breeze to AES. I would think that Someone at Avaya would know that. As I stated several times, UUI leaves my Breeze server in the INVITE whether I add it or not. If I add UUI, I can see that it does get stuck into User-to-User along with a bunch of unprintable characters. We ran the same debug on the AES when I had the customer on the line and it wasn't seeing anything UUI-wise.

Again, let's talk. This problem is a week old and I need to get it figured out or tell the customer that Breeze is not the way to go.

Thanks, Nick. That's an option and one I may have to take if Avaya doesn't respond with a way to get Breeze added data recognized as UUI by AES and TSAPI. I didn't realize my "simple" snap-in was going to be this difficult. :-(

Some more information. I tried add my own User-to-User header, but it gets overwritten by Breeze when the INVITE leaves. I am still not sure what Breeze is sticking in it. So, inbound INVITE has no User-to-User header. Outbound INVITE has User-to-User header, but it's not the one I added.

To ensure that I was adding the header correctly I added my own custom header. My custom header appears in the outgoing INVITE.

Still waiting to hear how to add UUI in Breeze so it's available via TSAPI later on in the call flow. The customer is growing impatient.

This was in my original message:

User-to-User: 04FA08000200315E7E5E0CC803353032;encoding=hex

I basically did a call.setContextId("502");

There was no user-to-user header coming into Breeze. Only going out.

Do you need additional traces? This is from the customer system and I need to coordinate with them for access and someone to run test calls.

I need to put a specific three digit value into the UUI of a call that will eventually be transferred to a call recording system. The call recording system uses TSAPI to retrieve the UUI for the call.

Unfortunately, that is all I know of what is happening. I need a way to add these three digits. I thought setContextId() was how that occurred, and although I see the value I use put into the SIP user-to-user header, it's not doing what I want it to do. I see my three digits, but I see other stuff, too.

I guess what I need to know is how to use Breeze to attach data to a call that TSAPI will treat as UUI.

Thanks!

Can I get someone from Avaya to reply? What do I need to do to get UUI from Breeze to AES? I have a customer waiting to deploy my snap-in and this needs to work.

I wrote an outbound Snap-In that intercepts a call and adds UUI with call.setContextID(). I want the UUI data to be available to the AES so it can send it in a TSAPI call.

I add it with call.setContextId().

I ran a call through and set the UUI to 502. I watched the SIP messages with traceCE. When the call enters the Breeze server I see no User-to-User header. When it leaves I see this:

User-to-User: 04FA08000200315E7E5E0CC803353032;encoding=hex

If I run that through a Hex to ASCII converter I get a bunch of unprintable characters followed by a 502.

I am not an AES expert, but I do not see the UUI showing up there.

Questions:

Am I adding UUI properly?
How to I interpret the User-to-User header?
Is there something special that I need to do to make sure that my 502 is available for TSAPI?

One more thing. If I remove my snap-in I still see User-to-User in the outgoing INVITE. What is that for?

Thanks, Joel. It turns out that the error really was a missing cert. It wasn't obvious, but after digging around quite a bit I found the cert, loaded it, and everything worked.

I am not sure why the error was so different from what I've experienced before when I was missing a cert, but I am thankful that I was able to find it. The demo will now go as planned tomorrow morning.

I receive this error when calling a web service from a Java Snap-In. It looks different from what I receive when a cert is not loaded.

com.ibm.jsse2.util.h: PKIX path validation failed: java.security.cert.CertPathValidatorException: The revocation status of the certificate with subject (CN=*.meraki.com, OU=EssentialSSL Wildcard, OU=Domain Control Validated) could not be determined.

Update: I can call this REST service from Postman on my PC. I looked in certmgr and do not see any Meraki certificates.

Can anyone help me understand what I need to do on my Breeze server to get past this? Thanks.

Thanks, Joel. That helps.

Is anyone aware if an agent greeting application has been built with Breeze? Is it even possible?

The current Avaya non-Breeze solution does not work with SIP phones and the customer requires one that does.

That would be fantastic. I meet with the customer on Wednesday and I would love an answer before then.

One more thing, I have been reading what I can find about Conversational Intelligence and I see mentions of an API. However, I don't see anything on DevConnect that tells me what that API is and what it can do. Has it been published?

Thank you, Joel. Can you define "not too long"? I have a customer that really wants to deploy this functionality.

There are actually several Java classes for speech search: SpeechFactory(), SpeechSearchListener(), etc.

That leads me to a new question. Does the Rest interface still exist, or was that pulled along with the Snap-In?

Since the Real-Time Speech Snap-In is no more, are the Java APIs to perform those actions gone, too?