[AVTCORE] update to RFC5285 allowing both one byte and two bytes RTP header extesnions in the same RT stream

"Roni Even" <ron.even.tlv@gmail.com> Wed, 16 September 2015 07:01 UTC

Return-Path: <ron.even.tlv@gmail.com>
X-Original-To: avt@ietfa.amsl.com
Delivered-To: avt@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E7511B37C1 for <avt@ietfa.amsl.com>; Wed, 16 Sep 2015 00:01:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.471
X-Spam-Level: *
X-Spam-Status: No, score=1.471 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_SORBS_WEB=0.77, SPF_PASS=-0.001] autolearn=no
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 7fqWZUdkud3e for <avt@ietfa.amsl.com>; Wed, 16 Sep 2015 00:01:40 -0700 (PDT)
Received: from mail-wi0-x236.google.com (mail-wi0-x236.google.com [IPv6:2a00:1450:400c:c05::236]) (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 84DF01B37BE for <avt@ietf.org>; Wed, 16 Sep 2015 00:01:39 -0700 (PDT)
Received: by wicgb1 with SMTP id gb1so59312154wic.1 for <avt@ietf.org>; Wed, 16 Sep 2015 00:01:38 -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:content-type :thread-index:content-language; bh=aJYKk3wmdCqmE/XnfZ6hTjATt0uucsc4YMczLssgnE4=; b=x/8J/1r7AFnxzZUO2iKEkStOlhKh079II4hqUqrF9YK/LmF0BcUvGUunciBBrJx+Ub JwQ/LYLbdYpu33gs7uiD1BT5mHHhyNjMX+axltBwbuwCq+E3TxVTbZPlLNZKi1rTNTJe v/UAGRjG6sVo+ejx5W9/5XpV7jcU/5wJdAOASe3kI1b7D1KpdDS3yz9XA62V3vb2l1dB J1qPlb7YKrfVbeFTJCuIdIvnuISIxfH8aYBFqEdhhtV/Ui9XyEN0LB5jKrHVH8V7RZB0 99Vr7WiwsxHCkhvLdQdeMb8nOuHYiWvZPrQL+Ia8bT0IfgOnyMmMLt6MoUtB0tq7K1IR yNYw==
X-Received: by 10.180.79.5 with SMTP id f5mr15140191wix.79.1442386898206; Wed, 16 Sep 2015 00:01:38 -0700 (PDT)
Received: from RoniPC (bzq-79-176-23-173.red.bezeqint.net. [79.176.23.173]) by smtp.gmail.com with ESMTPSA id mz12sm2828068wic.4.2015.09.16.00.01.36 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 16 Sep 2015 00:01:37 -0700 (PDT)
From: "Roni Even" <ron.even.tlv@gmail.com>
To: "Magnus Westerlund" <magnus.westerlund@ericsson.com>, <avt@ietf.org>
Date: Wed, 16 Sep 2015 10:01:34 +0300
Message-ID: <065e01d0f04d$86dd6a30$94983e90$@gmail.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_065F_01D0F066.AC2D6150"
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AdDwTAAo/mEI86GZR9KFnLWYdG9mxA==
Content-Language: he
Archived-At: <http://mailarchive.ietf.org/arch/msg/avt/XXs0JmlvHf1KcKRoinGUGsT_MPE>
Subject: [AVTCORE] update to RFC5285 allowing both one byte and two bytes RTP header extesnions in the same RT stream
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.15
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, 16 Sep 2015 07:01:41 -0000

Hi,

As I was corrected by Magnus the conclusion in Parhue was to update RFC5285
allowing both one byte and two bytes RTP header extensions in the same RT
stream but not in the same RTP packet.

 

When working on the update I would like to get feedback on some points made
at the meeting and ones I encountered when looking at RFC5285

 

1.       At the meeting Mo suggested to use ID>15 only for the two bytes RTP
header extensions when mixing in the same RTP stream, is this OK. 

2.       Should it also be applicable when only using two bytes in an RTP
stream

3.       Section 5 mandate that the SDP signaling will be either session or
media level. Mixing is not allowed. I assume it has to do with uniqueness of
the IDs. Should we change it?

4.       We will need to negotiate the support for this mode, is this OK

5.        Since his mode applies to all RTP header extensions in an RTP
stream it should be a new SDP attribute, it can be a media level for only
one SDP RTP session or a session level attribute. Comments?

 

Thanks

Roni Even