- From: Iñaki Baz Castillo <ibc@aliax.net>
- Date: Fri, 1 Apr 2016 17:17:07 +0200
- To: Bernard Aboba <Bernard.Aboba@microsoft.com>
- Cc: "public-ortc@w3.org" <public-ortc@w3.org>, Erik Lagerway <erik@hookflash.com>, Robin Raymond <robin@hookflash.com>, Peter Thatcher <pthatcher@google.com>
2016-03-31 4:01 GMT+02:00 Bernard Aboba <Bernard.Aboba@microsoft.com>: > [BA] There are open issues relating to the object model for RTX/RED/FEC that > have the potential to affect both the ORTC API as well as WebRTC 1.0: > > My preference would be to have a discussion of these issues well before TPAC > (or even the July IETF meeting in Berlin). > > This could be accomplished via an online meeting (an ORTC CG meeting and/or > a WebRTC WG virtual interim) I would like to highlight the current discussions so we can agree on the exact topics of the meeting. IMHO those are the following (I've tried to isolate them so we can handle them individually): 1) RTCRtpSender: have full RTCRtpParameters before sending RTP ------------------------------------------------------------------------------------------- Current API clearly invites the developer to leave empty the RTCRtpEncodingParameters field of the sending RTCRtpParameters. The rationale for this is that, in most common scenarios, the receiver just needs the RTCCodecParameters and perform the "RTP matching rules" of the spec. However, in order to be WebRTC 1.0 compliant, the sender must be able to construct a full SDP offer before sending RTP. This means that he needs the exact `encodings` (including SSRC values and so on). The developer cannot construct such a complex `encodings` sequence as the exact features may be browser dependent. Issue in detail and proposal: - https://github.com/openpeer/ortc/issues/447 Related: - https://github.com/openpeer/ortc/issues/438 2) Codecs: syntax and relationship for media codecs and feature codecs ------------------------------------------------------------------------------------------------- Whether feature codecs (RTX, FEC, etc) must be defined as real media codecs or not. Some good progress here: - https://github.com/openpeer/ortc/issues/444 3) RTCRtpParameters: relationship between codecs and encodings ------------------------------------------------------------------------------------------ Currently both `codecs` and `encodings` include cross-references that make the resulting `RTCRtpParameters` weak and error prune, with multiple way of expressing the same. The fact that in some common cases leaving `encodings` empty does the work should not prevent the API from making it easy to manage the whole RTP parameters (if needed) in a reliable way. 4) RtpSender & RtpReceiver and receiver: share IDL definitions or not ---------------------------------------------------------------------------------------------- Whether the current RTCRtpParameters and RTCRtpEncodingParameters should be split into RTCRtpSenderParameters+RTCRtpReceiverParameters and RTCRtpEncodingParameters+RTCRtpDecodingParameters or not. Related issues: - https://github.com/openpeer/ortc/issues/440 - https://github.com/openpeer/ortc/issues/445 NOTE: I've added this topic at the end given that it may depend on decisions made for the previous topics. So, I hope we can at least agree on what we disagree and make the meeting as constructive as possible :) Thoughts? -- Iñaki Baz Castillo <ibc@aliax.net>
Received on Friday, 1 April 2016 15:17:58 UTC