Subject: [MMUSIC] Review of draft-ietf-mmusic-sdp-simulcast-05

From: Magnus Westerlund <[email-masked]>
Date: Mon, 26 Sep 2016 11:26:13 +0200

Hi,

So I am one of the authors, but I have not actually reviewed the 
complete document in a while so therefore I thought it important to 
perform this review. I want my comments and feedback to be public 
comments also so that we can discuss them in the whole WG.

My summary are that this document is not yet ready to request 
publication for. Several significant issues needs to be addressed.

1. Section 2.1:
This document makes use of the terminology defined in RTP Taxonomy
     [RFC7656], and RTP Topologies [RFC7667].  In addition, the following
     terms are used:

"In addition" is not right here due to the first item in list below.

2. Section 4:

       Editor's note: Consider adding an explicit requirement that the
       solution supports use of simulcast even when using multiple codecs
       and multiple redundant RTP streams per defined codec (or something
       similar), since this is really an existing requirement and should
       also fully motivate the use of RID as identification mechanism.

Should this editor's note simply be removed? Or do we want to be 
explicit about this requirement and add text?

3. Section 6.1:

    In the list of simulcast streams, each SCID is separated by a
    semicolon (";").

The paragraph with the above text and the previous one is confusing in 
its usage of simulcast streams and SCID. The SCID is one particular 
simulcast stream format, while in an offer the list between two ;, i.e. 
sc-alt-list can be a set of offered alternative simulcast formats for a 
particular simulcast stream. This should be rewritten to be clearer on 
what it means.

   "The "a=simulcast" attribute has a parameter in the form of one or two
    simulcast stream descriptions, each consisting of a direction ("send"
    or "recv"), followed by a list of one or more simulcast streams."

I note that the equivalent to "sc-value" is not a simulcast stream, 
rather something else, maybe simulcast stream set description.

4. Section 6.4:

This section will have to be removed as RID lacks declarative support 
and thus this simulcast specification can't support it either. It there 
exist sufficient interest then extension specifications will have to be 
written.

5. Section 7: RTP Middlebox handling and RTP receiver requirements

When using simulcast and the RTP middlebox performs switching operations 
the resulting middlebox to receiver RTP streams can have different 
characteristics. Based on discussion in Berlin there need to exist a 
specification for what behaviors that are acceptable and expected. This 
needs to be added either here or in a separate document.

6. Section 13.1:

RFC5109, RFC7741 can be moved to informational list.

[I-D.ietf-mmusic-sdp-bundle-negotiation] i think actually belongs on the 
normative from the importance of it, even if the actual references are 
not strictly normative versions. But, there are so many important relations.

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: Ron Even <[email-masked]>
Date: Tue, 27 Sep 2016 01:44:52 +0300

Hi,
I also wondered why vp8 is normative reference and h.264 informative, they
are all informative.

I am not sure what is requirement 2 inspection 4, especially 2.1 and how it
relates to simulcast
Roni

On Monday, September 26, 2016, Magnus Westerlund <
[email-masked]> wrote:

> Hi,
>
> So I am one of the authors, but I have not actually reviewed the complete
> document in a while so therefore I thought it important to perform this
> review. I want my comments and feedback to be public comments also so that
> we can discuss them in the whole WG.
>
> My summary are that this document is not yet ready to request publication
> for. Several significant issues needs to be addressed.
>
> 1. Section 2.1:
> Should this editor's note simply be removed? Or do we want to be explicit
> about this requirement and add text?
>
> 3. Section 6.1:
>
> The paragraph with the above text and the previous one is confusing in its
> usage of simulcast streams and SCID. The SCID is one particular simulcast
> stream format, while in an offer the list between two ;, i.e. sc-alt-list
> can be a set of offered alternative simulcast formats for a particular
> simulcast stream. This should be rewritten to be clearer on what it means.
>
> I note that the equivalent to "sc-value" is not a simulcast stream, rather
> something else, maybe simulcast stream set description.
>
> 4. Section 6.4:
>
> This section will have to be removed as RID lacks declarative support and
> thus this simulcast specification can't support it either. It there exist
> sufficient interest then extension specifications will have to be written.
>
> normative from the importance of it, even if the actual references are not
> strictly normative versions. But, there are so many important relations.
>
> Cheers
>
> Magnus Westerlund
>
> _______________________________________________
> mmusic mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mmusic
>