[hydra-dev] sip stacks (new topic)

[Kevin P. Fleming]

On 08/10/2010 09:23 AM, Olle E. Johansson wrote:
> 
> 10 aug 2010 kl. 16.02 skrev Simon Perreault:
> 
>> On 2010-08-10 09:34, Olle E. Johansson wrote:
>>>> I'm sure this is understood, but just to re-iterate, 
>>>> I expect there to be _multiple_ SIP stacks available
>>>> for Hydra - at any rate the architecture _must_
>>>> support multiple stacks.
>>>
>>> Right. And we need to figure out what we are going to do with SIP, draw up an architecture.
>>>
>>> For SIP ua stuff, like if we need to register or subscribe, we might want one "hydralet". For SIP server stuff, like SIP trunks, we might want another.
>>>
>>> And if the architecture works, we can have multiple implementations.
>>
>> I had understood from previous discussion that it would be possible to
>> have multiple SIP stacks, but that efforts (by Digium and this
>> community) would be concentrated on a single one.
>>
>> Is this conclusion still valid?
> 
> I don't see why not, it's up to Digium where they put their efforts. But I don't see that the design should limit us to only ONE sip implementation in a hydra network.
> 
> Regardless, I would like to see some architecture ideas in regards to SIP.

There is no relationship between 'architecture' and 'SIP stack' at all,
actually. The Hydra architecture allows for multiple channel drivers,
each implementing any protocol they wish, even if there are multiple
implementations of the same protocol. Channel drivers will be named by
the administrator installing them (with reasonable defaults), so there's
no magic to the name 'SIP' for a channel driver, if that's even what
gets chosen.

Now, as far as being able to change SIP stacks: the SIP components that
Digium's team is building will be designed around PJSIP. If we have a
component that can act as a registrar for SIP endpoints, and
send/receive calls using INVITE-based dialogs, that component will *not*
be built in such a way that the 'SIP stack' portions of it could be
replaced with a different stack. The SIP stack and the component(s) that
use it will be tightly coupled together, and it doesn't seem worthwhile
to try to create some sort of 'SIP stack' abstraction layer that would
allow such components to be used with alternative stacks.

With that said, though, the source code of these components will of
course be available, and anyone who wishes to produce a component that
*also* can act as a registrar and send/receive calls using INVITE-based
dialogs but is built on reSIProcate, oSIP, Sofia-SIP or some other stack
would certainly be free to do so.

-- 
Kevin P. Fleming
Digium, Inc. | Director of Software Technologies
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
skype: kpfleming | jabber: kfleming at digium.com
Check us out at www.digium.com & www.asterisk.org