Re: WebRTC: One-Way Audio When Browser is Offerer (DTLS Role Question)

Hello,

On 07.08.26 15:25, Ricardo Castillo via sr-users wrote:
> Hi guys! I bring you a case that was experienced and resolved, and and some existential questions ;) 
>
> Problem Summary (kamailio how registrar server and asterisk how b2bua)
>
> Scenario: Server-deployed WebRTC webphone making calls to another server-deployed webphone.  
> Symptom: Bidirectional SIP signaling succeeds, but call initiator (offerer) has **no audio**.  
> Answerer receives nothing; answerer can transmit fine to offerer.
>
> ## Investigation: What We Measured
>
> **WebRTC Internals dump from offerer side:**
>
> ```
> dtlsState:    "connecting"  (never reaches "connected")
> packetsSent:  0             (DTLS never starts)
> iceState:     "connected"   (ICE nominates a pair, writable=true, RTT measured)
> ```
>
> The second transport existed with old `rtcpMuxPolicy: negotiate`:
> ```
> Transport 1: iceState=connected, dtlsState=connecting, packetsSent=0
> Transport 2: iceState=new, dtlsState=new (unused, no candidates)
> ```
>
> **SDP received by offerer (answer from Kamailio):**
> ```
> m=audio 17070 UDP/TLS/RTP/SAVPF 8 126
> a=rtcp:17070
> a=rtcp-mux
> a=setup:passive          ← THE QUESTION
> a=fingerprint:sha-256 [...]
> a=ice-ufrag:[...] a=ice-pwd:[...]
> a=candidate:...          ← Asterisk's single candidate
> ```
>
> **SIP signaling:** Fully correct. No errors, no retransmissions, clean 200 OK.
>
> **Hypothesis:**  
> `DTLS=passive` in the answer (`onreply_route[REPLY_TO_WS]`) produces `a=setup:passive`.  
> Per RFC 5763 §5, this assigns the offerer the **active DTLS role** ("send ClientHello").  
> But Chrome only sends the `ClientHello` if **it wrote** `a=setup:active` in its own SDP,  
> not if the role was assigned via the answer.
>
> **The A→B→A Test:**
>
> 1. **A (baseline):** `DTLS=passive` → `a=setup:passive` → Offerer silent, `packetsSent=0`
> 2. **B (change):** `DTLS=active` → `a=setup:active` → **Offerer receives audio, `packetsSent > 0`**
> 3. **A' (revert):** `DTLS=passive` → `a=setup:passive` → Offerer silent again
>
> **Result:** Same Kamailio, same client, same network. Only the `DTLS=` flag changed.  
> Audio works/fails with the flag.
>
>
> SOLUTION:
>
> ## What I Changed (The Fix)
>
> In rtpengine_manage I was use: DTLS=active
>
> **Effect:**  
> - `DTLS=active` → RTPEngine emits `a=setup:active` in answer
> - Chrome receives `setup:active` → takes **passive** DTLS role (server)
> - RTPEngine initiates the DTLS ClientHello
> - Handshake completes, audio flows
>
> ----------------------- 
>
> **Is this the expected behavior?**
>
> 1. Should `a=setup:passive` in an answer always work, or does it depend on the browser?
> 2. Is Chrome's behavior (only initiating if it wrote the role) documented in any spec?
> 3. Has anyone else seen this issue with server-deployed WebRTC webphones where the 
>    offerer is a modern Chrome?
> 4. Should the pattern be: **offer → delegate role (actpass), answer → assume initiative (active)**?

I remember that a while ago I had to test flipping the active/passive
role between the offer/answer for different UAs to get it work smooth,
specially when multiple browsers and mobile apps are involved. Not sure
the current state of each browser, but good that you shared your
findings with current Chrome, it is valuable to know about it.

Cheers,
Daniel

-- 
Daniel-Constantin Mierla (@ asipto.com)
twitter.com/miconda -- linkedin.com/in/miconda
Kamailio Consultancy, Training and Development Services -- asipto.com
Kamailio Advanced Training - Online, Oct 5-8, 2026 -- asipto.com

__________________________________________________________
Kamailio - Users Mailing List - Non Commercial Discussions -- [email protected]
To unsubscribe send an email to [email protected]
Important: keep the mailing list in the recipients, do not reply only to the sender!