Subject: [rtcweb] (resend) RE: Relaxing SDP O/A (was RE: Agenda requests for Atlanta meeting)

From: Matthew Kaufman <[email-masked]>
Date: Sat, 20 Oct 2012 10:21:51 -0700

(Resending from my personal account as the list server dropped a bunch 
of messages and I will be resending from my personal account a few that 
I think are still particularly relevant)

Harald Alvestrand [[email-masked]]:

 > Because making an interface that makes following an existing practice

 > easy (but does not enforce all the constraints of that practice) is

 > better than making an interface that makes following that practice

 > very complex?

If this myth were correct, it would be a good argument. In practice, the 
JSEP interface (which claims to loosely follow an existing practice) is 
*more difficult* to use when interoperating with endpoints that actually 
follow that practice than the API we proposed does.

In our testing, the amount of Javascript required to unpack the pile of 
SDP that is emitted by an existing implementation of JSEP (the Google 
Chrome beta), pick it apart into what you actually need to interop with 
a real gateway endpoint, exhaustively test what SDP can then be put back 
in to setLocalDescription and setRemoteDescription (as there is no 
specification saying what SDP is and is not allowed here, and no error 
reporting to speak of), and then the signaling on top of that all adds 
up to more than twice as much Javascript as it takes to use our proposed 
direct-manipulation API, create SDP that is compatible with the far end 
you are interoperating with, and start media flowing.

If the existing API actually had a description of what SDP is and is not 
acceptable, and specified an error reporting mechanism that was actually 
helpful for developers, then it would *still* take 2x the Javascript to 
call any endpoint other than one of your own because of the need to 
manipulate the SDP and the need to implement a state machine in 
Javascript while the browser is also keeping a bunch of state internally.

I encourage anyone who cares about interoperability to replicate our 
experiment... build an application using the Chrome beta that calls a 
gateway speaking SIP for signaling and ICE-lite for consent verification 
and see how "easy" it is or isn't.

Matthew Kaufman

---

From: Harald Alvestrand <[email-masked]>
Date: Sun, 21 Oct 2012 00:30:17 +0200

(Chrome developer hat on)
Thanks for the info - can you point to the bugs you filed on these 
issues with our implementation? I'll try to see that they're followed up.

It would be helpful if you specified which endpoint you interoperated 
with, but the most important thing is to show what the SDP was and where 
it was wrong for interoperability.

Frankly, the code in Chrome is a completely new SDP parser/generator, 
and definitely needs testing.

           Harald

On 10/20/2012 07:21 PM, Matthew Kaufman wrote:
> of messages and I will be resending from my personal account a few 
> that I think are still particularly relevant)
>
> If this myth were correct, it would be a good argument. In practice, 
> the JSEP interface (which claims to loosely follow an existing 
> practice) is *more difficult* to use when interoperating with 
> endpoints that actually follow that practice than the API we proposed 
> does.
>
> In our testing, the amount of Javascript required to unpack the pile 
> of SDP that is emitted by an existing implementation of JSEP (the 
> Google Chrome beta), pick it apart into what you actually need to 
> interop with a real gateway endpoint, exhaustively test what SDP can 
> then be put back in to setLocalDescription and setRemoteDescription 
> (as there is no specification saying what SDP is and is not allowed 
> here, and no error reporting to speak of), and then the signaling on 
> top of that all adds up to more than twice as much Javascript as it 
> takes to use our proposed direct-manipulation API, create SDP that is 
> compatible with the far end you are interoperating with, and start 
> media flowing.
>
> If the existing API actually had a description of what SDP is and is 
> not acceptable, and specified an error reporting mechanism that was 
> actually helpful for developers, then it would *still* take 2x the 
> Javascript to call any endpoint other than one of your own because of 
> the need to manipulate the SDP and the need to implement a state 
> machine in Javascript while the browser is also keeping a bunch of 
> state internally.
>
> gateway speaking SIP for signaling and ICE-lite for consent 
> verification and see how "easy" it is or isn't.
>
> Matthew Kaufman
>
>
>
>
> _______________________________________________
> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtcweb

---

From: Bernard Aboba <[email-masked]>
Date: Sat, 20 Oct 2012 16:20:07 -0700

Harald said:
"Thanks for the info - can you point to the bugs you filed on these
      issues with our implementation? I'll try to see that they're
      followed up."

[BA] To determine whether something is a "bug" or a "feature" it helps to have a specification that states what is expected.  Since we're primarily talking about SDP usage within the API rather than what travels over the wire (after all, signaling is out of scope in WebRTC), http://tools.ietf.org/html/draft-nandakumar-rtcweb-sdp is only a baby step toward determining whether the SDP output by createOffer is conformant or whether input to setLocalDescription or setRemoteDescription should be acceptable or not, and if not, what should happen. 
For example,  posting the SDP that is emitted by various createOffer() implementations might enhance the appreciation of the importance of the issue, I am not sure how to evaluate the results without understanding whether that output is expected to be valid SDP or not.  For example, if trickle ICE is used, then perhaps one should not expect createOffer to provide SDP with valid addresses and ports filled in; instead that information is expected to be filled in later.

---

From: Matthew Kaufman <[email-masked]>
Date: Sat, 20 Oct 2012 22:12:22 -0700

On 10/20/2012 4:20 PM, Bernard Aboba wrote:
> issues with our implementation? I'll try to see that they're followed up."
>
> [BA] To determine whether something is a "bug" or a "feature" it helps 
> to have a specification that states what is expected.  Since we're 
> primarily talking about SDP usage within the API rather than what 
> travels over the wire (after all, signaling is out of scope in 
> WebRTC), http://tools.ietf.org/html/draft-nandakumar-rtcweb-sdp is 
> only a baby step toward determining whether the SDP output by 
> createOffer is conformant or whether input to setLocalDescription or 
> setRemoteDescription should be acceptable or not, and if not, what 
> should happen.
>

Precisely the problem. It isn't a "bug" with the Google Chrome beta. It 
is a "bug" with the current specification, which says "see SDP O/A RFC" 
rather than "this is what a browser must allow" or even "this is the 
type of error a browser must throw if the rules aren't followed".

I'll pick some choice examples from some SDP that the latest Chrome beta 
just gave me from createOffer (without pasting the entire blob it 
disgorges):

s=-

Can I add "e=[email-masked]" right after this?

How about a "p=" line?

a=group:BUNDLE audio video

Can I remove this before passing it back to setLocal Description?

a=ice-options:google-ice

How about removing this? Or changing it to 
"a=ice-options:matthew-special-ice"?

a=sendrecv

Can I change it to sendonly?

a=rtcp-mux

Remove this?

a=crypto:1 AES_CM_128_HMAC_SHA1_80 
inline:66AIWBQ/R+UnMc4N/NP/b2hjEB6ydFMMCc8n3DMp

Remove this? Change the key? Set up DTLS-SRTP instead?

a=rtpmap:103 ISAC/16000

Change this to rtpmap: 110 ISAC/16000 because I prefer 110 as the codec ID?

a=ssrc:1018881792 cname:B0VSPpORV75cCTIv

Delete this? Change the ssrc ID because I don't like this one? or the cname?

m=video 1 RTP/SAVPF 100 101 102 c=IN IP4 0.0.0.0

Change this to RTP/SAVP ? [Never mind that "IN IP4 0.0.0.0" is a strange 
thing to have coming from "createOffer"]

NOWHERE in the JSEP specification can I find the answers to these 
questions. That makes working out what is allowed a browser-by-browser 
exhaustive search, which is unacceptable.

Matthew Kaufman

---

From: Harald Alvestrand <[email-masked]>
Date: Sun, 21 Oct 2012 08:51:15 +0200

On 10/21/2012 01:20 AM, Bernard Aboba wrote:
> For example,  posting the SDP that is emitted by various createOffer() 
> implementations might enhance the appreciation of the importance of 
> the issue, I am not sure how to evaluate the results without 
> understanding whether that output is expected to be valid SDP or not. 
>  For example, if trickle ICE is used, then perhaps one should not 
> expect createOffer to provide SDP with valid addresses and ports 
> filled in; instead that information is expected to be filled in later.
Actually all of the issues I've seen in real testing so far have fallen 
into two broad cateories:

- Issues where the endpoints are known to be noninteroperable - for 
instance by requiring ICE, requiring SRTP, or using different video 
codecs. No amount of SDP munging will fix those.
- Issues where the Google implementors have failed to understand some 
subtlety of SDP syntax, encountered an SDP extension that we didn't 
expect to see, or didn't get around to handling that part of the syntax 
yet - for instance when we were sending "s=" instead of "s= ".

When we started out, I expected a host of issues of the type you 
envision - where people who are reading the SDP specs have serious 
differences of opinion about what should be the right outcome - but so 
far, I haven't seen that happening.

Perhaps we haven't gotten to the hard parts yet, or perhaps the SDP 
specification, when used for the basic stuff that we're so far doing, is 
less troublesome than we thought?

That's why I keep on pushing for bugs to be filed - I believe we can 
identify problem areas more easily by saying "when X tries to negotiate 
a connection with Y, A happens, but B should happen instead".
Also, I learn much more from those discussions than a discussion phrased 
in general terms!

                 Harald

---

From: Bernard Aboba <[email-masked]>
Date: Sun, 21 Oct 2012 08:10:21 -0700

Harald said: 

"When we started out, I expected a host of issues of the type you
    envision - where people who are reading the SDP specs have serious
    differences of opinion about what should be the right outcome - but
    so far, I haven't seen that happening."

[BA] Defining what SDP specs are relevant is not difficult.  draft-nandakumar-rtcweb-sdp enumerates the relevant specifications to a good degree of accuracy (I agree with 90+ percent of what is in the draft).   If all we had to do was quibble about which SDP references are MUST/SHOULD/MAY within that document, then with sufficient WG attention, the probability of convergence would be high.  However, this would not cover:

* Expectations for SDP parser resilience.  Experience indicates that this was not sufficiently well described in RFC 3264 and 4566.  For example, my understanding is that Chrome stops parsing in some cases when it hits SDP it does not understand.  While this approach is quite common in SDP implementations (and may not violate 3264/4566 so as to be classifiable as a "bug"), expectations for resilience could be better defined.  
* Error handling.  What happens when the parser detects an error and how do we know what it objected to?  Is an exception or error callback fired?  Does this provide an indication of what SDP lines caused the error? Is there a way to retrieve the SDP that the browser decided to act upon (which may be different from what was input)? 
* Guidance with respect to API usage, both general and specific, such as the questions Mathew mentioned. 

Overall, these questions relate more to the API than to existing or in-progress SDP specifications within IETF, which raises the question of where they would be best addressed.

---

From: Cullen Jennings <[email-masked]>
Date: Sun, 21 Oct 2012 17:41:59 -0600

On Oct 21, 2012, at 9:10 AM, Bernard Aboba <[email-masked]> wrote:

> Harald said: 
> 
> "When we started out, I expected a host of issues of the type you envision - where people who are reading the SDP specs have serious differences of opinion about what should be the right outcome - but so far, I haven't seen that happening."
> 

We could put some implementer notes in one of the drafts to try and help cover some of the common things developers need to deal with. That would be helpful for many things that use SDP. Having some example SDP that included "bogus future extensions" that a parse should successfully ignore might help people test their SDP implementations. Note that unlike the IETF, the W3C tends to have have a conformance test suite to deal with things like this so in some weird way, the W3C might end up improving the interoperability of the SDP. 

> * Error handling.  What happens when the parser detects an error and how do we know what it objected to?  Is an exception or error callback fired?  Does this provide an indication of what SDP lines…

I think the combination of the JSEP and WebRTC spec need to get very clear on all the issues you raised. I'd like to see error handling a major part of the discussion at the W3C meeting as we have not really tacked that yet in the spec. Last time I looked, no one had replied to Anant's proposal. 

> * Guidance with respect to API usage, both general and specific, such as the questions Mathew mentioned. 

The issue of what can be changed that Mathew raised has been discussed as an open issue and we know that we need to nail that down in the specification. It seemed like one of the things that could be left till a bit later in the process when we had more information about what the use cases were and what to put. The one use case that has been raised very clearly is people want to be able to remove a particular codec for various reasons. I suspect that lots of people will argue to make sure that type of change of SDP is supported. I'm not sure what use case drive the rest but 100% agree this is a topic we need to put some time into.  Right now, it does not seem to be holding up implications which are still trying to nail down all the basic stuff along with ICE, DTLS, etc. 

> Overall, these questions relate more to the API than to existing or in-progress SDP specifications within IETF, which raises the question of where they would be best addressed. 

I suspect most of them are in the WebRTC spec and some of them in ietf drafts but either way, I agree all the points you raised need to be specified.

---

From: Matthew Kaufman <[email-masked]>
Date: Sun, 21 Oct 2012 20:59:05 -0700

> The issue of what can be changed that Mathew raised has been discussed as an open issue and we know that we need to nail that down in the specification. It seemed like one of the things that could…

The API surface exposed in the browser must be *completely* specified. 
While I am glad that you "100% agree this is a topic we need to put some 
time into," I also know that in the years since SDP O/A was first 
proposed a concrete set of interoperability specifications has yet to 
materialize, and so it seems unlikely that this WG or the W3C WG will 
manage to fully document what changes to the SDP emitted by createOffer 
and the SDP accepted by setLocalDescription and setRemoteDescription are 
permitted without a *significant* effort.

I will note that the JSEP draft says that calling createOffer is 
optional, and so it must be possible to, with only access to the 
specification and the referenced specifications, generate a blob of SDP 
which is accepted by setLocalDescription in *every* browser 
implementation. We are nowhere near that point.

All of this is of course easily avoided by choosing an API surface which 
is not an underspecified blob of SDP.

Matthew Kaufman