Re: API design

On 3 Jul 2013, at 02:12, Eric Rescorla <ekr@rtfm.com> wrote:

> On Tue, Jul 2, 2013 at 5:43 PM, Roman Shpount <roman@telurix.com> wrote:
> On Tue, Jul 2, 2013 at 8:48 AM, Eric Rescorla <ekr@rtfm.com> wrote:
> 
> One clarification: Firefox and Chrome use the same DTLS stack; NSS.
> However, I am familiar with non-browser implementations which use
> OpenSSL's stack.
> 
> 
> I guess my to my point Chrome and Firefox share codec
> 
> Yes. 
> 
>  
> and DTLS implementations.
> 
> Yes, but as I said, there are non-browser DTLS implementations which use OpenSSL's
> stack.
> 
>  
> SDP parser, ICE, and JavaScript interface are different. So we got non-obvious portions of code shared and different.
> 
> Also the state machine.
> 
>  
> BTW, are you using libsrtp in your DTLS implementation or did you migrate to a more stable crypto?
> 
> Both Firefox and Chrome use libsrtp.
> 
> 
> I'm not really following what your objection is here. The subject of this thread
> appears to be compatibility of the API, not the transport layer, and as stated the
> APIs were independently developed and in fact implemented along quite
> different lines (the Ffox API is in JS and the Chrome one is in C++).
> 
> -Ekr
> 
>  

As an extra datapoint (in case anyone cares) we've implemented the whole media wire protocol
(STUN/ICE/DTLS/BUNDLE/SRTP) in java from the spec. It interoperates nicely with chrome and firefox.
the crypto parts are open source.

The only code shared with chrome is libopus (which is optional). 
Feel free to play with it on phono.com .

Generating compatible SDP was the biggest single problem.

Tim.