[asterisk-dev] 13 November, 2012 New SIP stack update

[Daniel Pocock]

On 14/11/12 17:28, Olle E. Johansson wrote:
> 
> 14 nov 2012 kl. 16:33 skrev Daniel Pocock <daniel at pocock.com.au>:
> 
>> On 14/11/12 15:16, Olle E. Johansson wrote:
>>
>>
>>> Unfortunately that's what I see with both PJsip, Resiprocate and Sofia users - many private "forks". 
>>
>> I'd be interested to see examples of the private forks of resiprocate
> I will see if I can get permissions to give such examples.
> 
>>
>> There are many branches in SVN, but most of them started with the
>> intention to merge back into trunk.
> 
> And what happened?
> 

If you look at the repository before the 1.8 release, you will notice
some big merges.  E.g. the autotools stuff was all done on a branch, it
was almost 12 months in the making.  Then I merged it about April

Other changes evolved the same way.

Some things were just experiments and the branches remain

>>> I have no insight into why this is the state of the SIP stack "industry". The discussion I've had with
>>
>> Some people are developing for Windows, mobile or other platforms.
>> Their packaging needs are very different.
>>
>> E.g. on Windows it is common to embed libraries and link statically.
>>
>> On mobile, there is no dependency-based packaging system, so projects
>> like Lumicall (mjsip) and CSipSimple (pjsip) just embed a (forked) SIP stack
> Seems like you agree with me here.

Yes, I think that with mobile in particular, special hacks are often
needed (e.g. for cross compiling or to support sleeping) and the
development priorities are wildly different.

But that doesn't mean those changes can't go back upstream...

reSIProcate has been reasonably successful in supporting this wide range
of platforms, e.g. Scott is mostly developing on Windows, I am building
Debian packages, and I've also cross-compiled for OpenWRT (e.g. to run
it on my TP-Link WR1043ND router)

Another reason people fork is because of repositories: people like to
have their own repository, making their own commits, etc.  git let's
people do that much more easily.  For the type of problem you are trying
to solve, I believe git will be a big part of the solution, it gives you
autonomy, and that is why I suggest I would take on the responsibility
of getting reSIProcate into github (if the rest of the community agrees
to trust me with that of course...)

>>
>>
>>>
>>> I would like to see another discussion soon - how we should change the core PBX in order
>>> to be able to build a proper SIP stack. If Digium and the community invest in this development,
>>> I would like to see an upgrade of the core so that we can do things right. In my installations,
>>> I have almost only SIP. I do believe a majority of Asterisk channels today are SIP. 
>>
>> One other possibility: maybe drop things like TLS support and encourage
>> people to use a proxy for that.  Obviously Asterisk will not know what
>> was in the certs, so it won't be able to pass such details through to
>> the dialplan environment, but otherwise it may be technically sound and
>> easier to support.
> 
> I don't take that as a serious suggestion. Sorry. If we are going to handle SRTP, then
> we do need TLS to Asterisk. We can't rely on another magical piece of software
> to do TLS termination or fix other issues we have, we need to provide our users 
> with a reasonable level of security and functionality. 
> 
> Asterisk needs to work properly in standalone mode.

I agree it is not a long-term solution - but I currently run TCP between
the repro proxy and Asterisk.  repro does all the TLS connectivity to my
Polycom phones.  This works really well for me.  So just encouraging
people to use that paradigm until the new SIP module is available may
relieve some of the support burden for Digium.