Inbound calls are failing with Room Subscription Timed Out error

Getting Started
,
1

We have on-prem Cisco CUBE sending calls in, but they are failing. additionally, the agent shows a status of pending.

2

image
image2300×948 193 KB

4

rebuilt the agent and it now shows as running. Calls are still failing, but this time with a no 200 OK response. Im not sure where the 10.34.6.150 IP is coming from as its not an IP on our network

image
image2338×1764 209 KB

5

I just checked your trunk. It seems like calls go through to an agent.

6

Thank you. How do I get a call from my CUBE / SIP trunk to work? please see note about missing 200 OK

7

Have you tried capturing a PCAP and see what the issue is?

8

We have other SIP trunks that are configured with other providers, also using external IPs, that are working. what would we be looking for in the PCAP?

9

If I were looking in a PCAP I would try and understand what the cause of the missing 200 OK is. Was there a private IP advertised?

10

Cc: @rgarrett

The 10.34.6.150 is the loudest clue, that’s RFC 1918 private space, so wherever it’s showing up in the SIP signaling, the response routing is broken at that point.

In the PCAP from the CUBE outbound side, look at the INVITE you send to LiveKit and check three headers:

  1. Via: topmost branch, should be the CUBE’s public-facing IP, not a private one.
  2. Contact: same. LiveKit’s 200 OK gets routed to whatever address is in Contact:. If that’s 10.34.6.150, the OK leaves LiveKit headed into private space and never reaches you.
  3. Request-URI / To: to verify the trunk-routing match LiveKit’s expecting.

Then look at what comes back. 100 Trying arriving means the INVITE landed. The 200 OK is the one to focus on, capture both the LiveKit > public-internet leg (if you have visibility) and arrival at CUBE’s WAN interface. If LiveKit emitted a 200 OK addressed to 10.34.6.150, that’s the smoking gun.

Most likely fix is on the Cisco side, if your Contact: is private, voice service voip > sip > bind control source-interface <public-facing-iface> (and bind media similarly) usually corrects it. Worth comparing the failing trunk’s voice class sip-trunk against one of the trunks that’s working, the bind / NAT-related lines are likely where they diverge.

11

If you have a Call id (SCL_) that has the issue and you see the PCAP in your LiveKit dashboard let me know and I will take a look at it.

12

Yep! we dont have a 10.34.x.x subnet. If I get ya a PCAP from our end, where can I upload it?

13

You can DM me with it, then just flag here once you’ve sent it, and I will take a look.

14

You can upload in here, otherwise, you can DM me on Livekit Slack Community.