Closed Bug 1398820 Opened 6 years ago Closed 6 years ago

Firefox adds multiple a=extmap for RID with different ID when sending two videos with simulcast

Categories

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

Product:
Core
Component:
WebRTC: Signaling
Version:
55 Branch
Type:
defect

Tracking

()

Status:
RESOLVED FIXED
Milestone:
mozilla57
Tracking Flags:
Tracking Status
firefox57 --- fixed

People

(Reporter: ibc, Assigned: dminor)

Details

Attachments

(1 file)

Bug 1398820 - Do not add duplicate rtp extensions;
59 bytes, text/x-review-board-request
bwc
: review+
Details 
Let's call pc.addTrack(track1, stream) with a video track, and then enable simulcast using rtpSender.setParameters(...). This is the resulting SDP offer:


v=0
o=mozilla...THIS_IS_SDPARTA-55.0.3 1665190823946382244 1 IN IP4 0.0.0.0
s=-
t=0 0
a=sendrecv
a=fingerprint:sha-256 81:B4:63:AA:0B:C0:70:AC:78:05:19:60:5B:CD:62:34:49:B6:62:06:2A:3E:12:EE:67:31:C6:CE:D3:11:C3:A1
a=group:BUNDLE sdparta_0 sdparta_1
a=ice-options:trickle
a=msid-semantic:WMS *
m=audio 61373 UDP/TLS/RTP/SAVPF 109 9 0 8 101
c=IN IP4 192.168.178.24
a=candidate:0 1 UDP 2122252543 2001:16b8:4291:fa00:144d:2d68:f92d:f102 51808 typ host
a=candidate:1 1 UDP 2122187007 2001:16b8:4291:fa00:64e6:a128:7653:1477 51809 typ host
a=candidate:2 1 UDP 2122121471 192.168.178.24 61373 typ host
a=candidate:3 1 TCP 2105524479 2001:16b8:4291:fa00:144d:2d68:f92d:f102 9 typ host tcptype active
a=candidate:4 1 TCP 2105458943 2001:16b8:4291:fa00:64e6:a128:7653:1477 9 typ host tcptype active
a=candidate:5 1 TCP 2105393407 192.168.178.24 9 typ host tcptype active
a=sendrecv
a=end-of-candidates
a=extmap:1/sendonly 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:7cee51df1839db9ec1bf5c009d174f70
a=ice-ufrag:282a656e
a=mid:sdparta_0
a=msid:{7c80e8d7-2d8f-e84f-8da8-4693fe0b8c26} {a30db97c-4185-3a4f-ad8f-f16c26a638c7}
a=rtcp-mux
a=rtpmap:109 opus/48000/2
a=rtpmap:9 G722/8000/1
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=setup:actpass
a=ssrc:3905938001 cname:{dbdcc3ac-f1d9-0e44-8efb-af10de5d224e}
m=video 0 UDP/TLS/RTP/SAVPF 120 121 126 97
c=IN IP4 192.168.178.24
a=bundle-only
a=sendrecv
a=extmap:1 http://www.webrtc.org/experiments/rtp-hdrext/abs-send-time
a=extmap:2 urn:ietf:params:rtp-hdrext:toffset
a=extmap:3/sendonly urn:ietf:params:rtp-hdrext:sdes:rtp-stream-id
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=fmtp:120 max-fs=12288;max-fr=60
a=fmtp:121 max-fs=12288;max-fr=60
a=ice-pwd:7cee51df1839db9ec1bf5c009d174f70
a=ice-ufrag:282a656e
a=mid:sdparta_1
a=msid:{7c80e8d7-2d8f-e84f-8da8-4693fe0b8c26} {8165d3fc-80ae-1143-9ac0-7241f62dd10c}
a=rid:low964 send
a=rid:medium964 send
a=rid:high964 send
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=simulcast: send rid=low964;medium964;high964
a=ssrc:1041156897 cname:{dbdcc3ac-f1d9-0e44-8efb-af10de5d224e}
a=ssrc:2981360168 cname:{dbdcc3ac-f1d9-0e44-8efb-af10de5d224e}
a=ssrc:3701227096 cname:{dbdcc3ac-f1d9-0e44-8efb-af10de5d224e}


As you can see, Firefox has chosen a=extmap:3 for RID:

  a=extmap:3/sendonly urn:ietf:params:rtp-hdrext:sdes:rtp-stream-id

Cool.


Then add another video track and set also simulcast for it. And create a offer. This is how it looks:


v=0
o=mozilla...THIS_IS_SDPARTA-55.0.3 1665190823946382244 2 IN IP4 0.0.0.0
s=-
t=0 0
a=sendrecv
a=fingerprint:sha-256 81:B4:63:AA:0B:C0:70:AC:78:05:19:60:5B:CD:62:34:49:B6:62:06:2A:3E:12:EE:67:31:C6:CE:D3:11:C3:A1
a=group:BUNDLE sdparta_0 sdparta_1 sdparta_2
a=ice-options:trickle
a=msid-semantic:WMS *
m=audio 61373 UDP/TLS/RTP/SAVPF 109 9 0 8 101
c=IN IP4 192.168.178.24
a=candidate:0 1 UDP 2122252543 2001:16b8:4291:fa00:144d:2d68:f92d:f102 51808 typ host
a=candidate:1 1 UDP 2122187007 2001:16b8:4291:fa00:64e6:a128:7653:1477 51809 typ host
a=candidate:2 1 UDP 2122121471 192.168.178.24 61373 typ host
a=candidate:3 1 TCP 2105524479 2001:16b8:4291:fa00:144d:2d68:f92d:f102 9 typ host tcptype active
a=candidate:4 1 TCP 2105458943 2001:16b8:4291:fa00:64e6:a128:7653:1477 9 typ host tcptype active
a=candidate:5 1 TCP 2105393407 192.168.178.24 9 typ host tcptype active
a=sendrecv
a=end-of-candidates
a=extmap:1/sendonly 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:7cee51df1839db9ec1bf5c009d174f70
a=ice-ufrag:282a656e
a=mid:sdparta_0
a=msid:{7c80e8d7-2d8f-e84f-8da8-4693fe0b8c26} {a30db97c-4185-3a4f-ad8f-f16c26a638c7}
a=rtcp-mux
a=rtpmap:109 opus/48000/2
a=rtpmap:9 G722/8000/1
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=setup:actpass
a=ssrc:3905938001 cname:{dbdcc3ac-f1d9-0e44-8efb-af10de5d224e}
m=video 0 UDP/TLS/RTP/SAVPF 120 121 126 97
c=IN IP4 192.168.178.24
a=bundle-only
a=sendrecv
a=extmap:1 http://www.webrtc.org/experiments/rtp-hdrext/abs-send-time
a=extmap:2 urn:ietf:params:rtp-hdrext:toffset
a=extmap:3/sendonly urn:ietf:params:rtp-hdrext:sdes:rtp-stream-id
a=extmap:4/sendonly urn:ietf:params:rtp-hdrext:sdes:rtp-stream-id
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=fmtp:120 max-fs=12288;max-fr=60
a=fmtp:121 max-fs=12288;max-fr=60
a=ice-pwd:7cee51df1839db9ec1bf5c009d174f70
a=ice-ufrag:282a656e
a=mid:sdparta_1
a=msid:{7c80e8d7-2d8f-e84f-8da8-4693fe0b8c26} {8165d3fc-80ae-1143-9ac0-7241f62dd10c}
a=rid:low964 send
a=rid:medium964 send
a=rid:high964 send
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=simulcast: send rid=low964;medium964;high964
a=ssrc:1041156897 cname:{dbdcc3ac-f1d9-0e44-8efb-af10de5d224e}
m=video 0 UDP/TLS/RTP/SAVPF 120 121 126 97
c=IN IP4 192.168.178.24
a=bundle-only
a=sendrecv
a=extmap:1 http://www.webrtc.org/experiments/rtp-hdrext/abs-send-time
a=extmap:2 urn:ietf:params:rtp-hdrext:toffset
a=extmap:3/sendonly urn:ietf:params:rtp-hdrext:sdes:rtp-stream-id
a=extmap:4/sendonly urn:ietf:params:rtp-hdrext:sdes:rtp-stream-id
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=fmtp:120 max-fs=12288;max-fr=60
a=fmtp:121 max-fs=12288;max-fr=60
a=ice-pwd:7cee51df1839db9ec1bf5c009d174f70
a=ice-ufrag:282a656e
a=mid:sdparta_2
a=msid:{7c80e8d7-2d8f-e84f-8da8-4693fe0b8c26} {27e85a01-4947-834c-9923-5732bea85ed3}
a=rid:low902 send
a=rid:medium902 send
a=rid:high902 send
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=simulcast: send rid=low902;medium902;high902
a=ssrc:1190437139 cname:{dbdcc3ac-f1d9-0e44-8efb-af10de5d224e}
a=ssrc:528573577 cname:{dbdcc3ac-f1d9-0e44-8efb-af10de5d224e}
a=ssrc:1285060159 cname:{dbdcc3ac-f1d9-0e44-8efb-af10de5d224e}


Here there are two m=video sections. Both have a=simulcast and their corresponding a=rid lines. However, in both m=video sections now there are duplicated a=extmap for RID:

  a=extmap:3/sendonly urn:ietf:params:rtp-hdrext:sdes:rtp-stream-id
  a=extmap:4/sendonly urn:ietf:params:rtp-hdrext:sdes:rtp-stream-id

OUGH!

It seems to me that, for each m=section with simulcast, Firefox is adding a new RID extmap ID. Obviously it should just use one.

Please please please: When you fix this, make sure that Firefox uses an unique extmap RID ID for all the m= sections (avoid having extmap ID "aliases"...). In the use case above, both m=video sections should just contain:

  a=extmap:3/sendonly urn:ietf:params:rtp-hdrext:sdes:rtp-stream-id
Rank: 25
Priority: -- → P2
Assignee: nobody → dminor
Mass change P2->P3 to align with new Mozilla triage process.
Priority: P2 → P3
Fiddle I used for testing: https://jsfiddle.net/dminor/sL2bcwva/

I wasn't sure if we need to consider extensionattributes when testing for a duplicate extension.
Comment on attachment 8908613 [details]
Bug 1398820 - Do not add duplicate rtp extensions;

https://reviewboard.mozilla.org/r/180270/#review185432

::: media/webrtc/signaling/gtest/jsep_session_unittest.cpp:4146
(Diff revision 1)
> +  SetLocalOffer(offer, CHECK_SUCCESS);
> +  SetRemoteOffer(offer, CHECK_SUCCESS);
> +  std::string answer = CreateAnswer();
> +  SetLocalAnswer(answer, CHECK_SUCCESS);
> +  SetRemoteAnswer(answer, CHECK_SUCCESS);

If we're just checking the offer, we probably don't need to do all this.
Attachment #8908613 - Flags: review?(docfaraday) → review+
Pushed by dminor@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/f73a6867afee
Do not add duplicate rtp extensions; r=bwc
https://hg.mozilla.org/mozilla-central/rev/f73a6867afee
Status: NEW → RESOLVED
Closed: 6 years ago
status-firefox57: --- → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla57
You need to log in before you can comment on or make changes to this bug.