Re: MWI handling

[Kevin Hawkins <lists@xxxxxxxxxxxxxxxxx>]

Gregg Liming wrote:

>Hi Kevin,
>
>	I'd like to get some consensus on this fairly soon so that I can
>complete the asterisk connector.  Specifically, I'm wondering about a
>statement below that suggested that you were thinking of adding
>parameters to the existing "Line" block.  Voice mail messages
aren't
>linked to a specific line in asterisk (as they are w/ PSTN solutions);
>so, that metaphor doesn't quite work.  Until rereading your original
>reply below, I was assuming a new block called MWI.  Such a block might
>look like
>
>xap-header
>{
>	v=12
>	hop=1
>	uid=FF963401
>        class=CTI.info
>        source=liming.axc.home:vm.default.01
>        target=*
>}
>MWI
>{
>	totalmessages=42
>        readmessages=16
>}
>
>	Your thoughts/reactions?
>
>
Hi Greg.

I guess this comes down to really what sub addressing you are using
within the application. ie you will  have the whole 'asterisk'
application ....

UID=FF963400

source=liming.axc.home

and then some specific endpoints.  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. But maybe you would create
sub addresses for each user if the messages can be categorised this way
?? 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 ?

Re the MWI block I think a more general name like 'Messages' might be
more obvious - 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).

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.  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'.  So xAP Switchboard always sees
the Skype line as 'free' to place calls. 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. 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. 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. 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.

>	Next, I have specific questions about the response of a CTI.Query:
>1)  Are Line and (if the above is correct) MWI blocks for all endpoints
>specified in a single CTI.Info message; or, are they enumerated in
>separate messages (specifying their endpoint in a fully qualified
source)?
>2)  If the former, how do you name or label a Line block?  I would have
>expected something BSC-esque; but, the CTI docs that I'm looking at
>don't have anything to identify a line in the Line block.
>
>
( this was clarified in your next message )

>	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.

>	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 ??

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.

- 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. 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 to the file such that it can be
played if required.  There are issues of security and privacy here
though.  At the moment as I aimed xAPTel at a home use I have ignored
these.  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...

- ignoring the actual formality of a CTI schema you are of course free
to add whatever you wish to your own 'asterisk' schema say. This would
enable you to play with all sorts of ideas and then perhpas after a bit
of real world experience we could adopt them into a CTI schema. This is
how the Meteor schema eveolved and why I'm now pushing this into CTI.
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.

Kevin


>
>Quoting Gregg Liming (9/16/05 11:12 AM):
>
>
>>Quoting Kevin Hawkins (9/16/05 7:54 AM):
>>
>>
>>
>>>Hi Gregg,
>>>
>>>   Certainly within my early CTI schema I don't have a message
waiting
>>>schema - but I should have ;-) It can be added quite easily on
a per
>>>line ie per UID basis by a suitable parameter
"Messages=" or
>>>"MessagesWaiting=".  For a more complex mailbox
application I'm
>>>wondering if it may be somewhat different and possibly not
within the
>>>scope of the CTI schema and more part of an email or general
messaging
>>>schema... certainly if it has a lot of 'context' data as to
mailbox
>>>names, priorities, ID's,  etc.    Does Stuart perhaps have
anything
>>>within his email  apps I wonder ?
>>>
>>>   Looking below at the parameters you suggest,  I think this
could be
>>>incorporated within the CTI schema  as the data is fairly
simple, and
>>>fits within a sort of answerphone or data model where you have
'new' and
>>>'saved' messages.  I'm somewhat against the mailboxID as a
parameter
>>>though... as the message waiting parameter would already have a
context
>>>set by the source address / UID.   <thinking aloud>
However,, perhaps
>>>this is appropriate in a CTI context as well ...where a
'message' comes
>>>in on one line but is left for a specific person (perhaps via
DTMF) so
>>>the line ID  is irrelevent. But .... in that case probably the
source
>>>sub address (and UID) should then be identifying the user by
name.<
>>>/thinking aloud>
>>>
>>>
>>Yes--agreed.  So, for example, the source may be something like:
>>
>>vendorid.deviceid.instanceid:vm.01
>>
>>where vm is the collection of voicemail boxes and don't map
directly to
>>"line" subaddresses.
>>
>>
>>
>>
>>>So taking on board your last 'BTW' paragraph I think
>>>we're of the same view.
>>>
>>>
>>yes
>>
>>
>>
>>
>>>   In my apps I try as hard as possible to remove 'contextual'
>>>information from the bodies.  This is because declaring the
value of one
>>>parameter only in the 'context' of another (eg Messages=2 ,
Name=Kevin)
>>>makes it very difficult for other applications to parse. (eg to
display
>>>#messages waiting for Kevin in HomeSeer).   Other listeners
have to know
>>>which parameters are 'context' and which are general values . .
 ie that
>>>Messages=  relates to 'Kevin' only.  There is no easy way to
recover
>>>that info currently.    If you move 'Name' to a sub address
then all is
>>>well again.  xAP currently does not have a way of identifying
context
>>>parameters vs general values in the same blocks so I work on
the basis
>>>that 'class + source:sub + blockname" should set the full
context of the
>>>parameter and the sub address portion of the address is very
key to this
>>>working.   A lot of James' app's do handle recovery of
parameters based
>>>on some other context parameter which is nice though.
>>>
>>>
>>yep--agreed as well.
>>
>>
>>
>>
>>>   So lets just agree on the param names and I'll add them to
the CTI
>>>schema.
>>>
>>>
>>I think we're now talking about just the 2--right?  Specifically,
>>totalmessages and newmessages.  I'm not hung up on the names; just
let
>>me know what you decide.
>>
>>While we're discussing this... Should was also mimic the other CTI
and
>>BSC semantics which have a info and event message where event is
sent on
>>some change and info is sent at some definable interval and/or on
>>request (is there a query for CTI?).
>>
>>
>
>
>
>
>Yahoo! Groups Links
>
>
>
>
>
>
>
>
>
>