Re: [AVTCORE] Draft new: draft-holmberg-avtcore-5761-update-00

Paul Kyzivat <pkyzivat@alum.mit.edu> Wed, 22 June 2016 22:32 UTC

Return-Path: <pkyzivat@alum.mit.edu>
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 0DF7112DD5C for <avt@ietfa.amsl.com>; Wed, 22 Jun 2016 15:32:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.935
X-Spam-Level:
X-Spam-Status: No, score=-1.935 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=comcast.net
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 lu6wD0-kIGtI for <avt@ietfa.amsl.com>; Wed, 22 Jun 2016 15:32:05 -0700 (PDT)
Received: from resqmta-ch2-11v.sys.comcast.net (resqmta-ch2-11v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:43]) (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 BB4FA12DD66 for <avt@ietf.org>; Wed, 22 Jun 2016 15:32:03 -0700 (PDT)
Received: from resomta-ch2-13v.sys.comcast.net ([69.252.207.109]) by resqmta-ch2-11v.sys.comcast.net with SMTP id Fqf1b831tTKbsFqglbsW0u; Wed, 22 Jun 2016 22:32:03 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1466634723; bh=QOp8ehtRjhwq5OIIS+21TmldqzLL512AuNBVcBLEcEw=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=coDkRmcK3EaFjaK+hVPDlwQU9td3ObpdNhJCbCqDZvbn+Z5rLNqLfp2ePMirkEcQ8 YgEIP2DlM0OxK6dYHqupi8WltO6RKIwbZUxPFCg6vCJCi7Si+Lp6Hfhde35q8UEbv2 UgWT6m+ZBhe4H3iOE9PWfYU7iNLVy7wvy8P0VQwxkNy+hdAicZ86S3lVlrkkUUIEq/ M2m8ibtNOjUnNiWzBIyXLIXGmuOeYFbaEDbR/kdjh3yHQigu9XrYqPqJ/iVpSlykuz YKZKtzBnw1drEpBjHngKMC7Xjw+MVD1vOxbnoT7yT52LUTUc5SjJ/XGDyJg2Vohw6n SS7vqmb0LFCzg==
Received: from Paul-Kyzivats-MacBook-Pro.local ([73.218.51.154]) by resomta-ch2-13v.sys.comcast.net with comcast id 9yY21t00Q3KdFy101yY29u; Wed, 22 Jun 2016 22:32:03 +0000
To: avt@ietf.org
References: <D386CB5E.AC1C%christer.holmberg@ericsson.com> <140601d1cc9d$9a49e1c0$cedda540$@gmail.com> <7594FB04B1934943A5C02806D1A2204B381009F3@ESESSMB209.ericsson.se> <144401d1cccc$2b41eaf0$81c5c0d0$@gmail.com>
From: Paul Kyzivat <pkyzivat@alum.mit.edu>
Message-ID: <e8df15c7-42ae-9521-6e95-250b92516ef7@alum.mit.edu>
Date: Wed, 22 Jun 2016 18:32:01 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.1.0
MIME-Version: 1.0
In-Reply-To: <144401d1cccc$2b41eaf0$81c5c0d0$@gmail.com>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/avt/gTkJUgr2S4UPUkr-VIDdp2ZPthA>
Subject: Re: [AVTCORE] Draft new: draft-holmberg-avtcore-5761-update-00
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, 22 Jun 2016 22:32:07 -0000

On 6/22/16 5:22 PM, Roni Even wrote:

> */That is tied to my question about can the answerer use a=RTCP to
> receive multiplex RTP and RTCP without explicitly using rtcp-mux
> attribute?/*

I agree that is fuzzy. IMO, attempts to do that ought to be considered 
an error. But I don't know what sort of recovery action should be taken 
for this error.

Note that for an *answerer* to attempt this leads to nonsense. It means 
the offerer will be sending both RTP and RTCP to a single port while the 
answerer (who set this up) must still send them to separate ports. And 
since it wasn't anticipating that these be multiplexed it will 
presumably be buffering as if they are going to separate ports. I would 
think that would make a mess.

It would be less problematic if first signaled by the offerer, because 
then the answerer knows what is going on if it also uses a single for 
both in the answer. But in this case they ought to be explicitly 
signaling that they are multiplexing.

It would be good to revise the definition of a=rtcp to clarify this, so 
somebody not aware of a=rtcp-mux doesn't do this by accident.

	Thanks,
	Paul