Re: Re: Update on xAP Asterisk?

[Gregg Liming <gregg@xxxxxxxxxxx>]

Christopher wrote:
> sounds like a great project coming along.. I like the idea of being
> able to see calling state real time of my extensions and trunks.. ..

ummm... not sure that I was suggesting that this will be the case--at
least not generically.

> unless im misinterpreting your message. if I knew more about perl im
> sure I could probably write what I want to do in an AGI script
> and "generate" xap messages...

The work that I'm doing is not an AGI--as they have other useful
applications but are intrusive to the dialplan (e.g., extensions.conf)
and can make attempting to track state (across the dialplan) *very*
difficult.

> I think what I want is real simple..
> press a number in an auto attendant which would generate a xap
> message sent to my xap conduit in which homeseer would pick it up and
> act on it..

IMO, you want something that is best implemented via AGI and is
essentially the "action" of an IVR menu.  There's an existing AGI
that's
part of the misterhouse distro that communicates an xAP message in a
schema that's peculiar to mh; but, could be easily adapted to your
needs.  If you have interest, you can either grab it from an mh distro
(re: code/public/asterisk_jason_mhcommand.agi), or send me your email
address off-list and I'll mail you a copy.

> 2 way comms would be a plus but not even essential that
> way homeseer could send bacl a "yeaay" or "neigh"
which I could have
> asterisk play "confirmed" or "denied",

The mh AGI actually listens for an xAP message that is echoed back and
generates a TTS message (via one of the cepstral engines--see
www.cepstral.com) that is streamed back into the channel.  So, the
feedback can be much more complex than a simple acknowledgement; you
could ask for and then listen to the weather if homeseer can give it out
textually.

> so I would hit "6" it turns on
> a light, homeseer returns an "on" and that would be sent
back through
> the conduit where the xap application would set a variable 1 or 0 and
> meawhile my asterisk would be sitting at a "wait" playing me
music or
> such and then compare the variable and play the appropriate prompt..

Yep--all doable now (well, at least in the context of mh and asterisk;
assuming that homeseer is equally capable, then...)

A couple of caveats to using AGIs for xAP messaging:
1) They're inherently transient and therefore can't maintain a regular
heartbeat (more like an arrhythmia ;) ).  That makes 2-way xAP not so
guaranteed.
2) Implementing 2-way in AGIs forces a "blocking condition" to
the
context while awaiting the reply.  There's no good way (IMO) to
gracefully degrade for delayed/non-existent replies.

Given the above 2 issues, I'm been toying around the notion of maybe
extending the connector that I'm working on to eventually deal w/ those
sorts of problems.  Either way, there will always be "hooks" into
the
dialplan to signal the desired outcome.

> thats just my particular idea of what id like to do...
> -Christopher
> --- In xap_automation@xxxxxxx, Gregg Liming <gregg@l...>
> wrote:
>
>>Quoting Christopher (9/15/05 4:05 PM):
>>
>>>I too am interested in XAP enabling my asterisk PBX. I
currently
>
> run
>
>>>a Homeseer 1.7 setup with the XAP connector, im looking to be
>
> able
>
>>>to control homeseer devices, execute homeseer scripts etc via
>
> Auto
>
>>>attendants or extensions on my asterisk PBX. I thought that
>
> someone
>
>>>by the name of patrick lidstone had asterisk fully xap
enabled..
>
> did
>
>>>he not release his code or programs to the public? is this
>
> project
>
>>>abandoned on his end? or is gregg's project another to operate
as
>>>well,
>>
>>I can't speak to any work that Patrick may have done; perhaps he
>
> will
>
>>respond.  My work on this front has taken a while to get started;
>
> but, I
>
>>am now (finally) making some progress.  The reason for taking a
>
> while is
>
>>that this approach is purely non-intrusive wrt the Asterisk
>
> dialplan and
>
>>I have to determine what combinations of Asterisk event sequences
>
> cause
>
>>a state that can be reasonably reported on.  I've also been trying
>
> to
>
>>refactor a portion of existing mh xAP code into a library that can
>
> be
>
>>used for projects like this and others (e.g., zoneminder).  That
>
> being
>
>>said, the basic approach seems to look good so far as I can now
>
> maintain
>
>>a calling state machine w/i the app (something that AGIs have a
very
>>hard time with).  In case Paul is listening, I am grabbing
>>"newmessagecount" and "oldmessagecount" for
voicemail boxes that are
>>user defined w/ no problem.
>>
>>I'm guessing that I'm a week or 2 away from something that the
"hard
>>core" would find useful.
>>
>>
>>>i am available for any testing like im sure many others are.
>>
>>That's good.  The initial "test" release will only be
tested
>
> against my
>
>>inspection of xAP messages--not against apps like SB.  So, there
>
> will no
>
>>doubt be issues there.   FWIW: my real interest is with integration
>
> with
>
>>Misterhouse; so, my own testing w/ SB will be deferred. Also, I
>
> would
>
>>suggest initial testers be somewhat *nix savvy as there are a
>
> number of
>
>>issues like launching and perl library updates that may be a bit
>>non-trivial at first.
>>
>>
>>>I
>>>started with asterisk@home but have pretty much abandoned
editing
>
> my
>
>>>configs with AMP due to the limited functionality and so im
>
> pretty
>
>>>much using it now as a regular distro and manually edit my
>
> configs.
>
>>That's good; because, it's likely that this connector will assume a
>
> fair
>
>>degree of expertise w/ Asterisk and *nix.  Specfically, there is no
>>"install shield"-like ease of installation; and, very
definitely no
>>"snazzy" GUI.
>>
>>On a final note, initial functionality will be xAP messages
>
> appropriate
>
>>for CID, outgoing call logging, and (assuming that the schema for
>
> MWI
>
>>can be worked out) MWI.  More advanced features like directed
>
> dialing
>
>>(i.e., using xAP to initiate a call) will take a bit longer.  There
>
> will
>
>>also almost certainly need to be extensions to existing schemas
>
> and/or
>
>>new ones to handle the features that are useful w/i Asterisk.
>>
>>HTH,
>>
>>Gregg
>
>
>
>
>
>
>
>
>
>
> Yahoo! Groups Links
>
>
>
>
>
>
>