Support for DTMF back to incoming SIP caller?

[eli-kaplan]

From what I can see in the codebase these two flows seem to be implemented:

• Sending outbound DTMF when making an outbound call from the SIP bridge -> SIP
• Parsing/forwarding incoming DTMF digits from inbound callers (SIP -> SIP bridge)

However, the flow I'm hoping to implement for my use case requires the opposite direction:

• SIP caller calls inbound to the LiveKit SIP bridge
• Native WebRTC client in LiveKit Room sends DTMF digits to SIP participant (inbound caller)
• SIP participant forwards DTMF digits back to the inbound SIP caller

Am I understanding correctly that this (somewhat niche) dataflow is not currently supported? If not, I assume the workaround for now would probably be just sending the DTMF tones in-band as normal audio.

[dennwc]

You are right, this flow is currently not supported.

It won't be particularly hard to implement, because SIP participant will only need to listen on its own WebRTC data channel and encode DTMF as outbound calls already do.

We were discussing it internally before, and the main concern is that if multiple SIP participants are present, DTMF from one will be passed to another. This might have unintended consequences if LK is set to bridge a call between some autonomous system that supports DTMF and untrusted SIP participants.

It might be solved by adding can_accept_dtmf flag to Dispatch Rule and CreateSIPParticipant. That way DTMF won't be forwarded by default to SIP, unless explicitly enabled.