Twilio 32102 / SIP 488 before answer with TLS + SRTP REQUIRE: how to obtain the rejected SDP?

Telephony
1

We are testing an outbound call through LiveKit Cloud and Twilio Elastic SIP Trunking. One controlled test call was rejected at the INVITE stage, before answer, with:

INVITE failed: sip status: 488: 32102 The SDP is not correctly formatted.

We verified these settings in both authenticated dashboards:

  • LiveKit outbound transport: SIP_TRANSPORT_TLS, destination port 5061.
  • LiveKit media encryption: SIP_MEDIA_ENCRYPT_REQUIRE (also shown in the call’s Events payload).
  • Twilio Secure Trunking: Enabled.
  • Call recording: Disabled.
  • Default SIP codecs; no custom codec list.
  • Python Agents SDK 1.7.1; RTC SDK 1.1.15.

The request uses the existing stored outbound trunk:

api.CreateSIPParticipantRequest(
    sip_trunk_id="<redacted>",
    sip_call_to="<redacted>",
    room_name="<redacted>",
    participant_identity="<redacted>",
    participant_name="Test call",
    wait_until_answered=True,
    hide_phone_number=True,
)

The agent and room start normally, but no answered call or business conversation occurs. LiveKit’s call analytics show no downloadable PCAP and no negotiated codec. Twilio’s Debugger has only the generic 32102 message; no SDP or response body. We have requested a normal technical support ticket from Twilio as well.

We have not changed encryption settings or retried the call. We do not yet know whether the problem is a codec, SDES crypto attribute, media protocol, or another SDP field, and are not reporting a confirmed broad outage.

How can we obtain a sanitized outbound INVITE SDP, or the specific parser rejection reason, for a failed TLS/SRTP call? Is there a supported private channel to provide a call ID for internal trace lookup when no PCAP is available? Are there known current compatibility issues between LiveKit Cloud’s generated SDP and Twilio Secure Trunking?

Project, Room, Trunk, call, log identifiers and phone numbers have been omitted deliberately. Any raw SDP with crypto keys should be handled privately rather than posted publicly.

2

I can find the call ID you are referring to, and took a look.

I see the request reaching Twilio but when we send the INVITE with credentials they return 488. So, the TLS connection was established but Twilio rejected the INVITE itself - that tells me nothing wrong with your trunk credentials or port setting etc.

I’m not able to say why Twilio rejected the INVITE, my guess would be something related to a encryption setting that they do not accept, but they would be in the best place to tell you that. You mentioned you have a support ticket with Twilio and I assume you already gave them the Provider Call ID which you can find on the LiveKit dashboard page for your failed call: https://cloud.livekit.io/projects/p_/telephony/SCL_YOUR_CALL_ID/outbound

No PCAP was generated on our side for this

3

Thank you for reviewing the call and confirming that TLS was established and that no PCAP was generated.

Twilio Voice Support has replied that the INVITE was rejected by its edge parser before a Call SID was created, so the rejected SDP is absent from standard call logs. They are asking for the raw originating INVITE PCAP. We checked the Provider Call ID field in the LiveKit dashboard and confirmed that its value was already included in the private Twilio ticket.

Could LiveKit export the original outbound SIP INVITE/SDP text or a server signaling trace for this failed call, through a supported private channel? That would help resolve the gap between Twilio’s request for PCAP and the absence of a PCAP on the LiveKit side. We have asked Twilio whether a raw INVITE/SDP text export would be acceptable and whether its edge team can recover a specific parser rejection reason.

If the original signaling is unavailable, what supported LiveKit Cloud tracing procedure should be prepared before a further controlled reproduction with TLS and SRTP REQUIRE? Please let us know if the exact generated SDP or trace can be retrieved without another call.

The exact rejection reason remains unknown; encryption compatibility is still a hypothesis. We have kept the verified settings unchanged and have not retried. Project, call, log identifiers, phone numbers and crypto keys remain omitted from this public thread.

4

I don’t have access to the outbound SDP.
I suggest first testing with SIP_MEDIA_ENCRYPT_ALLOW as that will generate a different SDP

I would also suggest trying without encryption on the trunk (as a test), and disabling it on the Twilio side also