WebRTC 1.0 compatibility: support for p-time

[aboba]

Currently, ORTC API does not include any capabilities or parameters relating to p-time. This potentially represents a WebRTC 1.0 backward compatibility issue.

[steely-glint]

There are some situations where this would be useful. I'm thinking of lowbandwidth audio only situations - like GSM Edge or BGAN or some TV-whitespace deployments which work much better with bigger less frequent packets.

[pthatcherg]

Should we just put this in RtpCodecParameters.parameters, or should we have
a specific RtpCodecParameters.ptime? Or do we want .minptime and .maxptime?

On Wed Nov 12 2014 at 3:34:03 AM steely-glint notifications@github.com
wrote:

There are some situations where this would be useful. I'm thinking of
lowbandwidth audio only situations - like GSM Edge or BGAN or some
TV-whitespace deployments which work much better with bigger less frequent
packets.

—
Reply to this email directly or view it on GitHub
#160 (comment).

[aboba]

Response on the ORTC list:
http://lists.w3.org/Archives/Public/public-ortc/2014Nov/0005.html

[aboba]

Here is a summary of ptime support in various codecs:
https://www.ietf.org/mail-archive/web/rtcweb/current/msg11485.html

Here is the summary of the recommendations from https://tools.ietf.org/html/draft-ietf-rtcweb-jsep:

Section 5.2.1 (Intial Offers):
Each m= section MUST include the following attribute lines:
...
o For each supported codec, "a=rtpmap" and "a=fmtp" lines, as
specified in [RFC4566], Section 6. For audio, the codecs
specified in [I-D.ietf-rtcweb-audio], Section 3, MUST be be
supported.

o If this m= section is for media with configurable frame sizes,
e.g. audio, an "a=maxptime" line, indicating the smallest of the
maximum supported frame sizes out of all codecs included above, as
specified in [RFC4566], Section 6.

[aboba]

Response on the list:
http://lists.w3.org/Archives/Public/public-ortc/2014Nov/0016.html

[aboba]

Peter Thatcher said:

"Should we just put this in RtpCodecParameters.parameters, or should we have
a specific RtpCodecParameters.ptime? Or do we want .minptime and .maxptime?"

[BA] As noted in Magnus' summary, there are codec-specific ptime capabilities and settings that would be discovered in RtpCodecCapability.parameters and set in RtpCodecParameters.parameters.
However, since the JSEP draft requires " an "a=maxptime" line, indicating the smallest of the maximum supported frame sizes out of all codecs included" it would be useful to have RtpCodecCapability.maxptime and RtpCodecParameters.maxptime so as to make it possible to discover a codec's maxptime, configure it and then compute the smallest of the maxptime values for all codecs.

[aboba]

Peter Thatcher said:

"Should we just put this in RtpCodecParameters.parameters, or should we have a specific RtpCodecParameters.ptime? Or do we want .minptime and .maxptime?"

[BA] Here is a summary of ptime support in various codecs:
https://www.ietf.org/mail-archive/web/rtcweb/current/msg11485.html

And here is the summary of the recommendations from https://tools.ietf.org/html/draft-ietf-rtcweb-jsep:

Section 5.2.1 (Intial Offers):
Each m= section MUST include the following attribute lines:
...
o For each supported codec, "a=rtpmap" and "a=fmtp" lines, as
specified in [RFC4566], Section 6. For audio, the codecs
specified in [I-D.ietf-rtcweb-audio], Section 3, MUST be be
supported.

o If this m= section is for media with configurable frame sizes,
e.g. audio, an "a=maxptime" line, indicating the smallest of the
maximum supported frame sizes out of all codecs included above, as
specified in [RFC4566], Section 6.

As noted in Magnus' summary, there are codec-specific ptime capabilities and settings that could be discovered in RtpCodecCapability.parameters and set in RtpCodecParameters.parameters. However, since the JSEP draft requires " an "a=maxptime" line, indicating the smallest of the maximum supported frame sizes out of all codecs included" it would be useful to have RtpCodecCapability.maxptime and RtpCodecParameters.maxptime so as to make it possible to discover a codec's maxptime, configure it and then compute the smallest of the maxptime values for all codecs.
A proposed resolution would look like this:

partial dictionary RTCRtpCodecCapability {
unsigned long maxptime;
}

partial dictionary RTCRtpCodecParameters {
unsigned long maxptime;
}

[juberti]

Discussed in CG meeting today. Agreement to add two things:

1. RtcCodecCapability.maxptime // the max ptime supported by the codec
2. RtcCodecParameters.maxptime // a way to push in the max ptime supported by the remote side/

This allows one to generate a=maxptime (by taking the minimum value of 1) across all codecs), as well as to receive a=maxptime (by taking the received value and passing it as 2) for all codecs)

Separately, we can consider 3), the notion of a encoding parameter 'ptime', which would directly control the packet size of the encoder, i.e. if we had ptime=1ms, we would only generate 1ms packets, or ptime=100ms generates 100ms packets. Specifically, this is distinct from maxptime, which is just guidance as to "don't go over this maximum". But 3) isn't needed for WebRTC 1.0, so we can figure out the details here later.

[robin-raymond]

To clarify:

RTCCodecCapability.maxptime is a capability of the decoder/receiver but not of the encoder/sender. RTCCodecParameters.maxptime is a setting of encoder/sender but not of the decoder/receiver.

As a result, peers can exchange the maxptime capability of their decoders, and then set the maxptime setting of their encoders appropriately.

[aboba]

Text for Section 9.3.1:
maxptime of type unsigned long
The maximum packetization time supported by the RTCRtpReceiver.

Text for Section 9.6.1:
maxptime of type unsigned long
The maximum packetization time set on the RTCRtpSender. Not specified if unset.