[AVT] The need for Offer/Answer sections in RTP payload format specifications

Magnus Westerlund <magnus.westerlund@ericsson.com> Tue, 27 January 2004 01:03 UTC

Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA27278 for <avt-archive@odin.ietf.org>; Mon, 26 Jan 2004 20:03:49 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AlHdP-0001nV-16 for avt-archive@odin.ietf.org; Mon, 26 Jan 2004 20:03:20 -0500
Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0R13IuM006892 for avt-archive@odin.ietf.org; Mon, 26 Jan 2004 20:03:18 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AlHdI-0001iX-Si; Mon, 26 Jan 2004 20:03:12 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Al7EZ-0004NC-Bq for avt@optimus.ietf.org; Mon, 26 Jan 2004 08:56:59 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA06132 for <avt@ietf.org>; Mon, 26 Jan 2004 08:56:57 -0500 (EST)
Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Al7EX-00073W-00 for avt@ietf.org; Mon, 26 Jan 2004 08:56:57 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Al7De-000720-00 for avt@ietf.org; Mon, 26 Jan 2004 08:56:02 -0500
Received: from albatross-ext.wise.edt.ericsson.se ([193.180.251.49]) by ietf-mx with esmtp (Exim 4.12) id 1Al7Cz-0006zu-00 for avt@ietf.org; Mon, 26 Jan 2004 08:55:21 -0500
Received: from esealnt613.al.sw.ericsson.se ([153.88.254.125]) by albatross-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i0QDtJqY001679; Mon, 26 Jan 2004 14:55:19 +0100 (MET)
Received: from ericsson.com (research-1fd0e1.ki.sw.ericsson.se [147.214.34.33]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id CZD2V598; Mon, 26 Jan 2004 14:55:19 +0100
Message-ID: <40151BE4.1010503@ericsson.com>
Date: Mon, 26 Jan 2004 14:53:40 +0100
X-Sybari-Space: 00000000 00000000 00000000 00000000
From: Magnus Westerlund <magnus.westerlund@ericsson.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax)
X-Accept-Language: sv, en-us, en
MIME-Version: 1.0
To: avt@ietf.org
CC: Colin Perkins <csp@csperkins.org>
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60
Content-Transfer-Encoding: 7bit
Subject: [AVT] The need for Offer/Answer sections in RTP payload format specifications
Sender: avt-admin@ietf.org
Errors-To: avt-admin@ietf.org
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/avt>, <mailto:avt-request@ietf.org?subject=unsubscribe>
List-Id: Audio/Video Transport Working Group <avt.ietf.org>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/avt>, <mailto:avt-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit

Hi AVT members,

We AVT chairs would like to make all writers of RTP payload format aware
of one thing. There exist a need for most RTP payload formats to have a
section discussing the usage of the MIME parameters in regards to the
SDP Offer and Answer model defined in RFC 3264. This concerns all RTP
payload formats that use parameters to configure either the payload
format itself or the transported codec.

The reason for these is to achieve the best possible interoperability.
And the interoperability is affected in several ways through the use of
MIME defined parameters.
- Configuration of RTP payload formats and codecs: If one end-point A
offers functionality set SA and end-point B offers another functionality
set SB. Then it is possible that SA has no common subset with SB, thus
preventing interoperability.

- Understanding when offered set SA and supported set SB contains
possibilities for sub-setting. Certain offered sets can be subsetted and
still useful. A MIME specification should be explicit about if
parameters can be downgraded or not. For example, an video profile level
specification can be downgraded to a lower level in the response and
still achieve interoperability. However an AMR payload format
configuration parameter like "octet-align" is binary, i.e. requiring one
to support this configuration.

- Possibility to make recommendations on how to form offers that
maximizes interoperability. However this is application dependent and
should normally be kept in an more open terms. However for example for
the AMR payload format can be configured into several usages. For some
applications it does make sense to offer multiple payload types where
the payload format is configured in different way. For example a
streaming server can offer both a octet-aligned only PT and one with
interleaving if they would use offer answer.

Thus we request that authors write an "Offer-Answer model consideration"
in their SDP usage section. This should cover the following:

- How configurations effect the interoperability.
- What parameters that are possible to subset and which are not.
- Recommendations on how to achieve good interoperability.

Comments on this are solicited.

Best Regards

Magnus & Colin

-- 

Magnus Westerlund

Multimedia Technologies, Ericsson Research EAB/TVA/A
----------------------------------------------------------------------
Ericsson AB                | Phone +46 8 4048287
Torshamsgatan 23           | Fax   +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com





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