[asterisk-dev] Asterisk Support for as-feature-event package

[Martin Koenig]

Hi Dev,

are there currently any ongoing efforts or plans to integrate the
as-feature-event package into Asterisk?

The package interworks DND and Call Forwarding and ACD States between a SIP
end device and a pbx system. It basically enables the phone to activate call
forwarding and dnd features in the server by sending XML (similar to UACSTA)
bodies as SIP NOTIFY within a SUBSCRIBE dialog to the pbx, and vice versa
enables PBX to send states to the phone. Basically, no call forwarding or
dnd state is kept in the phone locally anymore, it is displayed in the phone
and implemented in the pbx.

The spec is originally broadsoft, but more and more phones support this
(snom, Yealink/tiptel, aastra, Gigaset, ...), and it is also part of the
snom one / pbxnsip product.

With best regards,
Martin
--
Martin König
Manager Presales & Quality Assurance

STARFACE GmbH
Stephanienstr. 102
76133 Karlsruhe

fon: [phone]
fax: [phone]
mobil: [phone]
***@starface.de
www.starface.de

Handelsregister: Amtsgericht Mannheim HRB 110990
UStID-Nr: DE-243439720
Geschäftsführung: Florian Buzin, Barbara Mauve

[Olle E. Johansson]

Post by Martin Koenig
Hi Dev,
are there currently any ongoing efforts or plans to integrate the
as-feature-event package into Asterisk?
The package interworks DND and Call Forwarding and ACD States between a SIP
end device and a pbx system. It basically enables the phone to activate call
forwarding and dnd features in the server by sending XML (similar to UACSTA)
bodies as SIP NOTIFY within a SUBSCRIBE dialog to the pbx, and vice versa
enables PBX to send states to the phone. Basically, no call forwarding or
dnd state is kept in the phone locally anymore, it is displayed in the phone
and implemented in the pbx.
The spec is originally broadsoft, but more and more phones support this
(snom, Yealink/tiptel, aastra, Gigaset, ...), and it is also part of the
snom one / pbxnsip product.

First, do you want to fund the work?

Secondly, is the spec public?

Last time I checked a Broadsoft spec they wanted license fees....

/O

[Martin Koenig]

Post by Olle E. Johansson
First, do you want to fund the work?

Maybe - or we might do it ourselves

Post by Olle E. Johansson
Secondly, is the spec public?

The spec contains a lot more than this. This specific part is a derivate of
ECMA-323 which is public.

It can be found here:

http://interop.broadsoft.com/files/BW-SIPAccessSideExtensionsInterfaceSpec-R
170.pdf

Section 8 is the relevant one.

Best regards,
Martin

[Olle E. Johansson]

Post by Martin Koenig

Post by Olle E. Johansson
First, do you want to fund the work?

Maybe - or we might do it ourselves

Great, then there's a point in discussing this :-)

Post by Martin Koenig

Post by Olle E. Johansson
Secondly, is the spec public?

The spec contains a lot more than this. This specific part is a derivate of
ECMA-323 which is public.
http://interop.broadsoft.com/files/BW-SIPAccessSideExtensionsInterfaceSpec-R
170.pdf
Section 8 is the relevant one.

Since we already have support for outbound subscriptions, the discussion should be about states in Asterisk.
Currently we have no DND or forward states on extensions... You could potentially connect this to custom states to have maximum flexibility.

/O

[Russell Bryant]

----- Original Message -----

Post by Olle E. Johansson

Post by Martin Koenig

Post by Olle E. Johansson
Secondly, is the spec public?

The spec contains a lot more than this. This specific part is a
derivate of
ECMA-323 which is public.
http://interop.broadsoft.com/files/BW-SIPAccessSideExtensionsInterfaceSpec-R
170.pdf
Section 8 is the relevant one.

Since we already have support for outbound subscriptions, the
discussion should be about states in Asterisk.

Well ... sort of, only for MWI right now, right? On that note, how's the SIP device state outbound subscriptions project going these days? Is there any hope of that making it in for Asterisk 1.10?

Post by Olle E. Johansson
Currently we have no DND or forward states on extensions... You could
potentially connect this to custom states to have maximum flexibility.

I think this would be a good feature to have. It could be something like chan_sip registering new device state providers for other sorts of states. I think it would be best to try to not introduce logic that tries to mesh this in with normal device states. Having it as its own state type would be neat, though.

exten => foo,hint,SIP-dnd:mypeer

Call forward state is a bit more complicated, since there is custom meta data associated with a call forward. It's not just a state.

If anyone wanted to work on this, let's be sure to review the design on this list before you go off and code it to make sure we've got good agreement on the approach.

[Olle E. Johansson]

Post by Russell Bryant

Post by Olle E. Johansson
Currently we have no DND or forward states on extensions... You could
potentially connect this to custom states to have maximum flexibility.

I think this would be a good feature to have. It could be something like chan_sip registering new device state providers for other sorts of states. I think it would be best to try to not introduce logic that tries to mesh this in with normal device states. Having it as its own state type would be neat, though.
exten => foo,hint,SIP-dnd:mypeer
Call forward state is a bit more complicated, since there is custom meta data associated with a call forward. It's not just a state.
If anyone wanted to work on this, let's be sure to review the design on this list before you go off and code it to make sure we've got good agreement on the approach.

Why limit it to SIP? We're still building a multiprotocol PBX, right?

We need to come up with a state that matches XMPP and SIP presence - there's a generic IETF guideline for this that I forgot the name for. The only object in Asterisk we can match it to is the voicemail accounts, lacking a user concept - hint: my old AUM code....

/O

[Russell Bryant]

----- Original Message -----

Post by Olle E. Johansson
Why limit it to SIP? We're still building a multiprotocol PBX, right?

Well, we're building a multi-protocol telephony applications platform that can be turned into a PBX. :-)

If there was a way to make it more generic that makes sense, I'm good with that. The SIP-dnd device state provider kind of approach is very raw; expose the data, let the 'application' figure out what to do with it.

Post by Olle E. Johansson
We need to come up with a state that matches XMPP and SIP presence -
there's a generic IETF guideline for this that I forgot the name for.

Let me know if you remember. I'll go do some reading.

Post by Olle E. Johansson
The only object in Asterisk we can match it to is the voicemail
accounts, lacking a user concept - hint: my old AUM code....

You're right, there's no user concept. Arguably the concept of users is business logic that belongs outside of Asterisk. It's tough to decide where to draw the line sometimes.

Thanks,