Re: [rtcweb] Number of samples (ptime) to be supported by required codecs (draft-ietf-rtcweb-audio-05)

[Harald Alvestrand <[e-mail]>]

On 02/25/2014 11:23 AM, Magnus Westerlund wrote:
> On 2014-02-19 19:11, Harald Alvestrand wrote:
>> On 02/19/2014 09:16 AM, Magnus Westerlund wrote:
>>> On 2014-02-18 23:58, Harald Alvestrand wrote:
>>>> I may be a little simple-minded, but if we have a recommendation that
>>>> receivers MUST be able to receive all packetizations of G.711 and OPUS
>>>> up to 200 ms per packet, and that receivers should signal this by
>>>> sending "a=maxptime:200" in their SDP, what situations exist where
>>>> interoperability is not going to be achieved?
>>> Interoperability is going to be achieve in the direction towards this
>>> endpoint. The question is if we achieve interoperability in the
>>> direction from that endpoint.
>> So, given that there is nothing in the G.711 specification about which
>> sample sizes a G.711 receiver has to support - the right approach seems
>> to be to amend the G.711 MIME registration with this information.
> Yes, it would for the future. But considering the wide-spread deployment
> of this payload format I don't see that having any short term effect on
> the interoperability.
>
> Also, the recommendations are actually context dependent. Thus, it is
> not obvious that a single recommendation is suitable.
>
>> This is not a WebRTC issue; it is an absence of specification for the
>> non-WebRTC devices that use G.711. The RTCWEB specifications can
>> reasonably be expected to point to existing information about this
>> issue; it is not reasonable (in my mind) that the RTCWEB WG decide what
>> these values should be.
>>
> I would argue for this consideration based on that this is done in the
> WebRTC context, not any other context.

For which value of "this" is that true?

All other contexts that use G.711 send packets with a certain ptime 
(which determines the number of samples per packet).

It seems that all other contexts have managed to survive without a 
specification of which ptime it makes sense to send, except for an upper 
bound (maxptime).

When this situation occurs, usually one of two things is happening:

- There's an agreement not captured in the standard, which all 
participants follow.
- The choice doesn't matter for interoperability.

If the second is the case, I think the RTCWEB specification needs to say 
nothing.
If the first is the case, the agreement not captured in the standard 
needs to be captured in a standard. But this is not an RTCWEB standard.

        Harald