[asterisk-dev] SIP Stack Research

[Mark Michelson]

On 11/08/2012 04:56 PM, Saúl Ibarra Corretgé wrote:
> Joshua Colp wrote:
>> Hola,
>>
>> (Apologies for the semi-long email)
>>
>> As Mark mentioned in his earlier email I've been working on researching
>> viable SIP stacks for the new SIP channel driver. I've scoured the far
>> reaches of the internet looking for new stacks that may have come into
>> existence since my previous Asterisk SCF research but in the end the
>> three that came to the top were Sofia-sip, Resiprocate, and pjsip.
>>
>> You can find my research on them at
>> https://wiki.asterisk.org/wiki/display/AST/SIP+Stack+Research
>>
>> I've detailed what I looked at and the impressions I got for each. This
>> is by no means a deep deep deep analysis as that would take considerably
>> more time. What it does cover though is the community for each project,
>> how easy it is to use, general impression on features, interoperability,
>> and (in my opinion) most importantly documentation.
>>
>> Through doing all of this research I have learned that there is no
>> perfect SIP stack, but all of the ones I mentioned will do what we need.
>> No matter which one you choose though you are effectively giving up
>> something you could have gotten with another one so we have to find a
>> balance. I think our balance should be towards a stack that has great
>> documentation, is easy to use (and expand), provides the features we
>> want, and still has an active community.
>>
>> After examining the three options I've ordered them as follows according
>> to my personal opinion against the above:
>>
>> 1. pjsip
>> 2. Resiprocate
>> 3. Sofia-sip
>>
>> But Josh, why did you order it as such?!?
>> Good question, Josh.
>>
>> The documentation for pjsip is great and makes it easy to learn exactly
>> how to use it and what is going on. The general architecture of it makes
>> extending it *extremely* easy and you can inject your own modules at
>> many different layers. The project itself is still being actively
>> developed and maintained. The time required to get up to speed and use
>> pjsip is also very low since there are people in the Asterisk community
>> who are familiar with it and have used it.
>>
>> Resiprocate came second because the documentation is not as complete or
>> expansive as pjsip, 'nor is the higher level (APIs that reduce the
>> amount of code we have to write) feature count. It would also be more
>> difficult to use it with Asterisk as it is C++ based, and this would
>> also decrease the number of people who could help with that integration.
>>
>> Sofia-sip came last because it did not have as good of documentation as
>> resiprocate or pjsip and the project itself seems to have become
>> stagnant. It also lacks as many higher level features as pjsip.
>>
>> The purpose of this email is to bring about discussion on this subject
>> as a whole and try to reach a conclusion on which SIP stack would be the
>> best in the eyes of the community.
>>
>> Thanks for reading this long email and I look forward to the discussion.
>>
>> Cheers,
>>
>
> Hi Josh,
>
> As you know, my experience is basically with PJSIP, I just played with 
> Sofia very briefly years ago so I don't remember much.
>
> The only thing that concerns me a bit are threading issues with PJSIP. 
> We have run into deadlocks while developing SIP SIMPLE SDK, and the 
> main SDK user is Blink, a client application, not a server. There are 
> tons of clients implemented with PJSIP, but most of them use the pjsua 
> API, with has a giant lock. Servers with PJSIP? Not many, at least in 
> the Open Source multiverse.
>
> Back in 2006 FreeSWITCH attempted to implement mod_pjsip, to use it as 
> their SIP stack, but they gave up and threading issues was apparently 
> one of the reasons. People from PJSIP were involved FWIW. Yes, 6 years 
> is a long time, but AFAIK, PJSIP hasn't changed it's internal design. 
> Also, FS and Asterisk are different things, but I think t's worth 
> considering, nevertheless.
>
Can you expand more on how these deadlocks occurred and what issues 
FreeSWITCH experienced?

> Now, I guess that depending on how / at what level the integration is 
> made we may not run into these issues in Asterisk. Since you guys 
> already used it in SCF, what was the experience there? Were high load 
> benchmarks performed?

I can explain the threading model used in Asterisk SCF.

There was a single monitor thread that serviced sockets (in PJSIP terms, 
this was doing pjsip_endpt_handle_events). When a SIP message was 
received on this thread, it bubbled up through PJSIP's transaction and 
dialog/ua layers. Once it got to us, we did what we had to with the 
request/response data and then dispatched further processing into a 
thread pool.

The thread pool worked in such a way that all related work would be 
handled in sequence, typically by the same thread. The definition of 
"related work" varied by context. For a media session or subscription, 
this would mean all work pertaining to a particular dialog. For a 
registrar, this would mean all work pertaining to a specific address of 
record.

When the SIP component in Asterisk SCF was told by another Asterisk SCF 
component to send a SIP message, the sending of the SIP message would be 
dispatched to the thread pool as well.

By doing things this way, nearly all PJSIP operations on a dialog 
happened in sequence in a single thread. The exception to this was the 
monitor thread. The messages had to go through PJSIP's transaction and 
dialog layers so that we could know where to dispatch the message. This 
meant that the monitor thread had the potential to contend with the 
thread pool for dialog or transaction locks, but we never witnessed a 
deadlock in our testing.

 From my understanding, Darren Sessions did load testing of the SIP 
component in Asterisk SCF where he would run around 10,000 calls through 
it. I don't know what the exact call scenarios were, so it could be that 
even with a large call volume, the tests were not designed in a way that 
made it possible to trigger a deadlock.

>
> I don't know much about reSIProcate, but PJSIP has its own proactor 
> and Sofia its own reactor, how would any of these be integrated into 
> Asterisk's current architecture, at a first glance?
>
If using PJSIP, I imagine we'd use a model very similar to what was used 
in Asterisk SCF. In other words, a thread or threads servicing the 
sockets and a separate threadpool used to separate work per-dialog (or 
other logical unit). We would not be using the pjsua API since we would 
need more control than it provides. I can't comment on Sofia since I 
have not worked with it before and am not familiar with its threading.

> Keep up the good work!
>
>
> Cheers,
>