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

[Harald Alvestrand <[e-mail]>]

(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:
> (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 [[e-mail]]:
>
> >
>
> > 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
>
>
>
>
> _______________________________________________
> rtcweb mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/rtcweb