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

Magnus Westerlund <> Thu, 19 May 2011 08:13 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4CC5EE0713 for <>; Thu, 19 May 2011 01:13:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -106.471
X-Spam-Status: No, score=-106.471 tagged_above=-999 required=5 tests=[AWL=0.128, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id xImGoYqx0gzC for <>; Thu, 19 May 2011 01:13:22 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 35853E0711 for <>; Thu, 19 May 2011 01:13:21 -0700 (PDT)
X-AuditID: c1b4fb39-b7bfdae000005125-44-4dd4d11f5091
Received: from (Unknown_Domain []) by (Symantec Mail Security) with SMTP id 1E.B5.20773.F11D4DD4; Thu, 19 May 2011 10:13:19 +0200 (CEST)
Received: from [] ( by ( with Microsoft SMTP Server id; Thu, 19 May 2011 10:13:18 +0200
Message-ID: <>
Date: Thu, 19 May 2011 10:13:18 +0200
From: Magnus Westerlund <>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv: Gecko/20110414 Thunderbird/3.1.10
MIME-Version: 1.0
To: Colin Perkins <>
References: <> <>
In-Reply-To: <>
X-Enigmail-Version: 1.1.1
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 8bit
X-Brightmail-Tracker: AAAAAA==
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 08:13:23 -0000

On 2011-05-19 09:45, Colin Perkins wrote:
> On 19 May 2011, at 08:30, 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?
> The problem with using an optional parameter is that the extension
> changes the semantics and is not backwards compatible. This would
> break older implementations that ignore the new parameter. A new
> payload type will not be understood by old implementations, but at
> least it won't be misinterpreted. Because of this, I think we want
> new media types.

I agree this is an issue for declarative usages when an end-point using
a declarative SDP will think it understands the media format but it
doesn't. But in negotiated usages this issue would not be present as the
introducing part can only use the new semantics if the peer confirmed


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: