Re: [AVTCORE] [avtext] Additions to RFC5285bis?

"Roni Even" <ron.even.tlv@gmail.com> Wed, 15 June 2016 17:41 UTC

Return-Path: <ron.even.tlv@gmail.com>
X-Original-To: avt@ietfa.amsl.com
Delivered-To: avt@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D24512DA80; Wed, 15 Jun 2016 10:41:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level:
X-Spam-Status: No, score=-2.699 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_LOW=-0.7, 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 30szUuT7n4Zb; Wed, 15 Jun 2016 10:41:39 -0700 (PDT)
Received: from mail-lf0-x22a.google.com (mail-lf0-x22a.google.com [IPv6:2a00:1450:4010:c07::22a]) (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 CB3F312DA77; Wed, 15 Jun 2016 10:41:36 -0700 (PDT)
Received: by mail-lf0-x22a.google.com with SMTP id q132so22961410lfe.3; Wed, 15 Jun 2016 10:41:36 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:subject:date:message-id:mime-version:thread-index :content-language; bh=UKYsWWlZ1UDFnNP1M7Axa9RHnwdiwVQL8sJ8pSZo9jU=; b=VUn6wUBiYXh3u+aH1LoGWDR0PRi/4lD939Cr1I3U3XK4zfQSJ/YD1hO5tPC5Th+o/P 3vNs3AzghpLykPiovqmEo1YJXRCNwkiLsKD3wq7rhF1Yy9qN5GL1NZ4k4AWrtkS3UYfM lalf/04LHivcNCuriBJNvPJUnQcRxgLEKyNMAU8RN4xqdfZEbQuzBCSOVsof+ka4W3Zy LrCTOONN3mW9aSkvmMhvTjbEOqOcylhuA0PPcq2gbDPqisWPsZZNsa5TrhHCs/phdZu1 6BPxRsVbB0BCmKEhQY4bTzJ1TVjD5xq4rlnDYhLokh84aVoGDV2HjNFrvAX9Wh4cRXYP vCDA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:cc:subject:date:message-id:mime-version :thread-index:content-language; bh=UKYsWWlZ1UDFnNP1M7Axa9RHnwdiwVQL8sJ8pSZo9jU=; b=A0EEqDjQEqsZKybwN778GQlxgO9J86Mbu1Hsm4heyshjIKheAjCVFTrBoavbDHvvYU vSI5s1WBy9eU2UC5UkM9xduEVs7XA+Nw/wYqF67A0LIe5BVpun3/X+bRV/fYKYisBQSR FIMhrI34ma2wVf5mjITQ9BRocx7C/mgFVc4fwUfIh4wdaEZTiA3PsephYV9PVGNap+Tg BIyAw7tFWpfl6k09MDYevHorfvcT+elSR4ri5+ECK0SH+0T7PVIVT2d/E4VSLDK3oN8b Nhy5/6bmlfdAb1rqv0OtZyPYlZkMi4yWeJBIKv38mg+7ImTBmHisK6Q5csC/bLGROxl2 f3OQ==
X-Gm-Message-State: ALyK8tKVtzodZ4E3BOFoH6uLWfu1Kbhh1bIwPmzslPNgHUzyc9w6/jojMxcqGcjaZt9n0g==
X-Received: by 10.28.29.146 with SMTP id d140mr496883wmd.27.1466012494909; Wed, 15 Jun 2016 10:41:34 -0700 (PDT)
Received: from RoniPC (bzq-79-179-194-235.red.bezeqint.net. [79.179.194.235]) by smtp.gmail.com with ESMTPSA id bu7sm1468796wjc.42.2016.06.15.10.41.31 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 15 Jun 2016 10:41:33 -0700 (PDT)
From: Roni Even <ron.even.tlv@gmail.com>
To: 'Colin Perkins' <csp@csperkins.org>, Magnus Westerlund <magnus.westerlund@ericsson.com>
Date: Wed, 15 Jun 2016 20:40:10 +0300
Message-ID: <0eea01d1c72c$f8c566f0$ea5034d0$@gmail.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0EEB_01D1C746.1E1473B0"
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AdHHLLimIaSZYyvFSfuqTiYcYJL0+A==
Content-Language: he
Archived-At: <https://mailarchive.ietf.org/arch/msg/avt/COi3ky9WLcgMcdsN7YEVPK39bgA>
Cc: jonathan@vidyo.com, avtext@ietf.org, draft-ietf-avtcore-rfc5285-bis@ietf.org, avt@ietf.org, 'David Singer' <singer@apple.com>
Subject: Re: [AVTCORE] [avtext] Additions to RFC5285bis?
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 17:41:45 -0000

Hi,

(I removed some of the recipients – discuss in avtcore)

 

As David Singer pointed out draft-ietf-avtext-sdes-hdr-ext section 4.2.3 discuss the transmission considerations for RTP header extensions.

So do you think we can that this text is the relevant one for RFC5285-bis to discuss why and when to repeat sending RTP header extensions since one of the difference between RFC5285 and the bis draft is that we acknowledge that delivery of RTP header extension is crucial.

 

I also agree that it will be good to split section 4.1 

 

Roni

 

 

From: avtext [mailto:avtext-bounces@ietf.org] On Behalf Of David Singer
Sent: Wednesday, June 15, 2016 7:49 PM
To: Colin Perkins
Cc: avtext@ietf.org; draft-ietf-avtcore-rfc5285-bis@ietf.org; jonathan@vidyo.com; IETF AVTCore WG; avtext-chairs@ietf.org; Mirja Kühlewind; draft-ietf-avtext-splicing-notification@ietf.org
Subject: Re: [avtext] Additions to RFC5285bis? was Re: Mirja Kühlewind's Discuss on draft-ietf-avtext-splicing-notification-07: (with DISCUSS and COMMENT)

 

Looks to me like we need to loot and pillage from at least the SDES draft, and update (and split into sub-sections, as it’s already long and a mix of topics) section 4.1 of 5285.  Yes, a section on repetition considerations and reliability seems reasonable to me.

 

On Jun 15, 2016, at 6:07 , Colin Perkins <csp@csperkins.org> wrote:

 

Hi Magnus,

I agree that this makes sense, and is probably better than having more general discussion in the splicing notification draft.

Colin






On 15 Jun 2016, at 08:54, Magnus Westerlund <magnus.westerlund@ericsson.com> wrote:

Hi,
(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.

Cheers

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




-- 
Colin Perkins
 <https://csperkins.org/> https://csperkins.org/

 

David Singer

Manager, Software Standards, Apple Inc.