Re: [AVTCORE] Discuss on draft-ietf-avt-forward-shifted-red-06

Qiaobing Xie <> Thu, 19 May 2011 19:50 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id F3AA8E0742 for <>; Thu, 19 May 2011 12:50:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id UfVMUsQehNcp for <>; Thu, 19 May 2011 12:50:03 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 41C88E082C for <>; Thu, 19 May 2011 12:50:03 -0700 (PDT)
Received: by iyn15 with SMTP id 15so3020920iyn.31 for <>; Thu, 19 May 2011 12:50:03 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=gamma; h=domainkey-signature:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=ZiEwcvjSZWnEZbWEYa7awKmvlYRSsHkCyoZlrVuYTmc=; b=J1NfdbxHBAkHMu/oLDPlAgp0HDhD6UFSit8Ifbmg21MnB6n7O1UCbIqgPl8QtETvS+ uKkIFeIEbLGxIK3ylX4JuowjwJl8TC4o6VVDDciZtTtvSKPYE43lO/QCqeoo0MTZcgcS wNmW3BJV+Z3Ihoasb4Zs7e6AjBobOoUFAmOpU=
DomainKey-Signature: a=rsa-sha1; c=nofws;; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=wjB6832EitukCUW5WoErTzf6hPbAQHI214vOqSZVeuUnQy1XUEw+mJ2xSrPgzaqs9I 2RWV1Nx746FzHGM6BX0b7NxNSLRNKxMrHlqFIPe/UaFYWonZHWRZjBDpQtWvMugKWrmA wct82TDmsgTL32RT6VikLbE3S4g2MxY5iLAlQ=
Received: by with SMTP id w10mr2657611ibi.63.1305834602635; Thu, 19 May 2011 12:50:02 -0700 (PDT)
Received: from Qiaobing-Xies-Mac-Pro.local ( []) by with ESMTPS id c1sm1202968ibe.51.2011. (version=TLSv1/SSLv3 cipher=OTHER); Thu, 19 May 2011 12:50:01 -0700 (PDT)
Message-ID: <>
Date: Thu, 19 May 2011 14:49:59 -0500
From: Qiaobing Xie <>
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv: Gecko/20110414 Thunderbird/3.1.10
MIME-Version: 1.0
To: Magnus Westerlund <>
References: <>
In-Reply-To: <>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 8bit
Cc: IETF AVTCore WG <>
Subject: Re: [AVTCORE] Discuss on draft-ietf-avt-forward-shifted-red-06
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Audio/Video Transport Core Maintenance <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 19 May 2011 19:50:04 -0000


I will be fine with either approach. From an implementation and documentation maintenance point of view, the "new optional parameter" approach is simpler. As for your concern "how well the implementations handle new optional parameters", I think the question actually applies to *any* new optional parameter introduced here. We must have tons of experiences for that from the field already. I would be shocked if this would be the first time a new optional parameter is introduced.


On 5/19/11 2:30 AM, Magnus Westerlund wrote:
> WG,
> Peter Saint-Andre has one part of his discuss which I believe we need WG
> input on.
>> 1) It is not clear to me why this document is registering 2 new MIME types,
>> instead of just registering a new optional parameter "forwardshift" for the
>> already registered audio/red MIME type. Handling of these 2 new MIME types
>> without the "forwardshift" parameter seems to be identical to the handling of
>> audio/red.
> I have discussed this discuss with Peter and clarified that there is one
> actual difference between the two approaches.
> Where using new mime types results in that one handles this as two
> independent media formats. Thus requiring two different payload types
> and negotiating them independently. And these two payload types is in
> fact resulting to a doubling of the number of payload types required in
> relation to the combination of primary secondary. This as each payload
> type only can carry one specific combination of redundancy.
> Using a optional parameter in the existing types has the result that one
> uses only one payload type and in a negotiation context, like SDP
> offer/answer one will use forward redundancy if both peers acknowledge
> the optional parameter, and if the other doesn't understand one gets
> automatic downgrade to RFC 2198 behavior. If this is the desired
> behavior my small concern is how well the implementations handle new
> optional parameters. They should but I have no knowledge how well people
> implements that handling.
> So the question to the WG is what behavior is really desired here?
> Please provide any feedback before the 2nd of June.
> 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:
> ----------------------------------------------------------------------