W3C home > Mailing lists > Public > public-webrtc-logs@w3.org > September 2019

[webrtc-pc] [[SendCodecs]] is updated based on answers, but [[SendEncodings]] is updated based on remote description (#2313)

From: docfaraday via GitHub <sysbot+gh@w3.org>
Date: Fri, 27 Sep 2019 15:09:57 +0000
To: public-webrtc-logs@w3.org
Message-ID: <issues.opened-499501103-1569596996-sysbot+gh@w3.org>
docfaraday has just created a new issue for https://github.com/w3c/webrtc-pc:

== [[SendCodecs]] is updated based on answers, but [[SendEncodings]] is updated based on remote description ==
Because the details of a send codec are determined by the remote description (for example, asymmetric payload type), we need to be paying attention to the remote description when setting [[SendCodecs]].

Also, right now the spec updates [[SendCodecs]] and [[SendEncodings]] at a different time; since the two are linked by payload type, and payload type can change due to negotiation, we have a referential integrity problem. For example, if we receive a remote offer that changes the payload type of a codec, that will be reflected immediately in [[SendEncodings]], but [[SendCodecs]] will still have the old payload type for that codec.

If we intend to continue updating [[SendEncodings]] on remote offers (pre-answer), we probably want to also update [[SendCodecs]]. Unfortunately, the prose around [[SendCodecs]] says these represent what has been negotiated, which would no longer be true. Also, if we do this, we need to specify how rollback/multiple offers works.

If we intend to update [[SendEncodings]] only when offer/answer completes, this ends up being cleaner. However, it would mean that JS would not be able to make changes to [[SendEncodings]] that come from a remote offer until after negotiation is complete, which might be undesirable.

Another approach might be to abandon the use of payload type as the thing that links [[SendEncodings]] to [[SendCodecs]], and instead use rid. rid is more stable than payload type. We could have each entry in [[SendCodecs]] contain a list of rids that it has been negotiated to send, and define the simulcast envelope that way. The potential downside to this is if we allow the rids to be renegotiated (say, we start with 'low', 'med', and 'high', and then a renegotiation happens that changes to rids 'tall', 'grande', and 'venti'). In that case, we have a referential integrity problem again.

Thoughts?

Please view or discuss this issue at https://github.com/w3c/webrtc-pc/issues/2313 using your GitHub account
Received on Friday, 27 September 2019 15:09:58 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:22:29 UTC