#We are using the custom server option.
frail tartan
@daring minnow -- could you advise on this? We use the websockets setup to invite an agent to an existing call and it was working last week Mar 7th) but now it doesn't.
this was my first post --
might have missed this somewhere but we had a custom setup with Twilio and our Azure sever that was working a week ago (Mar 7th). Now we cannot get the EL Agent to answer and calls are all showing 0 seconds in the history. Our wss stream connect URL used "incoming-call-eleven" but should we change this now to use this instead "twilio/inbound_call" ?? All of our agent, Twilio, and audio settings have not changed, so we're stuck on what may be the problem.
daring minnow
Will refer to team, I'm not aware of any changes
frail tartan
@daring minnow thank you -- I'm thinking it's a settings issue on our part, but can you confirm the websockets setup is still working like before? We are calling this URL with the AgentID coming through correctly. We just need to confirm that this still works as per the original Inbound setup?
https://OURSERVER.azurewebsites.net/incoming-call-eleven?agent_id=XXXX
or @whole plover ^^ -- we had this working well as of March 7th and now it's not connecting. Trying to troubleshoot on our end too, but curious if anything changed with the audio or websockets for Inbound
daring minnow
checked with team and no changes that would cause this to stop working for you
can you verify rhat your endpoint /incoming-call-eleven is still properly configured to handle the websocket connection and generate the appropriate TwiML response like in this guide here https://elevenlabs.io/docs/conversational-ai/guides/twilio/custom-server
and check you are using μ-law 8000 Hz
frail tartan
yes we are using μ-law 8000 Hz. The customer server setup we did initially was using https://elevenlabs.io/docs/conversational-ai/libraries/web-sockets along with fastify to handle media streams. We need an incoming call to go through our system first before connecting to the agent, so that is why we bult it this way rather than using the Native Twilio integration.
frail tartan
@daring minnow or @whole plover -- so this websocket setup hasn't changed or should still work? Our devs thought this was an update made recently regarding the audio.
whole plover
frail tartan
thank you! @devout thunder -- any help on this would be greatly appreciated. It was working as of March 7th, but then hasn't since. Meaning, the call is registering, but audio is not connecting and just shows 0:00 for call duration. I added our server URL to the allowed hosts too and we even tried to use the SignedURL setup... same result.
frail tartan
hi guys -- @devout thunder or @daring minnow any ideas on what is causing these calls to end immediately? Again, they worked perfectly prior to March 7th, which is around when you added the call initiation data webhook. We have tried the Native integration too along with a Tool, but it's not working either:
We are having the same trouble with this agent (ID dVKAkal50KtF3s4p348A) on both the custom server and the native integration. I appreciate you all are handling a ton of questions and I love what you're doing, but we are about to pivot to another solution. Here is a conversationID -- Y9q2qztp4rilyCujOGe0 as an example:
The Twilio error is this one:
The Media Stream has received a websocket close event defined by https://developer.mozilla.org/en-US/docs/Web/API/CloseEvent
Saw this too - The remote server ended the connection with a termination code listed in https://tools.ietf.org/html/rfc6455#section-7.4.1
