[hydra-dev] sip stacks (new topic)

[Olle E. Johansson]

10 aug 2010 kl. 16.34 skrev 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.
I think there is a relationship, but you might use the word "architecture"
differently than me in this discussion. You explain your SIp architecture
well below, which is what I asked for.

> 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.
And where do you put the stuff that exists in the Asterisk channel driver,
which is not call-related, like subscriptions and registrations?
Where would you put presence if we add that, still in a channel driver?
if so "channel driver" is a bad name.

> 
> 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.
That would be stupid, since most SIP stacks already have their own
abstraction layer for good and bad. I want to make sure that there's
no routing in the core that points all things related to the SIP protocol
to a particular module.
> 
> 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.

Or the Asterisk SIP "stack"... ha ha.

/O