New issue
Advanced search Search tips

Issue 913478 link

Starred by 3 users

Issue metadata

Status: Available
Owner: ----
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Linux , Android , Windows , Chrome , Mac , Fuchsia
Pri: 2
Type: Bug


Participants' hotlists:
WebRTC-1.0-Spec-Compliance


Sign in to add a comment

Support "a=msid:-" without track IDs

Project Member Reported by hbos@chromium.org, Dec 10

Issue description

The so-called "appdata" field should no longer be signaled.
See https://github.com/rtcweb-wg/jsep/pull/850/files.

We should add test coverage though to make sure that our implementation does not barf on legacy SDP. We can either ignore the appdata field or "use it iff a new track was created"
 
What do we want the track object's ID to be if the track is created due a the remote description? I assume an empty string is probably not the right choice. Randomly generated string?
As I showed when writing the protocol/msid-parse.html WPT test, the incoming track object's ID is always a random string.

This isn't what the spec used to say, so that change has been applied before the spec change.

What we have to do here is:

- Get parsing of "a=msid:-" into M73, so that Chrome doesn't barf on it (and UMA counters for how often we see the two versions)
- Wait at least 2 versions - M75 or later
- Start generating "a=msid:-"

Standard procedure for incompatible changes.
The msid-parse.html WPT test showed (during development) that the track "id" field is a random string.
Let's document what we already do.

Sign in to add a comment