BLISS WG J. Elwell
Internet-Draft Siemens Enterprise Communications
Intended status: Informational GmbH & Co KG
Expires: November 2, 2007 M. Vakil
Microsoft Corporation
May 2007
An Analysis of Do Not Disturb (DND) Implementations in the Session
Initiation Protocol (SIP)
draft-elwell-bliss-dnd-00.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on November 2, 2007.
Copyright Notice
Copyright (C) The IETF Trust (2007).
Abstract
Do Not Disturb (DND) is a commonly used expression for indicating a
condition where a human user of real-time communications does not
wish to be interrupted by incoming calls or other forms of
communication. This document discusses the nature of DND, ways of
observing DND, and limitations of and possible improvements to DND
Elwell & Vakil Expires November 2, 2007 [Page 1]
Internet-Draft Do Not Disturb May 2007
support in the Session Initiation Protocol (SIP) and the Rich
Presence Information Data Format (RPID).
This work is being discussed on the bliss@ietf.org mailing list.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. What is DND? . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Approaches to observing DND . . . . . . . . . . . . . . . . . 4
4. Indicating DND via SIP presence . . . . . . . . . . . . . . . 4
5. Handling communications that encounter a DND condition . . . . 5
5.1. Rejection due to DND . . . . . . . . . . . . . . . . . . . 5
5.2. Forwarding due to DND . . . . . . . . . . . . . . . . . . 7
5.3. Proxy involvement . . . . . . . . . . . . . . . . . . . . 7
6. Overriding a DND condition . . . . . . . . . . . . . . . . . . 8
7. Setting and clearing a DND condition . . . . . . . . . . . . . 8
8. Conclusions and recommendations . . . . . . . . . . . . . . . 8
9. IANA considerations . . . . . . . . . . . . . . . . . . . . . 9
10. Security considerations . . . . . . . . . . . . . . . . . . . 9
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9
12. Informative References . . . . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10
Intellectual Property and Copyright Statements . . . . . . . . . . 12
Elwell & Vakil Expires November 2, 2007 [Page 2]
Internet-Draft Do Not Disturb May 2007
1. Introduction
The Session Initiation Protocol (SIP) (RFC 3261 [1] establishes calls
or sessions for real-time communication between users and for sending
instant messages. Do Not Disturb (DND) is a commonly used expression
for indicating a condition where a human user of real-time
communications does not wish to be interrupted by incoming calls or
other forms of communication. While this condition exists, the user
normally requires that incoming calls or messages be rejected or
given alternative treatment such as forwarding to voicemail.
Presence systems can indicate the state of a user to authorised
watchers, thereby allowing them to avoid initiating communications
when the user is not available. A DND condition is one condition
where the user would not normally be available.
Although SIP can be used to reject calls or messages in the face of a
DND condition or take alternative action, this is not well
standardized and different implementations have emerged. Although
these generally can interoperate to some extent, they do not always
result in consistent indications to callers. Likewise, although
presence systems based on the basic Presence Information Data Format
(PIDF) defined in RFC 3863 [3] and the rich PIDF defined in RFC 4480
[8] can indicate availability or otherwise of a user, these formats
cannot explicitly indicate a DND condition.
This document discusses the nature of DND, ways of observing DND, and
limitations of and possible improvements to DND support in SIP and
RPID.
2. What is DND?
Do Not Disturb (DND) is a commonly used expression for indicating a
condition where a human user of real-time communications does not
wish to be interrupted by incoming calls or other forms of
communication. Such a condition tends to last for a few 10s of
minutes or a few hours, perhaps because the user is in a meeting or
is concentrating on an important job. It does not tend to be used
when the user is absent (e.g., on vacation, travelling or simply not
in the office) and is unable to receive incoming communications. It
does not tend to be used when the user is simply busy on another
communication occupying resources needed for a new communication
(e.g., when engaged in a telephone call and therefore unable to
receive further telephone calls on the same device). The condition
can be selective according to the type of communication (e.g.,
instant messaging (IM) allowed but telephone calls not allowed). It
does not tend to be used for non-real-time communications such as
Elwell & Vakil Expires November 2, 2007 [Page 3]
Internet-Draft Do Not Disturb May 2007
email. A DND condition might apply to all callers or might grant
exceptions to certain callers (e.g., to an assistant or secretary).
For the purposes of this document, DND is defined as follows:
Do Not Disturb (DND): a condition whereby a user of real-time
communications does not wish to be interrupted by incoming calls
or other forms of communication.
3. Approaches to observing DND
There are two basic approaches to ensuring that a DND condition is
observed.
With the first approach, the condition is advertised to potential
callers so that they are aware and do not attempt to initiate
communications that would violate the condition. This can be
achieved through a presence application.
With the second approach, communications encountering a DND condition
at the destination receive alternative treatment, such as forwarding
to voicemail, forwarding to another user, or rejection.
In other words, the first approach is equal to giving indications as
in a traffic light, and the second approach is more a means of
enforcement, where if someone doesn't honor these indications, action
is taken on an incoming call at the destination.
Note that even with the first approach, a destination with a DND
condition can still receive incoming communications, and hence the
second approach is still needed. Some callers will not check
presence information or be unable to access presence information, and
others might attempt a communication regardless.
4. Indicating DND via SIP presence
RFC 4480 [8] defines rich presence extensions to the basic Presence
Information Data Format (PIDF) defined in RFC 3863 [3]. PIDF defines
only "open" or "closed" as a status, although this can be accompanied
by a free text note in one or more languages. RFC 4480 extends this
by defining certain activities such as "appointment", "away", "meal",
"meeting", "on-the-phone", "busy", etc.. Furthermore an activity can
be bounded in time by means of "from" and "until" attributes. Most
activities can be associated with a status of either "open" or
"closed", perhaps using "open" in conjunction with activities that
would imply "closed" in order to allow communication in urgent
Elwell & Vakil Expires November 2, 2007 [Page 4]
Internet-Draft Do Not Disturb May 2007
situations. Status might depend on the type of communication, e.g.,
audio or IM.
It can be seen that there is no explicit indication of a DND
condition, although a number of activities, particularly when
accompanied by status "closed", suggest that the user does not wish
to be disturbed.
One option to indicate DND in a rich PIDF document (RFC 4480 [8])
would be to extend RPID by introducing a "do-not-disturb" activity
with "open" status. First, the "do-not-disturb" activity would
clearly communicate DND state in a presence document. This would
allow watchers to select an appropriate presence state indication for
presentation purposes. Secondly, using "open" status would indicate
that communication might still be possible, depending on destination
policies. On the other hand, a "closed" status would be too
restrictive.
5. Handling communications that encounter a DND condition
Typical treatment of an incoming communication encountering a DND
condition at the destination is to reject it, forward it to voicemail
or forward it to another user or device. This treatment could be in
line with a callee's current handling of incoming calls when in an
"offline" state.
5.1. Rejection due to DND
When rejecting a SIP INVITE or MESSAGE request due to DND, either a
suitable SIP response code or a defined header field value needs to
be selected, to report the condition to the caller or to enable
intermediary proxies in the callee's domain to handle the rejection
due to DND in some way (see Section 5.3).
Of course, the callee may not wish to reveal the DND condition to the
caller. If not, and if it cannot rely on a proxy in its domain to
take alternative action, then a code such as 486 Busy (to make it
look like a busy condition), 180 Alerting followed later by 408
Request Timeout (to make it look like a no reply condition) or 603
Decline (to make it look like a deliberate rejection by the user)
might be chosen. However, the choice of SIP response code or SIP
header field in this situation is outside the scope of this document.
Assuming the callee is prepared to reveal the DND condition to the
caller, one possibility is the SIP 480 Temporarily Unavailable
response code. RFC 3261 [1] assigns the following meaning to the 480
response code:
Elwell & Vakil Expires November 2, 2007 [Page 5]
Internet-Draft Do Not Disturb May 2007
"The callee's end system was contacted successfully but the callee
is currently unavailable (for example, is not logged in, logged in
but in a state that precludes communication with the callee, or
has activated the "do not disturb" feature). The response MAY
indicate a better time to call in the Retry-After header field.
The user could also be available elsewhere (unbeknownst to this
server). The reason phrase SHOULD indicate a more precise cause
as to why the callee is unavailable. This value SHOULD be
settable by the UA. Status 486 (Busy Here) MAY be used to more
precisely indicate a particular reason for the call failure.
"This status is also returned by a redirect or proxy server that
recognizes the user identified by the Request-URI, but does not
currently have a valid forwarding location for that user."
Although this suggests the use of 480 for indicating a DND condition,
480 is not used exclusively for this purpose. The second quoted
paragraph indeed indicates another condition that would give rise to
a 480 response. Furthermore, RFC 3398 [2]recommends mapping a couple
of Q.850 causes to 480 (19 No Answer from User and 20 Subscriber
Absent), and although these both have the general meaning of user
temporarily unavailable, neither has quite the semantics of DND. RFC
3261 recommends the use of the reason phrase for indicating a more
precise meaning. The inclusion or a Retry-After header field can
sometimes be useful in a DND situation where the duration of the
condition can be anticipated.
Some implementations use the 486 Busy Here response code. However,
this does not explicitly indicate a DND condition unless the reason
phrase is used. It may suggest that techniques such as the dialog
event package (RFC 4235 [4]) can be used to detect when a device
becomes free, but this probably will not work in the case of DND,
since the device concerned is likely to be free anyway. In fact some
implementations use 486 for a separate "make busy" feature. Again
the Retry-After header field can be used to good effect.
Another possibility is 603 Decline. However, this may be considered
too impolite. Also it causes any other branches in a forking
situation to be abandoned, which may or may not be the desired
outcome. Furthermore, it appears to mean that a proxy cannot even
forward to voicemail, say. Again the Retry-After header field can be
used to good effect, and this may counter the perception of
impoliteness.
Whichever response code is used, it is possible to use the reason
phrase to denote a particular condition, rather than the standard
reason phrase (e.g., use "480 Do Not Disturb" instead of "480
Temporarily Unavailable"). As there is no standardized reason phrase
it is suitable only for display purposes and not for taking automated
Elwell & Vakil Expires November 2, 2007 [Page 6]
Internet-Draft Do Not Disturb May 2007
action. Also there is the language problem. Another possibility is
to use the Error-Info header field to provide a URI where more
information is available. This would be suitable for rendering to a
user, and within a given deployment could be acted on automatically
by agreeing particular URI values (e.g., URNs).
The problem at present, with no standardized means of indicating DND
and a variety of different implementations, is that interworking is
compromised. For example, suppose a proxy is configured to take
particular action (e.g., forward to voicemail) on receipt of a DND
indication and expects that indication to be in the form of a 480
response. The expected proxy behaviour will not occur if a UA from a
different vendor issues a different response for a DND condition
(e.g., 486, 603). Likewise, unexpected behaviour might arise if the
UA emits a 480 response under circumstances other than DND.
Another issue is the SIP heterogeneous error response forking problem
(HERFP), whereby a forked request can receive different error
responses from different branches. For example, one UAS could
respond with 480 to indicate DND and another could indicate 486 to
indicate a busy condition. There is no rule for which of these is to
be conveyed back to the UAC. This is a well-known problem with SIP
and solving this problem is outside the scope of this document.
5.2. Forwarding due to DND
If calls are to be forwarded due to DND, there might be some benefit
in indicating the reason for forwarding to the new target. One way
to achieve this is by placing a suitable SIP response code (e.g.,
480) in the URI for the new target, as specified in RFC 4458 [7].
This works either for forwarding by a UA (by redirecting using a 3xx
response) or for forwarding by a proxy (by retargeting or by
redirecting). However, there is no provision for including a reason
phrase, so the code alone has to be sufficient. Also if further
retargeting or redirection occurs (resulting in yet another new
target URI), then this information is overwritten.
Another mechanism for conveying the DND condition to a forwarded-to
target is request history information (RFC 4244 [5]). This suffers
from the limitation that it works only for retargeting, because there
is no facility to convey the reason for redirection (only the 3xx
response code is provided in this case).
5.3. Proxy involvement
A proxy (or B2BUA) can be involved in DND in two ways.
Firstly, if a UAS rejects a request due to DND, a proxy in that
Elwell & Vakil Expires November 2, 2007 [Page 7]
Internet-Draft Do Not Disturb May 2007
domain can take alternative action, e.g., forward to voicemail or to
another user. To do this, it requires an explicit indication of the
condition in the response from the UAS. Also a DND-aware proxy could
handle heterogeneous error responses in a meaningful way, e.g., by
ensuring that DND is reported to the caller when some UASs have
reported busy and some DND.
Secondly, a proxy can be aware of the DND condition in advance
through some non-SIP means or by presence watching and can reject or
forward calls without first passing the request to registered
contacts. This allows a DND condition to apply to all contacts and
also removes the HERFP problem.
6. Overriding a DND condition
In some environments certain users might be authorised to override a
DND condition at a called user. A technique that might be applicable
is specified in RFC 4412 [6].
7. Setting and clearing a DND condition
Setting or clearing a DND condition at a device is a local matter.
Setting or clearing a DND condition at a proxy can be done by non-SIP
means (e.g., via a web page or by downloading a script). The only
support provided by SIP is in publishing presence information to a
compositor.
8. Conclusions and recommendations
OPEN ISSUE. Where do we go from here? There was a HUGE email thread
beginning 2007-08-02 in which this was discussed at length, without
firm conclusions. Many of the issues raised and opinions expressed
are hopefully captured above. There did not seem to be any appetite
for a new SIP response code. There seemed to be a majority of
opinions in favour or using 480 in some way. Possibly 480 together
with a Retry-After header field would imply something like a DND
condition, although the problem there is how to handle the situation
where the user has not specified a duration. So a new response code
(or a new header field) would have the merit of providing an explicit
indication without necessarily needing to include a Retry-After
header field.
A major part of that thread discussed the treatment of 6xx responses
(and 603 in particular) by proxies, and whether it is intended to
prevent retargeting to voicemail or to another AoR. It seems there
Elwell & Vakil Expires November 2, 2007 [Page 8]
Internet-Draft Do Not Disturb May 2007
is ambiguity in RFC 3261 concerning the precise meaning of 6xx
responses. There was also a suggestion that there might be a more
general need (beyond DND) for a UA, when rejecting a request, to
indicate to the domain proxy how to handle forking and retargeting,
based on what the user has indicated (e.g., if the user pressed the
"forward to voicemail" button, the proxy should do that and abandon
other branches). These aspects require further elaboration, either
in a future version of this draft or separately.
Furthermore, is there a desire to extend RPID?
Possible requirements for ongoing work include:
REQ1 - There MUST be a way for a UA to indicate through presence
that it is not willing to receive a call or message because the
user does not wish to be disturbed.
REQ2 - There MUST be a way for a UA to indicate when rejecting a
call that the user does not wish to be disturbed.
REQ3 - There MUST be a way to determine the scope of DND when
multiple contacts are available.
REQ4 - There MUST be a way for the DND condition to take
appropriate precedence in a HERFP situation.
REQ5 - It MUST be possible for a proxy that is aware of a DND
condition to take appropriate action without forwarding the call
or message request to the UA.
REQ6 - It MUST be possible for a proxy to intervene in a rejection
by a UA due to DND and take alternative action (e.g., forward to
voicemail).
9. IANA considerations
None.
10. Security considerations
For reasons or privacy or politeness a user may not wish to reveal
his/her precise state to a caller or presence watcher, and this might
extend to the DND condition. To get around this, a less precise
indication may need to be given.
11. Acknowledgements
Thanks to Shida Schubert for carrying out an initial review and
providing comments.
Elwell & Vakil Expires November 2, 2007 [Page 9]
Internet-Draft Do Not Disturb May 2007
12. Informative References
[1] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP:
Session Initiation Protocol", RFC 3261, June 2002.
[2] Camarillo, G., Roach, A., Peterson, J., and L. Ong, "Integrated
Services Digital Network (ISDN) User Part (ISUP) to Session
Initiation Protocol (SIP) Mapping", RFC 3398, December 2002.
[3] Sugano, H., Fujimoto, S., Klyne, G., Bateman, A., Carr, W., and
J. Peterson, "Presence Information Data Format (PIDF)",
RFC 3863, August 2004.
[4] Rosenberg, J., Schulzrinne, H., and R. Mahy, "An INVITE-
Initiated Dialog Event Package for the Session Initiation
Protocol (SIP)", RFC 4235, November 2005.
[5] Barnes, M., "An Extension to the Session Initiation Protocol
(SIP) for Request History Information", RFC 4244, November 2005.
[6] Schulzrinne, H. and J. Polk, "Communications Resource Priority
for the Session Initiation Protocol (SIP)", RFC 4412,
February 2006.
[7] Jennings, C., Audet, F., and J. Elwell, "Session Initiation
Protocol (SIP) URIs for Applications such as Voicemail and
Interactive Voice Response (IVR)", RFC 4458, April 2006.
[8] Schulzrinne, H., Gurbani, V., Kyzivat, P., and J. Rosenberg,
"RPID: Rich Presence Extensions to the Presence Information Data
Format (PIDF)", RFC 4480, July 2006.
Authors' Addresses
John Elwell
Siemens Enterprise Communications GmbH & Co KG
Hofmannstrasse 51
D-81379 Munich
Germany
Phone: +44 115 943 4989
Email: john.elwell@siemens.com
Elwell & Vakil Expires November 2, 2007 [Page 10]
Internet-Draft Do Not Disturb May 2007
Mohammad Vakil
Microsoft Corporation
One Microsoft Way
Redmond, WA 98052
USA
Email: mvakil@microsoft.com
Elwell & Vakil Expires November 2, 2007 [Page 11]
Internet-Draft Do Not Disturb May 2007
Full Copyright Statement
Copyright (C) The IETF Trust (2007).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Elwell & Vakil Expires November 2, 2007 [Page 12]