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

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: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] 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.

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

> -----Original Message-----
> From: Colin Perkins [mailto:csp@csperkins.org]
> 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
> 
> On 12 Mar 2013, at 16:40, DRAGE, Keith (Keith) wrote:
> > 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.
> 
> 
> 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/
> 
> 

_______________________________________________
Audio/Video Transport Core Maintenance
avt@ietf.org
https://www.ietf.org/mailman/listinfo/avt