[Asterisk-Users] Polycom-Asterisk hints/presence

[BJ Weschke]

On 6/1/06, Damon Estep <damon at suburbanbroadband.net> wrote:
>
> >
> >  You're right in that there is nothing in technology spec to support
> > the concept of shared line appearance, but I think what was more to my
> > point was that you could get access to a "shared line" from more
> > channels than just a SIP channel. I'd probably want the ability to
> > have two SIP channels and an IAX channel in a "shared line group", and
> > while SIP provides for structured communication to ask for a
> > grant/deny access to this resource, there isn't any reason the same
> > couldn't be done off the IAX channel via feaure mapped DTMF just as
> > you can "park" a call off of a Zap channel today even though the
> > underlying technology has no idea what the concept of Park really is.
> > The concept of channels in Asterisk are not technology specific, and
> > as a result, implementations of things like "shared lines" really
> > shouldn't be either.
> >
> > --
> > Bird's The Word Technologies, Inc.
> > http://www.btwtech.com/
>
>
> What you are describing is an ability to dynamically "bundle" channels
> in the dialplan, that is you would define the members of the group, and
> then ring the group instead of the channel, this can already be done
> manually.

 No. Not really. That wasn't really what I was trying to describe, but
if that's what you've come up with, I obviously didn't convey myself
well.

>
> That is not what the sip version of shared lines does, it allows
> simultaneous registrations of multiple user agents into a user agent
> account, and then allows any one of the registered UAs to seize the call
> when it rings. When the SIP server evaluates where the INVITE should go
> it sends it to multiple UAs, and that is the thing asterisk can not do
> without a dialplan that tells it to do so and a unique account for each
> UA to register on. It is limited to one registration per user account.
>

 I'm aware of the functionality, and I reiterate, there really isn't
any reason an IAX channel, a Zap channel, or any other channel
technology that Asterisk supports shouldn't be able to share this
"account" with other SIP UAs already part of the group account. The
registration  to the group account should be technology agnostic and
the seizure request and device state change notification should be a
technology agnostic API.

> I understand your "technology agnostic position", and it makes sense,
> however my vote (for the little that it is worth) would be to implement
> a SIP rfc complaint shared line appearance capability (and/or bridged
> line appearance), and then, if possible, extend it to support zaptel and
> iax and whatever else is popular. SIP is arguably the most common choice
> for NEW VoIP implementation, and it also appears to be the common ground
> upon which all vendors of VoIP gear will meet for interoperability. IAX,
> even with its advantages, will not likely progress to the same stage of
> universal acceptance, it may very well be the choice of many asterisk
> users, but in the end you will still have to talk SIP interoperate with
> the "VoIP Revolution"
>

 It's really not that simple. You're proposing to create a "middle
layer" channel technology within the SIP channel driver when the SIP
channel driver technology is just an "edge" channel technology in
Asterisk. I think this has little to do with forcing market acceptance
of IAX in my mind, and please don't think there's any political
motives behind the feature not already being there. I think they're
purely technical at this point.

> I can not imagine Nortel, Cisco, Lucent, Sonus, BroadSoft, and
> (probably) Polycom, or any of the other commercial players, embracing a
> protocol developed and supported by proponents of open source software
> :)

 No, I'm not holding my breath for them to implement IAX either, but
that's not really the point here.

>
> If your comments echo those of past conversations on the matter I can
> see that a bounty at this point would not be money well spent, since any
> work the comes from it is not likely to make the cut. A bounty would
> only be useful to accelerate the implementation of a feature where there
> is widespread agreement on what the architecture should be.
>

 A bounty for what? A bounty for implement a SIP only functionality? I
would agree that this is likely money not well spent. If you're
proposing a bounty for it to be a core-driven functionality, I do
think that would be money well spent.

-- 
Bird's The Word Technologies, Inc.
http://www.btwtech.com/