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

From: Bernard Aboba <[email-masked]>
Date: Thu, 16 Feb 2012 17:02:42 -0800

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?

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).

---

From: Justin Uberti <[email-masked]>
Date: Thu, 16 Feb 2012 21:52:20 -0500

On Thu, Feb 16, 2012 at 8:02 PM, Bernard Aboba <[email-masked]>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.

> ****
> ** **
> offer/answer, but typically don’t mention all the SDP extension documents
> parent show off a baby picture of their child, saying “isn’t she cute?”
> “baby” is now living in a trailer in North Dakota with their 5th husband,
> 8 children, and 6 cats. ****
>
> ** **
>
> 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
> 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.
> ****
> ** **
> 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtcweb
>
>

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 17 Feb 2012 08:40:46 +0100

Hi, 

> 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?
>
> 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). 

In my opinion, the "hints" could be use by the JS app to indicate what SDP extensions it is able/willing to handle. 
That way, even if the browser/API supports all the SDP extensions in the world, a simple app would not have to.

Regards,

Christer

---

From: "Hutton, Andrew" <[email-masked]>
Date: Fri, 17 Feb 2012 11:33:00 +0100

Hi,

> offer/answer, but typically don't mention
> createOffer() could conceivably be simpler
> > full-fledged "offer".   For example, if we were dealing with a
> browser that could support RTP, SRTP, AVP
> > 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?
> >
> 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)?
> >
> > I am hoping that JSEP will never need to utilize RFC 5939 semantics
> in the SDP blobs it produces or consumes, but I can
> In my opinion, the "hints" could be use by the JS app to indicate what
> SDP extensions it is able/willing to handle.
> That way, even if the browser/API supports all the SDP extensions in
> the world, a simple app would not have to.
> 

[Andy] - If a simple app is one that does not have to worry about interworking then I assume it would not care about SDP probably just passing the SDP blob without change between browsers. However if the app has to handle complex interworking scenarios then it really would help if there is a clear description of the SDP profile which the browser supports.  It was clear from the discussion at the interim that we need to nail some of the SDP options down.

Surely the aim should be to keep the SDP subset that the browser needs to support reasonably small and well defined and leave the complicated interworking stuff to the applications that need to do that.