Subject: [AVTCORE] WG last call on draft-ietf-avtcore-avp-codecs-01

From: Magnus Westerlund <[email-masked]>
Date: Tue, 12 Mar 2013 15:02:53 -0400

WG,

This is to announce the start of a WG last call on:

Update to Recommended Codecs for the RTP Profile for Audio and Video
Conferences with Minimal Control (RTP/AVP) to be published as a proposed
standard.

Document can be retrieved here:
https://datatracker.ietf.org/doc/draft-ietf-avtcore-avp-codecs

Please provide any feedback by the 31st of March.

Regards

Magnus Westerlund
WG chair

----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone  +46 10 7148287
Färögatan 6                | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto: [email-masked]
----------------------------------------------------------------------

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Tue, 12 Mar 2013 20:40:11 +0000

I'm trying to parse the final sentence of the change made to RFC 3551.

Essentially this i-d modifies:

"   Audio applications operating under this profile SHOULD, at a minimum,
   be able to send and/or receive payload types 0 (PCMU) and 5 (DVI4).
   This allows interoperability without format negotiation and ensures
   successful negotiation with a conference control protocol."

To become:

"   Audio applications operating under this profile SHOULD, at a minimum,
   be able to send and/or receive payload type 0 (PCMU).
   This allows interoperability without format negotiation and ensures
   successful negotiation with a conference control protocol. Some
   environments MAY make support for PCMU mandatory."

What the final sentence currently says is that some environments provide an option to make support for PCMU mandatory, which implies that other environments do not provide such an option. Neither of those make sense to me and there I believe that cannot be the meaning.

I suspect we are looking for sentence that looks more like "Some environments REQUIRE support for PCMU", but I am not sure if there is an "only" floating around in there somewhere.

Regards

Keith

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Magnus Westerlund
> Sent: 12 March 2013 19:03
> To: IETF AVTCore WG
> Subject: [AVTCORE] WG last call on draft-ietf-avtcore-avp-codecs-01
> 
> WG,
> 
> _______________________________________________
> Audio/Video Transport Core Maintenance
> [email-masked]
> https://www.ietf.org/mailman/listinfo/avt

---

From: Colin Perkins <[email-masked]>
Date: Fri, 15 Mar 2013 14:05:48 -0400

On 12 Mar 2013, at 15:02, Magnus Westerlund wrote:
> Update to Recommended Codecs for the RTP Profile for Audio and Video Conferences with Minimal Control (RTP/AVP) to be published as a proposed standard.
> 

I just have a minor nit: the profile names are "RTP/AVP", "RTP/SAVP", "RTP/AVPF", and "RTP/SAVPF", not just "AVP", "SAVP", "AVPF", and "SAVPF"; it would be good if the terminology in the draft was updated to match this. Otherwise, looks good.

-- 
Colin Perkins
http://csperkins.org/

---

From: Colin Perkins <[email-masked]>
Date: Fri, 15 Mar 2013 13:59:36 -0400

> I suspect we are looking for sentence that looks more like "Some environments REQUIRE support for PCMU", but I am not sure if there is an "only" floating around in there somewhere.

I don't think the draft ought to say "only". This sentence looks to be addressing the RTCWeb use case, which makes PCMU mandatory to implement but also allows other codecs. 

To my reading, "Some environments MAY make support for PCMU mandatory" and "Some environments REQUIRE support for PCMU" are equivalent, but I have no objection to the change if you think it clearer.

-- 
Colin Perkins
http://csperkins.org/

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Tue, 19 Mar 2013 17:15:22 +0000

I'm still confused.

Surely PCMU0 was recommended before this update and is recommended now.

DVI4 was recommended before this update and is now optional.

I guess the result of that is that I can be conformant but implement neither, although it will not be a terribly useful implementation.

Regards

Keith

> From: Colin Perkins [mailto:[email-masked]]
> Sent: 15 March 2013 18:00
> To: DRAGE, Keith (Keith)
> Cc: Magnus Westerlund; IETF AVTCore WG
> Subject: Re: [AVTCORE] WG last call on draft-ietf-avtcore-avp-codecs-01
> 
> > What the final sentence currently says is that some environments provide
> an option to make support for PCMU mandatory, which implies that other
> environments do not provide such an option. Neither of those make sense to
> me and there I believe that cannot be the meaning.
> >
> > I suspect we are looking for sentence that looks more like "Some
> environments REQUIRE support for PCMU", but I am not sure if there is an
> "only" floating around in there somewhere.
> 
> 
> I don't think the draft ought to say "only". This sentence looks to be
> addressing the RTCWeb use case, which makes PCMU mandatory to implement
> but also allows other codecs.
> 
> To my reading, "Some environments MAY make support for PCMU mandatory" and
> "Some environments REQUIRE support for PCMU" are equivalent, but I have no
> objection to the change if you think it clearer.
> 
> --
> Colin Perkins
> http://csperkins.org/
> 
>

---

From: "Somogyi, Gabor (NSN - HU/Budapest)" <[email-masked]>
Date: Wed, 20 Mar 2013 14:06:25 +0000

RFC 1890 (obsoleted by 3551):
   Audio applications operating under this profile should, at minimum,
   be able to send and receive payload types 0  (PCMU)  and 5 (DVI4).

Maybe I am a little bit late, as RFC 1890 was finalized in 1996. Still, my question is why PCMU should be supported, while PCMA is absolutely optional?

As far as I know in traditional telecom networks G.711 u-Law (PCMU) is used in North America and Japan only, while A-law is used by the vast majority. And when interconnecting A-law and u-Law regions, then A-Law is used. That suggests that supporting PCMA is at least as important as PCMU.

Maybe I answered my own question referring to "traditional telecom networks". I have no access to VoIP / IMS statistics. What is the usage ratio between PCMU and PCMA nowadays? And do you see any firm trend in royalty and patent free codec usage, such as Opus? I am just asking, because if you plan decades ahead, then writing that a high bandwidth but low quality G.711 SHOULD be supported sounds a bit like living in the 20th century. Well, actually in the pre-1980 era, as on radio networks, such as GSM, at least the bandwidth was optimized. And "modern" wireless devices, such as 3GPP LTE clients may not support PCMA/PCMU at all, even though this RFC draft applies to them. (See 3GPP TS 26.114 section 5.2 "Codecs for MTSI clients in terminals".)

All in all, I may say that supporting PCMU or PCMA is RECOMMENDED, but definitely remove SHOULD. 

BR,
Gabor Somogyi

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of ext DRAGE, Keith (Keith)
Sent: Tuesday, March 19, 2013 6:15 PM
To: Colin Perkins
Cc: Magnus Westerlund; IETF AVTCore WG
Subject: Re: [AVTCORE] WG last call on draft-ietf-avtcore-avp-codecs-01

I'm still confused.

Regards

Keith

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Wed, 20 Mar 2013 14:11:04 +0000

-----Original Message-----
From: <Somogyi>, "Gabor   (NSN - HU/Budapest)" <[email-masked]>
Date: Wednesday, March 20, 2013 4:06 PM
To: Keith 'DRAGE <[email-masked]>, Colin Perkins
<[email-masked]>, "[email-masked]" <[email-masked]>
Cc: Magnus Westerlund <[email-masked]>
Subject: Re: [AVTCORE] WG last call on draft-ietf-avtcore-avp-codecs-01

>Maybe I am a little bit late, as RFC 1890 was finalized in 1996. Still,
>my question is why PCMU should be supported, while PCMA is absolutely
>optional?
>
>As far as I know in traditional telecom networks G.711 u-Law (PCMU) is
>used in North America and Japan only, while A-law is used by the vast
>majority. And when interconnecting A-law and u-Law regions, then A-Law is
>used. That suggests that supporting PCMA is at least as important as PCMU.
>
>Maybe I answered my own question referring to "traditional telecom
>networks". I have no access to VoIP / IMS statistics. What is the usage
>ratio between PCMU and PCMA nowadays? And do you see any firm trend in
>royalty and patent free codec usage, such as Opus? I am just asking,
>because if you plan decades ahead, then writing that a high bandwidth but
>low quality G.711 SHOULD be supported sounds a bit like living in the
>20th century. Well, actually in the pre-1980 era, as on radio networks,
>such as GSM, at least the bandwidth was optimized. And "modern" wireless
>devices, such as 3GPP LTE clients may not support PCMA/PCMU at all, even
>though this RFC draft applies to them. (See 3GPP TS 26.114 section 5.2
>"Codecs for MTSI clients in terminals".)
>

From 2119 perspective, RECOMMENDED and SHOULD are identical.

>I guess the result of that is that I can be conformant but implement
>neither, although it will not be a terribly useful implementation.
>
>Regards
>
>Keith
>
>
>

---

From: "Somogyi, Gabor (NSN - HU/Budapest)" <[email-masked]>
Date: Thu, 21 Mar 2013 13:42:19 +0000

> From 2119 perspective, RECOMMENDED and SHOULD are identical.

Oh, yes, you are right. Then I would simply remove that recommendation entirely.

PCMU was not and will not be supported by quite wide range of RTP/AVP devices for the reasons I mentioned. That recommendation may fit PSTN and enterprise VoIP networks in the US, but generally it does not seem to be right. In other words PCMU is either supported by devices even without having that recommendation or it is not supported regardless of that recommendation. Then why to have it?

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 25 Mar 2013 09:49:06 +0100

WG,

Here is my individual review of the draft.

1. The Abstract must not contain citations, see 3.1.B of the
ID-checklist: https://www.ietf.org/id-info/checklist.html Instead use
title or abbreveitaded title to make clear what is referred to.

2. Section 3 and 3.1:

I believe that this section would be clearer if it was presented as:

3.  Updates to RFC 3551

   The following text of [RFC3551] is hereby updated as set forth below
   in Section 3.1:

   Audio applications operating under this profile SHOULD, at a minimum,
   be able to send and/or receive payload types 0 (PCMU) and 5 (DVI4).
   This allows interoperability without format negotiation and ensures
   successful negotiation with a conference control protocol.

3.1.  Updates to Section 6

   In the final paragraph of Section 6, replace, "payload types 0 (PCMU)
   and 5 (DVI4)," with "payload type 0 (PCMU)."  Also, add a final
   sentence to this paragraph that states, "Some environments MAY make
   support for PCMU mandatory." Resulting in the following paragraph:

   Audio applications operating under this profile SHOULD, at a minimum,
   be able to send and/or receive payload type 0 (PCMU). This allows
   interoperability without format negotiation and ensures successful
   negotiation with a conference control protocol. Some environments
   MAY make support for PCMU mandatory.

---- end of suggested text ----

Note, this does not take the other comments or mailing list discussion
into account.

Cheers

Magnus

-- 

Magnus Westerlund