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

<Ye-Kui.Wang@nokia.com> Sun, 16 November 2008 16:46 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 02D593A6995; Sun, 16 Nov 2008 08:46:34 -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 3410A3A6995 for <avt@core3.amsl.com>; Sun, 16 Nov 2008 08:46:32 -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 xmUVUgfglq6O for <avt@core3.amsl.com>; Sun, 16 Nov 2008 08:46:31 -0800 (PST)
Received: from mgw-mx03.nokia.com (smtp.nokia.com [192.100.122.230]) by core3.amsl.com (Postfix) with ESMTP id 1172D3A6774 for <avt@ietf.org>; Sun, 16 Nov 2008 08:46:30 -0800 (PST)
Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-mx03.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id mAGGkQmx013846; Sun, 16 Nov 2008 18:46:27 +0200
Received: from vaebh102.NOE.Nokia.com ([10.160.244.23]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Sun, 16 Nov 2008 18:46:26 +0200
Received: from vaebe101.NOE.Nokia.com ([10.160.244.11]) by vaebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Sun, 16 Nov 2008 18:46:26 +0200
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Date: Sun, 16 Nov 2008 18:46:24 +0200
Message-ID: <44C96BEE548AC8429828A3762315034701492BE5@vaebe101.NOE.Nokia.com>
In-Reply-To: <ybuk5b3r95k.fsf@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: AclH/lU64V/mqQOARTGg47DDlh0oZAADCzWg
References: <026F8EEDAD2C4342A993203088C1FC0508BF251C@esealmw109.eemea.ericsson.se><44C96BEE548AC8429828A376231503470149232D@vaebe101.NOE.Nokia.com><ybuy6znjw82.fsf@jesup.eng.wgate.com><44C96BEE548AC8429828A3762315034701492B47@vaebe101.NOE.Nokia.com> <ybuk5b3r95k.fsf@jesup.eng.wgate.com>
From: Ye-Kui.Wang@nokia.com
To: rjesup@wgate.com
X-OriginalArrivalTime: 16 Nov 2008 16:46:26.0231 (UTC) FILETIME=[DDA65C70:01C9480A]
X-Nokia-AV: Clean
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
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

Thanks for the clarification, which is important. According to this, it
appears that if the RTP header extenstion contains Decoder Order Number
information, then there is no problem, as this information not related
to anything in the RTP header. A good thing is that this solution is
really generic!

BR, YK 

>-----Original Message-----
>From: ext Randell Jesup [mailto:rjesup@wgate.com] 
>Sent: 16 November, 2008 17:19
>To: Wang Ye-Kui (Nokia-NRC/Tampere)
>Cc: ingemar.s.johansson@ericsson.com; avt@ietf.org
>Subject: Re: [AVT] 
>draft-schierl-avt-rtp-multi-session-transmission-00.txt
>
><Ye-Kui.Wang@nokia.com> writes:
>>>>>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?
>
>True - but if you modify the main package, passing through the header
>extension becomes tricky.  For example, a B2BUA may leave the payload
>alone, but almost always rewrites the RTP header, and may 
>generate it's own
>(or modify passed-through) RTCP packets.  If the header extension
>references the header (sequence or timestamps), you could be 
>broken.  Or if
>the header extension references the SSRC, or data carried in the RTCP
>stream (like NTP time), you could also be broken, and there's no way to
>know if you don't understand (and comply with) the extension.
>
>I mention things like this because Asterisk does those 
>actions, I think.
>
>-- 
>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