Re: Introduction

[Kevin Hawkins <lists@xxxxxxxxxxxxxxxxx>]

Adam Stevens wrote:

>
>
>
>
>Also, what's the procedure if you need something added to an existing
>schema?  For example, I've had a quick look at the CID/Meteor one, and
>it occurs to me that CID.Incoming could do with an additional parameter
>to indicate call origin (eg, PSTN/VoIP/Line number etc).
>
>
>
It is possible to add your own parameters into an existing schema in
that they will then be ignored by other applications but you mustn't
alter the usage of an existing parameter.  However it's generally better
to try and break out your information into additional blocks that get
sent in the same message  or perhaps revisit the purpose of the schema.
For example the current 'richer' CID schema is named  CID.Meteor  and as
such VOIP say wouldn't be needed. What we perhaps need is a broader CID
schema not associated with say the Meteor.

In writing xAPTel I have currently 'abused' the CID.Meteor schema by
adding quite a few parameters into the existing schema blocks eg as you
say VoIP or as I listed it vPSTN (meaning it could handle VoIP to a
standard PSTN number). I also added 'Skype' for example as VoIP has
several variant protocols.  I intend to migrate my abused CID.Meteor
schema to a new CTI schema but it takes a bit of getting right so what I
have works currently with say xAP Switchboard.  I have also added new
messages like line events (busy offhook onhook dial capabilities) and
events like 'busy' 'outgoing.callanswered' 'callrefused' 'callfailed'
etc which Skype allowed me to produce and parameters like 'tag=' to
identify a call that might even swap lines during its life.

One other concept worth using is that xAP addresses can optionally be
broken into two components separated by a :

eg   <main address> : <sub address>
UKUSA.Tel.Machine:Line1
The <main address> has the form 
<vendor>.<device>.<instance>  and the
sub address can also be segmented using  '.' s into a hierarchy should
you wish

The main address is normally the application or device  itself and the
sub address are the various segmented endpoints within that.  So an 8
channel light dimmer would have one main address but 8 sub addresses. In
our context a telephone CID server application might have one main
address and an endpoint for each individual line - indeed xAPTEl does
just that.   This is how you can identify the line number you needed
above or ask a specific line to do something eg 'dial' .    The main
application always has a UID of the form FFxxxx00   where xxxx is a 4
digit hex string unique, on your network  to that application.  The '00'
at the end signifies that this is the main application (not an endpoint
within it) and the source would not have any sub address..  When an
endpoint sends data it changes the last two digits of the UID to a
number that uniquely identifies itself eg FFxxxx03   is endpoint '03'
which might be named <main address>:Line3  for example.

UID=FF1A2200  for Source=UKUSA.Tel.machine
UID=FF1A2209  for Source=UKUSA.Tel.machine:OfficeLine


>Thinking about CID, It does almost make things more complex.
>Presumably, if you had a system which announced via voice and/or
display
>incoming CID, you'd need to do something like:
>
>xAP CID --> xAP Database lookup (gets name from number) --> xAP
>display/announce/logging(?)
>
>
Yes, it's a 3 step process but effectively still instantaneous on
Ethernet.  The big gain is that everything becomes a network available
information providor or device eg the CID lookup and you could drop in
different applications that support the schema and it all still works,
eg if you replaced your Meteor with an XYZ device that had a xAP driver,
- a networked Meteor -(or a networked X10 controller for example).
Everything hears everything else. Also the constituent parts are not
reliant on each other being present,  as in a typical client / server
application where timeouts and embrace situations can lock applications.
If one app disappears then you lose that functionality, that's all.  You
could even incorporate redundant hardware this way (two Meteors on the
same line for example).

Originally I wrote an 'all in one' CID application.  Meteor input, STD
database lookup, Caller name /call history DB, TTS and OSD messaging
output, Slim server integration with on the fly dialled display, IR
remote searchable callhistory  etc etc..  and of course it was never
finished and never really suitable for other people who wanted a
different OSD or CID device - or a US STD lookup or had an ABC modem
etc. It would never have worked for anyone but me.   So I then set about
breaking it down into mutiple xAP components and xAPTel is the CID
reporting part of that. James took up the logging and database side with
xAP Switchboard and the display side is supported with xAP Desktop or
xAP Watcher - even Tivo or now Windows Media Centre and can be either
actioned from xAP Switchboard or using any script engine like VB or xAP
Desktop or HomeSeer.  Some limited display (tray balloons/popups still
exist in both if needed) .  Indeed even something like XLobby or Main
Lobby  can display caller information now with this approach.


>...as there's nothing in the CID schema which indicates an announcement
>message.  Don't get me wrong, I like the fact this is so modular, and I
>guess it means that you can plug any CID-compliant xAP module into the
>xAP database lookup module in the knowledge that it'll do any of the
>additional stuff afterwards (on-screen display, SAPI announcements,
>database logging of calls etc. etc).
>
>
You can add your own bits to the schema if you wish - or maybe that
should be part of a CTI schema or just handled by a script engine that
watches for events/triggers and generates actions.

>
>
>>As
>>I mentioned before, you should also try to make your apps
>>hub-aware if possible.
>>
>>
>
>Ah.  I was wondering how that worked.  Are hubs generally writing into
>existing applications, or does the user need to know that he needs to
>run a hub if he's running more than one xAP client on a PC?
>
>
Hubs are available as applications - your apps do need to be hub aware
but it's a very easy thing to add and is  transparent to the application
once running. The difference is that at startup you need to step through
a range of ports to find a free one (starting at 32768 usually) and then
announce with a hertbeat which one you are using. If you monopolise 3639
at startup then you will be the only app that can hear xAP messages and
normally the hub which is started as the first app reserves this so that
it can relay messages to the client apps.

>Sorry for all the questions!
>
>
Everyone learns from them - keep them coming.

>Cheers,
>Adam.
>
>
>
K