Re: MWI handling

[Gregg Liming <gregg@xxxxxxxxxxx>]

Kevin,

First, I'd like to apologize for the tenor of my previous post.  You
were trying to be helpful and my reaction to various portions was
inappropriate.  After review, I see that I was confusing many of your
statements intending to reflect your opinion or be illustrative as
though they were strong guidance or fact.  I'll be sure to ask next time
rather than assume incorrectly.

What I hope is a continuation of a useful exchange (at least for me) is
embedded below.

Gregg

Quoting Kevin Hawkins (10/3/05 7:44 AM):
> Gregg Liming wrote:
>>Quoting Kevin Hawkins (10/2/05 1:50 PM):

>>>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.
>>
>
> OK -security will come into play here though too where say you have a
> 'sales' mailbox or a 'support' one where certain users only can get
> access to the content.  This will have to be implemented server side -
> but that's a whole other topic
>

agreed.  To some extent, though, if security really is an issue, then
perhaps xAP's broadcast nature is inappropriate for use anyway.
Fortunately, message count reporting is optional in the asterisk connector.


>>> 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.
>>
>>
>
> The existing UID is a temporary restriction and I guess  you (indeed
> EVERYONE) should be planning , and coding around an expanded UID too
-(
> I have pre released the likely spec here anyway) .  Then when  we
support
> these it will drop in far more naturally.

Thanks for that info.  I will definitely take a look and be ready.

> If the above doesn't work for
> Asterisk then I guess you need to implement an alternative. The CTI
> schema is in a very early stage of its life and it will be in need of
> many changes and additions . I welcome any suggestions and proposals
in
> this area. Bear in mind though the CTI schema is intended to handle as
> wide a range of devices as possible, i.e. VOIP for example is just one
> of many possible call types and there should be as much commonality as
> possible between them. If something really is Asterisk specific then
an
> Asterisk schema might work better

I don't yet see anything Asterisk specific and also believe in the same
goal--creating a useful schema that is vendor/protocol agnostic.

I know that I was originally challenged by being limited to just the
concept of a "line".  In particular, I see 2 concepts--not 1: (1)
"end-devices" and (2) "carriers" (adopting your name
from below).  In
asterisk, this division is very pronounced.  End-devices are typically
hand- or head-sets (although could also be the voicemail or
autoattendent) and carriers are things like channel banks, single POTS
(plain ol' telephone system) adapters (e.g., a modem) and VoIP trunks.
I had been attempting to "fold" these 2 concepts into the current
single
line concept--which somewhat worked albeit a bit of a kludge on my end.

I can't help but wonder if your dynamic devices are born out of a
similar need.  In my opinion, it would be quite useful to explicitly
report on both and to recognize them as being distinct.  Now that I
understand that it is "fair game" to "move" a call (via
the tag) from
one device to another, I would think that I need to consider a similar
approach but with explicit devices to support both concepts.

>>>So xAP Switchboard always sees
>>>the Skype line as 'free' to place calls.
>>>

and, the Skype line is essentially a "carrier"--correct?

>>>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.
>>
>
> No we don't want to force dynamic UID's if at all possible but there
> isn't any other way practically if the hardware or software endpoints
> don't map well.  When you re-use UID's between say a call that arrived
> at 1PM and another that arrived at 1.05PM what is the commonality in
the
> fact they have the same UID, they would have different tags but the
> UID/subaddress is just a  temporary container.

Ok--thanks for that clarification on your usage.  I'm trying to get my
head around whether your dynamic endpoints are more like the
"end-device" or "carrier" concept reference above.

> Also when I say I place
> a call on that line I mean that xAP Switchboard targets that 'service'
> to place the call. It doesn't expect in anyway the call to go out on
the
> 'service' UID it requested - it just asks for that type of service. 
An
> alternative would be to add a parameter into the 'place call' xAP
> message sent to the whole application (i.e. to Asterisk with no sub
> address) that says what type of service you need but again the call is
> going to pop up somewhere else as it originates if you are using sub
> addressing at all .

Actually, the addition of a "service" parameter in the place call
message would be a tremendous benefit to include times when the
subaddress (to the end-device) is specified.  As an example, place call
on "Gregg's handset" via service "acmetel".  In
asterisk, "service" maps
to something called an asterisk context.  This context and the
end-device's id as well as context rules determine which
"carrier" is
used.  So, it is useful to not tie "service" parameter to a UID
(not
that I'm thinking that you were suggesting that).

>
>>Calls are telephony-centric and should
>>(IMO) never be managed as separate UIDs.  Am I missing something
that is
>>core to xAP principles here?
>>
>>
>
> Nope but I am curious as to how you will be managing it in any other
> way. But this is your choice in how you implement an Asterisk conduit.
> The way you choose to do it will differentiate your app from others
and
> is your competitive/technical differentiator in the saem way that many
> different word processors compete.

My preference/goal is not be different, but be interoperable to the
extent possible.

> You can choose of course not use sub
> addresses at all and include the 'context' of a call within the block
> but that does add ambiguity as to which block parameters are context
and
> which are values.  I am now confused as to which sub address division
> (if any) you are wanting to use for your calls  how you choose to do
> this is really your call.

I'm thinking that I have a static pool of lines (that map to the concept
of "end-device") and, optionally, a static pool of
"carriers".  I
definitely get the idea that you don't want to embed context in a block.
However, when reacting to a CID event, I'm most interested on which
carrier a call is coming in on more than which line is ringing.
Likewise, I care about what carrier is used for a given line when
calling out or having received a call.  So, it is unclear to me how I
can avoid embedding some form of context info (e.g,. carrier subaddress
or "name") into a block unless a separate message is generated
for the
carrier using the corresponding tag so that the end application
"joins"
the information provided by two separate messages.  Separate messages
keep the schema less "polluted" but does force additional state
tracking
on the end application.  Do you have a preference or guidance?

> I have one line that advertises a capability to place an outgoing call
> via a certain method eg VOIP and that line always remains free and
> 'advertises' the routing capability.

This "line" seems equivalent to the concept of
"carrier".

> A client requests that a call be
> placed on that carrier and xAPTel responds by allocating that call a
> UID/sub address and showing the call being placed on the first 'free'
> UID above that virtual line. So to an extent my lines grow upwards
from
> a base UID as they are used.   Think of my first sub address (the one
> you target to place a call) as a service advertiser rather than a
line.

Understood--you want/need something for SB to reference to initiate call
placement.

> This implementation was never meant to scale to large multinational
> multi switchboard setups , but if we can create a CTI schema that does
> then it would be great. The call tag is there to identify a call which
> may route through many different incoming/outgoing transfers, swapping
> lines and even technologies , perhaps originating on PSTN and then
being
> transferred using VOIP etc.   Maybe we need a separate 'carrier
> capability' offering schema rather than the aspect that you seem to
> dislike which is that I advertise a fictious free line.  Would that be
> more natural an approach ?

Yes

> Bearing in mind also that often lines
> (carriers) are routed/selected by a switchboard intelligently using
> least cost/ time of day / destination/ availability algorithms such
that
> a call that you ask to be originated via a PSTN line could actually
end
> up being transferred from your local switch to a remote switch via
> internal tie lines (either analog or digital)  and then routed out via
> VOIP to a foreign office and onwards perhaps by PSTN in some form.

Yes--that intelligence is embedded in asterisk via the dial-plan and is
"referenced" (initiated) by something called the asterisk
context.  So,
if the call placement includes your service parameter (which would hold
the value of the context), then this works perfectly.  I'm still
assuming that the subaddress for the placed call is still to the line
(which references a handset).  That means that asterisk decides what
carrier will actually be used--not the originating application/client.

>>Is this what SB expects? or is this just xAP-Tel's policy?
>>
>>
>
> SB and xAPTel were developed to use the same approach - if you can
come
> up with something more suitable then maybe it would be better to use
that .

The addition of an optional service argument will be sufficient as far
as I'm concerned.  I'll be sure to allow for default "service" if
nothing is specified.

The remaining issue (IMO), is how best to associate the "carrier"
w/ the
"line" for incoming and outgoing messages as discussed above.
Specifically, either separate messages (if so, then I see something
really simple for carrier that species tag [mandatory] and direction
[optional]) or embedding the carrier "reference" in a block
(which I
understand is a "no-no").


>>>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.
>>
>>
>
> Do you have an alternative proposal then ?  My UID's are a pool of
free
> lines that represent calls in progress - thats just how I've chosen to
> implement them. At the base (specific non dynamic UID)  is one
allocated
> 'service' advertising its capability and then as each line (of this
> capability) gets used I occupy UID's growing from this base upwards.
As
> a 'line/call' becomes released I drop the UID back into a pool such
that
> it can be reused.

I think so and should be non-intrusive.  I was interpreting your
discussion as the way that it should/must be done--vice could (or in
your case is) done.  Since it works for you, then leave it as is.
However, I believe that I can get by w/o any dynamic UIDs given an
optional service tag (which will always default to something and be
resolved internal to asterisk to a specific carrier).  On a call
placement, the carrier would report an outgoing call and the tag.  The
line still reports incoming or outgoing on in and out calls as well as
free when doing nothing.


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

side note: the comment above assumed that "line" was more closely
aligned with the concept of "carrier".  Now that it isn't, then
this is
no longer an issue.


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

Yes--your explanation was good.  I was not thinking "out of the
box".

>>I'm *really* hoping to avoid this.  For now, I'm planning on always
>>reporting "free".

More wrong thinking on my part.  Again, the concept of "line" is
now
associated w/ the end device (i.e., handset).

>
> In which case a simple xAP application wont be able to tell if a line
is
> available or free .... surely - how would xAP Switchboard show all the
> current calls in progress along with their direction
> (originator/destination) ?

Now that my thinking is more aligned to the concept of line and
end-device, usage can be properly tagged.

> Are you saying it should monitor one line
> (the VOIP service) and track all the different tags to segment the
calls
> - which is workable but more involved ?

No; but, if carriers provide more info (as they currently provide none);
they might be more usable by SB in time.  I will work on proposals for
augmenting CTI or a new CTI2 schema as needed for such info.  For now, I
don't see any changes to SB--for the exception of possibly adding a
"service" arg support at a later date.

> My intention is just to change all the class names as a first step. I
> would recommend (if you use the CTI schema) that you have a flag that
> will allow the Meteor class to be dropped and replaced with CTI

Ok, I will work toward that.  I would recommend considering tag to be
either a mandatory argument or "strongly encouraged" in the new
CTI
schema as w/o it, state tracking is virtually impossible.

>>>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?
>>
>>
>
> No - not at all - it just meant that for a general CT schema we need
to
> consider more forms of messages than just voice - it indirectly
implies
> that we might need/consider a Class=CTI.Message with a blockname of
> Voice  Text   File or something.

ok--for now, however, I'm assuming that adopting the CTI.Event and
CTI.Info classes with a new "Messages" block and totalmessages,
readmessages args is what will be the initial baseline.  Please let me
know if you object or prefer something else.


> The CTI schema isnt sufficiently mature yet to handle all the complex
> permutations that Asterisk might introduce , nor the sheer
permutations
> that a corporate switchboard / telephone network might introduce. Plus
> of course it needs to handle all sorts of environments of which
Asterisk
> is just one.   So have a go at adding/proposing  what you need . As
you
> were seeking the interoperability with say xAP Switchboard I attempted
> (perhpas foolishly)

... not at all.  I was being quite foolish in my previous response.

> to outline above how it works today between xAPTel
> and xAp Switchboard and how you could achieve this in it's current
form
> , the fact you may not like how this works (notwithstanding it might
> also be a very bad way of doing it anyway) is somewhat at odds with
your
> desire to leverage existing apps.

As outlined above, my shifting the use of line to be aligned w/ the
end-device and not the carrier should address the issue.  Also, based on
my current understanding of how Tel and DB work, I shouldn't have to
adopt the dynamic device pool strategy for the connector to still work
since SB won't be driving the decision about which carrier connects w/
which end-device.  Eventually adding a service arg ought to address
remaining deficiencies.