Re: [rtcweb] Review of Section 5.3 of draft-ietf-rtcweb-sdp-10

Suhas Nandakumar <suhasietf@gmail.com> Thu, 26 July 2018 18:27 UTC

Return-Path: <suhasietf@gmail.com>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B1951130DCB; Thu, 26 Jul 2018 11:27:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S9eJt0uFwQmt; Thu, 26 Jul 2018 11:27:56 -0700 (PDT)
Received: from mail-vk0-x22e.google.com (mail-vk0-x22e.google.com [IPv6:2607:f8b0:400c:c05::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BB125124D68; Thu, 26 Jul 2018 11:27:55 -0700 (PDT)
Received: by mail-vk0-x22e.google.com with SMTP id 125-v6so1261228vke.11; Thu, 26 Jul 2018 11:27:55 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=h81W/pqKM/YMOBcIoib3xS/Z+RAQ9j9W2xZ2Zdi1fuY=; b=cjxvpIlWW+TuAO7zmITvVsRpX/AsCCwO5hvasVms58Wgat9X0ZG4k/v4WZZixg00aO /jdxTLLS1mCHE77f/HNQAlDKHuwCPGynhIW1nohYRCy6xU3ivzWv2yKHhbRfCt86DuBJ yWqlr4iiW0vG8apPn+5yqPSmeWe6OmMBYWUh428d5Rj4/1RYsTva17Zs8n2FPbKibsaW mqSeqnN0eMA8L5fv6zt4gbsDQ14mnHcbD78VKb1dI9t9RsuGH4wsIcSBbpJl3DZmBCdZ 4+JAmDvZ3Em5E7adlarrFFYCwHVFjIN/xYyeJEvoiadkIyWKgkIrYOXNucF3X4LbNG46 AygQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=h81W/pqKM/YMOBcIoib3xS/Z+RAQ9j9W2xZ2Zdi1fuY=; b=BdKCMe7qMoZDFotOAo1reOxpc1EHQmMwS4b40lI7AyE/wvN8f6TqpxDyANc6w/K7/f zlEy1bG9q97OpfsLTnJlGSWfZWo7rrU+tlkoe67VrdRZJkWKdueQNEAkXvDdtLegQzzf 8Vqxg++MdKEnJZA7VS/ClL3i9VRA0r1zcYvSedoN4RD7Xb/tdSgQ2YOpmpgKlXFLuP0n HkQIupTF0rnQCNyjEiL2lPmeJb84+6z9Jb/a+wZUFjQcvooWsRgPIiHEwN3TjF+vVVys l+KBTOneh84ctzTdNAFuqBdVAeqQRG+tjWRUyqaFyatvQTpgVPD4J07/UtWFRcu2c+1p 9WIA==
X-Gm-Message-State: AOUpUlHs6pBC/2LJviVQS+QvPiKjhPMDZv9NfizHgLmVbp/E+6sZOTC3 dlLnPWcyvJbxKWGgy60YwiDuLRKxe4mZILrhcKY=
X-Google-Smtp-Source: AAOMgpcsBM5Rr4Yr7ALWgTcqfSJjx1M5sVM03nhTXN8BPpNPG1R/fjYqr9d2+XSTmKRxzgLyaEItIZm1YPXWSMKRd9Q=
X-Received: by 2002:a1f:26ce:: with SMTP id m197-v6mr1924190vkm.115.1532629674749; Thu, 26 Jul 2018 11:27:54 -0700 (PDT)
MIME-Version: 1.0
References: <a061e3cc-4a81-0a1f-ebd5-999e6973bc24@ericsson.com>
In-Reply-To: <a061e3cc-4a81-0a1f-ebd5-999e6973bc24@ericsson.com>
From: Suhas Nandakumar <suhasietf@gmail.com>
Date: Thu, 26 Jul 2018 11:27:43 -0700
Message-ID: <CAMRcRGQ_ywf97i5XorXHOjQsXkjvVz8vtBM2ZyBR726fFiPZ7A@mail.gmail.com>
To: Magnus Westerlund <magnus.westerlund@ericsson.com>
Cc: rtcweb@ietf.org, draft-ietf-rtcweb-sdp@ietf.org
Content-Type: multipart/alternative; boundary="00000000000056047d0571eb279e"
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtcweb/W4s6ICv4HRGv9hFfDbIr5M_ik1I>
Subject: Re: [rtcweb] Review of Section 5.3 of draft-ietf-rtcweb-sdp-10
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.27
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <rtcweb.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rtcweb/>
List-Post: <mailto:rtcweb@ietf.org>
List-Help: <mailto:rtcweb-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 26 Jul 2018 18:28:00 -0000

Hello Magnus

 Thanks for the review. We will be working on your comments soon and post
an update.


cheers
Suhas

On Wed, Jul 4, 2018 at 7:57 AM Magnus Westerlund <
magnus.westerlund@ericsson.com> wrote:

> Hi,
>
> I have reviewed Section 5.3 only with a focus on the simulcast and
> multi-stream aspects. For example I have not cared if the ICE details
> are correct in these examples.
>
>
> A. Section 5.3.1:
>
> BUNDLE grouping framework enables multiplexing of all the 5 streams
>     (1 audio stream + 4 video streams) over a single RTP Session.
>
> It might be good to use RFC 7656 terminology and be specific in that
> this results in 5 source RTP streams.
>
> B. Section 5.3.1.
>
> As 5.3 says that this will use FEC or RTX and this one doesn't maybe be
> explicit that it is not added, or rewrite 5.3.
>
> C. section 5.3.1:
>
>     | a=group:LS m0 m1                            | [RFC5888]           |
>
> Is it intentional that video 2 is not included in the lip-synch group?
> May require a intention comment for this case.
>
> D. 5.3.1:
>
>     One video source corresponds to VP8 encoding, while the other
>     corresponds to H.264 encoding.
>
> As the m= block represents a media source, if the need is to provide one
> video camera's images (the media  source) as both VP8 and H.264 where
> each are in two different resolutions, then simulcast can handle that
> fine within a single m= block. So from my perspective this is a wrongly
> constructed example from that premise. Can you please clarify if you
> want two media source, i.e. two cameras, or two encoder formats VP8 and
> H.264, or two resolutions, or any combination of them?
>
> I would recommend this example to be two media sources, with encoding
> simulcast. The resolution can be skipped as the later example includes
> resolution simulcasting.
>
> E. Section 5.3.1:
>
>     | a=rtcp-fb:* nack                            | [RFC5104]           |
>
>     | a=rtcp-fb:* nack pli                        | [RFC5104]           |
>
> I would note that generalized NACK as well as picture loss indication
> (PLI) is defined in RFC4585.
>
> F. Section 5.3.2:
>
>     This section shows an SDP Offer/Answer for a session with an audio
>     and a single video source.  The video source is encoded as layered
>     coding at 3 different resolutions based on [RFC5583].  The video
>     m=line shows 3 streams with last stream (payload 100) dependent on
>     streams with payload 96 and 97 for decoding.
>
> Also here use of RFC 7656 terminology to talk about (source) RTP streams
> when applicable would be good.
>
> G. Section 5.3.2:
>
>    | a=rtpmap:96 H264/90000                      | [RFC6184]           |
>     | a=fmtp:96 profile-level-id=4d0028;          | [RFC6184]H.264      |
>     | packetization-mode=1;max-fr=30;max-fs=8040  | Layer 1             |
>     | a=rtpmap:97 H264/90000                      | [RFC6184]           |
>     | a=fmtp:97 profile-level-                    | [RFC6184] H.264     |
>     | id=4d0028;packetization-mode=1; max-        | Layer 2             |
>     | fr=15;max-fs=1200 |                     |
>     | a=rtpmap:100 H264-SVC/90000                 | [RFC6184]           |
>     | a=fmtp:100 profile-level-                   | [RFC6184]           |
>     | id=4d0028;packetization-mode=1; max- |                     |
>     | fr=30;max-fs=8040 |                     |
>     | a=depend:100 lay m1:96,97                   | [RFC5583]Layer 3    |
>
> I have my doubts about this configuration. First of all as it is SVC in
> Single RTP session mode (SST) I don't think it results in multiple RTP
> streams. I think the answerer will interpret this, which of these
> encodings can support. A non scalable H.264, another non-scalable H.264
> or SVC that can contain a number of layers.
>
> Secondly a=depend is only defined for MST mode in RFC 6190.
>
> You also have the wrong reference for the H-264-SVC a=rtpmap and a=fmtp
> line.
>
> H. Section 5.3.3:
>
>     | a=extmap:3 urn:ietf:params:rtp-             | [I-D.ietf-avtext-ri |
>     | hdrext:sdes:rtp-stream-id                   | d]                  |
>
> After this line you should have also this line:
>
>     | a=extmap:4 urn:ietf:params:rtp-             | [I-D.ietf-avtext-ri |
>     | hdrext:sdes:repaired-rtp-stream-id                   |
> d]                  |
>
> This to enable the RTX streams to indicate which source RTP stream they
> are repairing. Add to both offer and answer.
>
> I. Section 5.3.3
>
> Why isn't RTX enabled for the audio also?
>
> J. Section 5.3.3. Answer:
>
>    | m=video 0 UDP/TLS/RTP/SAVPF 98 100 101 103  | BUNDLE accepted     |
>
> Payload types 100 and 101 are undefined in this media description.
>
> K. Section 5.3.4 Answer:
>
>     | a=rtpmap:101 VP8/90000                      | [RFC7741]           |
>
> Wrong media type for the payload should be RTX.
>
> L. Section 5.3.4 Answer:
>
> Missing rtcp-fb definitions to enable use of NACK which RTX depends on.
>
>
> M. Section 5.3.5:
>
>   | a=fmtp:101 L=5; D=10; ToP=2; repair-        | [I-D.ietf-payload-f |
>     | window=200000                               | lexible-fec-scheme] |
>     | a=fmtp:103 L=5; D=10; ToP=2; repair-        | [I-D.ietf-payload-f |
>     | window=200000                               | lexible-fec-scheme] |
>
> As the parameters are the same, I don't see a point with having two
> payload types. Two different RTP repair streams can use the same payload
> type. As Flex-FEC can do all the binding using the CSRC field, there are
> also no need to have the repaired-rtp-stream-id header extension for
> this one.
>
> N. Section 5.3.5:
>
> Does it make sense to still have NACK for a session with FEC. If it
> fails isn't PLI or FIR
>
> Cheers
>
> Magnus Westerlund
>
> ----------------------------------------------------------------------
> Network Architecture & Protocols, Ericsson Research
> ----------------------------------------------------------------------
> Ericsson AB                 | Phone  +46 10 7148287
> Torshamnsgatan 23           | Mobile +46 73 0949079
> SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com
> ----------------------------------------------------------------------
>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
>