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

[bugzilla-daemon at freedesktop.org]

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





--- Comment #12 from Andres Salomon <dilinger at collabora.co.uk>  2010-03-22 21:04:55 PST ---
(In reply to comment #9)
> I propose the following translation for flag names from SIP engineerese to my
> understanding of common English:
> 
> "Headers" -> "Network" (meaning conceal network routing information etc.)

I went with "PersonalInfo", providing examples of "URIs, telephone numbers,
various informational email headers, etc".  Maybe this should be split into
AddressingInfo (ie, Network stuff like phone numbers, email addresses, etc) and
PersonalInfo (useragent headers, etc)?

> "Session" -> "Media" (they mean to anonymize the origin of media streams)

A compromise - "MediaSession" :)

> "Critical" -> "Mandatory" or leave as is

Mandatory sounds much better, yep.

> "ID" -> "Untrusted" or "NotTrusted" (do not reveal to entities outside the
> trust domain)

"HideTrustDomain"?

> 
> Also, should "user" mode be communicated to CM so that it attempts to scramble
> the From URI as recommended in RFC 3323, or let the client do this explicitly
> with handles, perhaps by a requestable property? If the former, should the CM
> then expose the scrambled channel-specific self handle/ID as properties on
> Channel.Interface.Anonymity?
> 

Perhaps we could make this a property on the Connection iface called
"DisplayName", where we leave it up to the CM whether the property is 'read' or
'readwrite'?  For SIP, I would think it makes sense to have the CM scramble the
>From URI according to the RFC (and thus leave the property as 'read')... For
some other VOIP services that go through an asterix PBX and allow configuration
of caller-id, I can imagine this being 'read-write' as the user changes their
display phone number.


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