RE: [AVT] The need for Offer/Answer sections in RTP payload forma t specifications

[Belling Thomas <[e-mail]>]

Dear Magnus and Collin,

thank you for this initiative.
We also had some internal dicussions about the AMR RTP payload format, RFC 3267, with that respect.
Is there any intention to remmedy this, e.g. by updating the RFC or writing an additional one?

Best regards, Thomas


----------------------------------
Dr. Thomas Belling
Siemens AG           
Sankt-Martin-Str. 76 
D-81541 München Germany
ICM N PG SP ST N1
MCH M 34 307
Tel     [phone]
Fax     [phone]
Mobile  [phone]
Email   [e-mail]




-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On Behalf Of Magnus Westerlund
Sent: Monday, January 26, 2004 2:54 PM
To: [e-mail]
Cc: Colin Perkins
Subject: [AVT] The need for Offer/Answer sections in RTP payload format specifications


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 [phone]
Torshamsgatan 23           | Fax   [phone]
S-164 80 Stockholm, Sweden | mailto: [e-mail]





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

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