[Bug 24909] Anonymity API (e.g. suppressing caller-ID)

[bugzilla-daemon at freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=24909

--- Comment #27 from Senko Rasic <senko at senko.net> 2010-04-20 09:36:49 PDT ---
(In reply to comment #21)
> (In reply to comment #20)
> >   · Others think that supporting these other flags is fine, but we
> >     should order the flags by how obscure they are, so that the one you
> >     actually care about — OriginatorInfo, aka caller-id — is first, and
> >     then the introduction can say "If you just care about hiding your
> >     caller ID, call Set("Flags", 1)".
> 
> Sure, the ordering is arbitrary atm (as the modes have changed quite a bit).  
> A client who just wants to set caller-id shouldn't make assumptions about the
> CM, though; the process should be something like -
> 
> SetAnonymityMode(GetProperty("SupportedAnonymityModes"));
> SetProperty("Mandatory", true);
> 
> Likewise, turning caller-id back off should be -
> 
> SetAnonymityMode(0);
> 
> If the client actually cares about a various subset of anonymity settings (ie,
> they only want to turn off caller-id, but leave hide-trust-domain turned off)
> is going to need to look at individual mode flags anyways.

AIUI the idea here is that we can perhaps come up with a logical ordering of
the "anonymity-levels" (instead of a set of orthogonal flags), in which hiding
the caller ID would be the first, and then additional anonymity (hiding of
network info, sesison info, etc) would compound onto that.

(In reply to comment #26)
> (In reply to comment #25)
> > So far, HideCallerId boolean property on the connection would have sufficed. It
> > could also be a requestable property on the channels, though at the moment,
> > tp-ring parses it from the phone number (#31# and *31# from 3GPP 22.030).
> 
> There is a reason why a simple boolean did not suffice. The underlying CLIR
> supplementary service can be provisioned by the network to be permanently on,
> on by default or off by default. The setting cannot be changed (unless the
> network operator changes it). CLIR can be invoked or suppressed on per call
> basis, however.
> 
> The Maemo 5 settings UI provides three choices, "Use network default", "On" or
> "Off". The Privacy property is empty, "id" or "no-id", correspondingly. If the
> Privacy property is "id" or "no-id" (or #31# or *31# prefix was used with the 
> telephone number) a CLIR invocation or suppression element was added to the
> SETUP request sent to the network. 
> 
> Anonymity API should probably support both invocation or suppression of the
> anonymity services, either with two sets of flags, or with an extra flag for
> each service that can be suppressed.

This could tie in with what I've mentioned above - if we can have a logical
ordering of anonymity levels, we can add "default" and "force show id" in
there, too. Something like:

enum AnonymityLevel {
  SHOW_CALLER_ID,
  DEFAULT,
  HIDE_CALLER_ID,
  HIDE_NETWORK_INFO,
  ...
};

.. where DEFAULT means "whatever the default server settings are if we can't
find out / unknown" in Connection context, and "whatever the connection
settings are" in Channel context. With this, you can have channel suppressing
CLIR even though it's enabled in Connecion

> That depends upon the SIP folks; exactly how much control do you want to
> provide to a UI when allowing modification of SIP anonymity modes?

Umm, all of the flags, to just map it straight to the privacy header? :)
I tried to boil it down to some generally meaningful categories, but if such
complexity is deemed not desirable/useful, some of them could be collapsed,
with some consensus on what each broad privacy category should mean for SIP.

>From what I've seen here, both SIP Headers and Session privacy flags are
network related - the former is for the control channel, while latter is for
the media itself. So, if we want to have a smaller number of options, it might
make sense to clump them together into eg. HideNetworkInfo.

OTOH if we don't want anonymity levels, and opt for orthogonal flags instead,
I'd say we rather add the Caller ID one for the moment, and then just add more
if/when we need to. But in this case, it looks to me like we're really going to
have at least have Caller ID into a separate property, because of the tristate
(enable, suppress, default) value for channels.

> It would be also a good idea to provide a specific error code for the cases
> where the anonymity service cannot be provided. (SIP does not do that, unless
> you use Proxy-Require: privacy and get 420 back.) On GSM, if you try to invoke
> CLIR but the CLIR service is not provisioned, a special cause code is returned.

Can't we have this with a combination of Mandatory flag and existing
NotAvailable if it's set and the anonymity level is not available? (ie. if
Mandatory is not set, can/should tp-ring ignore CLIR request failing?)

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
You are the assignee for the bug.