Re: MWI handling

[Kevin Hawkins <lists@xxxxxxxxxxxxxxxxx>]

Gregg Liming wrote:

>Quoting Kevin Hawkins (10/2/05 1:50 PM):
>
>
>>If the 'messages' dont relate to a
>>'line' or 'call' then I am guessing maybe they should be reported
by the
>>main application - ie without a sub address.
>>
>>
>
>hmm... that seems to be counter to the whole point of subaddressing...
>
>

There is a sub addressing feature in xAP you can use it if you wish or
you can ignore it. Whatever suits the application best.  Ideally for sub
addressing to be useful there must be some natural division of the
application into endpoints. Although this often  happens naturally with
hardware I/O it can equally be applied to software endpoints e.g. a news
reporter could present each news feed on a separate sub address.
Information that does not relate to a specific sub address can be
supplied from the '00' UID - ie the whole application rather than a
specific sub address.

>
>
>>But maybe you would create
>>sub addresses for each user if the messages can be categorised this
way
>>??
>>
>>
>
>yes--that seems more appropriate.  But, just like a human has one or
>more mail inboxes--they also may have one or more voicemail
boxes--hence
>the desire not to force a 1 to 1 correspondence between voicemailboxes
>and most anything else.
>
>
Greg - this is your call as a software developer - you have to choose
some division for sub addresses that works logically for your
application. If that division is 'mailboxes' then fine. That's how some
email applications work too.

>
>
>>So you would then have a number of  line or call sub addresses (see
>>below) and also some sub addresses for each voicemail user perhaps
??
>>Does that make more sense ?
>>
>>
>
>Yes--I believe.  Again, the idea is that any number of mailboxes might
>exist that are not forced to align w/ the current concept of a line nor
>w/ a user.  At some point, the alignment of user to mailbox would be
>needed; but, as far as I'm concerned, this is a client app issue--not a
>reporting one.
>
>
>
OK -security will come into play here though too where say you have a
'sales' mailbox or a 'support' one where certain users only can get
access to the content.  This will have to be implemented server side -
but that's a whole other topic

>>Re the MWI block I think a more general name like 'Messages' might
be
>>more obvious
>>
>>
>
>ok--I'll make the change.
>
>
>
>>- such a block would be sent as an 'info' periodically or
>>an 'event' if the number of messages changed .    The source
subaddress
>>would perhaps be the person the message was for (??).  BTW There
>>shouldn't be a target line in the message above, not in .infos . 
Also
>>target=* won't match anyone - the older 'match everything' usage
was
>>target=*.>  but nowadays the 'match everyone' usage is
target=>:> to
>>match absolutely everything (including every endpoint inc sub
addresses)
>>or target=> (to match every xAP application - but not the sub
address
>>endpoints).
>>
>>
>
>Thanks for that clarification.  I must have glossed over that part of
>the specs.
>
>
>
>>  In my application I chose to use individual lines as endpoints
which
>>worked well for normal telephone lines but isn't quite such a
natural
>>fit for VOIP.  So what I did was create a new subaddress/UID for
every
>>'call' that was in place at any one time. So I had say sub address
01,
>>02 ,03 mapped to say the three normal telephone lines and then   a
range
>>of UID's available to VOIP eg 10-2F  - in my case Skype.  When a
new
>>call arrived (incoming) or was placed (outgoing) then it grabbed a
free
>>UID and reported its call status for the duration of that call on
that
>>UID.  So it wasn't a line persay , it was a call.  Given that ,
then
>>there was always an 'incoming' or 'outgoing' call status for that
call.
>>Now - there was one other aspect that made all this work. I created
a
>>'virtual' line for Skype that always reported its status as 'free'
-
>>this way it was always possible to grab a free line for an outgoing
call
>>even when calls were already in place.
>>
>>
>
>Thanks for that clarification; now, I understand the rationale.
>Unfortunately, the complexity of maintaining a similar metaphor in
>Asterisk would be unmanageable--especially with the current UID
>limitation still in force.
>
>
The existing UID is a temporary restriction and I guess  you (indeed
EVERYONE) should be planning , and coding around an expanded UID too -(
I have pre released the likely spec here anyway) .Then when  we support
these it will drop in far more naturally. If the above doesn't work for
Asterisk then I guess you need to implement an alternative. The CTI
schema is in a very early stage of its life and it will be in need of
many changes and additions . I welcome any suggestions and proposals in
this area. Bear in mind though the CTI schema is intended to handle as
wide a range of devices as possible, i.e. VOIP for example is just one
of many possible call types and there should be as much commonality as
possible between them. If something really is Asterisk specific then an
Asterisk schema might work better

>
>
>>If the hardware or VOIP provider
>>placed some restriction on how many calls could be in place
>>simultaneously then I guess this line would report 'free' up until
this
>>limit was reached and then go 'busy'.
>>
>>
>
>Yes--but that's never the case for any VoIP providers that I'm aware
of.
> Admittedly, I use carriers that don't tend to support
"consumer" markets.
>
>
I did say 'if' and maybe someone  has some hardware like a router or
something that had two tel interfaces on it so could only handle two
calls.  In the Skype world I think I have put an arbitrary restriction
of 32 concurrent calls in there , but it is an arbitrary decision just
so that I know that a certain range of UID's relate to Skype.  Available
bandwidth restrictions might come into play too

>
>
>>So xAP Switchboard always sees
>>the Skype line as 'free' to place calls.
>>
>>
>
>Perhaps this is the crux of the issue.  I'd prefer to adopt a similar
>"semantic" w/o requiring the labeling of "Skype" as
it doesn't apply to
>non-skype calls.
>
>
Does Asterisk handle Skype calls ?  If not then you wouldn't ever be
reporting a line as 'Skype' at all - you would be reporting them as VOIP
or SIP or  whatever identifies what calls can be placed on that
carrier/line

>
>
>>It then places a call on this
>>line but I immediately move it to it's own unique UID which
represents
>>the 'call' and it lives there for the duration of the call.
>>
>>
>
>Ok--perhaps here's my real concern... We don't really want to force
>dynamic UIDs for placed telephony calls--right?  UIDs are to be mapped
>to as real a device as possible.
>
No we don't want to force dynamic UID's if at all possible but there
isn't any other way practically if the hardware or software endpoints
don't map well.  When you re-use UID's between say a call that arrived
at 1PM and another that arrived at 1.05PM what is the commonality in the
fact they have the same UID, they would have different tags but the
UID/subaddress is just a  temporary container.  Also when I say I place
a call on that line I mean that xAP Switchboard targets that 'service'
to place the call. It doesn't expect in anyway the call to go out on the
'service' UID it requested - it just asks for that type of service.  An
alternative would be to add a parameter into the 'place call' xAP
message sent to the whole application (i.e. to Asterisk with no sub
address) that says what type of service you need but again the call is
going to pop up somewhere else as it originates if you are using sub
addressing at all .

> Calls are telephony-centric and should
>(IMO) never be managed as separate UIDs.  Am I missing something that
is
>core to xAP principles here?
>
>
Nope but I am curious as to how you will be managing it in any other
way. But this is your choice in how you implement an Asterisk conduit.
The way you choose to do it will differentiate your app from others and
is your competitive/technical differentiator in the saem way that many
different word processors compete.  You can choose of course not use sub
addresses at all and include the 'context' of a call within the block
but that does add ambiguity as to which block parameters are context and
which are values.  I am now confused as to which sub address division
(if any) you are wanting to use for your calls  how you choose to do
this is really your call.

>
>
>>There is a
>>'Tag' parameter that uniquely identifies this call so if it does
change
>>in its placement somehow - eg it's held and transferred somehow
then the
>>Tag remains with the call.
>>
>>
>
>Yes--this is (IMO) what uniquely identifies that call and should be the
>dynamic part of the call--not the UID.
>
>
Yes, It is the commonality and identity across the calls duration.
UID's are just containers for calls in progress. In my implementaton I
chose to segment my UID space by carrier type (PSTN  MSN Yahoo SKYPE
VOIP etc) and have a pool of UID's in each space available for the calls.

>
>
>>xAP Switchboard then could see (should it
>>wish) that the call it originally asked to be placed on UID
FFxxxx10 say
>>actually went out on FFxxxx16 because the Tag was carried over.
>>
>>
>
>Surely not!  Are you quite serious?  IMO, this will never scale
properly
>(except for very simple residential solutions) and would be overly
>complex to manage for asterisk as there's never a limit and the concept
>of "channel reuse" doesn't apply.
>
>
Yes - surely so - you asked how I do it and that is the solution I use -
I have one line that advertises a capability to place an outgoing call
via a certain method eg VOIP and that line always remains free and
'advertises' the routing capability.  A client requests that a call be
placed on that carrier and xAPTel responds by allocating that call a
UID/sub address and showing the call being placed on the first 'free'
UID above that virtual line. So to an extent my lines grow upwards from
a base UID as they are used.   Think of my first sub address (the one
you target to place a call) as a service advertiser rather than a line.
This implementation was never meant to scale to large multinational
multi switchboard setups , but if we can create a CTI schema that does
then it would be great. The call tag is there to identify a call which
may route through many different incoming/outgoing transfers, swapping
lines and even technologies , perhaps originating on PSTN and then being
transferred using VOIP etc.   Maybe we need a separate 'carrier
capability' offering schema rather than the aspect that you seem to
dislike which is that I advertise a fictious free line.  Would that be
more natural an approach ? Bearing in mind also that often lines
(carriers) are routed/selected by a switchboard intelligently using
least cost/ time of day / destination/ availability algorithms such that
a call that you ask to be originated via a PSTN line could actually end
up being transferred from your local switch to a remote switch via
internal tie lines (either analog or digital)  and then routed out via
VOIP to a foreign office and onwards perhaps by PSTN in some form.

>Is this what SB expects? or is this just xAP-Tel's policy?
>
>
SB and xAPTel were developed to use the same approach - if you can come
up with something more suitable then maybe it would be better to use that .

>Specifically, is UID mapping of this sort an expected behavior of this
>domain?  For that matter, is it for any domain?
>
>
The division of UID's into ranges and then the ranges to handle
different features is natural in xAP. A hardware board with serial ,
parallel and analog I/O might allocate 01-08 for digital 11-1C for
analog in , 21-2C for analog out and 66 for serial say.    UID 2A might
be just a UID used for reporting errors as a BSC text device.  In my
case I utilised a specific (not dynamic) UID to advertise a line
capability and then I use the UID's sequentially above that as a pool of
lines , acquiring the lowest free one at any time when a new outgoing or
incoming call appears.  The important thing is that xAP doesn't
formalise what you have to do - it is just a message construct that you
can use/apply in many many different ways. xAP is very simple but hugely
flexible in how you can choose to apply it. It is always nice when
devices sub divide into natural endpoints as this allows natural
adoption into the sub addressing model but some devices just don't - and
for those a more complex schema with context parameters provided in the
schema bodies is likely to be the solution.

>
>
>>UID
>>FFxxxx16 would of course report the full range of line actions as
well
>>showing the outgoing called number .   This 'Tag' is often used to
>>attach information to calls as they are transferred around an
office
>>say, keeping a customers record with a call or seeing who actually
has
>>already spoken to this caller, by extension.
>>
>>
>>
>
>Understood.  Again, the "tag" is something part of the
semantic of
>telephony that is embedded in the block--not the UID.  I really have a
>problem with the use of dynamic UIDs that reflect the semantic of a
>functional domain.
>
>
Do you have an alternative proposal then ?  My UID's are a pool of free
lines that represent calls in progress - thats just how I've chosen to
implement them. At the base (specific non dynamic UID)  is one allocated
'service' advertising its capability and then as each line (of this
capability) gets used I occupy UID's growing from this base upwards. As
a 'line/call' becomes released I drop the UID back into a pool such that
it can be reused.

>
>
>>>	Is there an expectation that a CTI.Event be sent anytime a
given line
>>>has some incoming or outgoing call on it?  If so, I question
the utility
>>>of the LineState values "incoming" and
"outgoing" for VoIP lines as they
>>>(in many cases) can be simultaneously incoming, outgoing and
free (since
>>>new "channels" get created on demand to satisfy
additional call out /
>>>in).  The LineState attribute suggests that it is mandatory; 
I'm just
>>>concerned that the current values may not make sense and client
apps
>>>might make false assumptions about line capacity based on a
value.
>>>Perhaps I should just always mark VoIP lines as
"Free"?
>>>
>>>
>
>
>
>>I hope I've explained why this was used above. The main line
provision
>>uses a phantom line that indeed is always free as you suggest (for
VOIP)
>>- and I move 'calls' rather than lines off onto new sub addresses.
>>
>>
>
>I'm *really* hoping to avoid this.  For now, I'm planning on always
>reporting "free".
>
>

In which case a simple xAP application wont be able to tell if a line is
available or free .... surely - how would xAP Switchboard show all the
current calls in progress along with their direction
(originator/destination) ? Are you saying it should monitor one line
(the VOIP service) and track all the different tags to segment the calls
- which is workable but more involved ?

>
>
>>>	Lastly, what is implied by the Dialler value of
"VPSTN" (vice "PSTN")?
>>>Are free to add new values to Network and Dialler to address
network
>>>types that don't fit either PSTN or Skype?
>>>
>>>
>>>
>>>
>>What I was trying to convey with 'Skype' for example was that a
call
>>could be placed to a 'Skype' username via this 'line'. If someone
added
>>MSN Messenger then there would be another ID telling me that I
could
>>place a call to an MSN ID via that line, but Skype can't place a
call to
>>a MSN user for example. Some multiclient messagers might be able to
do
>>support say MSN, Yahoo, Skype  etc etc.   What happens is that a
call
>>comes in on a certain type of line eg your normal POTS /PSTN line
but
>>sometimes that caller could be accessible via several lines.  In
Skype
>>you can ring another Skype user or indeed a normal telephone number
if
>>you additionally use theSkype OUT service.  Likewise if you use
SkypeIN
>>then a normal tel caller can ring you on Skype.   vPSTN was an
>>indication that the line could actually be used to place a call to
a
>>standard PSTN number (ordinary tel number) as well as to say the 
Skype
>>username.  So when you dialled back tehecaller you could choose
either
>>to do it via your normal tel line or VOIP using Skype.   As more
>>standards emerge then these will expand and expand. SIP should be
there
>>for example I guess in Asterisk ??
>>
>>
>
>It's not that simple in Asterisk as the "client" to
"line" possibilities
>are n*m to x*y (which means very complex).  For now, I intend to handle
>this w/i asterisk connector via a statically config'd relationship.
>I'll report back when I come up w/ something that I believe will
>properly scale to VoIP.
>
>
I would welcome a schema proposal for CTI that allows VOIP to coexist
with all the other forms of telephony that there are - (not something
that is VOIP specific)  - the purpose of a schema is to abstract the
hardware from the function it provides. The goal ( rather optimistically
) is that if you swapped out 'Asterisk' for an 'ACME' switchboard both
of which implemented the xAP CTI schema then it would just work as it
did before in relation to control and reporting to external applications.

>
>
>>A couple of other thoughts Greg
>>
>>- it is my intention to move all the 'Meteor' schema into the CTI
schema
>>as is in the list you have. ie I will just change the Class= over
.I
>>think defining a CTI schema is going to be very much an evolving
thing
>>and probably we will move forward and backtrack quite a bit along
the
>>way. But unless we actually do it then we wont get anywhere.
>>
>>
>>
>
>Ok--that's quite ok w/ me.  The only "clients" of these
messages are SB
>and mh.  I assume that you're working through the former and I can
>address the latter.
>
>
My intention is just to change all the class names as a first step. I
would recommend (if you use the CTI schema) that you have a flag that
will allow the Meteor class to be dropped and replaced with CTI

>
>
>>- the other thing is that I haven't yet supported 'text messages'
or
>>'chat' sessions that the likes of Skype and others privide. Indeed
these
>>expand to file transfer etc.  Maybe this should all tie in with
your
>>'messages' somehow as a schema.
>>
>>
>
>>From a pure semantic standpoint; they don't apply as my immediate
>interest was reporting "recorded" messages (heard and total).
 That's
>obviously different from what is mentioned above. So, does that mean
>that the block name should revert back to MWI to reflect the intended
>semantic and not interfere w/ the above?
>
>
No - not at all - it just meant that for a general CT schema we need to
consider more forms of messages than just voice - it indirectly implies
that we might need/consider a Class=CTI.Message with a blockname of
Voice  Text   File or something though - or alternatively  adding a
context parameter into the block that indicates  type=voice  perhpas.
Even within voice there are two variants - I guess one that is only
accesible via a handset and one that is available as a playable voice
data file . the presence of a file reference (of whatever form) might
serve to differentiate these .  Again we must consider more than just
the immediate application (eg Asterisk) and more the functionality of a
general CTI schema.  Thisactually is very similar to how the 'Meteor'
schema arrived insted of a 'CallerID' schema. It's often best (and
certainly easier) to create a specific schema for a device and then
implement / experiment with  that ;  then given the experience gained
you look at creating a schema that represents the 'functionality' rather
than the 'device'

>
>
>>Certainly Skype supports voicemail and
>>if the voice message can be accessed as an audio file then within
the
>>messages block should be a pathname
>>
>>
>
>I assume you would really mean URI and not actually a pathname.
>
>
yes...

>
>
>>to the file such that it can be
>>played if required.
>>
>>
>
>I don't quite think a simple reference to the location is sufficient as
>this implies "file" based access--which is far too limiting. 
Streams
>are a different matter.
>
>
This was just illustrative of any viable  mechansim to access the
original data, perhaps the telephony system will offer its own idents to
stored messages that can only be played via a handset eg MsgID #2228934

>
>
>> There are issues of security and privacy here
>>though.  At the moment as I aimed xAPTel at a home use I have
ignored
>>these.
>>
>>
>
>Eventually, it probably would be a good idea to agree on semantics for
a
>class/block to exchange keys.
>
>
I agree - and expanding/creating  a CTI schema to work for more complex
telephony environments is a big task and has many security issues. My
approach (rightly or wrongly) has been to address the SOHO markets, if
others can adapt or create something far more suitable for the bigger
installatons then I welcome that but it's not something I need myself.

>
>
>>Skype chat and text messages would be already be in ascii form
>>of course so we possibly need to identify what sort of message this
is
>>eg a voicemail, filetransfer, ascii etc etc...
>>
>>
>>
>
>FWIW: Asterisk vm are never ASCII--just streamed audio.
>
>
But my point was that a CTI schema (being generic and not only for
Asterisk) would need to be flexible an encompass  all these types of
messaging.  Can Asterisk not handle say SMS ( text messaging via mobile
phones)  ? I'm sure some enterprising individual will add that in time
if not.

>
>
>>- ignoring the actual formality of a CTI schema you are of course
free
>>to add whatever you wish to your own 'asterisk' schema say.
>>
>>
>
>Yes, but arguably pointless unless any other client cares to listen. 
My
>preference is to not simply leverage xAP--but to be compliant as
>possible with useful schemas.
>
>
The CTI schema isnt sufficiently mature yet to handle all the complex
permutations that Asterisk might introduce , nor the sheer permutations
that a corporate switchboard / telephone network might introduce. Plus
of course it needs to handle all sorts of environments of which Asterisk
is just one.   So have a go at adding/proposing  what you need . As you
were seeking the interoperability with say xAP Switchboard I attempted
(perhpas foolishly) to outline above how it works today between xAPTel
and xAp Switchboard and how you could achieve this in it's current form
, the fact you may not like how this works (notwithstanding it might
also be a very bad way of doing it anyway) is somewhat at odds with your
desire to leverage existing apps.   Why not come up with a CTI2 schema
proposal , or proposals to add into the CTI schema and if that's a flyer
then I'm sure other clients will support it. To work with the existing
apps then there's really little choice but to do it the way that it
works currently or get the apps modified.   I'm sure xAP Switchboard was
ever intended to be positioned as an industrial strength corporate front
end to a telephone infrastructure - it just serves the needs of most of
our existing xAP (SOHO) users . But xAP is sufficiently flexible such
that really complex and capable schema can be implemented but they take
a lot of architecting to get right. xAP is well suited for this sort of
application but it's a lot of thought, experience and above all time to
come up with the ideal schema that's truly scalable.  My approach was to
get something out there now for the existing spread of HA users.


>
>
>>The advantage of a CTI schema would be that all other 'telephony'
apps
>>should just integrate with it eg xAP Switchboard whereas an
'asterisk'
>>schema would need specific schema support.
>>
>>
>
>Exactly.
>
>
and of course you can implement many types of schema concurrently - apps
like HomeSeer , xAP Floorplan, xAP Desktop, and I assume Misterhouse can
pull any parameters from any xAP message so although you might have your
own schema anyone using these apps can interact with it.   xAPTel
implements both the Meteor / CTI and CID schema.   The only caution (and
I keep mentioning this) is that when you mix context parameters with
value parameters within a block it is not readily apparent to
applications (like the above) which are which.  MisterHouse would have
to examine several parameters to display another single parameter in
context. Often human interpretation can separate the two (and electronic
schema definitions will offer this too) but currently they need to be
manually linked.

silly example....

Call.info
{
direction=outgoing
line=2
linetype=PSTN
extension=247
user=kevin
dialled=02081234567
Area=Outer London
Name=Greg
Company=ACME Corporation
LastCalled=3/3/2005 14:27
LastCallDirection=Incoming
LastCallDuration=00:04:01
Duration=00:05:08
NumCalls=23
}

If you want to display who is on line 2 currently then you need to watch
for call.info blocks and scan the parameters for a line=2 and then pick
up the name= parameter - you can't just pickup the name= in isolation.
Line=2 sets the context.  Also line= and linetype= are probably linked -
you couldnt get a line=2 and a linetype=VOIP in the same block but no
info exists to identify this relationship. In my applications I try
wherever possible to take the context outside of the block - but when
there's a lot of info reported this just isnt possible.









Kevin