Re: Proposal: face meeting in Madrid

Hi all,

The idea of having a f2f unto itself is great, we always get plenty
accomplished when we do that. Unfortunately, I know of at least 1 editor
and potentially 1 chair who may not be in a position to travel overseas.
With that in mind I would propose we do a virtual interim in May sometime.

We also need to have a look at all the issues, PRs and comments and come up
with an agenda that we call feel we can make the most progress with during
the time we have together.

This week and next week I am slammed but near mid-April I can have a look
at the repo and come up with a doodle for a date and a draft agenda we can
all bash on.

Thanks!
Erik, CG Chair.


*Hookflash* <http://hookflash.com/> | m 1.604.562.8647 | erik@hookflash.com
| @elagerway <http://twitter.com/elagerway>

On Fri, Apr 1, 2016 at 8:17 AM, Iñaki Baz Castillo <ibc@aliax.net> wrote:

> 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>
>