Compatibility with recent browsers

[saghul]

(I'm about to go on vacation for a few weeks so I thought I'd brain-dump here before I forget!)

The README mentions compatibility with Firefox and Chrome, but I couldn't replicate this, I got failures with both. Upon further inspection I see that you implemented the latest draft-ietf-mmusic-sctp-sdp spec (kudos!) or at least version 08. Chrome and Firefox don't seem to do so, and even if Chrome has some code to work with draft version 12, it's broken: https://code.google.com/p/webrtc/issues/detail?id=5039

I did get librtcdc working with Chrome and Firefox by hacking it to use the old syntax: DTLS/SCTP in the media line and a=sctpmap. I wonder if it would be desirable to support this mode as well, by using some flag. For incoming offers it would be auto-detected. I know this sucks, but maybe applying Postel's principle here is A Good Thing?

There seems to be a bug with DTLS roles handling. Quoting RFC 5763:

The endpoint MUST use the setup attribute defined in [RFC4145].
      The endpoint that is the offerer MUST use the setup attribute
      value of setup:actpass and be prepared to receive a client_hello
      before it receives the answer.  The answerer MUST use either a
      setup attribute value of setup:active or setup:passive.  Note that
      if the answerer uses setup:passive, then the DTLS handshake will
      not begin until the answerer is received, which adds additional
      latency. setup:active allows the answer and the DTLS handshake to
      occur in parallel.  Thus, setup:active is RECOMMENDED.  Whichever
      party is active MUST initiate a DTLS handshake by sending a
      ClientHello over each flow (host/port quartet).

Right now the library uses setup "active" for the client role and "passive" for the server role. Looks like it should use "actpass" for the client role, "active" otherwise and not allow anything other than "actpass" in an offer. ( had to hack this together in order to get it to work with Chrome, because it would refuse an offer with "active").

Thanks a ton for this library, I hope to make more contributions once I'm back :-) Keep up the great work!

[chadnickbok]

Any chance you've had time to turn these hacks into a pull request?

[saghul]

Not yet, but I still have plans to do so. Feel free to take a stab at it though.

[chadnickbok]

I have, but I still can't connect to chrome - here's a copy-paste of my diff so far: https://gist.github.com/chadnickbok/2bab102d28ae2576d270

I'm having some small success connecting to the browser, but my datachannel gets closed immediately. It seems like the usrsctp_connect function is failing, but I can't figure out why.

[chadnickbok]

Here's an initial attempt at a pull request: #11

Haven't gone through and updated the python yet - wanted to get comments on the changes first.