[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