[asterisk-dev] SIP: So you mean you want to be able to *dial* something?

[Joshua Colp]

Olle E. Johansson wrote:
> 25 feb 2013 kl. 22:39 skrev Joshua Colp<jcolp at digium.com>:
>
>> Olle E. Johansson wrote:
>>>> Making the core better aware of this should be a goal in the
>>>> future but at this point in time I think with the above we can
>>>> meet what a lot of end users want.
>>> ´ So how would device-state work here?
>>>
>>> If one device is free and one busy - how would queue() parse
>>> that?
>> Until such time as the core becomes aware at a lower level the
>> presence module for the new SIP work would provide a simplified
>> aggregate view which is tweakable, much like you do in chan_sip
>> right now.
>
> We don't aggregate devices in chan_sip - that's done in the pbx core.
> You would then have aggregation twice which is not a good thing, like
> forking twice. If I want to implement a device state proxy that says
> "if one phone is busy, all is busy" I would have to implement that
> twice, once in the core and once in the sip channel driver. That's no
> good.

chan_sip does interpretation based on configuration which controls what 
to return to the device state core, busylevel. This is going to have to 
exist for the new SIP work as well. It's business logic, it has to. 
That's what I meant by aggregation.

The real difference between chan_sip and the new SIP work at this level 
is simply that it will have to check multiple addresses when returning a 
device state in that situation.

You talk as if all of this work is going to prevent an individual from 
doing things as they did before and individually addressing their 
devices. It won't. If someone needs that granularity, they can still do 
it that way. I don't think that should prevent us from implementing things.

> I think this is too large a step for the first version of the new
> channel driver as it will affect the PBX core too.

This is not going to be perfect, it can't be without exposing and moving 
more to the PBX core. My personal goal is to make this a feature that is 
usable by a good subset of the user base. For the next iteration we can 
improve things and unify it so the users who have to use the old 
approach can move to the new approach.

What do others think?

-- 
Joshua Colp
Digium, Inc. | Senior Software Developer
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
Check us out at:  www.digium.com  & www.asterisk.org