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

"Pascal Buhler (pabuhler)" <pabuhler@cisco.com> Fri, 29 June 2012 07:45 UTC

Return-Path: <pabuhler@cisco.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 07C2521F86B7 for <avt@ietfa.amsl.com>; Fri, 29 Jun 2012 00:45:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.599
X-Spam-Level:
X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
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 S8UMR8ISXL4u for <avt@ietfa.amsl.com>; Fri, 29 Jun 2012 00:45:27 -0700 (PDT)
Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 2610E21F86B4 for <avt@ietf.org>; Fri, 29 Jun 2012 00:45:27 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pabuhler@cisco.com; l=1398; q=dns/txt; s=iport; t=1340955927; x=1342165527; h=from:to:cc:subject:date:message-id: content-transfer-encoding:mime-version; bh=CNaVx/JPRN1le6hOGmCyWBUmQLNFrlrWunGFrlTsQCg=; b=f5TgC2CCK+9Ahs7kR0YfNnFUAYrSEGjLdf0nptlsjHt99VLGhMxsfRfe M1wv810OsxTrfAZmMWisrzZZPjZRadb7sjlEaePd1gab5Jb2cuMQZ6VVr 9fI5lKmAW6KlyQtZj1VhlP8dKW9HSi5DDM7HKQQOXhvwgUR9PqZqYG9M+ I=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Av0EANNc7U+tJV2b/2dsb2JhbABFtkmBB4IaAQQSASc/EgEqFEImAQQODRqHaQuYUaBikGFgA5FThHGNC4Fmgl8
X-IronPort-AV: E=Sophos;i="4.77,497,1336348800"; d="scan'208";a="97208008"
Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-4.cisco.com with ESMTP; 29 Jun 2012 07:45:11 +0000
Received: from xhc-rcd-x07.cisco.com (xhc-rcd-x07.cisco.com [173.37.183.81]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id q5T7jBLa013652 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 29 Jun 2012 07:45:11 GMT
Received: from xmb-aln-x04.cisco.com ([169.254.9.25]) by xhc-rcd-x07.cisco.com ([173.37.183.81]) with mapi id 14.02.0298.004; Fri, 29 Jun 2012 02:45:10 -0500
From: "Pascal Buhler (pabuhler)" <pabuhler@cisco.com>
To: Magnus Westerlund <magnus.westerlund@ericsson.com>
Thread-Topic: comment on draft-westerlund-avtext-rtcp-sdes-srcname
Thread-Index: Ac1VyxsKVUarKPrxSCOaeJCjD+Dlyw==
Date: Fri, 29 Jun 2012 07:43:26 +0000
Message-ID: <7EC1BF197B21C747868126E92F8A7D62D8BE@xmb-aln-x04.cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.60.82.227]
x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19004.004
x-tm-as-result: No--33.142000-8.000000-31
x-tm-as-user-approved-sender: No
x-tm-as-user-blocked-sender: No
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Mailman-Approved-At: Fri, 29 Jun 2012 10:01:57 -0700
Cc: "Pascal Buhler (pabuhler)" <pabuhler@cisco.com>, "avt@ietf.org" <avt@ietf.org>
Subject: [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, 29 Jun 2012 07:45:28 -0000

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.


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.

Thanks

Pascal Buhler