JTAPI: Playing Audio Into a Call, Without Conferencing with a CTI-Port

[Bliss]

Hello.

When an incoming (customer) call enters the CUCM, after an agent has answered, I need to play a short (pre-recorded) audio into the call, so that both parties (customer & agent) hear it, before they continue to chat.

The way I currently accomplish it is by answering the customer's call with a CTI-port, which then initiates a 2nd call to the agent. When the agent answers, the two calls are merged into a conference call, and then, the audio is RTP streamed to CTI port's output, so that all call-parties hear it (i.e. the customer & the agent).

Is there a way to accomplish the same result without using a conference call?
Could a Consult-Transfer approach be applied? If so, how exactly?
Is another approach applicable?

Thanks much.

[DavidStaudt]

The Agent Greeting feature is designed to do just this.  It effectively creates a local conference using the phone's built-in-bridge DSP, with simplified call model.

[Bliss]

Thanks, David, for your feedback.

(1) Is the Agent Greeting a basic feature built into the CUCM itself (v14), or should it be purchased separately, or a part of UCCX/UCCE?

(2) Meanwhile, I've tried invoking the addMediaStream method of an agent's terminal-connection, while call is in TALKING state, but an InvalidStateException is thrown, saying: "Failed to start streaming media". Ofcourse, I've enabled Built-in-Bridge for this terminal, in CUCM's administration panel, and set its Privacy attribute to Off.

Could you suggest why and/or point an online code-snippet showing how to utilize the Agent-Greeting feature / 'addMediaStream' method?

[DavidStaudt]

1. It's a feature of CUCM...'IVR call' is mentioned as that is an easy way of implenting the agent greeting, i.e. having a unique IVR number per agent which auto answers and plays the desired audio file.  However, anything that can answer the call, play audio, and immediately hang up should work fine, e.g. a CTI port (though heed the note in the docs re threading) - for testing this could (I think) also just be another phone as long as it's answered quickly. (I have a vague recollection that the IVR call may be unusual in some way that may prevent some things from dealing with it...)
2. I'm not aware of a sample, unfortunately.  Possible things to look at:

• The phone doesn't support BiB (unlikely)
• BiB has been disabled for the phone
• Trying to answer the IVR call in the same JTAPI thread as the addMediaStream request
• The IVR call isn't answered within the CTI timeout interval
• The IVR call may have unusual characteristics, e.g. a limited JTAPI model (if it's a CTI port), only one media channel, etc., which may confuse the answering device if it's not prepared for it.  The example message sequence diagram may be helpful there.

[Bliss]

Thanks again, David, for the useful information.

Please note that the mere call to the addMediaStream method yields an (InvalidStateException) exception.

I'm not even getting to the stage at which the CTI-port should "answer" this call, not to mention the stage at which it should stream audio out.

Again, device's BiB setting is turned on (in CUCM admin-panel).

If you have any suggestion(s) as to how to tackle this - understanding what makes the addMediaStream call fail, by finding more details on the underlying behavior (i.e. what's happening "under the hood"), I'd appreciate it very much.

[upchaurasia]

addMediaStream should be called after call is answered. Which media server/library you are using to stream audio?

Regards

Umesh

[DavidStaudt]

In case you're still working on this, I created a sample app to demonstrate Agent Greeting, in this fork of the DevNet jtapi-samples repo: https://github.com/davidstaudt/jtapi-samples

At one point I did run into the same problem you describe, where addMedia() fails with InvalidStateException - I believe this was because my CTI port was not accepting/answering the incoming IVR call in time. Troubleshooting, I noticed that there was a 4 sec delay between addMedia() and the error, due to the call not being accepted in the new call accept timeout window.

[Bliss]

Thanks, @DavidStaudt, for the efforts you've put into this. Much appreciated.
Blessings and all the best.