[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [AVT] draft-schierl-avt-rtp-multi-session-transmission-00.txt
>>>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).
What are the (good) reasons for an intermediary to delete header
extensions? Isn't so that if there is something an intermediary does not
understand, it'd better not to touch the something?
BR, YK
>-----Original Message-----
>From: ext Randell Jesup [mailto:rjesup at wgate.com]
>Sent: 13 November, 2008 20:51
>To: Wang Ye-Kui (Nokia-NRC/Tampere)
>Cc: ingemar.s.johansson at ericsson.com; avt at ietf.org
>Subject: Re: [AVT]
>draft-schierl-avt-rtp-multi-session-traFrom avt-bounces at ietf.org Sat Nov 15 05:57:55 2008
Return-Path: <avt-bounces at ietf.org>
X-Original-To: avt-web-archive at optimus.ietf.org
Delivered-To: ietfarch-avt-web-archive at core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1])
by core3.amsl.com (Postfix) with ESMTP id AD8E83A68E7;
Sat, 15 Nov 2008 05:57:55 -0800 (PST)
X-Original-To: avt at core3.amsl.com
Delivered-To: avt at core3.amsl.com
Received: from localhost (localhost [127.0.0.1])
by core3.amsl.com (Postfix) with ESMTP id 5F90F3A68E7
for <avt at core3.amsl.com>; Sat, 15 Nov 2008 05:57:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level:
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5
tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
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 RyZIJydFkczh for <avt at core3.amsl.com>;
Sat, 15 Nov 2008 05:57:54 -0800 (PST)
Received: from mgw-mx09.nokia.com (smtp.nokia.com [192.100.105.134])
by core3.amsl.com (Postfix) with ESMTP id 7E6F93A682C
for <avt at ietf.org>; Sat, 15 Nov 2008 05:57:54 -0800 (PST)
Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213])
by mgw-mx09.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id
mAFDvlK1008542; Sat, 15 Nov 2008 07:57:50 -0600
Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by
esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959);
Sat, 15 Nov 2008 15:57:46 +0200
Received: from vaebe101.NOE.Nokia.com ([10.160.244.11]) by
esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959);
Sat, 15 Nov 2008 15:57:46 +0200
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Date: Sat, 15 Nov 2008 15:57:46 +0200
Message-ID: <44C96BEE548AC8429828A3762315034701492B47 at vaebe101.NOE.Nokia.com>
In-Reply-To: <ybuy6znjw82.fsf at jesup.eng.wgate.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [AVT] draft-schierl-avt-rtp-multi-session-transmission-00.txt
thread-index: AclFwHxBKapYrsJvShCsgCqpWnqJRwBaTuyg
References: <026F8EEDAD2C4342A993203088C1FC0508BF251C at esealmw109.eemea.ericsson.se><44C96BEE548AC8429828A376231503470149232D at vaebe101.NOE.Nokia.com>
<ybuy6znjw82.fsf at jesup.eng.wgate.com>
From: <Ye-Kui.Wang at nokia.com>
To: <rjesup at wgate.com>
X-OriginalArrivalTime: 15 Nov 2008 13:57:46.0439 (UTC)
FILETIME=[235EE570:01C9472A]
X-Nokia-AV: Clean
Cc: ingemar.s.johansson at ericsson.com, avt at ietf.org
Subject: Re: [AVT] draft-schierl-avt-rtp-multi-session-transmission-00.txt
X-BeenThere: avt at ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Audio/Video Transport Working Group <avt.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/avt>,
<mailto:avt-request at ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/pipermail/avt>
List-Post: <mailto:avt at ietf.org>
List-Help: <mailto:avt-request at ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/avt>,
<mailto:avt-request at ietf.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: avt-bounces at ietf.org
Errors-To: avt-bounces at ietf.org
>>>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).
What are the (good) reasons for an intermediary to delete header
extensions? Isn't so that if there is something an intermediary does not
understand, it'd better not to touch the something?
BR, YK
>-----Original Message-----
>From: ext Randell Jesup [mailto:rjesup at wgate.com]
>Sent: 13 November, 2008 20:51
>To: Wang Ye-Kui (Nokia-NRC/Tampere)
>Cc: ingemar.s.johansson at ericsson.com; avt at ietf.org
>Subject: Re: [AVT]
>draft-schierl-avt-rtp-multi-session-transmission-00.txt
>
><Ye-Kui.Wang at 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 at 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 at ietf.org
https://www.ietf.org/mailman/listinfo/avt
nsmission-00.txt
>
><Ye-Kui.Wang at 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 at 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 at ietf.org
https://www.ietf.org/mailman/listinfo/avt