[rtcweb] AMR and max-red in draft-ietf-rtcweb-fec

[Magnus Westerlund <[e-mail]>]

Hi,

As raised in the WG session there are where an open issue if there need 
to be any specification of the AMR/AMR-WB max-red parameter.

So RFC4867 do have the following on offer/answer usage of the parameter:

       -  The parameter "max-red" is a stream property parameter.  For
          send-only or send-recv unicast media streams, the parameter
          declares the limitation on redundancy that the stream sender
          will use.  For recvonly streams, it indicates the desired value
          for the stream sent to the receiver.  The answerer MAY change
          the value, but is RECOMMENDED to use the same limitation as the
          offer declares.  In the case of multicast, the offerer MAY
          declare a limitation; this SHALL be answered using the same
          value.  A media sender using this payload format is RECOMMENDED
          to always include the "max-red" parameter.  This information is
          likely to simplify the media stream handling in the receiver.
          This is especially true if no redundancy will be used, in which
          case "max-red" is set to 0.  As this parameter was not defined
          originally, some senders will not declare this parameter even
          if it will limit or not send redundancy at all.

Most notable is that media senders are RECOMMENDED to include it. Also 
note that it is the sender that indicates the limitation it intends to 
adhere to for the streams using this RTP payload type.

I also like to note that 3GPP in its specification for its Multimedia 
Telephony, has specified that one shall not use a value larger than 220 
ms, and the value should be a multiple of 20 ms.  Please see 3GPP TS 
26.114 version 13.3.0
http://www.3gpp.org/ftp/Specs/archive/26_series/26.114/26114-d30.zip

So from my perspective I think a WebRTC endpoint simply should follow 
the AMR RTP Payload specification when supported and include the 
parameter to indicate the actual upper range of the redundancy it 
intended to use. It is good to know about the limitation that 3GPP has 
defined as one likely reason to support AMR/AMR-WB is to be able to 
interoperate with 3GPP Services.

Thus I would suggest that a small addition to the Section 4.3 text and 
corrections in the first sentence:

OLD:
    For AMR/AMR-WB, support for redundant encoding, and the maximum
    supported depth, are controlled by the 'max-red' parameter, as
    specified in [RFC4867], Section 8.1.

NEW:
    For AMR/AMR-WB, support for redundant encoding, and the maximum
    used depth, is indicated by the 'max-red' parameter, as
    specified in [RFC4867], Section 8.1 and 8.2. The 3GPP Multimedia
    Telephony services specifies a maximum value of 220 ms for
    'max-red', see [3GPP.26.114].


New Informational Reference:

[3GPP.26.114]

<reference anchor="3GPP.26.114"><front><title>IP Multimedia Subsystem 
(IMS); Multimedia telephony; Media handling and 
interaction</title><author><organization>3GPP</organization></author><date 
day="17" month="March" year="2016"/></front><seriesInfo name="3GPP TS" 
value="26.114 13.3.0"/><format type="HTML" 
target="http://www.3gpp.org/ftp/Specs/html-info/26114.htm"/></reference>

Opinions?

Cheers

Magnus Westerlund

----------------------------------------------------------------------
Services, Media and Network features, Ericsson Research EAB/TXM
----------------------------------------------------------------------
Ericsson AB                 | Phone  [phone]
Färögatan 6                 | Mobile [phone]
SE-164 80 Stockholm, Sweden | mailto: [e-mail]
----------------------------------------------------------------------