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

From: Magnus Westerlund <[email-masked]>
Date: Mon, 26 Jan 2004 14:53:40 +0100

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: [email-masked]

_______________________________________________
Audio/Video Transport Working Group
[email-masked]
https://www1.ietf.org/mailman/listinfo/avt

---

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 28 Jan 2004 17:30:14 -0500

Magnus,

This is a good thing. One point I would add to it is this. The 
offer/answer model has two ways you can interpret parameters that 
occur in SDP. Either they are *negotiated*, such that the aim of 
offer/answer is to achieve a common value(s) for the parameters that 
are shared between both sides, and the other is simply a statement of 
"this is what I am going to use", and both sides can have totally 
different values. This is called "declarative". It is important that 
the SDP usage section be very clear on what the intended semantic is.

As examples, the set of codecs is negotiated, but the packetization 
intervals (ptime) are declarative.

-Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                600 Lanidex Plaza
Chief Technology Officer                    Parsippany, NJ 07054-2711
dynamicsoft
[email-masked]                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com