Subject: [rtcweb] RTP Usage: Reducing dependency on codec specifications

From: Magnus Westerlund <[email-masked]>
Date: Fri, 19 Apr 2013 15:38:40 +0200

WG,
As Individual and Editor of the WG document:

The latest version of the RTP usage for WebRTC says:

4.3.  Choice of RTP Payload Formats

   Implementations MUST follow the WebRTC Audio Codec and Processing
   Requirements [I-D.ietf-rtcweb-audio] and SHOULD follow the updated
   recommendations for audio codecs in the RTP/AVP Profile
   [I-D.ietf-avtcore-avp-codecs].  Support for other audio codecs is
   OPTIONAL.

   (tbd: the mandatory to implement video codec is not yet decided)

>From this I would like to make two observations.

The first that the audio codecs draft should actually include the RTP
payload format specification for the codecs it specifies to support. I
strongly think this is the right place because if one later changes the
codec requirements then one only need to update the audio specification
rather than also RTP usage.

Secondly, that it might be best remove strong normative dependencies on
the codec specifications in the RTP usage. We can clearly include
informative references saying that the codec specification for WebRTC
will specify the RTP payload formats to use. This also reduced cross
referencing and dependencies between these specifications. Thus allowing
us to move forward with the RTP usage independent on any continued video
or audio codec discussions that may occur in the WG.

I propose that we change the first paragraph and remove the open issue
(tbd) listed after so the text instead reads:

4.3.  Choice of RTP Payload Formats

The RTP payload formats to support depends on the media codecs that an
implementation supports for media transport in WebRTC. These includes
any codec mandated by other WebRTC codec specifications, such as the
audio codecs specified in WebRTC Audio Codec and Processing Requirements
[I-D.ietf-rtcweb-audio], or recommended by the RTP profile in use, see
Update to Recommended Codecs for the RTP Profile for Audio and Video
Conferences with Minimal Control (RTP/AVP)
[I-D.ietf-avtcore-avp-codecs]. Support of any additional codecs and
their RTP payload formats is OPTIONAL.

Thoughts about this?

I intended to suggest some text for the audio codec draft to improve its
specification of the RTP payload formats related to the codecs.

Cheers

Magnus Westerlund

----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone  +46 10 7148287
Färögatan 6                | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto: [email-masked]
----------------------------------------------------------------------

---

From: "Timothy B. Terriberry" <[email-masked]>
Date: Fri, 19 Apr 2013 10:09:55 -0700

> implementation supports for media transport in WebRTC. These includes

s/includes/include/

> [I-D.ietf-rtcweb-audio], or recommended by the RTP profile in use, see

"see" should probably begin a new sentence.

> their RTP payload formats is OPTIONAL.

This sounds reasonable to me.

---

From: Bernard Aboba <[email-masked]>
Date: Fri, 19 Apr 2013 17:42:19 -0700

> rather than also RTP usage.
[BA] I agree with this. 
> or audio codec discussions that may occur in the WG.>>> Thoughts about this?
> 
[BA] While I think this makes sense and I sympathize with the goal, in practice truly making the RTP usage doc codec-independent could turn out to be more difficult than it first appears.  One thing I have been noticing is that the approach to congestion control as well as loss recovery strategies (e.g. retransmission vs. FEC, adapting resolution/framerate via SDP vs. RTCP, use of AVPF feedback messages, etc.) may differ markedly between implementations of VP8 and H.264.  This raises the nasty possibility that even if the MTI codec disagreements were to be resolved (or if browsers were to support codec extensibility) that we'd still be with saddled with persistent video interoperability problems.

---

From: Harald Alvestrand <[email-masked]>
Date: Sat, 20 Apr 2013 22:19:06 +0200

I may be too simple-minded, but why isn't the correct reference to 
codecs in "RTP usage" a simple note saying

"Mandatory to implement codecs for RTCWEB are not specified in this memo."

or even less than that:

""

?

I simply don't see why it should need to be mentioned in this document.

On 04/19/2013 03:38 PM, Magnus Westerlund wrote:
> _______________________________________________
> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtcweb

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 22 Apr 2013 15:41:22 +0200

On 2013-04-20 02:42, Bernard Aboba wrote:
> [BA] While I think this makes sense and I sympathize with the goal, in
> practice truly making the RTP usage doc codec-independent could turn out
> to be more difficult than it first appears.  One thing I have been
> noticing is that the approach to congestion control as well as loss
> recovery strategies (e.g. retransmission vs. FEC, adapting
> resolution/framerate via SDP vs. RTCP, use of AVPF feedback messages,
> etc.) may differ markedly between implementations of VP8 and H.264.

I don't think this is primary difference between VP8 and H.264, I think
it is a highly a question of usage and implementation. Yes, there are
some things that might be more or less usable with a particular codec,
but can you point to any mechanism that is usable by one video codec
that isn't usable by another one?

I at least don't intended to make this media type independent when
necessary to make it clear what tools are suitable for which media type.

>  This raises the nasty possibility that even if the MTI codec
> disagreements were to be resolved (or if browsers were to support codec
> extensibility) that we'd still be with saddled with persistent video
> interoperability problems.  
> 

When it comes to interoperability I think my main concern is that WebRTC
implementations select different strategies and lock down so hard
towards their own strategy that the can't handle interoperating with a
peer implementation that has a different strategy.

Do you have specific issues that we could try to improve by being clear
on how they expected to work or make clear that one needs to handle
several different types of behaviors in regards to these?

Cheers

Magnus Westerlund

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 22 Apr 2013 16:12:15 +0200

> "Mandatory to implement codecs for RTCWEB are not specified in this memo."

I would add to this with also making clear that their payload format
also are not specified here.

There reason to include a reference to the AVP profile is that people
appear poorly aware that this contains recommendations. The reference to
the WebRTC audio and corresponding video can clearly be handled by the
Overview document. If others think making this as thin as possible I
will remove these references. What I think is important, as it appears
to be over and over questioned, is that WebRTC is capable of using any
codec that has an RTP payload format and can be negotiated between the
peers.

At least there appear to be support for the notion that the codec
documents should contain the RTP payload format specs for their
specified codecs. This allows me to move ahead with suggestion for such
text to audio.

Cheers

Magnus

-- 

Magnus Westerlund