[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [AVT] The need for Offer/Answer sections in RTP payload formatspecifications



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.

Magnus Westerlund wrote:

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

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


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