[AVTCORE] Additions to RFC5285bis? was Re: [avtext] Mirja Kühlewind's Discuss on draft-ietf-avtext-splicing-notification-07: (with DISCUSS and COMMENT)

Magnus Westerlund <magnus.westerlund@ericsson.com> Wed, 15 June 2016 07:54 UTC

Return-Path: <magnus.westerlund@ericsson.com>
X-Original-To: avt@ietfa.amsl.com
Delivered-To: avt@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 1FD9412B037; Wed, 15 Jun 2016 00:54:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.221
X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id eqaF5nu8w4c2; Wed, 15 Jun 2016 00:54:10 -0700 (PDT)
Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A2EC712B020; Wed, 15 Jun 2016 00:54:06 -0700 (PDT)
X-AuditID: c1b4fb25-f79f26d00000327e-59-5761099cc231
Received: from ESESSHC013.ericsson.se (Unknown_Domain []) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 88.BB.12926.C9901675; Wed, 15 Jun 2016 09:54:04 +0200 (CEST)
Received: from [] ( by smtp.internal.ericsson.com ( with Microsoft SMTP Server id; Wed, 15 Jun 2016 09:54:04 +0200
To: "Huangyihong (Rachel)" <rachel.huang@huawei.com>, =?UTF-8?Q?Mirja_K=c3=bchlewind?= <ietf@kuehlewind.net>, Colin Perkins <csp@csperkins.org>
References: <20160613125529.12490.86798.idtracker@ietfa.amsl.com> <65EAADDF-EE7F-414B-AF3F-45BA4B729500@csperkins.org> <57601B7E.3070208@kuehlewind.net> <51E6A56BD6A85142B9D172C87FC3ABBB86ED634A@nkgeml513-mbx.china.huawei.com>
From: Magnus Westerlund <magnus.westerlund@ericsson.com>
Message-ID: <a9cc4845-3eeb-23eb-0076-ca9008dc85c1@ericsson.com>
Date: Wed, 15 Jun 2016 09:54:02 +0200
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1
MIME-Version: 1.0
In-Reply-To: <51E6A56BD6A85142B9D172C87FC3ABBB86ED634A@nkgeml513-mbx.china.huawei.com>
Content-Type: text/plain; charset="utf-8"; format=flowed
Content-Transfer-Encoding: 8bit
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrKLMWRmVeSWpSXmKPExsUyM2K7pe4czsRwgynHTS1e9qxkt2g/d4LF 4uO9G6wWy1+eYLTY8foVi8XxM+9YLV5c/8hssX/xeWaLpZ2n2B04Pabdv8/m0XLkLavHkiU/ mTxaPi5k9Wh7doc9gDWKyyYlNSezLLVI3y6BK2PVNO+CBtmKN0f+szQwThXvYuTkkBAwkdj+ 6ig7hC0mceHeerYuRi4OIYEjjBIr1+5ignCWM0q8/radHcQRFjjNKDHxcxMjiCMiMJlRYtX6 y+wQZS8YJX6+WA42gFlgP5PEuj3zmUEmswlYSNz80cgGYvMK2Ev8+v2ZBcRmEVCVuH73IBOI LSoQI9F4+zA7RI2gxMmZT4BqODg4BcIkNr2MBQkzA42ZOf88I4QtL9G8dTbYeCEBbYmGpg7W CYyCs5B0z0LSMgtJywJG5lWMosWpxUm56UbGeqlFmcnFxfl5enmpJZsYgZFxcMtv1R2Ml984 HmIU4GBU4uFVcEsIF2JNLCuuzD3EKMHBrCTC68GaGC7Em5JYWZValB9fVJqTWnyIUZqDRUmc 1/+lYriQQHpiSWp2ampBahFMlomDU6qBMdPue236meWRUk+brrVlLGVWiJr4jSvq6dekw8uZ +1Nk0i7zpK8+2Z/vevfLr6JqsSNbnZYbcP/z/6YdnChoulp++vO2NfxzNmkUvdpmERXgVGMw 5U68u3BJbsCew5c60vxEwji/X+77rZXpP/92I5ejzfMjM6fvUbOe57XjPetE5TdnbANFlFiK MxINtZiLihMBrd1x34gCAAA=
Archived-At: <https://mailarchive.ietf.org/arch/msg/avt/fgUbiZCIVuvOsei6nF262M4_dz4>
Cc: "jonathan@vidyo.com" <jonathan@vidyo.com>, "avtext@ietf.org" <avtext@ietf.org>, draft-ietf-avtcore-rfc5285-bis@ietf.org, IETF AVTCore WG <avt@ietf.org>, "draft-ietf-avtext-splicing-notification@ietf.org" <draft-ietf-avtext-splicing-notification@ietf.org>, "avtext-chairs@ietf.org" <avtext-chairs@ietf.org>
Subject: [AVTCORE] =?utf-8?q?Additions_to_RFC5285bis=3F_was_Re=3A_=5Bavtex?= =?utf-8?q?t=5D_Mirja_K=C3=BChlewind=27s_Discuss_on_draft-ietf-avtext-spli?= =?utf-8?q?cing-notification-07=3A_=28with_DISCUSS_and_COMMENT=29?=
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Audio/Video Transport Core Maintenance <avt.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/avt>, <mailto:avt-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/avt/>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/avt>, <mailto:avt-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 15 Jun 2016 07:54:12 -0000

(As individual)

I think we stumbled on one thing that maybe should be included in the 
update of RFC5285.

Namely the discussion and reasoning why a sender may need to repeat a 
RTP header extension. See below excerpt from the discussion:

Den 2016-06-15 kl. 09:22, skrev Huangyihong (Rachel):
> Hi Mirja,
> As one of the authors, please see my replies inline.
> BR, Rachel
> -----邮件原件----- 发件人: Mirja Kühlewind [mailto:ietf@kuehlewind.net] 发送时

>>> - Why is just having the RTCP message not sufficient? Why are the
>>> RTP extensions needed as well?
>> RTP and RTCP are unreliable. The usual practice for these types of
>> extension is to send data both in RTCP, and in some number of RTP
>> packets, to increase the chances of it arriving in a timely manner.
>> The draft is following standard practice here.
> Thanks for clarification. That could be clarified in the text.
> Because the text says that RTCP is used because the RTP information
> might get lost. So I was wondering why you are not only using RTCP
> and make sure you send it sufficiently often. Saying that this is
> common practice would be helpful from my point of view. Is there a
> reference for this?
> [Rachel]: It's more like conventional method to increase robustness.
> As far as I know, there's no formal document to record this. Maybe we
> can address this like this
> OLD "
> To increase robustness against such case, the document also defines
> a complementary RTCP packet type to carry the same Splicing Interval
> to the splicer.
> "
> NEW " To increase robustness against such case, the document also
> defines a new RTCP packet type to carry the same Splicing Interval
> to the splicer. Since RTCP is also unreliable and may not so
> immediate as the in-band way, it's only considered as a complement to
> RTP header extension. "
>>> - And is the RTCP message send only once or multiple time? This
>>> is not specified.
>> That’s implementation dependent, and based on the expected packet
>> loss rate, the importance of the data, and the frequency with which
>> updates need to be sent.
> A recommendation or discussion should be provided here.
> [Rachel]: I think in Section 2, we have already provided some
> guidance on how often the Splicing Interval to be sent, which is not
> just limited to RTP header extension, also includes RTCP message.

This topic is also discussed in  	
draft-ietf-avtext-sdes-hdr-ext-07 Section 4.2.3.

 From my perspective I think the general transmission issues that needs 
to be considered with RTP header extension should be included in the 
update of RFC5285. That way each extension don't have to repeat it, only 
discuss additions or specific considerations for their formats.

To note I think that from SDES header Extension there should be included 
the topics of;

- MTU handling
- How many transmissions and if one can know it has reached the receiver
- Update handling, especially for extensions with data that can be sent 
using both RTCP and RTP header extension.

Note, this is my suggestion as an individual. Please discuss and comment.


Magnus Westerlund

Services, Media and Network features, Ericsson Research EAB/TXM
Ericsson AB                 | Phone  +46 10 7148287
Färögatan 6                 | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com