I’m testing an inbound SIP trunk on LiveKit Cloud and trying to use the EU regional SIP endpoint.
I’m seeing different TLS verification results between the global and EU endpoints using the same project, machine, CA trust store, port, and OpenSSL client.
Global endpoint
Verification: OK
New, TLSv1.3, Cipher is TLS_AES_128_GCM_SHA256
Verify return code: 0 (ok)
STATUS=PASS
The leaf certificate presented when connecting to the EU endpoint is:
subject=CN = *.sip.livekit.cloud
Subject Alternative Name:
DNS:*.sip.livekit.cloud
DNS:*.ofrankfurt1b.sipfe.livekit.cloud
I’m using the EU regional form derived from the project’s SIP URI:
.eu.sip.livekit.cloud:5061
The equivalent global hostname:
.sip.livekit.cloud:5061
validates successfully.
I have not disabled hostname verification or certificate validation.
Could someone confirm whether <project>.eu.sip.livekit.cloud is still the correct hostname for EU-pinned inbound SIP, and whether the certificate currently presented by that endpoint is expected?
Thanks Darryn. Just to clarify, <project> in my post was only a redaction placeholder, I’m using the actual sip_subdomain from the SIP URI shown in the LiveKit Cloud project settings.
From what I can see, this appears to match the regional endpoint format you mentioned, so I may be missing something else in the TLS/SNI setup. Happy to run any additional checks that would help narrow it down.
Also, a related routing question for our eventual deployment: our SIP carrier traffic will originate from Turkey. I don’t see a Turkey-specific inbound SIP region in the current regional endpoint list.
For traffic originating from a Turkish SIP carrier, which region would the global SIP endpoint normally select?
And is there any supported way to explicitly pin inbound SIP to Turkey, or to a closer region than the current EU endpoint?
I’m mainly trying to understand whether the global endpoint is the recommended option for Turkish traffic, rather than explicitly pinning it to EU.
Unless I’m misunderstanding something (which is always a real possibility ) this is on our end. I’m asking internally, but based on your error, I don’t think you could have both EU pinning, and hostname validation.
Also, a related routing question for our eventual deployment: our SIP carrier traffic will originate from Turkey. I don’t see a Turkey-specific inbound SIP region in the current regional endpoint list.
If you use the Global endpoint, it will connect to whichever is closest. You can place a few test calls, then look at the session in your dashboard to see the location where the participant came in at - this is not guaranteed to always be the same, since if there is some network or infrastructure issue we would need to work around the issue.
I’m mainly trying to understand whether the global endpoint is the recommended option for Turkish traffic
Based on this thread, I would recommend the global endpoint.
Thanks Darryn, really appreciate you checking this internally.
That clears things up for me. We’ll keep hostname validation enabled and use the global SIP endpoint for the Turkey deployment rather than trying to force EU pinning.
It’s also helpful to know that the global endpoint will route to the closest available region and that this may change depending on network or infrastructure conditions, so we won’t make any assumptions about a fixed region on our side.
I’ll keep an eye on the EU certificate issue in case there’s an update from the team, but this gives us a clear path forward in the meantime.
Thanks again for the detailed response and for looking into it.
) this is on our end. I’m asking internally, but based on your error, I don’t think you could have both EU pinning, and hostname validation.