Re: MWI handling

[Gregg Liming <gregg@xxxxxxxxxxx>]

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

Gregg

>
>     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
>>
>>
>>
>
>
>
>
>
>
>
> Yahoo! Groups Links
>
>
>
>
>
>
>
>