Remote Track ID and Label are blank for answers using Unified Plan, and sometimes after renegotiation

[jeremija]

I have a fix ready and am going to open a pull request associated with this issue. Would greatly appreciate feedback!

Your environment.

• Version: 364d0de
• Browser: Firefox and Chrome
• Other information: please see below

What did you do?

This happens in two cases:

1. I initiated a peer connection from server to Chrome or Firefox. Both of them default to unified plan and no longer return the track ID and label in the a=ssrc:<ssrc> msid:<track_id> <track_label> format, but in a=msid:<track_id> <track_label> format.

Should be fixed by: b078d57, already in #1135.

2. • I created a server with a sendrecv video transceiver
   • The server created an offer with asendrecv media section.
   • The browser answered with a recvonly media section.
   • The browser called addTrack() and requested negotiation from the server.
   • The server created an offer
   • The browser answered with a sendrecv media section and track ID / label
   • The OnTrack handler was called with the right ssrc, but blank id and label fields.

Should be fixed by 15beeb1, already in #1135.

What did you expect?

I expected track.ID() and track.Label() to be set, but they were blank: "" in both cases.

What happened?

There are two reasons why this happens:

1. Unified Plan uses a new attribute key: a=ssrc

From Unified Plan Transition Guide:

People who do detailed SDP parsing and care about msid attributes will have to check that their parsing code picks up the new format (a=msid)

The current code tries to extract it from:

a=ssrc:<ssrc> msid:<msid> <label>

However, both Firefox and Chrome now send it as:

a=msid:<msid> <label>
a=ssrc:<ssrc> cname:<cname>

2. Track.ID and Track.Label are not sent in the first SDP, but only during the renegotiation in the second answer

The pion/webrtc server generates an offer:

m=video 9 UDP/TLS/RTP/SAVPF 96 98 102
c=IN IP4 0.0.0.0
a=setup:actpass
a=mid:0
a=ice-ufrag:CdEJRWUFkiQvhkHz
a=ice-pwd:UulhpVNabGWvAHoAFhCbQNQYLjqmBOFR
a=rtcp-mux
a=rtcp-rsize
a=rtpmap:96 VP8/90000
a=rtpmap:98 VP9/90000
a=rtpmap:102 H264/90000
a=fmtp:102 level-asymmetry-allowed=1;packetization-mode=1;profile-level-id=42001f
a=ssrc:2596996162 cname:TjHVWxkKPtxTAeFD
a=ssrc:2596996162 msid:TjHVWxkKPtxTAeFD NjPSPGQVICwMHQxo
a=ssrc:2596996162 mslabel:TjHVWxkKPtxTAeFD
a=ssrc:2596996162 label:NjPSPGQVICwMHQxo
a=msid:TjHVWxkKPtxTAeFD NjPSPGQVICwMHQxo
a=sendrecv
... candidates and other streams

The first answer from the browser (addTrack hasn't been called yet):

m=video 56812 UDP/TLS/RTP/SAVPF 96 98
a=recvonly
a=end-of-candidates
a=fmtp:96 max-fs=12288;max-fr=60
a=fmtp:98 max-fs=12288;max-fr=60
a=ice-pwd:a1dbf2ff4fb7ad70afd549ecfc743786
a=ice-ufrag:91ad396c
a=mid:0
a=rtcp-mux
a=rtpmap:96 VP8/90000
a=rtpmap:98 VP9/90000
a=setup:active
a=ssrc:4199521927 cname:{f97c2d01-98b1-d848-9a6e-5786ee794fff}
m=audio 56812 UDP/TLS/RTP/SAVPF 111 0 8 9

At this point, a new *webrtc.Track is created in PeerConnection.startReceiver(), with id="" and label="". The startReceiver blocks in determinePayloadType() and no packets have been sent because the addTrack hasn't been called in the browser yet.

Next, a track is added in the browser, and the browser requests negotiation from the server. Below is a second offer from the pion/webrtc server:

a=mid:0
a=rtcp-mux
a=rtcp-rsize
a=rtpmap:96 VP8/90000
a=rtpmap:98 VP9/90000
a=rtpmap:102 H264/90000
a=fmtp:102 level-asymmetry-allowed=1;packetization-mode=1;profile-level-id=42001f
a=ssrc:2596996162 cname:TjHVWxkKPtxTAeFD
a=ssrc:2596996162 msid:TjHVWxkKPtxTAeFD NjPSPGQVICwMHQxo
a=ssrc:2596996162 mslabel:TjHVWxkKPtxTAeFD
a=ssrc:2596996162 label:NjPSPGQVICwMHQxo
a=msid:TjHVWxkKPtxTAeFD NjPSPGQVICwMHQxo
a=sendrecv
... candidates

And the browser's final answer is:

m=video 56812 UDP/TLS/RTP/SAVPF 96 98
a=sendrecv
a=end-of-candidates
a=fmtp:96 max-fs=12288;max-fr=60
a=fmtp:98 max-fs=12288;max-fr=60
a=ice-pwd:a1dbf2ff4fb7ad70afd549ecfc743786
a=ice-ufrag:91ad396c
a=mid:0
a=msid:{dac0424f-0b68-bd40-9e47-04780b0c4f70} {9d8ee2b5-345e-a041-92f3-8851865df6b3}
a=rtcp-mux
a=rtpmap:96 VP8/90000
a=rtpmap:98 VP9/90000
a=setup:active
a=ssrc:4199521927 cname:{f97c2d01-98b1-d848-9a6e-5786ee794fff}

After successful renegotiation, the OnTrack handler is called with track.ID() == "" and track.Label() == "", because those were the values during the first negotiation.