Re: [rtcweb] Review of Section 5.3 of draft-ietf-rtcweb-sdp-10
Suhas Nandakumar <suhasietf@gmail.com> Wed, 10 October 2018 03:42 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 567E6130E5F; Tue, 9 Oct 2018 20:42:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 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] 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 rBcceWbgxt0n; Tue, 9 Oct 2018 20:42:38 -0700 (PDT)
Received: from mail-vs1-xe34.google.com (mail-vs1-xe34.google.com [IPv6:2607:f8b0:4864:20::e34]) (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 F3ABB130E17; Tue, 9 Oct 2018 20:42:34 -0700 (PDT)
Received: by mail-vs1-xe34.google.com with SMTP id e206so3729808vsd.0; Tue, 09 Oct 2018 20:42:34 -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=24Iss1eEH38zlziYMppNQ3Mtwhda70OL+rcYYmq2Bs0=; b=VWMVjh5pTsUDboxd7HY3OFQYxLENfItXutl1USmVaf5ZbyKouXzN6Aqev9MMIM1xqG Ejax2qdOEoQcLiMmEdetssmWV/9vV5ZeRZJvhMjWqqalQrQ6Ftiz+RsB+819bzEKKukZ u5y6jr74lsFfUFLFXBrk4j0bwX/Llld7a37NyBx0iI+8GSovGAdCeF9LStYgQEAOpyth 79kqpUVko4/aAZ/8Br3lzRM/5kaS0NclB6T14Xl71KDJlelpp0IJUdNugOKVbUC9xU2y YRcDkXUnIquKBLXJO4nYDZ8kdxLJDIhgRpZ0y84YJ8mdFmK0dBUqWZR3KFhxPn/thpLZ /rzQ==
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=24Iss1eEH38zlziYMppNQ3Mtwhda70OL+rcYYmq2Bs0=; b=rTCuFFi1xjqqkSN+xmSArY6aSCFcImJlS+UuRR/6ZQxjqXChJTEGD8YRi4Vi3c4eQM v88t0hNVlODnVhPA4Q5WVlKmBMpsfOwbiiGOrmC16M2lMSeKo7CFR0PoxYRxJNSP5CVR zrNOIcCOd9dv+DQdhmuBoLYqI6HKfHJvHxIzB1WoCrqjSk98pa91qB3WcSUKoKlD3NMZ 9pqLAftJD54hUOJ+d45fBUCwCotAgMnpz/b01dNg9Io1z5L3grSgX401i4bscOxs8a2F EhqbUxlJjfIB+LSq9VzdJe+JVOXz/YINa+IVtEVDu6aANU5GMqxzQeIEb+ZcMIyXElgU b3ag==
X-Gm-Message-State: ABuFfoiypgGmVwM6xCt+kX9c5I/As2CnyjSULs0xIj4PXlgK7vm4JoSh OFLdrSJmxkw4mAbilYhOVYLMvc2LbgEgXYfY6GM=
X-Google-Smtp-Source: ACcGV61MHVBBzc7Pa0TlN7Bsyi7NMfsVsnshAy0Xr1xXpWId53eL5t+kq8Ehf3xXQPRbdw0qqEgug8KNEDN1qGOAe0k=
X-Received: by 2002:ab0:1d0d:: with SMTP id j13mr11838325uak.1.1539142953907; Tue, 09 Oct 2018 20:42:33 -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: Tue, 09 Oct 2018 20:42:20 -0700
Message-ID: <CAMRcRGSr=FFbUUA5f3jAh-v+B6UbR2fda-+J-Zihw8pVUsfHmg@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="00000000000006bdf80577d7a533"
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtcweb/RJtse-rWBqt6-2h7hfyCErK8xLQ>
Subject: Re: [rtcweb] Review of Section 5.3 of draft-ietf-rtcweb-sdp-10
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.29
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: Wed, 10 Oct 2018 03:42:42 -0000
Hello Magnus Apologies that this took a while. Please see inline. 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. > > Thanks for the review. I have submitted -11 version that should address the review comments. > > 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. > > [Suhas] Done > 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. > [Suhas] Update the description to mean some examples have FEC/RTX and not all. The idea was to have this section with examples that cover all these cases but not to have all these in all the examples. > > 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. > [Suhas] . The intention was to group one AV in a lip sync group and other can be a non-interactive stream. Updated the text to indicate the same. > 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. > > [Suhas]. Yes, the example wanted to showcase 2 different media sources (one encoded as vp8 and another as h264, can be natively encoded as well) and each being sent at 2 different resolutions. > 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. > [Suhas] Done, updated all the references. > > 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. > [Suhas] Updated. > > 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. > [Suhas] Agreed Magnus. On re-reading the example it confused me as well :-) Update the example to represent SST mode SVC configuration. > > 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. > [Suhas] Good catch. Added it. > > I. Section 5.3.3 > > Why isn't RTX enabled for the audio also? > [Suhas] No Specific reason. These are just examples to show configurations and thus picked MVP configurations to show the usage of SDP for scenario at hand than describing all possible options. > 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. > [Suhas] Thanks for catching this. Matched the answer with the offer now. > > K. Section 5.3.4 Answer: > > | a=rtpmap:101 VP8/90000 | [RFC7741] | > > Wrong media type for the payload should be RTX. > [Suhas] Nice find. Fixed it. > > L. Section 5.3.4 Answer: > > Missing rtcp-fb definitions to enable use of NACK which RTX depends on. > > [Suhas] Agreed. Added it. > > 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. > [Suhas] Good point. Moved to just one PT. Also i think you intend to include repaired-rtp-stream-id for this example too ? > 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 > [Suhas] Dont think its needed. Removed nack and kept pli > > 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