BLISS WG J. Elwell Internet-Draft Siemens Enterprise Communications Intended status: Informational GmbH & Co KG Expires: May 19, 2008 S. Srinivasan Microsoft Corporation November 16, 2007 An Analysis of Do Not Disturb (DND) Implementations in the Session Initiation Protocol (SIP) draft-elwell-bliss-dnd-01.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 May 19, 2008. 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 & Srinivasan Expires May 19, 2008 [Page 1] Internet-Draft Do Not Disturb November 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 . . . . . . . . . . . . . . . 5 5. Handling communications that encounter a DND condition . . . . 5 5.1. Rejection due to DND . . . . . . . . . . . . . . . . . . . 6 5.2. Forwarding due to DND . . . . . . . . . . . . . . . . . . 8 5.3. Proxy involvement . . . . . . . . . . . . . . . . . . . . 8 6. Overriding a DND condition . . . . . . . . . . . . . . . . . . 9 7. Setting and clearing a DND condition . . . . . . . . . . . . . 9 8. Conclusions and recommendations . . . . . . . . . . . . . . . 9 9. IANA considerations . . . . . . . . . . . . . . . . . . . . . 10 10. Security considerations . . . . . . . . . . . . . . . . . . . 11 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11 12. Informative References . . . . . . . . . . . . . . . . . . . . 11 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 Intellectual Property and Copyright Statements . . . . . . . . . . 13 Elwell & Srinivasan Expires May 19, 2008 [Page 2] Internet-Draft Do Not Disturb November 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. In particular it identifies the following issues: o indicating DND in RPID; o called UA indicating DND to its proxy so that alternative action can be taken; o indicating DND to the calling UA when the call is rejected because of DND; o the scope of DND when there are multiple contacts available. 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 Elwell & Srinivasan Expires May 19, 2008 [Page 3] Internet-Draft Do Not Disturb November 2007 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 email. A DND condition might apply to all callers or might grant exceptions to certain callers (e.g., to an assistant or secretary) so that only those particular callers can break through. A user can also invoke the condition casually for a particular incoming communication. A user might arrange that a DND condition be invoked automatically based on the user's current activity, e.g., when viewing a document full screen. 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. Elwell & Srinivasan Expires May 19, 2008 [Page 4] Internet-Draft Do Not Disturb November 2007 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 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. A DND condition can be detected at a called UA or at the domain proxy. The entity that detects the condition can determine the action to be taken. Alternatively, the proxy can override the action taken by the UA. For example, a UA might reject a call because of DND, but the proxy might wait to see what happens at other registered UAs and/or forward the call to voicemail. Elwell & Srinivasan Expires May 19, 2008 [Page 5] Internet-Draft Do Not Disturb November 2007 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 and to proxies to handle the rejection due to DND in some other way, if required (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: "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. Elwell & Srinivasan Expires May 19, 2008 [Page 6] Internet-Draft Do Not Disturb November 2007 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, for casual invocation of DND by the user when an incoming call arrives the user will already have been alerted. Therefore a 180 provisional response will probably already have been sent. Depending on the final response code, the caller may infer that this is not a blanket DND condition and that the called user does not wish to speak to that particular caller. 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 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. There are probably arguments for saying that the means of indicating a DND condition to a proxy (so that it can impose whatever policy is in force for such circumstances) should be different from the means Elwell & Srinivasan Expires May 19, 2008 [Page 7] Internet-Draft Do Not Disturb November 2007 of conveying a suitable indication to the caller (where precision might not be required). 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 interaction 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 domain can take alternative action, e.g., forward to voicemail or to another user, in accordance with established policy. 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. This poses an additional problem when there has been forwarding to a different user. For example, consider a call to Alice that for some reason is forwarded to Bob, where it gets rejected because of DND. If the DND condition is reported to the caller without also an indication that Elwell & Srinivasan Expires May 19, 2008 [Page 8] Internet-Draft Do Not Disturb November 2007 this condition applies to Bob, rather than Alice, this could be misleading. It might be better to report the original condition at Alice that led to Bob being contacted. This problem is not specific to DND, but is an example of a more general problem associated with heterogeneous error responses. Another factor is whether to act immediately when one UAS reports DND (cancelling any other outstanding branches) or wait for other branches to respond. This last aspect should really be controllable to match user requirements. 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. Setting or clearing the condition at a UA is a local matter. 8. Conclusions and recommendations OPEN ISSUE. Where do we go from here? There was a HUGE email thread beginning 2006-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 Elwell & Srinivasan Expires May 19, 2008 [Page 9] Internet-Draft Do Not Disturb November 2007 header field. There may need to be be a difference between what is indicated to the local proxy and what is indicated to the caller. 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 is ambiguity in RFC 3261 concerning the precise meaning of 6xx responses. One interpretation might be that a 6xx response should be on behalf of destinations in the same domain, but should have no impact on branches in other domains. 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 precedence in a HERFP situation in accordance with user requirements. 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). With the exception of presence aspects, DND is part of a broader topic of Automatic Call Handling (ACH) being discussed within the BLISS WG. However, the issues of a suitable response code and a suitable presence indication are specific to DND. 9. IANA considerations None. Elwell & Srinivasan Expires May 19, 2008 [Page 10] Internet-Draft Do Not Disturb November 2007 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, but this might then prevent intervention by the proxy in the callee's domain. 11. Acknowledgements Thanks to Mohammad Vakil for contributing material on presence and to Shida Schubert for carrying out an initial review and providing comments. 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. Elwell & Srinivasan Expires May 19, 2008 [Page 11] Internet-Draft Do Not Disturb November 2007 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 Srivatsa Srinivasan Microsoft Corporation One Microsoft Way Redmond, WA 98052 USA Email: srivats@exchange.microsoft.com Elwell & Srinivasan Expires May 19, 2008 [Page 12] Internet-Draft Do Not Disturb November 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 & Srinivasan Expires May 19, 2008 [Page 13]