Re: MWI handling

[Kevin Hawkins <lists@xxxxxxxxxxxxxxxxx>]

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>  So taking on board your last 'BTW' paragraph I think
we're of the same view.

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.

So lets just agree on the param names and I'll add them to the CTI
schema.

Kevin



Gregg Liming wrote:

>Does anyone know of a schema that addresses message-waiting-indicator
>(MWI) other than CID.Meteor's Incoming.CallWithCID (which is
>insufficient for my needs)?  Specifically, I'm looking for some way to
>communicate the following information:
>
>mailboxid - string [mandatory]
>totalmessages - int [mandatory] (any positive number could be used for
>MWIs that don't implement message counts)
>newmessages - int [optional] (refers to "unheard" messages)
>
>I had thought of trying to use BSC by encoding the totalmessages and
>newmessages into the text attribute and using the mailboxid as an
>endpoint; but, this seems rather much like a "hack" and
recipients of
>such messages would have to somehow know that the source and endpoints
>were mailbox "types" and therefore know how to parse the text
attribute.
>
>If no current schema exists for this, does extension to the evolving
CTI
>schema make sense?  If so, can the CTI "owners" offer
guidance or should
>I just suggest something?
>
>BTW: It makes no difference to me whether mailboxid is treated as (1)
an
>endpoint (subaddress), (2) a part of a block name, or (3) an attribute
>w/i a block.  They should not, however, be uniquely associated w/ any
>existing concepts of telephony "line" or "device"
as they can be
>separate (and, are, in Asterisk).
>
>Gregg
>
>
>