3 comments on “SDP: The worst of all worlds or why compromise can be a bad idea (Tim Panton)

  1. Well written post and an understandable rant. I’m working on a WebRTC gateway implementation myself, and I can confirm that dealing with SDP so far has proven to be, well, harsh at times, and certainly the harshest “beast” in the portfolio of protocols WebRTC mandates right now. Even now it is what is limiting the gateway itself, as it is hard to parse all possible combinations correctly (and as Tim pointed out, without much help from existing stacks unfortunately) without taking into account potentially unpredictable results. This forces me (and probably others) to keep things simple/simpler, despite what we could actually achieve with such a promising technology.

    SDP is not that complex, per se, but it is indeed overly verbose and ambiguous, and the fact that an apparently harmless mismatch in what you said and what you meant can cause underexplained errors when involving them in browsers certainly doesn’t help. Just to say the latest, the simple fact that I only placed a c-line at the session level and none at the media level caused an obscure “m-lines not matching” error in Chrome, that forced me to try and remove one line at a time to debug where the problem actually was.

    And I have trouble understanding how we got here in the first place: I was not against relying on SDP to ease the process of legacy interoperability, but we’ve added so much stuff to it in the meanwhile that (ignoring the ICE/DTLS stuff that few or no legacy endpoint supports anyway) this is not going to happen anyway.

    Anyhow, I agree with Tim on his conclusion: WebRTC is great and promises to be even greater, and we shouldn’t give up on it just because of SDP. Let’s just hope that things will get simpler in that respect in the future.

  2. Hi, I’m a ‘weekend pi hacker’ and was kind of looking forward to playing around with Webrtc datachannels but my initial Google for Java libraries isn’t inspiring too much confidence, do you have any recommendations/did you manage to write one and post it on github :-)?


    • Rob – no I didn’t get around to finishing my data channel stuff in Java (yet) – I think that
      most of what you need is in libjitsi – but perhaps not all of it.

      I am still working on the project, but it is very much on the back burner at the moment.
      I’m also not completely sure it would be open source, since it has turned out to be quite hard to do.

      The missing component is the sctp stack in java. I believe Jitsi used the one from the linux kernel and some jni – which works I guess, but isn’t what I had planned.


Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.