Can't find description of the Difference

[smpe...@gmail.com]

Hi,
Just found SIPJS after using JSSIP for a while. But despite reading that SIP.js is a hard fork of JSSIP I can found no further details on why this was done and what benefits it provides?

Can anyone explain?

Thanks,
Steven.

[Will Mitchell]

Hi Steven,

We forked from JsSIP about a year and a half ago now.  We did this for a few reasons.  At the time, we at OnSIP had actually been using JsSIP for several months in our own projects, such as https://www.getonsip.com and https://insta.onsip.com, and it worked quite well.  Eventually, though, we bumped up with the edge of JsSIP's capabilities.  Specifically, we were looking for more advanced call handling scenarios such as INVITEs without SDP and 100Rel support, and submitting Pull Requests was ineffective.  JsSIP had nearly frozen their development for several months, and that did not work for us.

So, we decided to fork it and keep going.  This allowed us to refactor the code significantly and tackle some things that we considered important.  Specifically, we wanted to bring SIP to the forefront and name things accordingly.  When things are named in a SIP-friendly manner, (ua.invite rather than ua.call), the behavior can be well-defined and tested to match the expectations set in the RFCs.  We've focused on keeping SIP.js active and continually developing support for more and more SIP RFCs (our homepage has the full list, although we just added support for the Replaces header as well).

We also recognize that while a SIP stack could be as simple as providing standard SIP functionality, sometimes that isn't enough and we have to ensure interoperability with our stack and different browsers and server-side stacks.  We do this by building SIP.js out into a more modular, customizable library.  By embracing modularity, we get to do things like separate the signaling from the media (as SIP was really designed) and provide different media backends for browsers, Node.js, Cordova, etc.  We couldn't do this at all at the time of fork.

Lastly, and this is not something that I as an author can take any credit for, I'm proud to say that we have an active community here on the forums.  Now, more often that not, questions about certain server configurations (*cough* Asterisk *cough*) are answered by fellow community members familiar with the software.  Compare the responses to similar questions between SIP.js and our pre-fork sibling library.  I'm curious what you'll find.

All that said, we have used JsSIP in the past and continue to have people use it on our OnSIP platform for their own applications.  It's a great codebase, which is part of why we originally chose it, and they've been doing a lot of work lately towards many of the same goals as SIP.js (supporting multiple environments, modularity, separation of signaling and media, etc).  We've even seen people use sipML5 with OnSIP.  The great thing about a standard protocol like SIP is that you can use whichever library has the best support for what you need.  All standards-compliant SIP stacks are compatible in that way, so the choice is really yours.

I'm glad you stumbled across SIP.js, and I hope you give it a try.  Most of the feedback for SIP.js from former JsSIP users has been positive. Let us know how you like it!

Cheers,

Will

[smpe...@gmail.com]

Hi Will,
Thanks for your response and background. I shall certainly give you library a go.

Thanks,
Steven.