- Newest
- Most votes
- Most comments
The quick answer is no, you described one way which is transfer the call to another phone number via PSTN. You can get the call back and continue the contact flow if you choose the option "Resume flow after disconnect" in the Transfer to Queue block only if the transfer happens within the contact flow. The other way to get 1 way audio out of Connect to a destination is through Kinesis Video Stream (in 2 channels, what customer hear and what customer say) https://docs.aws.amazon.com/connect/latest/adminguide/enable-live-media-streams.html
Can you describe more on your use case?
I thought I saw a similar scenario using Chime, but can't find it now. The call would come in to Chime and do the media forking between connect and the 3rd party app. You might want to poke around there to see if something like that would be possible.
david
Relevant content
- Accepted Answerasked 7 months ago
- asked 6 months ago
- asked a year ago
AWS OFFICIALUpdated a year ago- AWS OFFICIALUpdated 2 years ago
- AWS OFFICIALUpdated 3 years ago
- AWS OFFICIALUpdated 2 years ago
Thank you very much for your response.
My use case is that I have a legacy application that handles telephone calls. I cannot and do not want to edit this application. This legacy application has an API that works based on WebSocket. Each time one is opened, it is to attend a call; it sends and receives audio through the WebSocket in u-law 8000 format. It also sends some events, such as the end of the call or redirection.
Therefore, I am evaluating how to integrate it with Amazon Connect. My idea is to develop a module that connects this app with AWS Connect. I am open to any suggestions.
I greatly appreciate any additional information on the topic, as I am also not an expert in Connect.
Kinesis Video Stream seems like a valid option; I will investigate it further.
Regarding costs, which one do you think is the most convenient?
Is your app going to front end all the calls? And you agents will be on Connect? From directly working with Connect, this is not supported using websocket as bi-directional audio is needed (KVS is one way only). I would put some sort of device in front of Connect like Audiocodes that takes the call via SIP trunk and terminates it initially with you app, and redirect the call to Connect afterwards if needed.
But all of this might cost higher than rewrite this using Connect/Lex/Lambda which might be quicker, more scalable and lower cost, most importantly to get you out of the technical debt that you are in.
Thank you very much, but Connect/Lex/Lambda has many limitations. The legacy system I cannot modify has agent automations that are superior to what I can achieve with Connect (interruptions, speech disfluencies while calculations are being made, response time control according to the conversation context, etc).
Do you think Chime, as suggested by @dmacias, is feasible? From what I see at https://docs.aws.amazon.com/connect/latest/adminguide/integrate-video-calling-for-agents.html, it uses WebRTC. I could do a backend integration with WebRTC mimicking the behavior of Amazon Chime, but I don't know how closed Amazon's infrastructure will be in terms of encoding, security, or whether it will have any way of detecting that the communication does not come directly from the Chime library...
The WebRTC calling/video is inbound only and it is an alternative to PSTN inbound calls. So it would not be applicable. Can you give the complete use case and flow, base on your brief description, if this is a real time agent suggestion/coaching application while an agent is talking to customer, then KVS will be enough as you only need one way audio from Connect to the application. Alternative is to use Contact Lens Real Time streaming (KDS) to stream the transcribed text instead of the raw audio.
I have an application that exposes a websocket, each time a client connects it is capable of handling a real-time audio conversation, the application receives and sends audio in ulaw-8000 format. I want certain phone calls from connect to be answered by this application, in case of not finding a solution they would return to the connect agent. I understand that a simple way to integrate this would be to expose this application through a phone number (using Twilio for example), from connect forward the call, answer the call and if necessary forward it to another connect number, if I need the flow to continue in connect. My goal is to eliminate Twilio as an intermediary, a more direct integration with connect, and for the user not to leave connect. I hope I have been clear enough.