extmap direction for ssrc-audio-level causes Firefox to disable header extension.

RESOLVED INVALID

Status

()

Core
WebRTC: Networking
RESOLVED INVALID
a year ago
a year ago

People

(Reporter: steve, Unassigned)

Tracking

(Depends on: 1 bug, Blocks: 1 bug)

Trunk
x86_64
Mac OS X
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

a year ago
User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_3) AppleWebKit/602.4.8 (KHTML, like Gecko) Version/10.0.3 Safari/602.4.8

Steps to reproduce:

FF: 55.0a1 (2017-04-28) (64-bit) (MacOS 10.12.3)

Sending a=extmap:1/sendonly urn:ietf:params:rtp-hdrext:ssrc-audio-level in an offer to Firefox causes src-audio-level header extension to be disabled.


Actual results:

The answer from FF does not contain 

a=extmap:1/recvonly urn:ietf:params:rtp-hdrext:ssrc-audio-level

SDP
Local SDP
v=0
o=mozilla...THIS_IS_SDPARTA-55.0a1 7091948394175832951 0 IN IP4 0.0.0.0
s=-
t=0 0
a=sendrecv
a=fingerprint:sha-256 E2:55:E0:6D:6B:91:17:C3:A3:A6:EF:6D:C8:C1:91:D2:B1:7C:0C:AA:23:76:19:BE:B4:0B:EC:31:05:98:31:E8
a=group:BUNDLE sdparta_0 sdparta_1
a=ice-options:trickle
a=msid-semantic:WMS *
m=audio 36686 RTP/SAVPF 109 101
c=IN IP4 68.189.42.215
a=candidate:0 1 UDP 2122252543 10.0.1.14 64840 typ host
a=candidate:2 1 UDP 2122187007 10.1.10.64 58633 typ host
a=candidate:4 1 TCP 2105524479 10.0.1.14 9 typ host tcptype active
a=candidate:5 1 TCP 2105458943 10.1.10.64 9 typ host tcptype active
a=candidate:1 1 UDP 1686052863 68.189.42.215 36686 typ srflx raddr 10.0.1.14 rport 64840
a=recvonly
a=fmtp:109 maxplaybackrate=48000;stereo=1;useinbandfec=1
a=fmtp:101 0-15
a=ice-pwd:136148ef49c0ac32cd3a0d13fe2cbeba
a=ice-ufrag:1b01a1ec
a=mid:sdparta_0
a=rtcp-mux
a=rtpmap:109 opus/48000/2
a=rtpmap:101 telephone-event/8000
a=setup:active
a=ssrc:1357042078 cname:{d01e332d-0aa5-a14d-9a86-3cd3446c74ad}
m=video 36686 RTP/SAVPF 120
c=IN IP4 68.189.42.215
a=recvonly
a=extmap:1 http://www.webrtc.org/experiments/rtp-hdrext/abs-send-time
a=extmap:2 urn:ietf:params:rtp-hdrext:toffset
a=fmtp:120 max-fs=12288;max-fr=60
a=ice-pwd:136148ef49c0ac32cd3a0d13fe2cbeba
a=ice-ufrag:1b01a1ec
a=mid:sdparta_1
a=rtcp-fb:120 nack
a=rtcp-fb:120 nack pli
a=rtcp-fb:120 ccm fir
a=rtcp-fb:120 goog-remb
a=rtcp-mux
a=rtpmap:120 VP8/90000
a=setup:active
a=ssrc:3893555561 cname:{d01e332d-0aa5-a14d-9a86-3cd3446c74ad}

Remote SDP
v=0
o=- 1881251201 787200426 IN IP4 10.0.1.14
s=-
t=0 0
a=sendrecv
a=fingerprint:sha-256 4C:C6:EE:14:16:7C:EA:9B:C4:5A:EA:5D:28:5E:82:9E:BC:98:AE:29:42:DD:B6:1D:6C:B3:66:4A:5E:90:9D:7F
a=group:BUNDLE sdparta_0 sdparta_1
a=ice-lite
a=msid-semantic:WMS *
m=audio 55815 RTP/SAVPF 109 0 8 101
c=IN IP4 10.0.1.14
a=candidate:1796272311 1 UDP 2130706431 10.0.1.14 55815 typ host generation 0
a=sendrecv
a=end-of-candidates
a=extmap:1/sendonly urn:ietf:params:rtp-hdrext:ssrc-audio-level
a=fmtp:109 maxplaybackrate=0;stereo=0;useinbandfec=1
a=ice-pwd://p1MZ5mxdaHUURPRL3ems
a=ice-ufrag:KCp4gzvKl1qI0eLI
a=mid:sdparta_0
a=msid:bpjc4pVApNTLTdzJjbU6uBMlSiRDt3UXU2if a0
a=rtcp:55815
a=rtcp-mux
a=rtpmap:109 opus/48000/2
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=setup:actpass
a=ssrc:1 cname:bpjc4pV
a=ssrc:1 msid:bpjc4pVApNTLTdzJjbU6uBMlSiRDt3UXU2if a0
m=video 55815 RTP/SAVPF 120 121 126 97
c=IN IP4 10.0.1.14
a=candidate:1796272311 1 UDP 2130706431 10.0.1.14 55815 typ host generation 0
a=sendrecv
a=end-of-candidates
a=extmap:1 http://www.webrtc.org/experiments/rtp-hdrext/abs-send-time
a=extmap:2 urn:ietf:params:rtp-hdrext:toffset
a=ice-pwd://p1MZ5mxdaHUURPRL3ems
a=ice-ufrag:KCp4gzvKl1qI0eLI
a=mid:sdparta_1
a=msid:bpjc4pVApNTLTdzJjbU6uBMlSiRDt3UXU2if v0
a=rtcp:55815
a=rtcp-fb:120 ccm fir
a=rtcp-fb:120 nack
a=rtcp-fb:120 nack pli
a=rtcp-fb:120 goog-remb
a=rtcp-fb:121 ccm fir
a=rtcp-fb:121 nack
a=rtcp-fb:121 nack pli
a=rtcp-fb:121 goog-remb
a=rtcp-fb:126 ccm fir
a=rtcp-fb:126 nack
a=rtcp-fb:126 nack pli
a=rtcp-fb:126 goog-remb
a=rtcp-fb:97 ccm fir
a=rtcp-fb:97 nack
a=rtcp-fb:97 nack pli
a=rtcp-fb:97 goog-remb
a=rtcp-mux
a=rtpmap:120 VP8/90000
a=rtpmap:121 VP9/90000
a=rtpmap:126 H264/90000
a=rtpmap:97 H264/90000
a=setup:actpass
a=ssrc:2 cname:bpjc4pV
a=ssrc:2 msid:bpjc4pVApNTLTdzJjbU6uBMlSiRDt3UXU2if v0



Expected results:

I expected 

a=extmap:1/recvonly urn:ietf:params:rtp-hdrext:ssrc-audio-level to be in the answer.
(Reporter)

Updated

a year ago
OS: Unspecified → Mac OS X
Hardware: Unspecified → x86_64
(Reporter)

Comment 1

a year ago
I see why this may be happening. The attribute of the audio stream is marked sendrecv where it should be Offer(sendonly) and Answer(recvonly). This may be an issue with our clients.
Component: Untriaged → WebRTC: Networking
Product: Firefox → Core
This has nothing to do with the streams direction attribute. It's simply that Firefox does not support to receive the ssrc-audio-level extension. There is no code in Firefox to handle that extension on the incoming side. Therefore Firefox correctly drops the extension to tell the offerer not to waste bandwidth with an unsupported extension.
Status: UNCONFIRMED → RESOLVED
Last Resolved: a year ago
Resolution: --- → INVALID
Summary: extmap direction causes Firefox to disable header extension. → extmap direction for ssrc-audio-level causes Firefox to disable header extension.
(Reporter)

Comment 3

a year ago
So Firefox only supports sending ssrc-audio-level, but not receiving it?
(In reply to steve from comment #3)
> So Firefox only supports sending ssrc-audio-level, but not receiving it?

Yes, exactly.
FYI there is bug 1353841 for implementing the receiver side.
Depends on: 1353841
(Reporter)

Comment 6

a year ago
This is worth mentioning. Not sure if this is a bug. If so I can open a new ticket. With our SFU we send the initial offer to the browser. In the SDP we set:

a=extmap:1/sendonly urn:ietf:params:rtp-hdrext:ssrc-audio-level

This causes FF to disable the ssrc-audio-level extension. Now if an ICE restart is performed from Firefox, the Offer SDP will contain:

a=extmap:1/recvonly urn:ietf:params:rtp-hdrext:ssrc-audio-level

Updated

a year ago
Blocks: 1359872
(In reply to steve from comment #6)
> This is worth mentioning. Not sure if this is a bug. If so I can open a new
> ticket. With our SFU we send the initial offer to the browser. In the SDP we
> set:
> 
> a=extmap:1/sendonly urn:ietf:params:rtp-hdrext:ssrc-audio-level
> 
> This causes FF to disable the ssrc-audio-level extension. Now if an ICE
> restart is performed from Firefox, the Offer SDP will contain:
> 
> a=extmap:1/recvonly urn:ietf:params:rtp-hdrext:ssrc-audio-level

That indeed sounds like a bug to me. Would appreciate if you could open a new bug for that.
You need to log in before you can comment on or make changes to this bug.