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

[Magnus Westerlund <[e-mail]>]

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.

> 
> I mean - if a G.711 receiver is able to handle any packet size thrown at
> it, why do we need to put requirements on the sender (apart from "don't
> send bigger packets than the maxptime")? For interoperability with
> non-WebRTC endpoints?

If the above endpoint would be to send 109 samples in each RTP payload
then I think more than one of the current PCMA receivers would fall on
its back. In an WebRTC to WebRTC case, interoperability would be
achieved. However, if you talk about legacy interoperability (across a
gateway) you want to avoid having to basically insert a jitter buffer
and reconstitute the RTP payloads into something that that system
supports. That is why I suggest that certain common sizes an WebRTC
implementation MUST be capable of producing.

> 
> Of course, I do have a question, now that all the ptime and maxtime
> definitions have been put on the table:
> 
> Is it true that ptime and maxptime only specify the SDP sender's
> declaration of his desires for incoming packet streams? That is, that
> there is nowhere specified what the sender intends to send? I think that
> is true for ptime in RFC 3264 offer/answer, and would assume that the
> same is true for maxptime.

Yes, there are no attribute for its intended send direction unless the
m= block is a sendonly/recvonly O/A exchange where the sendonly
direction can kind of indicate it is preference for what it want/will send.

Cheers

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