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

Magnus Westerlund <magnus.westerlund@ericsson.com> Mon, 15 October 2018 14:40 UTC

Return-Path: <magnus.westerlund@ericsson.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 EB0B2130E80 for <rtcweb@ietfa.amsl.com>; Mon, 15 Oct 2018 07:40:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.65
X-Spam-Level:
X-Spam-Status: No, score=-4.65 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.351, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 IKxydcVIkhHS for <rtcweb@ietfa.amsl.com>; Mon, 15 Oct 2018 07:40:20 -0700 (PDT)
Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5154A130E3E for <rtcweb@ietf.org>; Mon, 15 Oct 2018 07:40:17 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1539614416; x=1542206416; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=hvSdAVPtQDZDxYoFCfpzJiTweXSOmxXt2vVXM/fZ0ok=; b=BHi4KtoePI569GV02nXv34itANrpzbGiyxFF2cS7NPvFypNV21Yn8AGKyWNWaqvD 8p8ZWWPFBrKmgUH+HWmGlG4NR6YoKS+xRVMWkiwwns49M2+8kMoitIfscAPL3jIG EY6iNoVgGsBEymNsj0rd6UIE3iS3oPNrVaRrJ5mAMN8=;
X-AuditID: c1b4fb30-2bbff700000047d2-1b-5bc4a6cf7990
Received: from ESESSMB502.ericsson.se (Unknown_Domain [153.88.183.120]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id FF.81.18386.FC6A4CB5; Mon, 15 Oct 2018 16:40:15 +0200 (CEST)
Received: from [100.94.48.21] (153.88.183.153) by ESESSMB502.ericsson.se (153.88.183.163) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Mon, 15 Oct 2018 16:40:15 +0200
To: Suhas Nandakumar <suhasietf@gmail.com>
CC: rtcweb@ietf.org, draft-ietf-rtcweb-sdp@ietf.org
References: <a061e3cc-4a81-0a1f-ebd5-999e6973bc24@ericsson.com> <CAMRcRGSr=FFbUUA5f3jAh-v+B6UbR2fda-+J-Zihw8pVUsfHmg@mail.gmail.com>
From: Magnus Westerlund <magnus.westerlund@ericsson.com>
Message-ID: <8334a2c9-c2f2-bfff-f51b-b0a561df106d@ericsson.com>
Date: Mon, 15 Oct 2018 16:40:15 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1
MIME-Version: 1.0
In-Reply-To: <CAMRcRGSr=FFbUUA5f3jAh-v+B6UbR2fda-+J-Zihw8pVUsfHmg@mail.gmail.com>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha-256"; boundary="------------ms010506020008060602040705"
X-Originating-IP: [153.88.183.153]
X-ClientProxiedBy: ESESSMB501.ericsson.se (153.88.183.162) To ESESSMB502.ericsson.se (153.88.183.163)
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrPIsWRmVeSWpSXmKPExsUyM2J7he75ZUeiDQ4vt7GYuGIdm8Xaf+3s FjvndjA7MHvsnHWX3WPJkp9MAUxRXDYpqTmZZalF+nYJXBndk7YxFrReYKr4+3QNWwPjjJlM XYycHBICJhIr+qawdzFycQgJHGWUeN75kQ3Cecco8fnsTmaQKmEBd4m9p7pZQGwRAS2J1Yvn gnUzC5hLnJzUD9XdxigxqWUTI0iCTcBC4uaPRjYQm1fAXuLTim9gDSwCqhJzfl8HGyoqECvx 6cpiZogaQYmTM5+ALeAUCJSY/egGK8SCbkaJXcd5QWwhAW2JhqYOVoizlSSuz7sOVM8BZKdL vD7NN4FRcBaSSbOQdEPYYRIbns9lh7DFJW49mc8EYZtJzNv8kBnCVpSY0v0QqIYDyFaTWNaq BBHWlli28DVUibXEjF8H2VCVg9imEq+PfmSEsI0llq37y7aAkWcVo2hxanFSbrqRkV5qUWZy cXF+nl5easkmRmBUHtzy22AH48vnjocYBTgYlXh4leceiRZiTSwrrsw9xKgCNOfRhtUXGKVY 8vLzUpVEeCVCDkUL8aYkVlalFuXHF5XmpBYfYpTmYFES57Xw2xwlJJCeWJKanZpakFoEk2Xi 4JRqYFy0c65Pml6PdtvDZ7UtNUKzhO3ubdNxnvv06/Yn095Wvq2V2dpXU+BXbaCWxVn5ad0m vctHWH0edfe3xTIfMHU+lcrHVnks21JNQKinQfbYsh6p3f/vGm3m+ObyIsNod0n3xt17NY5c 8vPavLOruV+Ca9Z3keWbd6TrSCy65/czaZ36tvvcf5RYijMSDbWYi4oTAUi9EODSAgAA
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtcweb/tBz5ylCCB9rLMNW_-A8kG23TjFE>
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: Mon, 15 Oct 2018 14:40:24 -0000

Hi,

I have looked at the changes in -11. I have some questions.

1. In table 29, section 5.3.2 regarding the H.264-SVC.

    | a=fmtp:100 profile-level-                   | [RFC6190] H.264     |
    | id=53001f;packetization-mode=0              | Scalable Encoding   |

Why are you using packetization-mode=0? For SVC in SST, wouldn't mode=1 
be the most reasonable choice?  Not that it will not work, but putting 
all the meta data NALUs into their own RTP packets seems unnecessary.

2. Table 30, same question as 1)

Otherwise the changes related to my review looks good.

Cheers

Magnus

On 2018-10-10 05:42, Suhas Nandakumar wrote:
> 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 
> <mailto: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 <mailto:magnus.westerlund@ericsson.com>
>     ----------------------------------------------------------------------
>
>     _______________________________________________
>     rtcweb mailing list
>     rtcweb@ietf.org <mailto:rtcweb@ietf.org>
>     https://www.ietf.org/mailman/listinfo/rtcweb
>
-- 

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
----------------------------------------------------------------------