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

[Magnus Westerlund <[e-mail]>]

On 2014-03-01 16:47, Harald Alvestrand wrote:
> 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.
> 

I appear to be in the rough on this. I don't expect any real issues with
this as long as implementations do sane things. (I was tempted to write
"the right thing (TM)".

Magnus Westerlund

----------------------------------------------------------------------
Services, Media and Network features, Ericsson Research EAB/TXM
----------------------------------------------------------------------
Ericsson AB                 | Phone  [phone]
Färögatan 6                 | Mobile [phone]
SE-164 80 Stockholm, Sweden | mailto: [e-mail]
----------------------------------------------------------------------