https://retellai.com/?utm_source=discord&utm_medium=seo logo
Powered by
Until this week, we were routing calls to the SIP ...
# ❓・ai-evy-support
k
@AI Evy Until this week, we were routing calls to the SIP endpoint sip:5t4n6j0wnrl.sip.livekit.cloud using the TLS protocol. Since this endpoint is being deprecated by the end of the month, we switched to the new Retell SIP server: sip:sip.retellai.com. However, we noticed that when using this new endpoint with the TLS protocol, Retell does not return the BYE method upon call termination; the method is only returned when using the TCP protocol. Could you please investigate what is happening with the TLS protocol on this new endpoint?
a
Thanks for tagging me @Keila. I'll look through relevant sources and get back to you shortly.
### Answer I don't have specific information in the sources about why BYE messages would not be sent over TLS transport versus TCP transport on 
sip.retellai.com
. This appears to be a call-specific investigation issue rather than something documented behavior. What I can confirm from the sources: Retell's SIP server supports TCP, UDP, and TLS/SRTP transport, with TLS using the URI format 
sip:sip.retellai.com;transport=tls
[(1) ]() [(2) ]() . Retell's SIP server presents a certificate signed by the Amazon Trust Services CA, and TLS handshake or certificate validation issues can occur particularly when an on-premises SBC or edge device is in the path, sometimes requiring the Root CA (and possibly the intermediate CA) to be installed in the trusted store of that device . To debug this specific issue, I'd recommend capturing a PCAP of the TLS call and inspecting the SIP signaling flow directly. You can filter for 
sip
traffic and look at the full call flow (INVITE → 200 OK → ACK → BYE) using Wireshark's Telephony → VoIP Calls → Flow Sequence feature [(3) ]() . Specifically check: - Whether the BYE is actually sent by Retell but not reaching your endpoint (a TLS/firewall/NAT issue) , versus Retell not sending it at all - SIP response codes and any errors in the signaling exchange - That port 5061 (TLS) is open bidirectionally, in addition to your RTP media ports Since this involves an active call-termination investigation, I'd suggest contacting support directly with the affected Call ID and a PCAP capture for deeper diagnosis: Visit [Documentation]() Visit [Hire certified Retell partner]() Would you like me to provide a general answer based on my knowl
edge instead, since the sources don't directly address this specific TLS/BYE behavior?
​ To learn more, see the sources I considered: [[1] Connect Genesys Cloud to Retell](https://docs.retellai.com/deploy/genesys) [[2] Avaya](https://docs.retellai.com/deploy/avaya) [[3] Debug SIP calls using PCAP file](https://docs.retellai.com/reliability/debug-calls-pcap) ​
Feel free to tag @AI Evy with additional questions. I also appreciate feedback, it helps me improve.
k
how can contact support directly?
@AI Evy how can contact support directly?
a
Thanks for the follow-up, @Keila. I'll get back to you soon.
### Answer
message has been deleted
Feel free to tag @AI Evy with additional questions. I also appreciate feedback, it helps me improve.
Thanks for the follow-up, @Keila. I'll get back to you soon.
k
@AI Evy how can contact support directly? as you mentioned?
a
### Answer You can contact Retell support through the [Customer Support Portal]() or by emailing [support@retellai.com](support@retellai.com) . [(1) ]() When you reach out about the TLS issue, include the affected Call ID and a PCAP capture of the call so the team can inspect the SIP signaling (INVITE → 200 OK → ACK → BYE) . If you need additional help, you can also review the [Documentation]() or [hire a certified Retell partner]() .
​ To learn more, see the sources I considered: [[1] Connect Retell voice agents to custom telephony](https://docs.retellai.com/deploy/custom-telephony) ​
Feel free to tag @AI Evy with additional questions. I also appreciate feedback, it helps me improve.
PreviousNext
Powered by