"Most likely a network issue. Perhaps NAT; perhaps firewalls; I don't like to guess but either way your CCT server must connect back to the client application on order to establish the service."

NB: we are way OT.

That's not inconsistent; they are different APIs and use different underlying protocols. The 'endpoint.txt' file only defines the server end; the client end is dynamically negotiated at runtime.

Most likely a network issue. Perhaps NAT; perhaps firewalls; I don't like to guess but either way your CCT server must connect back to the client application on order to establish the service.

This is a known issue with the reference client when handling SIP terminals. If you comment out the DND capability calls it should work as expected.

I believe it's one of the "no cost" labs but I guess it will depend. You should look here

https://devconnect.avaya.com/public/dyn/d_dyn.jsp?fn=379#AASM

for more info (i.e. "Remote Labs" on navigation menu).

If I'm understanding correctly, you cannot do what you're hoping to do. Attachments are only explicitly associated through the API in the AgentEmailWS and thus cannot be processed until an agent is handling the contact. Generally, I would suggest that you filter/process your email and attachments before they hit AACC.

As ever, if you're in a position to open a ticket we can try to figure out your application and give a little more guidance on the matter.

Initially, I would try using escaping the spaces in the path (rather than quoting) but if that fails (and no-one else is able to help-out), open a support ticket we'll chase it down for you.

YossiSalmon wrote:
Doing the same process on the CCMSERVER succeeded!

Installing the RTDSDK on CCMS is not supported (and will break the service). This may be the cause. Otherwise, it is most likely the firewall settings on the client, server, or both. RTD will establish a connection back to the client application and there should, therefore, be a rule to allow any and all communication from the CCMS to the client machine.

I believe that's what it's commonly used for (although more commonly it is pulled during orchestration and fed to the IVR, rather than from the RTD stream). I wouldn't be optimistic about getting detailed algorithmic spec. (probably proprietary) but your BDM or Avaya Support may be able to give you confidence from experience, rather than from an algorithm. Good luck, either way.

The expected wait time seems to be a bit of voodoo. You'll see references to it in the RTD, the Orchestration Designer and in the Client Administration documents; the last of these is the most informative but still tells you little about the internals. If you truly need more specifics you could open a tech-ticket and we can go to development, HOWEVER, I'd caution that it's a paid service and you may not get any more details than the documents currently provide -- they would probably, at least, clarify whether it's the same algorithm that's used in the other components (I currently assume that it is but that may not be the case). I guess you need to weigh up the value of the information against the cost of developing your own algorithm.

Personally, I think about it like a weighted average that's modified by number of agents, queues and historical data -- but that's just a guess. Sorry I can't say more -- perhaps others can.

Ensure you have the specified version of XAMPP (r1.7.2) if you are using the sample client. There are two calls which invoke call-time pass-by-reference and PHP 5.4 or later will fail. You can also modify those calls (remove the '&') to correct the error by there may be other items -- recommend you verify with specified XAMPP before updating.