Bug 236357 – Inbound-Audio-Only WebRTC calls not supported in Safari

• Component: WebRTC
• Status: NEW

[Jeff Whelpley]

There is currently no way to do an inbound-audio-only WebRTC call (i.e. where a user is only listening to a call without speaking) in Safari.

If you `offerToReceiveAudio: true` but also don't have any media constraints `{ audio: false, video: false }` (i.e. `getUserMedia()` is not called), then Safari will use mDNS .local addresses in the INVITE message which only work for peers in the local network. Even if you add STUN/TURN iceServers (which is meant to help with this situation), Safari will not send out ICE candidates that can be reached by peers outside the local network.

Currently Chrome supports inbound-audio-only WebRTC calls and Firefox also works if you use STUN/TURN iceServers.

This is not an issue in Safari if you call `getUserMedia({ audio: true })`, but it just doesn't make logical sense to force the user to give access to their microphone when their microphone will never be used for this use case.

[youenn fablet]

STUN/TURN should be working in Safari without private relay.
https://webrtc.github.io/samples/src/content/peerconnection/trickle-ice/ should work in that case and expose SRFLX candidates

[Radar WebKit Bug Importer]

<rdar://problem/89016581>

[youenn fablet]

@Jeff, can you provide more info on why/how you are to seeing STUN/TURN candidates?

[Jeff Whelpley]

Created attachment 453969 [details]
jssip log in safari

[Jeff Whelpley]

The log file I just attached is when I turn on debugging with jssip when I try the use case I described in Safari (i.e. offertoReceiveAudio: true).

You can see in the invite that gets generated that the relays for TURN can't be used because it has `raddr 0.0.0.0` and the host addresses are mDNS .local addresses.

In this use case we explicitly do not want to prompt the user for microphone permissions since they are not needed, but it appears audio would only work for peers on the same local network.

[youenn fablet]

> You can see in the invite that gets generated that the relays for TURN can't
> be used because it has `raddr 0.0.0.0`

I would believe 'raddr 0.0.0.0' does not break srflx or relay candidates.
AFAIK, related addresses are for instance not used by browsers to setup connections.

Can you detail why 'raddr 0.0.0.0' is breaking your application?

[Jeff Whelpley]

Apologies, I did not mean to imply that was causing the issue. That was a guess. I don't know what the cause of the issue is in Safari.

The issue is that media is not able to get to Safari in the use case with no media constraints (i.e. { audio: false, video: false }) and offerToReceiveAudio: true. The WebRTC session is established, but no media.

This use case does work in Chrome and Firefox, but not Safari.

[youenn fablet]

Would you be able to provide a repro case?
Since you are using offerToReceiveAudio, you are probably using adapter.js.
Can you upgrade to the latest version?

You can also send me a sysdiagnose at [e-mail], ideally with WebRTC logging enabled.

[youenn fablet]

Created attachment 453974 [details]
screenshot of web inspector to enable WebRTC logging

[Jeff Whelpley]

Created attachment 453999 [details]
WebRTC trace of issue

[Jeff Whelpley]

I wasn't aware of the WebRTC trace capability. I just added a trace of the use case I described. Let me know if anything else would help.

I am no expert of this trace, but near the end it does have an "RTP Timeout" which would make sense since like I said, the media doesn't get to Safari for this use case.

[youenn fablet]

(In reply to Jeff Whelpley from comment #11)
> I wasn't aware of the WebRTC trace capability. I just added a trace of the
> use case I described. Let me know if anything else would help.
> 
> I am no expert of this trace, but near the end it does have an "RTP Timeout"
> which would make sense since like I said, the media doesn't get to Safari
> for this use case.

I can see RTCPeerConnection::updateIceConnectionState(2E885B18) failed.
So the connection is indeed not successful.
I can see the remote description has one remote candidate 172.29.67.41.
Is that address accessible from the browser?

If the issue is rdar for relay candidates being 0.0.0.0, you can use the srflx candidate public IP address as related address and rewrite the TURN addresses.