Feature Request - Allow SIP INFO messages to be sent

[timothyaufdermauer]

I have a livekit agent that is acting as an IVA node in a RingCentral workflow. RingCentral uses SIP INFO messages to coordinate the bot in the workflow and maintain communication between the bot and the workflow. This allows the bot to pass information back to the workflow and allow intelligent routing after the bot exits, all while staying in the RingCentral telephony system and handling.

Right now, without this SIP INFO capability, I have to provision a new RingCentral phone number, place an outbound call to that phone number, then join the new SIP participant back into the original caller's room. There's a lot of coordination that goes into managing this process and a lot of failure points that have caused issues in the past. This is also currently completely disconnected from the RingCentral eco system and we lose a lot of capabilities that we would have if we were able to keep the original call within the same workflow.

[timothyaufdermauer]

corresponding feature request over in livekit/agents: livekit/agents#6329

unsure how these two repos would need to interact to make this happen, but I'm assuming changes will be needed on both sides

[lixuanqun]

Design discussion: Bidirectional SIP INFO (sip ↔ agents)

Design proposal for this issue, #331, and livekit/agents#6329. Goal: agree on the API surface before implementation.

Problem

• This issue / agents#6329: Agent needs to send SIP INFO (e.g. RingCentral IVA bot-update with Content-Type: application/json) so the call can stay inside the carrier workflow instead of a brittle second-leg outbound.
• sip INFO #331: Bidirectional INFO with arbitrary Content-Type + body (e.g. MSML / RFC 5707) while migrating from a traditional media server to LiveKit agents.

Today Allow already lists INFO, but there is no OnInfo handler → inbound INFO falls through to 405. Agents have no first-class way to send INFO either.

Existing patterns to align with

LiveKit SIP already has two mid-call control channels:

Channel	Direction	Semantics	Examples
DataPacket	both (async)	Fire-and-forget event	SipDTMF
Room RPC lk.sip.*	Agent → SIP participant	Request/response	GetRemoteHeaders, EndCall

SIP INFO needs both: send path wants the SIP status code; receive path should not require the agent to expose an RPC method.

Proposed API

1. Agent → SIP: Room RPC lk.sip.SendInfo

Extend SIPParticipantV1 in roomrpc/siprpc (same place as EndCall):

rpc SendInfo(SendInfoV1Request) returns (SendInfoV1Response);

message SendInfoV1Request {
  string content_type = 1;        // application/json, application/vnd.radisys.msml+xml, ...
  bytes body = 2;
  map<string,string> headers = 3; // optional extra SIP headers (filtered)
}
message SendInfoV1Response {
  uint32 status_code = 1;         // 200 / 415 / 481 / ...
  string reason = 2;
  string content_type = 3;        // if response carries a body
  bytes body = 4;
}

Agent sketch:

await sip_participant.perform_rpc(
    method="lk.sip.SendInfo",
    payload={"content_type": "application/json", "body": b'{"final": true, ...}'},
)

Why RPC (not DataPacket): callers need the SIP transaction result (RingCentral / MSML ops).

2. SIP → Agent: DataPacket SipInfo (like SipDTMF)

// livekit_models.proto — DataPacket oneof
message SipInfo {
  string content_type = 1;
  bytes body = 2;
  map<string,string> headers = 3; // filtered subset (no Via/Route/etc.)
}

Flow: in-dialog INFO → respond 200 OK (transport ACK) → SendData(SipInfo) to the room. Application-level replies are a follow-up SendInfo from the agent (matches how MSML / RC workflows usually work). Do not block the SIP INFO transaction waiting on agent business logic.

Behavior in livekit/sip

1. Register OnInfo; resolve dialog by Call-ID + tags (same as NOTIFY).
2. Inbound: validate in-dialog → 200 → publish SipInfo; oversize → 413; no dialog → 481.
3. Outbound (RPC): build INFO with Content-Type/Body/CSeq → wait for final response → fill SendInfoV1Response.
4. Limits (v1 defaults):
   • body max 64 KiB
   • outbound header denylist (align with getHeadersIgnore used by GetRemoteHeaders)
   • transparent transport — do not parse JSON/MSML
   • optional feature flag later; default enabled for dialogs that already allow INFO

Repo split

Repo	Change
livekit/protocol	SendInfo RPC + SipInfo DataPacket
livekit/sip	OnInfo / sendInfo / RPC registration / DataPacket forward
livekit/agents	helper + SipInfo event (#6329)

Non-goals (v1)

• RFC 6086 INFO Package negotiation (Recv-Info / Info-Package)
• Using INFO as DTMF (already have RFC 2833 + SipDTMF)
• Holding the SIP transaction open until an agent returns business payload
• Generic framework for every mid-dialog method (can refactor later)

Success criteria

1. Agent can send application/json INFO to a SIP participant and observe SIP status.
2. Peer-sent INFO is delivered to agents as SipInfo (content_type + body).
3. Covers RingCentral bot-update and opaque MSML-style payloads.
4. Docs: agent examples + clear boundary vs DTMF / existing lk.sip.* RPCs.

Questions

1. OK with RPC outbound + DataPacket inbound split?
2. Is 64 KiB body limit acceptable?
3. Default on, or trunk/feature-flag gated?
4. Any Cloud policy constraints on arbitrary INFO bodies/headers?

Happy to implement once this direction is confirmed (protocol PR first, then sip + agents).