Unable to Connect to Real-Time Streaming via Deepgram Client SDK from Specific IP Addresses #1028
-
Context:We have implemented real-time streaming using the Deepgram client for our application. Recently, some of our clients have reported being unable to connect to the Deepgram WebSocket. This issue has arisen only in the past few days; previously, they were able to connect without any problems. Observations:
Questions:
Additional Details:
Any guidance or insights into how to diagnose and resolve this issue would be greatly appreciated. Thanks in advance for your support! |
Beta Was this translation helpful? Give feedback.
Replies: 5 comments 2 replies
-
Thanks for asking your question. Please be sure to reply with as much detail as possible so the community can assist you efficiently. |
Beta Was this translation helpful? Give feedback.
-
Hey there! It looks like you haven't connected your GitHub account to your Deepgram account. You can do this at https://community.deepgram.com - being verified through this process will allow our team to help you in a much more streamlined fashion. |
Beta Was this translation helpful? Give feedback.
-
It looks like we're missing some important information to help debug your issue. Would you mind providing us with the following details in a reply?
|
Beta Was this translation helpful? Give feedback.
-
Hey @akshat-Eubrics, are you logging what errors are occurring at the time? It's possible that you're hitting your concurrency limit. |
Beta Was this translation helpful? Give feedback.
-
Beta Was this translation helpful? Give feedback.
You'll know if you're hitting the limit by the error codes you're getting. If your users can't connect, and in the logs you get 429 errors, that is you hitting the concurrency limit.
If your users are being disconnected, they'll be being sent an event with a reason (most likely).
There is no way right now for you to be able to proactively check your concurrency allocation, but there might be a hacky way to hit a /projects endpoint occationally and if that returns a 429, don't try to connect a user (Let me double check on that!).
You could also proxy the requests through your own backend server, which will give you better oversight on concurrency, logs, success, etc