Re: [rtcweb] JSEP: "simple" SDP subset?

On Thu, Feb 16, 2012 at 8:02 PM, Bernard Aboba <bernard_aboba@hotmail.com>wrote:

> While it’s true that JSEP is a step forward compared with the previous
> API, there Is still something that bothers me about using SDP in the API:
> do we understand what SDP subset will be supported by JSEP
> implementations?  Or are we setting ourselves up for a nasty
> interoperability problem?
>

I think this is pretty important to nail down; as we've gotten down into
the details, we've realized that we don't all mean the same thing when we
consider how we will represent "multiple video sources" or "video
resolution negotiation" in SDP.

I think http://tools.ietf.org/html/draft-cbran-rtcweb-protocols-00 was a
good first step regarding what WebRTC v1 "Baseline" should include, but we
need to be considerably more specific.

> ****
>
> ** **
>
> When people talk about SDP on this list, they refer to RFC 3264
> offer/answer, but typically don’t mention all the SDP extension documents
> that have had inconsistent takeup since then.   This is a bit like having a
> parent show off a baby picture of their child, saying “isn’t she cute?”
> while neglecting to mention that the picture is 30 years old, and that the
> “baby” is now living in a trailer in North Dakota with their 5th husband,
> 8 children, and 6 cats. ****
>
> ** **
>
> One of the things I like about JSEP is that the SDP produced by
> createOffer() could conceivably be simpler than what you’d send over the
> wire, because it’s just an expression of capabilities, not necessarily a
> full-fledged “offer”.   For example, if we were dealing with a browser that
> could support RTP, SRTP, AVP and AVPF, createOffer () wouldn’t have to
> express everything in RFC 5939 syntax, even if that is what was eventually
> sent.  All the application needs is a list of capabilities expressed in SDP
> from which it could compose an offer itself.  ****
>
> ** **
>
> However, while the SDP produced and consumed by JSEP can be “simpler”,
> things can get complicated in a hurry.  For example:****
>
> ** **
>
> **a.       **What if the user purchased a camera supporting layered
> video?  This is not a hypothetical, these cameras are on the market.  Do we
> know what the m lines look like?****
>
> **b.      **What if the browser can support RTP, SRTP, AVP and AVPF?
> Does createOffer() just use the most sophisticated profile (e.g. RTP/SAVPF)
> to keep things simple, letting the application decide what profile to
> include (e.g. RTP/SAVP if the responder is a legacy device unlikely to
> understand RTP/SAVPF, or capneg if the responder is likely to understand
> it)?****
>
> **c.       **What if the browser supports multiple security schemes (e.g.
> SRTP/SDES and DTLS/SRTP)?  What does the output of createOffer() look like?
> ****
>
> ** **
>
> I am *hoping* that JSEP will never need to utilize RFC 5939 semantics in
> the SDP blobs it produces or consumes, but I can understand if it **may**
> need to utilize SDP extensions not yet standardized (e.g. SRCNAME). ****
>
> ** **
>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
>
>