Re: [AVT] draft-schierl-avt-rtp-multi-session-transmission-00.txt

Randell Jesup <rjesup@wgate.com> Thu, 13 November 2008 19:00 UTC

Return-Path: <avt-bounces@ietf.org>
X-Original-To: avt-archive@optimus.ietf.org
Delivered-To: ietfarch-avt-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0AF253A6977; Thu, 13 Nov 2008 11:00:00 -0800 (PST)
X-Original-To: avt@core3.amsl.com
Delivered-To: avt@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 86E4F3A6977 for <avt@core3.amsl.com>; Thu, 13 Nov 2008 10:59:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.734
X-Spam-Level:
X-Spam-Status: No, score=-1.734 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, RDNS_DYNAMIC=0.1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bNtF2y7d6wE7 for <avt@core3.amsl.com>; Thu, 13 Nov 2008 10:59:57 -0800 (PST)
Received: from exchange1.wgate.com (pr-66-150-46-254.wgate.com [66.150.46.254]) by core3.amsl.com (Postfix) with ESMTP id 1F1A23A67AB for <avt@ietf.org>; Thu, 13 Nov 2008 10:59:56 -0800 (PST)
Received: from jesup.eng.wgate.com ([10.32.2.26]) by exchange1.wgate.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 13 Nov 2008 13:48:50 -0500
To: Ye-Kui.Wang@nokia.com
References: <026F8EEDAD2C4342A993203088C1FC0508BF251C@esealmw109.eemea.ericsson.se> <44C96BEE548AC8429828A376231503470149232D@vaebe101.NOE.Nokia.com>
From: Randell Jesup <rjesup@wgate.com>
Date: Thu, 13 Nov 2008 13:51:09 -0500
In-Reply-To: <44C96BEE548AC8429828A376231503470149232D@vaebe101.NOE.Nokia.com> (Ye-Kui Wang's message of "Thu, 13 Nov 2008 18:31:54 +0200")
Message-ID: <ybuy6znjw82.fsf@jesup.eng.wgate.com>
User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux)
MIME-Version: 1.0
X-OriginalArrivalTime: 13 Nov 2008 18:48:50.0612 (UTC) FILETIME=[7800B740:01C945C0]
Cc: ingemar.s.johansson@ericsson.com, avt@ietf.org
Subject: Re: [AVT] draft-schierl-avt-rtp-multi-session-transmission-00.txt
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: Randell Jesup <rjesup@wgate.com>
List-Id: Audio/Video Transport Working Group <avt.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/avt>, <mailto:avt-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/pipermail/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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: avt-bounces@ietf.org
Errors-To: avt-bounces@ietf.org

<Ye-Kui.Wang@nokia.com> writes:
>I tend to agree with Ingemar that the problem of the RTP header extension
>mechanism is not serious. If the RTP header extension mechanism is based
>on decoder order numbers of coded data units, then I think it is really
>generic and applies to any layered or multi-source codec, including
>flexible scalable video codecs such as SVC.


Ingemar Johansson writes;
>>I have a comment on 
>>draft-schierl-avt-rtp-multi-session-transmission-00.txt
>>
>>
>>=============
>>7.2.6.  RTP header extension
>>
>>   The RTP header extension may be used to add generic signaling about
>>   Data Alignment to RTP packets.
>>
>>7.2.6.1.  Identified problems
>>
>>   RTP header extensions are required to be ancillary information which
>>   can safely be discarded by receivers which do not understand them.
>>   Data alignment mechanisms do not satisfy this requirement.
>>=============
>
>>My question is ..how serious is the identified problem ?. 
>>My gut feeling is that a receiver that implements e.g decoding 
>>of G.718 content will likely update the RTP stack to recognize 
>>header extensions if header extensions are used to carry e.g 
>>the NTP timestamp related to the RTP timetstamp in the RTP header. 

What if an intermediary deletes the header extension?  (SBC, B2BUA,
raw message store, etc).

This isn't to say it might not be a good idea - but requiring header
extensions to pass through may not be a good idea.  You also have issues
where you can't use multiple header extensions in the same RTP packet, so
moving too much to them is a problem.

-- 
Randell Jesup, Worldgate (developers of the Ojo videophone), ex-Amiga OS team
rjesup@wgate.com
"The fetters imposed on liberty at home have ever been forged out of the weapons
provided for defence against real, pretended, or imaginary dangers from abroad."
		- James Madison, 4th US president (1751-1836)

_______________________________________________
Audio/Video Transport Working Group
avt@ietf.org
https://www.ietf.org/mailman/listinfo/avt