Re: MWI handling

[Gregg Liming <gregg@xxxxxxxxxxx>]

Quoting Kevin Hawkins (10/3/05 11:03 AM):
> Gregg -
>
>     Just to summarise that very long last post....in case it comes
over
> as a 'do it this way' type of view - it shouldn't

nope--I didn't interpret that from your post.

>     There is no requirement to use sub addressing but if there is some
> division that an application naturally fits around then it makes it
far
> more presentable and also brings the addressing of the individual
> enpoints outside of the block content which aids subsequent parsing
and
> context.. In the CTI schema there is as yet no definition of how this
> sub addressing should be implemented, originally it was centric around
a
> telephone 'line' approach but as we've found this does not scale or
> adapt well for say VOIP.

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

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.

>    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.
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".
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.
d) change Country arg to be optional
e) add optional Service arg to the call placement message (soon to be
CTI.dial?)

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

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

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

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

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