Owner and Monitor Privileges, how do they work?

[fdecker]

There are always 2 different answers, how do we think the TAPI spec
says it should be and how the majority of TSPs interpreted it. I've
seen where if you have *only* monitor privileges set, then incoming
calls will trigger no events unless another application is running and
IT has ownership privileges. But this seems to defeat the purpose of
"monitoring" which would be used in a logging application or inbound
caller ID only with no ability to answer the call. I would think
"monitor" is exactly what you are doing. Some applications still seem
to get the events. Is there something in the TSP that controls this? I
tried 4 or 5 different devices and all but one seemed to fire inbound
call state events with privilege set only to "monitor".

On the other hand, on some applications, if "owner" privilege is
granted, then on an inbound call, other applications that used to
actually handle the call stop working because they don't have code to
change their ownership on the call and they can't answer because they
are not the owner. So either way I'm stuck.

How *should* this work?

[Andreas Marschall [exMVP TAPI]]

On May 19, 10:56 pm, fdecker <fdeckerNOSP...@aol.com> wrote:
> There are always 2 different answers, how do we think the TAPI spec
> says it should be and how the majority of TSPs interpreted it. I've
> seen where if you have *only* monitor privileges set, then incoming
> calls will trigger no events unless another application is running and
> IT has ownership privileges. But this seems to defeat the purpose of
> "monitoring" which would be used in a logging application or inbound
> caller ID only with no ability to answer the call. I would think
> "monitor" is exactly what you are doing. Some applications still seem
> to get the events. Is there something in the TSP that controls this? I
> tried 4 or 5 different devices and all but one seemed to fire inbound
> call state events with privilege set only to "monitor".

Fred,
that's the way I've always implemented it - fire events even if only
monitoring is requested.
I guess only UniModem TSP implements it different... what I regard a
TSP bug (not a feature).

> On the other hand, on some applications, if "owner" privilege is
> granted, then on an inbound call, other applications that used to
> actually handle the call stop working because they don't have code to
> change their ownership on the call and they can't answer because they
> are not the owner. So either way I'm stuck.

IMO these are clearly very poor apps (not being aple to
lineSetCallPrivilege(,_OWNER)).

> How *should* this work?

A TSP should report incoming calls even ony monitor only.
Apps should use lineSetCallPrivilege(,_OWNER) if required to handle
not owned calls.

--
Best Regards
Andreas Marschall
Microsoft MVP for TAPI / Windows SDK / Visual C++ 2003-2008
TAPI / TSP Developer and Tester
My TAPI and TSPI FAQ:
http://www.I-B-A-M.de/Andreas_Marschall's_TAPI_and_TSPI_FAQ.htm
My Toto? Tools (a collection of free, mostly TAPI related tools):
http://www.i-b-a-m.de/Andreas_Marschall's_Toto_Tools.htm
TAPI development around the world (Frappr! map):
http://www.frappr.com/TAPIaroundTheWorld
* Please post all messages and replies to the newsgroup so all may
* benefit from the discussion. Private mail is usually not replied
to.
* This posting is provided "AS IS" with no warranties, and confers no
rights.