Re: MWI handling

[Kevin Hawkins <lists@xxxxxxxxxxxxxxxxx>]

Hi Gregg ,

I'll need a little more time to digest your previous post... but
here's some thoughts on this one.

Gregg Liming wrote:

>
>In my previous post, I was discussing the concepts of
"end-device" (such
>as a handset or headset) and "carrier".  It just occurred to
me that one
>option that might work well is to concatenate these two to form a
unique
>subaddress:
>
><voip_subaddress> = <end-device> . <carrier>
>
>an example:
>
>    sip_01.iax2_nufone (where sip_01 is my deskphone and iax2_nufone is
>a voip carrier).
>
>another example:
>
>    sip_01.zap_1 (where sip_01 is my deskphone and zap_1 is a POTS
>adapter tied to my residential PSTN service).
>
>
You can of course choose whatever sub address formats you like - that's
why xAP's so flexible - to my way of thinking this is a little contrived
but I agree it does create a descriptive address that identifies the
source & destination outside of the block .   You could also consider
maybe a source name of just the handset and a blockname that identified
the carrier  eg incoming.iax2_nufone .  I feel putting one or other
within the block is more natural though and aligning a souce address
with a  single endpoint ( and on rethinking there seem to be 3 natural
endpoints - see later) .   For my smaller setup - which after all is
just  a 3 line home setup plus Skype (and SIP although I dont use that)
then the line/call  arrangement seems to suit my needs better. However I
can't easily tell which extension (handset) is associated with the call
as my hardware doesn't differentiate them currently so I haven't
addressed the handset endpoint issue at all.

I do have (in my attic) three very capable switchboard here that I
removed from my previous company ( 100+ incoming and 150 extensions and
switchboards interconnected) - if I ever get to use them then your
arrangement might prove desireable.  My approach previously would
probably have been to send 'line info' for each line and 'extension
info' for each extension and 'call info' for each call and associate
them all together via the call tag within the body - which is actually
what the switches almost already does using its RS232 CTI port. I could
then issue a 'query' to either the handset or the line or the call to
recover the accompanying data from the other two eg which extensions(s)
are involved in Call XXXX or which line is extension XX using etc .
Being able to 'target' an extension to find related info seems very
useful - eg how long has that extension been busy - how many cumulative
calls its made, how many calls are queued to that extension etc. etc.
Thus my endpoints are all individual and not combinational . To me this
feels more natural, and there are 3 natural categories of devices - the
handsets, the lines and the calls.  I dont think its unreasonable to
allocate a large block of sub addresses to VOIP calls even though they
may be an intangible number there is still a practical  max number for
these , and the new UID format is adequately scaleable.  Also my
'extensions' endpoints could also be telephone groups (eg sales) - and
be targeted in the same way for info like current waiting calls or
average answer time etc.  I do recognise you can still target an
extension or a line in your proposal using target=>:sip_01.>  or
target=>:*.iax2_nufone but you can't access a 'call' or a 'group'
although maybe that's not so critical.

Also....I'm just thinking aloud here - in your scenario - what happens
when an incoming call arrives and rings a group of extensions - how
would you report that ?  Later if the call isnt answered or is
transfered it might be presented on a different handset or even group of
extensions (eg sales transfer the call to support) . The same call
identified by 'tag' would be shifting UID's all the time as your source
addresses (& hence UID)  would be changing wouldn't it ? - which is the
issue you didn't like regarding dynamic UID's ?

>The notable downside is that we now have a "big O" problem
since the
>number of subaddresses is M*N rather than M+N (w/ implications both on
>UID size as well as volume of periodic CTI.info messages).  But, I'm
>guessing that such a scheme remains consistent w/ the current Tel/SB
>implementation and it definitely addresses my need to know how a
>end-device and carrier are related.  Also, the impact of "big
O" problem
>significantly lowers once longer UIDs are permitted.  Then, it's more
of
>a config mgmt issue.
>
>
Well try it and see if it suits your need - If you do this I  would
recommend you offer two schema - one that works like you've outlined and
one that contains all the info in one message ie an Asterisk one eg
containing

extension=
line=
carrier=
diallednumber=
dialledname=
duration=
tag=
etc...

I still think it may be better to veer away from subaddressing if
it's going to generate so many permutations.  What actual size of
Asterisk install are you handling there and how many concurrent calls do
you realistically get ? Barring call centres & utility providors I have
found that even med/large companies rarely have more than 30 or so lines
although with increasing  remote teleworkers and multiple offices the
internal (remote) extension usage can get quite high I guess but those
are now almost always VOIP

> >    If however there is a better use of sub addressing , and I am
sure
>
>
>>there is,  that fits more naturally against a VOIP model (and if it
does
>>that it will probably be retrofittable against less complex models)
then
>>I think we should adopt that for the CTI schema. I'm very much open
to a
>>suggestion here .
>>
>>
>
>I'd like to know your thoughts on the above.  In addition, I would
>propose the following:
>a) migrate to the concept where a call is uniquely identified by the
>"tag" arg and not a UID.  This implies that possibly more
than one call
>can exist concurrently on the same subaddress/UID.
>
>
I think you hit a problem here firstly with compatability with any
existing application as they segment calls based on UID's and secondly
you can only have one source address matching one UID and as you are
varying the source address based on the enpoints that would mean that
two calls would have to have identical sub addresses in the source= line
if they shared a UID

>b) allow multiple line blocks for a CTI.event/info when more than one
>call is associated w/ a subaddress.  Only one line block would ever
>exist if LineState is "free".
>
>
Isn't this precluded for the reasons above ?

>c) add VOIP to the list of Network arg enumeration type (I could see
>this get more fine grained; but, for now, it would mean allowing the
>same capability of call transfer between PSTN and VoIP as you to w/
PSTN
>and Skype.
>
>
NP -that list is an open ended list of all compatible systems - ie a
system on which you can present the same "number" (to dial) and
it will
reach the correct destination, I don't know enough about VOIP to know if
this is workable or if you need a 'SIP' type (protocol) name etc rather
than VOIP

>d) change Country arg to be optional
>
>
The issue here was that phonebooks often don't store the full dial
number for PSTN calls so the connector had to know to add them to
'local' numbers eg for Skype, hence it needed the country code . With
VOIP this is probably irrelevent. This can actually be achieved at the
client too - and I think xAP Switchboard will do it automatically.

>e) add optional Service arg to the call placement message (soon to be
>CTI.dial?)
>
>
I need to digest your other message so can't comment (yet)

>I'm guessing that the most controversial proposed change is a/b.  I
>would also see that not adopting will not be a huge issue for asterisk
>connector users early on.  But, it would be nice to know how SB will
>behave if messages are generated that imply multiple concurrent calls
>(but not yet implementing "b)" ).
>
>
>
I am pretty sure SB differentiates calls by UID and will not segment
calls based on tag - as one 'line/call/UID' in xAPTel can only present
one call.

>>It may well be that there is no alternative but to
>>drop down to a much smaller use of sub addressing, perhaps where
"VOIP"
>>is one sub address as one style of interface and Skype is another
and
>>PSTN another
>>
>>
>
>I'm proposing more granularity rather than less.
>
>
I know but you are also encountering the 'big O' problem - and actually
it's even worse as its M*N * calls if you cant share calls on a UID.
The alternative being reporting the two endpoints within a block. But
it's your call (bad pun)  and xAP doesnt constrain or dictate how it
should be done . xAP does however mandate that the source address
matched against a specific UID does not change and is on a one to one basis

>
>
>>and then the blocks contain more contextual data and the
>>same sub address is used concurrently for many calls differentiated
by
>>the call 'tag' .
>>
>>
>
>Yes--but, try to minimize the requirement for acting/reporting call
>concurrency by driving up the subaddress granularity.  That allows
>reasonable usage in the near-term w/ growth in the long-term provided
>the above concurrency option is adopted.
>
>
I agree - it is a balance

>
>
>>Alternatively by implementing a much longer UID you
>>could even use the tag as the UID -
>>
>>
>
>I would "vote" against this as it drives toward the
requirement for
>stronger dynamic UID pool management (I'm pretty sure that your new UID
>syntax is not as long as asterisk's tag system; so, mapping could
become
>a nuisance).
>
>
>
The new UID scheme has unlimited lengths so it could match this if it
was necessary. The issue would be how long a call tag has to remain
unique - is it forever or for the duration of all concurrent calls. I
think the current 'big switch' I have invokes a unique 'whilst current
and within 24hours' approach but a pool of as few as say 100 ID's might
be workable on even med size systems - you can always augment them with
a  date/timestamp to create truly unique tags.

>>It may also be that sub addressing is not approriate in that
although
>>there are many possible candidates for such a division none fit
>>naturally.
>>
>>
>
>I' m fairly certain that the subaddressing proposal above should handle
>most any asterisk situation and is "backwards compatible" w/
the current
>line concept.
>
>
>
Give it a go - try it and see - realistically the xAP Asterisk users are
fairly small installs anyway.  If you support both a highly granularised
approach and also an additional schema where much of the information is
contained within one large block with a 'line summary' or equivalent
.info message and a  .event when anything changes  (and all call detail
/ endpoints info etc within a block) then people could choose which way
they interact with your application.     I'm sort of liking the 3
endpoint approach though - handset/group, line and call.

Kevin