Subject: [SIP] DCS privacy update - open issues

From: Flemming Andreasen <[email-masked]>
Date: Sun, 11 Jun 2000 19:26:47 -0400

Having cleared the RFC 2026 issues, I'm in the process of updating the
dcs-privacy draft (draft-dcsgroup-sip-privacy-01.txt) based on the
comments received in Adelaide, but would like some list discussion on
some of these first.

1. Remote-Party-ID authenticity
======================
Currently, the Remote-Party-ID may include an "rpi-auth" token intended
to provide authenticity service for the Remote-Party-ID specified. The
current scheme has some shortcomings, most notably that it is not linked
to the INVITE, which can be rectified fairly easily. However, upon
thinking further about this and also based on the SIP Security meeting,
it seems to me that this is simply a special case of a more general
security service, i.e. to provide authenticity (or other security)
service for one or more fields in a SIP message. The proposal is
therefore to simply to remove the "rpi-auth" token.

2. Remote-Party-ID type
=================
The "rpi-type" is intended to identify users by type rather than by name
under the assumption that some types of users may be granted privileges
different than others. One particular example we have identified and
defined in the draft is the type "operator" which we need for the
Busy-Line-Very end Emergency Interrupt. As has been noted, these are
specific service examples and the "operator" type tends to fall in the
service specific category as well. As the concept seems to apply in
general, but the particular application of it may depend on the
environment, the proposal is therefore simply to define "rpi-type" as a
token and have local policy determine particular values that may or may
not be supported.

3. OSPS header
============
As noted above, the OSPS header is not particularly general. but rather
service specific. In the case of BLV, busy call processing should not
result in a busy indication being returned but rather a duplicate media
stream. In the case of EI, a conversation/conference should be the
result. Taking a step back, the OSPS header can be viewed as a caller
request for some kind of specifial call processing - as has been noted,
this looks rather similar to caller preferences. The Request-Disposition
"ring-feature" already achieves parts of this, and an alternative to the
OSPS header would therefore be to simply expand upon this, e.g. by
adding a "bridge-feature" (which might be further described in terms of
simplex or duplex) or something similar.

All comments appreciated.

Thanks and regards

                Flemming Andreasen

--
Flemming Andreasen                Phone: +1 732 452 1667
Cisco Systems                     Fax:   +1 240 359 5839

_______________________________________________
SIP mailing list
[email-masked]
http://lists.bell-labs.com/mailman/listinfo/sip