Bug: WebRTC codec mismatch — bridge uses caller OFFER codec instead of ANSWER codec

[davidcforbes]

Description

Calls from WebRTC browsers produce static/garbage audio when the answer negotiates a different codec than the offer's first choice.

Root Cause

When a WebRTC browser sends an OFFER with Opus first, but the proxy's answer negotiates G722 (because the PSTN callee doesn't support Opus), the browser honors the answer and sends G722. However, codec_a was determined from the caller's OFFER first codec (Opus), so the bridge decodes G722 bytes with the Opus decoder.

SIP carriers behave differently — they typically ignore the answer and send their offer's first codec. WebRTC browsers strictly follow the answer.

Fix

In src/proxy/proxy_call/session.rs, detect WebRTC callers via RTP/SAVPF in SDP and use the answer's first codec for them (both early-media and 200 OK paths).

Fix commit: davidcforbes/rustpbx@d0e0cad