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 >
- [rtcweb] Review of Section 5.3 of draft-ietf-rtcw… Magnus Westerlund
- Re: [rtcweb] Review of Section 5.3 of draft-ietf-… Suhas Nandakumar
- Re: [rtcweb] Review of Section 5.3 of draft-ietf-… Suhas Nandakumar
- Re: [rtcweb] Review of Section 5.3 of draft-ietf-… Magnus Westerlund