1362581 - extmap direction for ssrc-audio-level for ICE restart

Status: RESOLVED WORKSFORME

(Core :: WebRTC: Signaling, defect, P3)

Description

[steve]

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:

Using FireFox Nightly I have a remote peer that is sendonly, and Firefox is recvonly. The remote peer sends the offer with the following extmap attribute for audio:

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

Firefox's answer does not contain the src-audio-level as I was told receiving this extension is not currently supported. Now if you do an ICE restart Firefox will include:

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


Actual results:

Here is the offer answer exchange from about:webrtc.

Local SDP (Answer)
v=0
o=mozilla...THIS_IS_SDPARTA-55.0a1 8471042672833957652 0 IN IP4 0.0.0.0
s=-
t=0 0
a=sendrecv
a=fingerprint:sha-256 AD:A1:48:12:B7:6C:F8:A1:67:E2:44:4E:5A:05:31:D5:F3:89:67:49:06:94:91:7B:A5:D0:78:3F:3C:56:F5:0C
a=group:BUNDLE sdparta_0 sdparta_1
a=ice-options:trickle
a=msid-semantic:WMS *
m=audio 63387 RTP/SAVPF 109 101
c=IN IP4 10.0.1.14
a=candidate:0 1 UDP 2122252543 10.0.1.14 63387 typ host
a=candidate:1 1 UDP 2122187007 10.1.10.64 54378 typ host
a=candidate:2 1 TCP 2105524479 10.0.1.14 9 typ host tcptype active
a=candidate:3 1 TCP 2105458943 10.1.10.64 9 typ host tcptype active
a=recvonly
a=end-of-candidates
a=fmtp:109 maxplaybackrate=48000;stereo=1;useinbandfec=1
a=fmtp:101 0-15
a=ice-pwd:d3bfeae826535a9d2a4265f8a4f5187e
a=ice-ufrag:d4c682f4
a=mid:sdparta_0
a=rtcp-mux
a=rtpmap:109 opus/48000/2
a=rtpmap:101 telephone-event/8000
a=setup:active
a=ssrc:3757324514 cname:{8e3822d0-e727-c749-b5c0-16468650ff0c}
m=video 63387 RTP/SAVPF 120
c=IN IP4 10.0.1.14
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:d3bfeae826535a9d2a4265f8a4f5187e
a=ice-ufrag:d4c682f4
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:2956882918 cname:{8e3822d0-e727-c749-b5c0-16468650ff0c}

Remote SDP (Offer)
v=0
o=- 1938276384 1431744545 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 61640 RTP/SAVPF 109 0 8 101
c=IN IP4 10.0.1.14
a=candidate:1796272311 1 UDP 2130706431 10.0.1.14 61640 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:7IKXgqhpHEdfiHoaIURgzr
a=ice-ufrag:uVW5eY8s6FRdPEex
a=mid:sdparta_0
a=msid:bpjc4pVApNTLTdzJjbU6uBMlSiRDt3UXU2if a0
a=rtcp:61640
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 61640 RTP/SAVPF 120 121 126 97
c=IN IP4 10.0.1.14
a=candidate:1796272311 1 UDP 2130706431 10.0.1.14 61640 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:7IKXgqhpHEdfiHoaIURgzr
a=ice-ufrag:uVW5eY8s6FRdPEex
a=mid:sdparta_1
a=msid:bpjc4pVApNTLTdzJjbU6uBMlSiRDt3UXU2if v0
a=rtcp:61640
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

After the ICE restart the offer sent by Firefox is: 

Local SDP (Offer)

v=0
o=mozilla...THIS_IS_SDPARTA-55.0a1 8471042672833957652 1 IN IP4 0.0.0.0
s=-
t=0 0
a=sendrecv
a=fingerprint:sha-256 AD:A1:48:12:B7:6C:F8:A1:67:E2:44:4E:5A:05:31:D5:F3:89:67:49:06:94:91:7B:A5:D0:78:3F:3C:56:F5:0C
a=group:BUNDLE sdparta_0 sdparta_1
a=ice-options:trickle
a=msid-semantic:WMS *
m=audio 49522 RTP/SAVPF 109 0 8 101 9
c=IN IP4 10.0.1.14
a=candidate:0 1 UDP 2122252543 10.0.1.14 49522 typ host
a=candidate:1 1 UDP 2122187007 10.1.10.64 52617 typ host
a=candidate:2 1 TCP 2105524479 10.0.1.14 9 typ host tcptype active
a=candidate:3 1 TCP 2105458943 10.1.10.64 9 typ host tcptype active
a=candidate:0 2 UDP 2122252542 10.0.1.14 64365 typ host
a=candidate:1 2 UDP 2122187006 10.1.10.64 54358 typ host
a=candidate:2 2 TCP 2105524478 10.0.1.14 9 typ host tcptype active
a=candidate:3 2 TCP 2105458942 10.1.10.64 9 typ host tcptype active
a=recvonly
a=end-of-candidates
a=extmap:1/recvonly urn:ietf:params:rtp-hdrext:ssrc-audio-level
a=fmtp:109 maxplaybackrate=48000;stereo=1;useinbandfec=1
a=fmtp:101 0-15
a=ice-pwd:3cc3b4ed36ab2f5e3611031f8d484a3d
a=ice-ufrag:b86fcdf9
a=mid:sdparta_0
a=rtcp:64365 IN IP4 10.0.1.14
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=rtpmap:9 G722/8000/1
a=setup:actpass
a=ssrc:3757324514 cname:{8e3822d0-e727-c749-b5c0-16468650ff0c}
m=video 61629 RTP/SAVPF 120 121 126 97
c=IN IP4 10.0.1.14
a=candidate:0 1 UDP 2122252543 10.0.1.14 61629 typ host
a=candidate:1 1 UDP 2122187007 10.1.10.64 63645 typ host
a=candidate:2 1 TCP 2105524479 10.0.1.14 9 typ host tcptype active
a=candidate:3 1 TCP 2105458943 10.1.10.64 9 typ host tcptype active
a=candidate:0 2 UDP 2122252542 10.0.1.14 51966 typ host
a=candidate:1 2 UDP 2122187006 10.1.10.64 57481 typ host
a=candidate:2 2 TCP 2105524478 10.0.1.14 9 typ host tcptype active
a=candidate:3 2 TCP 2105458942 10.1.10.64 9 typ host tcptype active
a=recvonly
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=fmtp:120 max-fs=12288;max-fr=60
a=fmtp:121 max-fs=12288;max-fr=60
a=fmtp:126 profile-level-id=42e01f;level-asymmetry-allowed=1;packetization-mode=1
a=fmtp:97 profile-level-id=42e01f;level-asymmetry-allowed=1
a=ice-pwd:3cc3b4ed36ab2f5e3611031f8d484a3d
a=ice-ufrag:b86fcdf9
a=mid:sdparta_1
a=rtcp:51966 IN IP4 10.0.1.14
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-fb:121 nack
a=rtcp-fb:121 nack pli
a=rtcp-fb:121 ccm fir
a=rtcp-fb:121 goog-remb
a=rtcp-fb:126 nack
a=rtcp-fb:126 nack pli
a=rtcp-fb:126 ccm fir
a=rtcp-fb:126 goog-remb
a=rtcp-fb:97 nack
a=rtcp-fb:97 nack pli
a=rtcp-fb:97 ccm fir
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:2956882918 cname:{8e3822d0-e727-c749-b5c0-16468650ff0c}


(Remote answer SDP is the same as the initial remote offer)




Expected results:

Firefox should not have src-audio-level in the offer until it is actually supported.

Comment 1

[Nils Ohlmeier [:drno]]

I'm wondering if this happens because the stream direction in the re-offer is recvonly.

Comment 2

[steve]

Note that Firefox does continue to consume the media after the ice restart. The topology of the network is:

Firefox(AV) -> SFU -> Firefox

Comment 3

[Nils Ohlmeier [:drno]]

Dan this is one of the bugs which hopefully should now easy to test with jsep_session_unittest after you landed the support for switching roles in it.

Comment 4

[Bulk Bug Changes for mreavy's org]

Mass change P2->P3 to align with new Mozilla triage process.

Comment 5

[Dan Minor [:dminor]]

Attachment: Bug 1362581 - Don't offer to receive extensions that are send only on reoffer;

Currently, when we switch roles after a ICE restart, we offer to receive any
extensions that the other side offered. This can lead to us offering to receive
an extension which is send only for Firefox. This change filters these extensions
out so that they do not appear in the offer.

Review commit: https://reviewboard.mozilla.org/r/183360/diff/#index_header
See other reviews: https://reviewboard.mozilla.org/r/183360/

Comment 6

[Byron Campen [:bwc]]

Comment on attachment 8911950 [details]
Bug 1362581 - Don't offer to receive extensions that are send only on reoffer;

https://reviewboard.mozilla.org/r/183360/#review188480

The only place where we write to the extmap attribute for offers is here:

https://dxr.mozilla.org/mozilla-central/source/media/webrtc/signaling/src/jsep/JsepSessionImpl.cpp?q=%2Bfunction%3A%22mozilla%3A%3AJsepSessionImpl%3A%3AGetRtpExtensions%28SdpMediaSection%3A%3AMediaType%29+const%22&redirect_type=single#810

If there is an ssrc-audio-level with the recv bit set in |extensions| here, that's a bug. It should never have ended up there in the first place. I only see one place where we install that extension (or indeed, any extension for audio), and it is doing the right thing:

https://dxr.mozilla.org/mozilla-central/source/media/webrtc/signaling/src/jsep/JsepSessionImpl.cpp#2391

I cannot see any way for this recvonly ssrc-audio-level to end up in an _offer_. I suspect that what we are actually seeing here is putting it in an _answer_, due to a flaw in the extmap negotiation code. Writing filtering code that yanks _sendonly_ extensions (eg; ssrc-audio-level) out of offers, _would_ prevent the answerer from messing up, but that's just masking the bug by introducing another one.

I suspect that the real problem lies somewhere in this function:

https://dxr.mozilla.org/mozilla-central/source/media/webrtc/signaling/src/sdp/SdpHelper.cpp?q=%2Bfunction%3A%22mozilla%3A%3ASdpHelper%3A%3AAddCommonExtmaps%28const+mozilla%3A%3ASdpMediaSection+%26%2C+const+std%3A%3Avector%3CSdpExtmapAttributeList%3A%3AExtmap%3E+%26%2C+mozilla%3A%3ASdpMediaSection+%2A%29%22&redirect_type=single#750

Comment 7

[Byron Campen [:bwc]]

I have a testcase that creates a reoffer with a recvonly m-section, and the ssrc-audio-level extmap is still _sendonly_. I guess you could argue that putting such an extmap in there is unnecessary, but it does not line up with the bug report.

I suspect that we're either seeing some adapter layer doing something wrong, or maybe this was a bug in 55 nightly that was subsequently fixed.

Comment 8

[Dan Minor [:dminor]]

(In reply to Byron Campen [:bwc] from comment #7)
> I have a testcase that creates a reoffer with a recvonly m-section, and the
> ssrc-audio-level extmap is still _sendonly_. I guess you could argue that
> putting such an extmap in there is unnecessary, but it does not line up with
> the bug report.
> 
> I suspect that we're either seeing some adapter layer doing something wrong,
> or maybe this was a bug in 55 nightly that was subsequently fixed.

Thank you for checking further, is this a WORKSFORME then?

Comment 9

[Byron Campen [:bwc]]

I can't get this to happen. Can you still reproduce this issue? If so, can you give us some code that we can run?

Comment 10

[Dan Minor [:dminor]]

I'm going to close this as WORKSFORME. Please reopen if you are still able to reproduce this. Thanks!