AMR PT (was RE: [AVT] The need for Offer/Answer sections in RTP payload forma t specifications)

[Franceschini Guido <[e-mail]>]

Dear all,

since I have just read that you are considering to update RFC3267, here is another possible issue.

I am recently tracking an interoperability problem with my implementation of RFC3267, which uses the Dynamic PT.
The problem is that the other equipment uses the static PT=3, assigned to GSM according to RFC3551.

I have only found this statement on PT in RFC3267 :

"The assignment of an RTP payload type for this new packet format is
outside the scope of this document, and will not be specified here.
It is expected that the RTP profile under which this payload format
is being used will assign a payload type for this encoding or specify
that the payload type is to be bound dynamically."

Therefore my question is: shall we use the static PT=3 or the dynamic PT ?

Thanks in advance
Guido Franceschini

TILAB - Multimedia Division
Via G.Reiss Romoli 274
I-10148 Torino, Italy
tel + 39 011 228 6137
fax + 39 011 228 6299



-----Original Message-----
From: [e-mail] [mailto:[e-mail]]On Behalf Of Magnus
Westerlund
Sent: Tuesday, January 27, 2004 11:57 AM
To: Belling Thomas
Cc: [e-mail]
Subject: Re: [AVT] The need for Offer/Answer sections in RTP payload
forma t specifications


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


====================================================================
CONFIDENTIALITY NOTICE
This message and its attachments are addressed solely to the persons
above and may contain confidential information. If you have received
the message in error, be informed that any use of the content hereof
is prohibited. Please return it immediately to the sender and delete
the message. Should you have any questions, please contact us by
replying to [e-mail]. Thank you
====================================================================

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