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

["Somogyi, Gabor (NSN - HU/Budapest)" <[e-mail]>]

> 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?

-----Original Message-----
From: ext Ali C. Begen (abegen) [mailto:[e-mail]] 
Sent: Wednesday, March 20, 2013 3:11 PM
To: Somogyi, Gabor (NSN - HU/Budapest); DRAGE, Keith (Keith); Colin Perkins; IETF AVTCore WG
Cc: Magnus Westerlund
Subject: Re: [AVTCORE] WG last call on draft-ietf-avtcore-avp-codecs-01

-----Original Message-----
From: <Somogyi>, "Gabor   (NSN - HU/Budapest)" <[e-mail]>
Date: Wednesday, March 20, 2013 4:06 PM
To: Keith 'DRAGE <[e-mail]>, Colin Perkins
<[e-mail]>, "[e-mail]" <[e-mail]>
Cc: Magnus Westerlund <[e-mail]>
Subject: 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.

From 2119 perspective, RECOMMENDED and SHOULD are identical.

>
>BR,
>Gabor Somogyi
>
>-----Original Message-----
>From: [e-mail] [mailto:[e-mail]] 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:[e-mail]]
>> 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
>[e-mail]
>https://www.ietf.org/mailman/listinfo/avt
>_______________________________________________
>Audio/Video Transport Core Maintenance
>[e-mail]
>https://www.ietf.org/mailman/listinfo/avt
>