WebRTC 1.0 compatibility: support for p-time #160

Closed
aboba opened this Issue Nov 4, 2014 · 10 comments

Projects

None yet

5 participants

@aboba
Contributor
aboba commented Nov 4, 2014

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 aboba added the 1.0 label Nov 21, 2014
@aboba
Contributor
aboba commented Nov 30, 2014

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
Contributor
aboba commented Dec 9, 2014

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
Contributor
aboba commented Jan 6, 2015

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;
}

@robin-raymond robin-raymond pushed a commit that referenced this issue Jan 22, 2015
Robin Raymond Updated Section 8.3 to reflect proposed matching rules, reflecting:
#48

Update to the Statistics API, reflecting:
#85

Update on 'automatic' use of scalable video coding, as noted in:
#156

Update to the H.264 parameters, as noted in:
#158

Update to the 'Big Picture', as noted in:
#159

Added support for maxptime, as noted in:
#160

Changed 'RTCIceTransportEvent' to 'RTCIceGathererEvent' as noted in:
#161

Update to RTCRtpUnhandledEvent as noted in:
#163

Added support for RTCIceGatherer.state as noted in:
#164

Revised the text relating to RTCIceTransport.start() as noted in:
#166

Added text relating to DTLS interoperability with WebRTC 1.0, as noted in:
#167

Revised the text relating to RTCDtlsTransport.start() as noted in:
#168

Clarified handling of incoming connectivity checks by the RTCIceGatherer as noted in:
#170

Added a reference to the ICE consent specification, as noted in:
#171
a927ecf
@juberti
juberti commented Jan 27, 2015

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
Contributor

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
Contributor
aboba commented Mar 11, 2015

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.

@aboba aboba closed this Apr 15, 2015
@fippo fippo referenced this issue in fippo/adapter Oct 31, 2016
Open

support ptime and maxptime #39

2 of 3 tasks complete
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment