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

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)**?


best regards!!

Ric
__________________________________________________________
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!