RE: [Sipping] draft-shacham-sip-media-privacy

As it has been captured by the discussions for Dean's answer mode draft
we are interested (at least in the mobile context) in a functionality
that will provide:

A. UASs with the ability to indicate the fact that they prefer (or
mandate)that their incoming calls need to be answered manually (higher
privacy) or automatically (lower privacy) by them
B. UACs with the ability to indicate the fact that they prefer (or
mandate) that their initiated calls to be answered manually (higher
privacy) or automatically (lower privacy) by the terminating points

Particularly keeping in mind that there are SIP based solutions such as
PTT that allow automatic playout of the incoming voice stream without
requiring user's consent.

In my view therefore there seem to be use cases and requirements in a
mobile environment in particular, for "privacy mandating" calls, now
whether the "preconditions-like" approach is appropriate given it
requires e2e negotiation is something that needs to be further
investigated.

It also seems to be interesting to investigate the overlaps and
relationship in general with draft-willis-sip-answeralert-00.

Best regards,
Haris

-----Original Message-----
From: sipping-bounces@ietf.org [mailto:sipping-bounces@ietf.org] On
Behalf Of Henning Schulzrinne
Sent: 05 August 2005 09:41
To: sipping
Subject: [Sipping] draft-shacham-sip-media-privacy

During the SIPPING meeting, the concern was raised that the media
privacy tags could never guarantee such privacy and that devices may not
be able to determine their privacy. This is true, but I think somewhat
besides the point.

This type of indication/request can never be perfect, but can prevent
some "accidents". I think this is mostly useful where devices are known
not to be reliably-private, e.g., pay and lobby phones. For example, in
a doctor's office, having a mechanism that indicates that such devices
should not be used can be helpful.

Also, my perception was that there was a fair amount of interest in the
recording issue. Maybe this can be broken out as needed.

I'd value further feedback on where to take this work.

Henning

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP Use
sip-implementors@cs.columbia.edu for questions on current sip Use
sip@ietf.org for new developments of core SIP

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sip@ietf.org for new developments of core SIP