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

Magnus Westerlund <magnus.westerlund@ericsson.com> Wed, 04 July 2018 14:57 UTC

Return-Path: <magnus.westerlund@ericsson.com>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 80484130DED for <rtcweb@ietfa.amsl.com>; Wed, 4 Jul 2018 07:57:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.31
X-Spam-Status: No, score=-4.31 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, 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 ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id flnDubrn50Pi for <rtcweb@ietfa.amsl.com>; Wed, 4 Jul 2018 07:57:02 -0700 (PDT)
Received: from sessmg23.ericsson.net (sessmg23.ericsson.net []) (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 E93BC12F1AC for <rtcweb@ietf.org>; Wed, 4 Jul 2018 07:57:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1530716215; 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=GRhPQxjedQT4K6Mett+cpCSBxV0hTHk95xM759d2uME=; b=VpPxCGVdHoizHmhEC1FQ3e8sPo+mRpoeGhqNpvk627+LqNOLBqnu6cVvjGOZI+82 4KHgsyM9YmHuwSA9Voj7iFSxSPJaprQr6Q90LvVu3S3weiL/AflRoBTiATywem4A U/Yfw1Y7o4HcpE1nzjxgegUDiEmA0JRZUzb31jE7zto=;
X-AuditID: c1b4fb2d-223ff700000055ff-b8-5b3ce037b2ee
Received: from ESESSMB502.ericsson.se (Unknown_Domain []) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 85.A2.22015.730EC3B5; Wed, 4 Jul 2018 16:56:55 +0200 (CEST)
Received: from [] ( by ESESSMB502.ericsson.se ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Wed, 4 Jul 2018 16:56:54 +0200
To: "rtcweb@ietf.org" <rtcweb@ietf.org>, <draft-ietf-rtcweb-sdp@ietf.org>
From: Magnus Westerlund <magnus.westerlund@ericsson.com>
Message-ID: <a061e3cc-4a81-0a1f-ebd5-999e6973bc24@ericsson.com>
Date: Wed, 4 Jul 2018 16:56:54 +0200
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0
MIME-Version: 1.0
Content-Type: text/plain; charset="windows-1252"; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-GB
X-Originating-IP: []
X-ClientProxiedBy: ESESSMB505.ericsson.se ( To ESESSMB502.ericsson.se (
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrFLMWRmVeSWpSXmKPExsUyM2J7ha75A5tog6db2S0mrljHZrH2Xzu7 A5PHkiU/mQIYo7hsUlJzMstSi/TtErgy1vzaxFawSq9i06rTrA2MZ1W7GDk5JARMJBbP28va xcjFISRwlFHiXMsZZgjnA6PEhkNTmUCqRAQ8Jaau3gNmswlYSNz80cgGYgsLWEl0/1/NAmLz CthLPPjxlRnEZhFQkXhy7h5YXFQgRmL1xsvsEDWCEidnPgGKc3Awg9RvLQMJMwvISzRvnc0M YYtLNH1ZyQpiCwloSzQ0dbBCHKokcX3edRYIO13iQ9dZlgmMArOQTJ2FMHUWkqmzkExdwMiy ilG0OLW4ODfdyFgvtSgzubg4P08vL7VkEyMwRA9u+a27g3H1a8dDjAIcjEo8vLXnbKKFWBPL iitzDzFKcDArifBWbwYK8aYkVlalFuXHF5XmpBYfYpTmYFES59VbtSdKSCA9sSQ1OzW1ILUI JsvEwSnVwGgXzuetkb6Db/5b/td2h/1aXTdqvV3Q6XS9glPWnj1FNG6J6Eqf2yZ9/Y1dzPvq Sl5N+FOaIXEyjImh4sasnVZ5E3lsLy24byRXvf8Ru/Xu/e2X/SbLyCfk1EwoZl609A1fKucx xi5bZs3bzJ6zGh/Pb1HSixZxczv+8Geexf7vHfu91G/oKLEUZyQaajEXFScCAGFeUF5NAgAA
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtcweb/8Z6OpFCmu7bRu5ph85mnWkEBg7s>
Subject: [rtcweb] Review of Section 5.3 of draft-ietf-rtcweb-sdp-10
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.26
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, 04 Jul 2018 14:57:05 -0000


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 

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


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