[hydra-dev] sip stacks (new topic)
Olle E. Johansson
oej at edvina.net
Tue Aug 10 10:07:39 CDT 2010
10 aug 2010 kl. 16.51 skrev Kevin P. Fleming:
> On 08/10/2010 09:46 AM, Olle E. Johansson wrote:
>
>>> 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.
>
> You are right; they won't live in a 'channel driver', although they
> might live in the same Hydra component, if it also implements presence
> and provider registration interfaces (and others, if they are created).
Right. There is really no reason to mix the server part, the SIP registrar and the SIP UA "phone" that registers in the same module.
That's a mistake we've made and still stuffer from...
> It's also possible, and would work equally as well, if the presence
> interfaces were implemented in a separate component... and it's not at
> all inconceivable that someone might feel that another SIP stack is much
> easier/better to use for presence management than PJSIP is, so they
> could create a presence management component that used that stack, but
> still use the PJSIP-based component for handling calls.
I would prefer only working with one stack as a developer, but I get your point.
The important part is that we make this possible.
>
> The fact that all these logical entities are abstracted into separate
> interfaces is what makes this so powerful, and it's very much unlike the
> way things are designed in Asterisk... because we got to start over :-)
Well, even old dogs like you and me have to learn on the way... :-)
/O
More information about the asterisk-scf-dev
mailing list