Re: MWI handling

[Kevin Hawkins <lists@xxxxxxxxxxxxxxxxx>]

>
>
>>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.
>
To an extent but I don't (currently) have the ability to transfer calls
between handsets - at least not in managed way - I can put one handset
down and pick up another on a POTS line ;-) - but which handset is
current is not determinable.  When I say I have dynamic UID's again this
confusion occurs because I am advertising the 'service' via a UID and
the client targets that UID to place a call - this is a bit of a red
herring as there is no reason this has to be either advertised using a
sub address  or tageted via a sub address (it could be advertised by the
main app)

> 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.
>
>
I still think 'lines' is valid in VOIP even if there is no finite number
- but you can assign a lineID to that call from a pool of ID's for that
carrier - which keeps VOIP handling inline with ISDN or copper wire.

>
>
>>>>So xAP Switchboard always sees
>>>>the Skype line as 'free' to place calls.
>>>>
>>>>
>>>>
>
>and, the Skype line is essentially a "carrier"--correct?
>
>
yes - the 'advertised' line is a carrier (capability ) advertisment.
But I number sequentially lines in use from a pool as calls are
made/received

>
>
>>>>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.
>
>
'lines', calls  or coversations occupying a trunk position - even if the
service is a VOIP one

>
>
>>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).
>
>
OK - I think I agree on that... we need to advertise the available
carriers somehow... - from the whole app and not a sub address.  My
previous route provided a sub address for each service eg Skype

>
>
>>>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.
>
>
Perhaps it is the concept that a UID addresses an endpoint that is
misleading - it can be any distinct 'entity' as such so that a sub
address (UID) could be a handset or a line (circuit) or a call.  I am
increasingly thinking that these three entities are the correct one for
telephony as they represent the two endpoints of the call (where it
enters your domain at the exchange and where it ends up - on a handset)
and 'what' it is that is being routed.  Arguably there is another
endpoint(s) that being the remote caller .  Given conference calls - or
circumstances where a call in 'ringing' state is being presented on
multiple handsets concurrently (eg ringing all sales lines) then  it can
get a bit more complex.   I am still undecided as to whether a  complex
'matrix switch' scenario like this lends itself to the simple sub
addressing capabilities with xAP at all.

>
>
>>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".
>
>
Yes.. and need not have a sub address as mentioned above

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

>
>
>>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.
>
Agreed  - there is still a clarification we need to make though.     A
service needs to know what numbers it can dial - for example only Skype
can dial 'John Doe' by the Skype username - but both Skype (if you
subscribe to SkypeOUT) and ordinary PSTN lines (and maybe some VOIP
services) can dial a standard telephone number.   If your dialplan
mandates that all traditional local telephone numbers are presented via
PSTN but nationwide/international go via IP then you almost need to
present a 'chosen service' plus a call type' parameter so the switch can
make a valid choice.  Or you leave that responsibility to the client. An
ISDN line for example can place both a data call and a tel call.

> 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.
>
>
Maybe - there is a different possibility of mismatched call type/service
we have to manage here - either within teh switch or the client. Given
most switchboard programmers like to be able to enforce their won dial
plans this seems to imply it should be done within teh switch but I am
not sure this service to call type matching is capable enough (within
dialplans)

>
>
>>>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").
>
>
It's not a no-no - it just makes parsing more difficult but in such a
complex schema as CTI I think it is inevitable.

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

I think you will still have issues - what happens for example when a
call is transferred to another handset - (or group of handsets) - if teh
sub address changes the UID must too.

> 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.
>
SB currently does not handle handset endpoints - its really a line based
logger - whether (ever) it would move to supportring a matrix system
like a true switchboard I don't know - that's a decison for James. The
fact it's called Switchboard is interesting ;-).  What we do need
however is for the CTI schema to support this.
Ultimately as calls meander around a switchboard with various handsets
joining and leaving the call and possibly other external lines too its a
very complex scenario - using a  call tag is the only real identity so
maybe that is the mandatory key - although I still think being able to
access handsets and lines via targeted queries is a huge bonus -
supporting groups and services maybe possible to eg asking who is
currently using Skype

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

>
>
>>>>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.
>
>
We need to identify them as voice in some way ....   and add a way of
playing the (several) voice file(s) if it is network accessible somehow.

>
Kevin