Subject: Re: [MMUSIC] Towards Simulcast

From: Adam Roach <[email-masked]>
Date: Fri, 16 Oct 2015 12:26:47 -0500

Moving to MMUSIC

On 10/16/15 11:59 AM, Peter Thatcher wrote:
> There's a lot of important stuff in the draft that wasn't discussed at 
> the interim call, such as the attributes/constraints an a RID and 
> what's mandatory to implement and not and how you know what the other 
> side supports or not.

So, let's step down from the meta-conversation and into the 
conversation, then. Addressing these three points:

There's a list of attributes in the current document. Do you think we 
need additional ones? If so, which ones?

As written, the document doesn't require support of any specific 
attributes. Do you think we should add a list of some that should be 
MTI? If so, propose a list.

Section 7.1 bullet 4 proposes a way to find out what the other side 
supports. Are there use cases you have in mind that it doesn't work with?

/a

---

From: Peter Thatcher <[email-masked]>
Date: Fri, 16 Oct 2015 18:15:57 -0700

On Fri, Oct 16, 2015 at 10:26 AM, Adam Roach <[email-masked]> wrote:

> There's a lot of important stuff in the draft that wasn't discussed at the
> interim call, such as the attributes/constraints an a RID and what's
> mandatory to implement and not and how you know what the other side
> supports or not.
>
>
> So, let's step down from the meta-conversation and into the conversation,
> then. Addressing these three points:
>
> There's a list of attributes in the current document. Do you think we need
> additional ones? If so, which ones?
>

​For the purposes of WebRTC, I think we need none of them, and should at
most support max-br.  ​So I'd actually be in favor of removing attributes
rather than adding them.  The fewer there are, the faster we can get the
document done.

> attributes. Do you think we should add a list of some that should be MTI?
> If so, propose a list.
> ​
>

​None is good.​  Can we make "pt=" optional as well?

> ​

​That could really use an example, because it's not very clear from reading
the text.  Please tell me if my understanding is correct:

If an offerer generates "a=rid:send X pt=*​", does that mean it supports
none of the attributes?  Does it have to put "a=rid:send X pt=*​
max-width=1000000000" to indicate it supports max-width but allows any
value?

If an offerer generates "a=rid:send X pt=*​ max-width=1000000000" and the
answerer doesn't support max-width, can it reply with  "a=rid:recv X
pt=*"?  Because it says in the document currently 'In the case of a syntax
error or an unsupported parameter, the "a=rid" line is removed.', which
seems to indicate it has to remove the RID, even though it's a receiver
that doesn't want to constrain the a=rid line any further.   Why does it
have to remove the a=rid line?

If the end result is that the offerer can put "a=rid:send X" in offer and
the answerer can put "a=rid:recv X" in the answer, then that would be
great, because that's exactly what I think a WebRTC client should be able
to do (use no rid-level attributes and no pt constraints).

---

From: Peter Thatcher <[email-masked]>
Date: Fri, 16 Oct 2015 19:45:05 -0700

On Fri, Oct 16, 2015 at 6:15 PM, Peter Thatcher <[email-masked]>
wrote:

>> the interim call, such as the attributes/constraints an a RID and what's

​I
t appears this was updated in -01 as
​ being optional to offer.  But if offer doesn't contain "pt=" and the
answer adds "pt=" when it wasn't in the offer, does the offerer have to
honor it?  What if the offerer doesn't want to support that?​

> ​That could really use an example, because it's not very clear from
> reading the text.  Please tell me if my understanding is correct:
>

​I​
t appears this was updated in -01 as ​"a=rid:X send max-width".  I like it.
​ ​
We should a
​dd an​
example of
​its use (if there isn't one; did I miss it?)

> have to remove the a=rid line?

​Even in -01 is still says "i
n the case of a syntax
​ ​
error or an unsupported parameter, the "a=rid" line is removed.
"​
​
​  Shouldn't we say that if a parameter is unsupported, the answer may
remove it?  ​

> to do (use no rid-level attributes and no pt constraints).
​
It looks like we're already there in -01 for offering ​"a=rid:send X".

But it doesn't appear you can answer back "a=rid:recv X" to​ "a=rid:send X
max-height" , and it appears that you could respond with "a=rid:recv X
pt=100" to ​"a=rid:send X".

​