Subject: [rtcweb] Work progress on draft-ietf-rtcweb-audio-codecs-for-interop

From: <[email-masked]>
Date: Fri, 10 Oct 2014 14:25:21 +0000

Dear all,

This document (http://tools.ietf.org/id/draft-proust-rtcweb-audio-codecs-for-interop-00.txt) being now a shared working document, I would be happy to get the views of the Group on how to jointly progress and improve it.

In order to trigger this discussion, I would propose the following modifications with 2 main purposes:
1) Remove any reference to "legacy" (and the corresponding definition section n°3): Even with the definition in section 3, this word "legacy" remains unclear and not really needed for the understanding of this draft: there are no reasons to limit the possible WebRTC interoperability use cases to "legacy" interop assuming we know clearly what "legacy" covers: any interoperability could be relevant if justified by real and significant use cases.
2) Emphasize and detail for AMR and AMR-WB some concrete points related to codec offer that are important for interoperability (which is indeed the core motivation of this draft)

As Editor of the document, I would be happy to consider any other additional text you may propose and include it in the document if agreeable by the Group

Best regards

Stéphane

-------------------------------------------------------------------------------------------
Proposed changes:

Modif 1
Title
[Additional WebRTC audio codecs for interoperability with legacy networks. ]
-> 
[Additional WebRTC audio codecs for interoperability. ]

Modif 2
[3.  Definitions - Legacy networks... ] -> removed

Modif 3
[4.  Rationale for additional WebRTC codecs
  ...The WebRTC technology is however expected to have more extended usage
  to communicate with  other types of clients.  It can be used for instance as an
  Access  technology to 3GPP IMS services or to interoperate with fixed or
   mobile VoIP legacy HD voice service...]
->
[4.  Rationale for additional WebRTC codecs
   ...The WebRTC technology is however expected to be used to communicate with
   other types of clients using other technologies. It can be used for instance
   as an access technology to 3GPP IMS services (e.g. VoLTE, ViLTE) or to interoperate with fixed or
   mobile Circuit Switched or VoIP services like mobile 3GPP 3G/2G Circuit
   Switched voice or DECT based VoIP telephony...]

Modif 4
Text added to section [5.1.3 Guidelines for AMR-WB usage and implementation with WebRTC]
[ In order to maximize the possibility of successful call establishment for WebRTC client offering AMR-WB it is important that the WebRTC client: 
-   Offer AMR in addition to AMR-WB with AMR-WB, being a wideband codec, 
     listed first as preferred payload type with respect to other narrow band
    codecs (AMR, G.711 .) and with Bandwidth Efficient payload format preferred.	
-  Be capable of operating AMR-WB with any subset of the nine codec modes and
    source controlled rate operation.
- Offer at least one AMR-WB configuration with parameter settings as defined
   in Table 6.1 and in Table 6.2 of [TS26.114].In order to maximize the
   interoperability and quality this offer do not restrict the codec modes
   offered. Restrictions in the use of codec modes may be included in the answer ]

Modif 5
Text added to section [5.2.3.  Guidelines for AMR usage and implementation with WebRTC]
[In order to maximize the possibility of successful call establishment for WebRTC
  client offering AMR, it is important that the WebRTC client: 
-  Be capable of operating AMR with any subset of the eight codec modes and
   source controlled rate operation.
- Offer at least one configuration with parameter settings as defined in
   Table 6.1 and in Table 6.2 of [TS26.114].In order to maximize the
   interoperability and quality this offer shall not restrict AMR codec modes
   offered. Restrictions in the use of codec modes may be included in the answer.

 For convenience, I attach a version in Word format with changes as revision marks

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.