Re: MWI handling

[Gregg Liming <gregg@xxxxxxxxxxx>]

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

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

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

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

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

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

> 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.  Calls are telephony-centric and should
(IMO) never be managed as separate UIDs.  Am I missing something that is
core to xAP principles here?

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

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

Is this what SB expects? or is this just xAP-Tel's policy?
Specifically, is UID mapping of this sort an expected behavior of this
domain?  For that matter, is it for any domain?

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

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

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

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

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

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

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

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

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

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