Hello everyone,

I have a question about WebRTC. The customer wants to establish a video connection to the end customer if required.

There is always an audio connection between employees and the end customer via telephone (mobile phone or landline), which must also remain during the video connection.

A softphone based on the BreezeClientSDK (latest version) is used as the endpoint for the employees.

The customer must not have to download any further software.

We have the following ideas for this:

1) The end customer calls up a website and connects via WebRTC to the employee in the current conversation. The employee accepts the video call directly on the softphone. Video reception from the customer's browser and audio remains over the telephone.

2) The employee goes to a website and generates a PIN. The end customer goes to a website and enters the PIN and the video connection is established directly browser to browser.

Can both or one of the described use-cases be implemented with the WebRTC SnapIn?

Is the WebRTC SnapIn at all necessary for the 2nd case or can a separate SnapIn be created, which controls the signaling between the clients via websockets and the SBC for STUN / TURN.


Greetings

Stefan

Hi. Unfortunately, the Breeze snap-in doesn't support video calls. We do have another offer (Avaya Mobile Video) that does support video calls. Let me get one of the experts there to address your specific use case.

Hi,

Thanks for the fast resposne. I have looked at some documents. But although it is listed under Breeze, I don't find anything in the documents about a SnapIn for Breeze.

Only Avaya Mobile Video Media Broker and Avaya Mobile Video Gateway would be added as new servers.

Is this correct or are the documents out of date?

Your understanding is correct. Product management wanted to put AMV under the Breeze umbrella but it really has nothing to do with the Breeze platform. It turns out that there is a new technology stack coming out soon for the AMV offer, including use of AAMS instead of the media broker. It will still be additional servers though.

It turns out that AMV unfortunately doesn't support your desired use case. The agent endpoint would see the original PSTN call and the subsequent video call as two separate calls. It cannot simultaneously render audio from one call and video from another. This is unlikely to change anytime soon.

One possible workaround could be that the agent would have a video-capable softphone or browser client as well as a phone or separate device for audio. The video endpoint and audio endpoint would have different phone numbers. When the new video call comes in, it would NOT be seen as a contact center call. It would be routed directly to the agent's video endpoint.

Might this work?

Thanks for the information. I already thought of something like that. We will discuss the next steps with the customer and compare the possibilities he has.

Thank you and greetings

Stefan