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

From: Belling Thomas <[email-masked]>
Date: Tue, 27 Jan 2004 11:23:01 +0100

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     +49 89 636 75207
Fax     +49 89 636 75577
Mobile  +49 172 2974678
Email   [email-masked]

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Magnus Westerlund
Sent: Monday, January 26, 2004 2:54 PM
To: [email-masked]
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 +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

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

---

From: Magnus Westerlund <[email-masked]>
Date: Tue, 27 Jan 2004 11:56:52 +0100

Hi Thomas,

>writing an additional one?

We authors are planning on updating RFC 3267 to go draft standard, then 
we can address this.. We will also fix some small issues with the text, 
however the current errata for RFC 3267 is very short.

I have written an initial proposal for this text which I include below, 
however please remember that it is a first version. Comments are welcome.

Cheers

Magnus

---------- Text Proposal for new chapter 8.3 -------------
8.3. Mapping MIME Parameters into SDP

  The information carried in the MIME media type specification has a
  specific mapping to fields in the Session Description Protocol (SDP)
  [11], which is commonly used to describe RTP sessions.  When SDP is
  used to specify sessions employing the AMR or AMR-WB codec, the
  mapping is as follows:

     -  The MIME type ("audio") goes in SDP "m=" as the media name.

     -  The MIME subtype (payload format name) goes in SDP "a=rtpmap"
        as the encoding name.  The RTP clock rate in "a=rtpmap" MUST be
        8000 for AMR and 16000 for AMR-WB, and the encoding parameters
        (number of channels) MUST either be explicitly set to N or
        omitted, implying a default value of 1.  The values of N that
        are allowed is specified in Section 4.1 in [24].

     -  The parameters "ptime" and "maxptime" go in the SDP "a=ptime"
        and "a=maxptime" attributes, respectively.

     -  Any remaining parameters go in the SDP "a=fmtp" attribute by
        copying them directly from the MIME media type string as a
        semicolon separated list of parameter=value pairs.

8.3.1 Offer-Answer Model Considerations

To achieve good interoperability with the AMR or the AMR-WB RTP payload
in an Offer-Answer usage in SDP the following considerations should be made:

- Each combination of the RTP payload configuration parameters
(octet-align, crc, robust-sorting, interleaving, and channels) is unique
in its bit-pattern and not compatible with any other combination. Due to
the application dependent nature of any configuration and they being
optionally to implement, care must be taken. When creating an offer in
an application desiring to use the more advance features (crc,
robust-sorting, interleaving, or more than one channel), the offerer is
RECOMMENDED to also offer an payload type containing only the
octet-align configuration with a single channel. If multiple
configurations are of interest to the application they may all be
offered, however care should be taken to not offer too many payload types.

- The parameters "mode-set", "mode-change-period", and
"mode-change-neighbor" SHOULD only be used when really needed due to
gateway scenarios, however their nature are such that they must either
be supported or no interoperability exist.

- The parameters "maxptime" and "ptime" should in most cases not effect
the interoperability, however the setting of the parameters can effect
the performance of the application.

8.3.2 Examples

  Some example SDP session descriptions utilizing AMR and AMR-WB
  encodings follow.  In these examples, long a=fmtp lines are folded to
  meet the column width constraints of this document; the backslash
  ("\") at the end of a line and the carriage return that follows it
  should be ignored.

  Example of usage of AMR in a possible GSM gateway scenario:

   m=audio 49120 RTP/AVP 97
   a=rtpmap:97 AMR/8000/1
   a=fmtp:97 mode-set=0,2,5,7; mode-change-period=2; \
     mode-change-neighbor=1
   a=maxptime:20

  Example of usage of AMR-WB in a possible VoIP scenario where UEP may
be used (99) and a fallback declaration (98):

   m=audio 49120 RTP/AVP 99 98
   a=rtpmap:99 AMR-WB/16000
   a=fmtp:99 octet-align=1; crc=1
   a=rtpmap:98 AMR-WB/16000
   a=fmtp:98 octet-align=1

  Example of usage of AMR-WB in a possible streaming scenario (two
  channel stereo):

   m=audio 49120 RTP/AVP 99 100
   a=rtpmap:99 AMR-WB/16000/2
   a=fmtp:99 interleaving=30
   a=maxptime:100

  Note that the payload format (encoding) names are commonly shown in
  upper case.  MIME subtypes are commonly shown in lower case.  These
  names are case-insensitive in both places.  Similarly, parameter
  names are case-insensitive both in MIME types and in the default
  mapping to the SDP a=fmtp attribute.

-- 

Magnus Westerlund