[MMUSIC] Adam Roach's Discuss on draft-ietf-mmusic-sdp-simulcast-12: (with DISCUSS and COMMENT)

Adam Roach <adam@nostrum.com> Wed, 20 June 2018 02:43 UTC

Return-Path: <adam@nostrum.com>
X-Original-To: mmusic@ietf.org
Delivered-To: mmusic@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 45A6C130DC9; Tue, 19 Jun 2018 19:43:15 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: Adam Roach <adam@nostrum.com>
To: The IESG <iesg@ietf.org>
Cc: draft-ietf-mmusic-sdp-simulcast@ietf.org, mmusic-chairs@ietf.org, fandreas@cisco.com, mmusic@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.81.2
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <152946259524.32242.17779655314097598295.idtracker@ietfa.amsl.com>
Date: Tue, 19 Jun 2018 19:43:15 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/mmusic/YLNo6YSPKLFcNQg03te5qth5qMw>
Subject: [MMUSIC] Adam Roach's Discuss on draft-ietf-mmusic-sdp-simulcast-12: (with DISCUSS and COMMENT)
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.26
List-Id: Multiparty Multimedia Session Control Working Group <mmusic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mmusic>, <mailto:mmusic-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/mmusic/>
List-Post: <mailto:mmusic@ietf.org>
List-Help: <mailto:mmusic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 20 Jun 2018 02:43:16 -0000

Adam Roach has entered the following ballot position for
draft-ietf-mmusic-sdp-simulcast-12: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-mmusic-sdp-simulcast/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

Thanks to everyone who put in the hard work to make this document happen. I have
found a blocking issue that I believe should be easy to address; but (due to the
potential impact on interoperability) document publication does need to be
blocked pending resolution of this issue. The problem is that the SDP examples
in this document are not consistent with the syntax and semantics defined in
draft-ietf-mmusic and draft-ietf-avtext-rid, as described below.

---------------------------------------------------------------------------

§4, Figure 1:

>  a=rid:1 send pt=97 max-width=1280;max-height=720
>  a=rid:2 send pt=98 max-width=320;max-height=180
>  a=rid:3 send pt=99 max-width=320;max-height=180
>  a=rid:4 recv pt=97

The final syntax for RID ended up with PT being treated the same as other
parameters, and therefore requiring a semicolon delimiter between it and
stream restrictions. So this example should read:

   a=rid:1 send pt=97;max-width=1280;max-height=720
   a=rid:2 send pt=98;max-width=320;max-height=180
   a=rid:3 send pt=99;max-width=320;max-height=180
   a=rid:4 recv pt=97

---------------------------------------------------------------------------

§4, Figure 1:

>  a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:RtpStreamId

Although the SDES item is called "RtpStreamId," the URN registered for its
identification is urn:ietf:params:rtp-hdrext:sdes:rtp-stream-id -- see section
4.3 of draft-ietf-avtext-rid. This example should read:

   a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:rtp-stream-id

---------------------------------------------------------------------------


The preceding two comments regarding SDP syntax also apply to Figure 2,
Figure 5, Figure 6, Figure 7, and Figure 8.

---------------------------------------------------------------------------

Figure 8 (which is missing a figure label):

>  a=rid:5 send pt=99,102;max-br=64000
>  a=rid:6 send pt=100,97,101,102

The selection of "5" and "6" for these RIDs goes against the advice in section
3.3 of draft-ietf-avtext-rid; and, even worse, may give the incorrect impression
that RID space is shared between media sections. Please adjust them to be 1 and
2 instead of 5 and 6.

Also, if LPC is intended to be used with the first RID (as is suggested by the
text above the example), then your "pt" value needs to be "pt=99,102,98" --
otherwise, the RID will prevent the use of PT 98. Remember: RID defines
*restrictions*. If you say "pt" and then don't list a PT in it, then that
missing PT is strictly forbidden from appearing with that RID.

There is a similar problem with the video section, which needs to read as
follows to match the explanatory text:

   a=rid:1 send pt=103,105,107;max-width=1280;max-height=720;max-fps=30
   a=rid:2 send pt=104,106,107;max-width=1280;max-height=720;max-fps=30
   a=rid:3 send pt=103,105,107;max-width=640;max-height=360;max-br=300000
   a=rid:4 send pt=104,106,107;max-width=640;max-height=360;max-br=300000


----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

I will be recusing myself from a ballot position once the preceding issues
have been resolved, as I am a contributor to this document. I found some minor
issues and a number of editorial nits that warrant correction prior to
publication.

---------------------------------------------------------------------------

§1:

>  Usage of multicast or broadcast transport is out of scope and left
>  for future extension.

"...future extensions."

---------------------------------------------------------------------------
§1:

>  This document describes a few scenarios that motivates the use of

"...that motivate the use..."

---------------------------------------------------------------------------

§3:

>  There are two principle approaches for an RTP Mixer to provide this

"...two principal approaches..."

---------------------------------------------------------------------------

§5.1:

>   sc-send      = "send" SP sc-str-list
>   sc-recv      = "recv" SP sc-str-list

While it's a bit muddled in the base SDP spec, it appears that the general
convention here is to make SDP strings case-sensitive. I believe this document
wants to cite RFC 7405, and adjust these two lines to read:

    sc-send      = %s"send" SP sc-str-list
    sc-recv      = %s"recv" SP sc-str-list

---------------------------------------------------------------------------

§5.2:

>  there is currently no mechanism for align the choice between
>  alternative rid-ids between different simulcast streams.

"...mechanism to align..."

---------------------------------------------------------------------------

Figure 7:

>  m=video 49602 RTP/AVPF 96 104
>  a=mid:zen
>  a=rtpmap:96 VP8/90000
>  a=fmtp:96 max-fs=3600; max-fr=30
>  a=rtpmap:104 rtx/90000
>  a=fmtp:104 apt=96;rtx-time=200
>  a=rid:1 send pt=96;max-fs=921600;max-fps=30
>  a=rid:2 send pt=96;max-fs=614400;max-fps=15
>  a=rid:3 send pt=96;max-fs=230400;max-fps=30
>  a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid
>  a=extmap:2 urn:ietf:params:rtp-hdrext:sdes:RtpStreamId
>  a=rtcp-fb:* ccm pause nowait
>  a=simulcast:send 1;~2;~3

While this isn't technically invalid (modulo the extmap lines), it's saying
something a bit odd. Namely, it's offering to use RTX if the answerer doesn't
understand RID, but forbidding the use of RTX if they do. You probably meant
something more like:

   a=rid:1 send pt=96,104;max-fs=921600;max-fps=30
   a=rid:2 send pt=96,104;max-fs=614400;max-fps=15
   a=rid:3 send pt=96,104;max-fs=230400;max-fps=30

Or, really, since that's all the PTs that are defined for this media section,
just leave it out altogether:

   a=rid:1 send max-fs=921600;max-fps=30
   a=rid:2 send max-fs=614400;max-fps=15
   a=rid:3 send max-fs=230400;max-fps=30

Either way is valid and sensible -- the second might be a better example,
since it demonstrates the use of simulcast without payload-restricted RID
lines. You don't want to give the erroneous impression that "pt" is required
on the RID line for simulcast to work.