Re: MWI handling

[Gregg Liming <gregg@xxxxxxxxxxx>]

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?

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.

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

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?


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