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

[Magnus Westerlund <[e-mail]>]

Hi Thomas,

Belling Thomas wrote:

>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
>
>  
>

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 

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