Subject: Re: [MMUSIC] Simulcast: Short timelines, draft impending

From: Harald Alvestrand <[email-masked]>
Date: Thu, 1 Oct 2015 14:05:45 +0200

While waiting for the draft, one thing that puzzled me on third reading
through this proposal:

On 09/25/2015 04:34 AM, Adam Roach wrote:
>
>  *
>
>    RIDs can be defined to be unidirectional, so as to allow
>    implementations to signal the ability to send a different number of
>    encodings than they can receive.
>
>  *
>
>    The values for each constraint can be specified to be different in
>    each direction.
>
>
>  *
>
>    The values (that is, identifiers) used for RID are proposed by the
>    offerer in a session, and are symmetric. The RID values in an answer
>    must be a subset of those present in the offer.

I'm a bit confused. How do we have unidirectional but symmetric RIDs?

If the answerer thinks that it is going to need more RIDs than the
offerer proposes, is he required to start a renegotiation to get what he
wants?

Spinoff from that: Is it, in general, possible to add more RIDs at
renegotiation time?

This may be obvious once the draft arrives.

---

From: Byron Campen <[email-masked]>
Date: Thu, 1 Oct 2015 10:38:37 -0500

> offerer proposes, is he required to start a renegotiation to get what he
    Yes. If the offerer has offered to send 3 RIDs, there is no reason 
for the answerer to expect that 4 would be a possible value. Similarly, 
if the offerer has offered to receive 3 RIDs, there is no reason for the 
answerer to expect that 4 would be something that the offerer could make 
use of. The general pattern here is offer what you can send, and what 
you would like to receive, and the answerer can downnegotiate as it sees 
fit.
> Spinoff from that: Is it, in general, possible to add more RIDs at
    Yes.

Best regards,
Byron Campen

---

From: Suhas Nandakumar <[email-masked]>
Date: Fri, 2 Oct 2015 15:48:06 -0700

Hello All

   As indicated by Adam in his email , we have submitted the draft defining
"RID".

   The draft can be found here:
https://datatracker.ietf.org/doc/draft-pthatcher-mmusic-rid/?include_text=1

   Please provide your feedback on the same.

Thanks
Suhas

On Thu, Sep 24, 2015 at 7:34 PM, Adam Roach <[email-masked]> wrote:

> At the W3C WebRTC interim meeting a couple of weeks ago, one of the issues
> that the group was not able to resolve was how to enable the use of
> simulcast for WebRTC browser implementations. A key point of contention was
> the use of unique payload types for each simulcast encoding in the current
> MMUSIC document (draft-ietf-mmusic-sdp-simulcast-01). Combined with the
> other features planned for WebRTC, there is concern that such an approach
> may lead to PT exhaustion within a session under certain reasonably
> expected circumstances.
>
>
> As important context: the WebRTC 1.0 specification is rapidly approaching
> finalization, and the working group hopes to leave the TPAC meeting at the
> end of October with all of the loose ends tied up. Simulcast is one of the
> more important and one of the most loose ends in the specification at the
> moment. As a result, we sincerely hope that we can come to consensus on a
> viable approach in MMUSIC over the next few weeks. To be explicit: the TPAC
> meeting is the week before the Yokohama IETF meeting, so we cannot afford
> to wait for the ordinary meeting-driven work schedule to push simulcast
> along. We hope to foster a useful and productive conversation on the
> mailing list well ahead of IETF 94.
>
>
> While there were some “hallway discussions” in Prague to discuss potential
> approaches that would address these concerns, none of these have yet been
> documented and shared with the mailing list.
>
>
> After significant conversations both at and after the interim WebRTC
> meeting, and considering information about the type of solutions that
> interested parties are likely to find acceptable, a number of the WebRTC
> participants have come up with a tentative proposal that we believe is
> likely to be simple, flexible, and satisfactory to everyone involved. At a
> high level:
>
>
>  *
>
>    The current behavior described in the MMUSIC simulcast draft remains
>    valid.
>
>  *
>
>    Additionally, we define a new attribute type (provisionally called
>    “RID”, for “RTP Stream ID”) that can be used to define additional
>    codec-independent constraints on PTs (e.g., max-fps, max-bps,
>    max-width, max-height).
>
>  *
>
>    When used, the RID value is encoded as part of the RTP packet, in an
>    extension header.
>
>  *
>
>    The parameters associated with a RID can be made more restrictive
>    (i.e., resolution decreased, bandwidth decreased), but not less
>    restrictive, in an answer.
>
>  *
>
>    For those sessions that use RIDs, the “a=simulcast” parameter is
>    enhanced to be able to carry RIDs instead of PTs.
>
>
> We hope to have an internet-draft that describes this approach in more
> detail by the end of next week.
>
> /a
>
> _______________________________________________
> mmusic mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mmusic
>

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 5 Oct 2015 12:22:29 -0400

Here are some comments on draft-pthatcher-mmusic-rid-00 that I made 
during my initial reading:

* Section 6:

All of the parameters mentioned pertain to video.

Perhaps it should be mentioned that these must only be used with 
compatible codecs. This is hinted at in section 7.2.2, but isn't very 
explicit.

It might also be good to mention that parameters meaningful for 
non-video codecs may be defined in the future.

In addition to the parameters listed here, there is another ('depend') 
that is mentioned in a few places. The closest thing to a real 
definition of the semantics of if are in section 10.3. I think there 
ought to be an explicit definition of it here - or at least a mention 
with a cross reference to the section where it is defined.

* Section 7.2.2:

Bullet 2 requires that any pt mentioned in a=rid must also be mentioned 
in an a=rtpmap or a=fmtp attribute. Did you intend to exclude the use of 
default PTs - that generally work without rtpmap or fmtp? Wouldn't it be 
better here to simply require that the PT in the rid line also be 
mentioned in the m-line? (I realize that default PTs are only for audio, 
and there is currently no need for rid with audio, but that might not 
always be the case.)

* Section 7.3:

Each rid line in the offer has a direction of send or recv. Presumably 
that is from the perspective of the sender of the sdp. I would expect 
(and the examples show) that in the answer each send would be changed to 
recv and visa versa. But this isn't mentioned.

In the case of errors, the rule is to omit the rid line for the rid in 
the answer. The effect of this is to process the media stream as if 
there were no rid constraints. It might be good to mention that if the 
answerer doesn't want to handle the media stream, or the specific PTs 
involved, without any rid constraints, then it should reject the m-line, 
or omit the affected PTs from the m-line in the answer.

rid-fmt allows the general 'fmt' syntax from 4566. That allows 
non-numeric values for non-rtp transports, but requires numeric PT 
values for RTP. Since rid applies only to RTP, the syntax here could be 
restricted to numeric PT formats.

* Section 9:

This doesn't quite conform to the pattern introduced in rfc4566bis. (It 
is not good to include "a=" in the syntax definition for individual 
attributes.) I suggest replacing the rid-syntax line with:

   rid-value = rid-identifier SP rid-dir SP rid-fmt-list SP rid-attr-list

(And also see my comment on section 12.2.)

The syntax of rid-identifier permits '-----', '-_" and other similar 
non-human-friendly identifiers. It might be good to limit this (for 
readability). E.g.

   rid-identifier = 1*alpha-numeric *(("-" / "_") 1*alpha-numeric)

The 'pt=' is entirely redundant. (The rid-fmt-list can be identified 
positionally.) Why is it there?

There seems to be some ambivalence in the text whether you are defining 
rid *attributes* or rid *parameters. In section 6 they are called 
parameters. Here there is a rid-attr-list but the elements of the list 
are called rid-xxx-param. Can you please decide on one term for these 
that stick to it?

* Section 10.*:

The a=rid lines in most/all of the examples are inconsistent with the 
syntax. E.g. The following:

    a=rid:1 send pt=*; max-width=1280; max-height=720; max-fps=30

ought to be:

    a=rid:1 send pt=* max-width=1280;max-height=720;max-fps=30

* Section 10.1:

This example shows that the proposed mechanism isn't ideal for this 
case. There are a *lot* of duplicated sdp lines devoted to specifying 
the identical attributes for multiple rid values. It seems like there 
ought to be syntax to avoid that redundancy.

* Section 12.2:

This doesn't quite conform the the pattern introduced in rfc4566bis.

I suggest the following:

    This document defines "rid" as SDP media-level attribute. The
    "rid" attribute is used to identify characteristics of RTP stream
    with in a RTP Session.

    Name: rid

    Value: rid-value

    Usage Level: media

    Charset Dependent: possibly

       This attribute is generally not charset dependent.
       However individual rid-level-attributes may be defined
       to be charset dependent.

    Syntax:

          See section 9.

    Example:

          a=rid:1 send pt=* max-width=1280;max-height=720;max-fps=30

* Section 12.3:

I'm still unclear of the relationship between rid-level attributes and 
other (session/media) attributes. Those others, regardless of the levels 
they apply to, belong to a single namespace. Do rid attributes occupy 
another level within the same namespace, or do they define a new namespace?

If they occupy a new namespace, it would be valid to define a rid-level 
attribute with the same name as (for example) a media-level attribute. 
That would be very confusing.

	Thanks,
	Paul

On 10/2/15 6:48 PM, Suhas Nandakumar wrote:
> Hello All
>
>     As indicated by Adam in his email , we have submitted the draft
> defining "RID".
>

---

From: Flemming Andreasen <[email-masked]>
Date: Tue, 6 Oct 2015 07:42:44 -0400

Thank you for submitting the draft. Will there be an update to the 
simulcast draft as well before the Interim meeting next week ?

-- Flemming

On 10/2/15 6:48 PM, Suhas Nandakumar wrote:
> On Thu, Sep 24, 2015 at 7:34 PM, Adam Roach <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     At the W3C WebRTC interim meeting a couple of weeks ago, one of
>     the issues that the group was not able to resolve was how to
>     enable the use of simulcast for WebRTC browser implementations. A
>     key point of contention was the use of unique payload types for
>     each simulcast encoding in the current MMUSIC document
>     (draft-ietf-mmusic-sdp-simulcast-01). Combined with the other
>     features planned for WebRTC, there is concern that such an
>     approach may lead to PT exhaustion within a session under certain
>     reasonably expected circumstances.
>
>
>     As important context: the WebRTC 1.0 specification is rapidly
>     approaching finalization, and the working group hopes to leave the
>     TPAC meeting at the end of October with all of the loose ends tied
>     up. Simulcast is one of the more important and one of the most
>     loose ends in the specification at the moment. As a result, we
>     sincerely hope that we can come to consensus on a viable approach
>     in MMUSIC over the next few weeks. To be explicit: the TPAC
>     meeting is the week before the Yokohama IETF meeting, so we cannot
>     afford to wait for the ordinary meeting-driven work schedule to
>     push simulcast along. We hope to foster a useful and productive
>     conversation on the mailing list well ahead of IETF 94.
>
>
>     While there were some “hallway discussions” in Prague to discuss
>     potential approaches that would address these concerns, none of
>     these have yet been documented and shared with the mailing list.
>
>
>     After significant conversations both at and after the interim
>     WebRTC meeting, and considering information about the type of
>     solutions that interested parties are likely to find acceptable, a
>     number of the WebRTC participants have come up with a tentative
>     proposal that we believe is likely to be simple, flexible, and
>     satisfactory to everyone involved. At a high level:
>
>
>      *
>
>     We hope to have an internet-draft that describes this approach in
>     more detail by the end of next week.
>
>     /a
>
>     [email-masked] <mailto:[email-masked]>

---

From: Magnus Westerlund <[email-masked]>
Date: Tue, 6 Oct 2015 13:49:33 +0200

> simulcast draft as well before the Interim meeting next week ?

Yes, hopefully later today. The changes in the simulcast is relatively 
minor as most of the open issues from simulcast perspective ends up in 
the RID draft. There are some open issues that need discussion, but an 
email on that will follow the submission.

cheers

Magnus Westerlund

----------------------------------------------------------------------
Services, Media and Network features, Ericsson Research EAB/TXM
----------------------------------------------------------------------
Ericsson AB                 | Phone  +46 10 7148287
Färögatan 6                 | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden | mailto: [email-masked]
----------------------------------------------------------------------

---

From: Flemming Andreasen <[email-masked]>
Date: Tue, 6 Oct 2015 07:57:51 -0400

Thanks - please make sure to get the updated draft and open issues sent 
out as soon as possible so people have time to digest and discuss before 
the virtual Interim. We would like to give people at least 1 week for 
this before the meeting.

-- Flemming

On 10/6/15 7:49 AM, Magnus Westerlund wrote:
> .

---

From: Byron Campen <[email-masked]>
Date: Thu, 8 Oct 2015 12:47:07 -0500

>    a=rid:1 send pt=* max-width=1280;max-height=720;max-fps=30
   Actually, it is worse than this; the grammar does not permit more than
one of "max-width", "max-height", etc. Also, the use of <param-val> (aka
<byte-string>) as the values of things like max-width precludes the use of
any delimiter, since param-val can contain anything except NUL, CR, and LF.
Things like max-width really should be a positive integer, so the grammar
will need to be tightened down. I'm guessing that what the author was
shooting for was ';' delimited, with positive integer values for everything
but depend=.

   Also, I would expect that stuff like pt=*,96,8,* is not permitted, but
the current grammar permits it.

Best regards,
Byron Campen

---

From: Byron Campen <[email-masked]>
Date: Thu, 8 Oct 2015 15:52:40 -0500

Some additional feedback on the grammar:

- The use of ';' as a delimiter for rid-list complicates the parse code if
';' is also used as a delimiter for rid-attr-list. For example, consider:

a=rid:3 send pt=96 depend=1;2;max-fps=30
vs
a=rid:3 send pt=96 depend=1,2;max-fps=30

- There does not seem to be anywhere for extensions to rid-attr-list to
hook in. We should make room for that, and forbid any such extensions from
using ';' since that is reserved as a delimiter.

- There is an example where max-br takes no value:

a=rid:1 send pt=97; max-br=; max-height=720;

   Is this intended?

Best regards,
Byron Campen

---

From: Byron Campen <[email-masked]>
Date: Thu, 8 Oct 2015 16:36:13 -0500

Yet more feedback; using ';' as a delimiter for rid-fmt-list could lead
to some confusion:

a=rid:1 send pt=96;97;98;max-width=800

   It would probably be good to avoid the use of ';' as a delimiter here
too.

Best regards,
Byron Campen