- From: Philipp Hancke via GitHub <sysbot+gh@w3.org>
- Date: Sat, 15 Jun 2024 22:55:02 +0000
- To: public-webrtc-logs@w3.org
I've always seen the "capability" as a "I support" in the sense of [XMPPs entity caps](https://xmpp.org/extensions/xep-0115.html) which had a nice mapping to ORTC. The way this traditionally worked was that getCapabilities returned static capabilities, getParameters the negotiated parameters (which include a payload type which is a dynamic thing). The negotiation is adding the dynamic payload type to the parameters. The semantic difference is that caps are "I can use" while parameters are "I use" (obviously you can not use something you are not capable of doing) The goal of #2834 was fine but missing that these objects semantically build ontop of each other. Same for header extensions. Now whether the payload type member is even required is questionable, it is read-only and can not be changed as it is determined by SDP negotiation. -- GitHub Notification of comment by fippo Please view or discuss this issue at https://github.com/w3c/webrtc-pc/issues/2974#issuecomment-2170960450 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Saturday, 15 June 2024 22:55:02 UTC