Re: [AVTCORE] comment on draft-westerlund-avtext-rtcp-sdes-srcname

Magnus Westerlund <magnus.westerlund@ericsson.com> Fri, 06 July 2012 14:05 UTC

Return-Path: <magnus.westerlund@ericsson.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 9886F21F85E0 for <avt@ietfa.amsl.com>; Fri, 6 Jul 2012 07:05:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.205
X-Spam-Level:
X-Spam-Status: No, score=-106.205 tagged_above=-999 required=5 tests=[AWL=0.044, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LhFEr+Q-+EV4 for <avt@ietfa.amsl.com>; Fri, 6 Jul 2012 07:05:20 -0700 (PDT)
Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 5F99D21F859A for <avt@ietf.org>; Fri, 6 Jul 2012 07:05:20 -0700 (PDT)
X-AuditID: c1b4fb25-b7fc16d000005db2-e1-4ff6f0af6b8f
Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 1F.3D.23986.FA0F6FF4; Fri, 6 Jul 2012 16:05:35 +0200 (CEST)
Received: from [127.0.0.1] (153.88.115.8) by esessmw0237.eemea.ericsson.se (153.88.115.91) with Microsoft SMTP Server id 8.3.264.0; Fri, 6 Jul 2012 16:05:35 +0200
Message-ID: <4FF6F0AE.9080407@ericsson.com>
Date: Fri, 06 Jul 2012 16:05:34 +0200
From: Magnus Westerlund <magnus.westerlund@ericsson.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:13.0) Gecko/20120614 Thunderbird/13.0.1
MIME-Version: 1.0
To: "Pascal Buhler (pabuhler)" <pabuhler@cisco.com>
References: <7EC1BF197B21C747868126E92F8A7D62D8BE@xmb-aln-x04.cisco.com>
In-Reply-To: <7EC1BF197B21C747868126E92F8A7D62D8BE@xmb-aln-x04.cisco.com>
X-Enigmail-Version: 1.4.2
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 8bit
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprJLMWRmVeSWpSXmKPExsUyM+Jvre76D9/8DS506Fq87FnJbrHx7SRW ByaPKb83snosWfKTKYApissmJTUnsyy1SN8ugSvjdu9RpoKbwhUXPj9naWB8wt/FyMkhIWAi 0f/zLyuELSZx4d56ti5GLg4hgVOMEn9WT2UGSQgJLGOUmPm9BsTmFdCW6O5fwNjFyMHBIqAi cfY2N0iYTcBC4uaPRjYQW1QgWGLa9HvsEOWCEidnPmEBKRcRMJZYtikZxGQWUJSY1C4JUiEs 4CjxvmkVC8QiD4n3rzeB2ZwCnhK7jr5hg7hMUuJe+2owm1lAT2LK1RZGCFteonnrbKgjtSUa mjpYJzAKzUKyeBaSlllIWhYwMq9iFM5NzMxJLzfSSy3KTC4uzs/TK07dxAgM3oNbfqvuYLxz TuQQozQHi5I4r/XWPf5CAumJJanZqakFqUXxRaU5qcWHGJk4OKUaGIVEX/oZ567Y9nXChl2H Zz/RuiVSJf/6wP925qKtR0tNLYWv7Fpx7WdqdfmxAzorl6qZZ33ifDHR/cyhnKQLMgl7E/nu 1ahmHw3uEp/XKyVkdffyrFnvc/238uu6Tm05KFsSfXFCfcQMpg/T8xnN2vIr83vfbr+6L6V4 N/vz1EXuH/zn1O78YqPEUpyRaKjFXFScCAAhJ5gbLAIAAA==
Cc: "avt@ietf.org" <avt@ietf.org>
Subject: Re: [AVTCORE] comment on draft-westerlund-avtext-rtcp-sdes-srcname
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.12
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: <http://www.ietf.org/mail-archive/web/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: Fri, 06 Jul 2012 14:05:21 -0000

On 2012-06-29 09:43, Pascal Buhler (pabuhler) wrote:
> 
> One of the problems mentioned in the draft, that is the case when
> receiving the RTP streams before the SEDS has arrived is something
> that needs to be addressed. The option of including the mapping in
> the SDP is not always appropriate due to devices like an RTP
> Translator in the middle. Therefore I was wondering if you have
> considered including a definition of a RTP header extension
> (http://tools.ietf.org/html/rfc5285) to include the SRCNAME in the
> RTP stream. Yes it is potentially a lot of bits wasted but it is up
> to the sender to decide the size of the SRCNAME so that can mitigate
> it somewhat. Also it may not be required in every packet just packets
> that make sense for example only in the beginning of a stream, at key
> points in the stream or else periodically. When using the SRCNAME to
> correlate two or more separate encodings of the same source it is
> important as a receiver that when first receiving one encoding and
> then switching to receive a second encoding to make this correlation
> as soon as possible.
> 

Thanks for the support for the general use case.

Yes, using a header extension to provide the information is a potential
extension for certain use cases that clearly can be an extension on the
basis of our proposed solution. Yes, clearly you should have the
flexibility to include such information as often or seldom as makes
sense in your application.

> 
> There is also mention of using this as a way correlating FEC with
> media. How would this work in the simulcast case where there are
> multiple encodings of the same source. How to use only SRCNAME to map
> the FEC stream to the individual media streams when all media streams
> have the same SRCNAME.

Yes, this has been raised previously and I agree we need to support it.
We think we have an idea how to improve SRCNAME to work also in those
cases. Now it is only of matter of manage to write it up before the
draft deadline.

Cheers

Magnus Westerlund

----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone  +46 10 7148287
Färögatan 6                | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com
----------------------------------------------------------------------