idnits 2.17.1 draft-elwell-bliss-ach-analysis-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 447. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 458. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 465. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 471. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (November 9, 2007) is 6014 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Duplicate reference: RFC3880, mentioned in '3', was also mentioned in '1'. == Outdated reference: A later version (-01) exists of draft-elwell-bliss-dnd-00 == Outdated reference: A later version (-18) exists of draft-ietf-sipping-config-framework-13 Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 BLISS WG J. Elwell 3 Internet-Draft Siemens Enterprise Communications 4 Intended status: Informational GmbH & Co KG 5 Expires: May 12, 2008 November 9, 2007 7 An Analysis of Automatic Call Handling Implementation Issues in the 8 Session Initiation Protocol (SIP) 9 draft-elwell-bliss-ach-analysis-00.txt 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on May 12, 2008. 36 Copyright Notice 38 Copyright (C) The IETF Trust (2007). 40 Abstract 42 This discusses problems associated with automatic call handling (ACH) 43 when using the Session Initiation Protocol (SIP). 45 This work is being discussed on the bliss@ietf.org mailing list. 47 Table of Contents 49 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 50 2. Examples of ACH . . . . . . . . . . . . . . . . . . . . . . . 3 51 3. Known problem areas with ACH . . . . . . . . . . . . . . . . . 4 52 3.1. Conflict between proxy and UA . . . . . . . . . . . . . . 4 53 3.2. Conflict between UAs . . . . . . . . . . . . . . . . . . . 5 54 3.3. Obtaining information from UA for ACH at proxy . . . . . . 5 55 3.4. Informing the calling UA . . . . . . . . . . . . . . . . . 5 56 3.5. Scope of conditions . . . . . . . . . . . . . . . . . . . 6 57 3.6. Configuring the proxy . . . . . . . . . . . . . . . . . . 6 58 4. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . 7 59 4.1. Proxy versus UA . . . . . . . . . . . . . . . . . . . . . 7 60 4.2. Avoiding inconsistent configurations . . . . . . . . . . . 8 61 4.3. Enterprise and carrier environments . . . . . . . . . . . 8 62 5. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 8 63 6. IANA considerations . . . . . . . . . . . . . . . . . . . . . 9 64 7. Security considerations . . . . . . . . . . . . . . . . . . . 9 65 8. Ackowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 66 9. Informative References . . . . . . . . . . . . . . . . . . . . 9 67 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 10 68 Intellectual Property and Copyright Statements . . . . . . . . . . 11 70 1. Introduction 72 The Session Initiation Protocol (SIP) (RFC 3261 [1] establishes calls 73 or sessions for real-time communication between users. When a call 74 is targeted at a called user, often the call is subject to some 75 automatic treatment to determine whether to present the call to the 76 user or take some alternative action such as forwarding to voicemail. 77 Similarly, if some condition arises after presenting a call to the 78 called user but before answer, automatic treatment can lead to some 79 alternative action. Automatic treatment is in accordance with policy 80 determined in advance by the user or the user's organization. This 81 automatic treatment of incoming calls is referred to as automatic 82 call handling (ACH) in this document. 84 In order to encourage innovation, ACH is deliberately not specified 85 in RFC 3261 or in RFCs that specify extensions to SIP. However, the 86 flexibility that this affords has sometimes led to problems, where 87 different implementations have approached the issue in different 88 ways, leading to unexpected and often unwanted behavior when those 89 implementations are deployed together. This document analyses the 90 sources of problems with ACH. 92 2. Examples of ACH 94 ACH can occur prior to or instead of presenting an incoming call to a 95 called user or after presentation but before the called user answers 96 the call. The particular treatment applied to a call is generally 97 dependent on a number of factors, examples of which are as follows: 99 o Whether there are other registered contacts that can handle the 100 call (e.g., a registered audio UA for an audio call). 101 o Whether the user's UA (or UAs) is known to be busy on another 102 call. 103 o Whether the user has failed to answer the call within a given 104 number of seconds. 105 o Whether the user is known to be unwilling to receive calls at the 106 present time (a condition often known as Do Not Disturb, DND). 107 o Whether the user is known not to be available (e.g., on vacation) 108 o Whether an alternative user (e.g., a colleague, an assistant, 109 another family member) is known to be available. 110 o Whether the AoR at which the call is targeted represents a single 111 user or a team or group of users. 112 o Time of day, day of the week, date, etc.. 113 o The type of call (e.g., audio, audio plus video, messaging, etc.). 114 o The source of the call (e.g., whether the caller is anonymous, 115 whether the caller is blacklisted or whitelisted, which 116 organization the caller belongs to, etc.). 118 Examples of particular treatment to be applied to a call if 119 appropriate conditions are met are as follows: 121 o Reject the call, with an appropriate indication to the caller. 122 This indication may or may not reveal the actual condition that 123 led to rejection. 124 o Forward the call to another UA serving that user (e.g., voicemail, 125 a mobile UA, a UA at another location). 126 o Forward the call to another user, e.g., the next member of a team, 127 an assistant. 128 o Modify the nature of the call (e.g., downgrade from audio to 129 messaging). 130 o Any of the above, but impacting presentation of the call at a 131 given UA, without impacting presentation at other UAs serving the 132 user. 134 A user can specify quite complex sets of rules for ACH. For example, 135 "if presence indicates I am in a meeting, or if my desk phone is 136 busy, or if I do not reply within 15 seconds, forward calls to my 137 assistant between the hours of 09.00 and 17.00, Monday to Friday, but 138 at other times forward to my voicemail, unless the call is from my 139 home or my partner's mobile phone, in which case forward to my mobile 140 phone". 142 3. Known problem areas with ACH 144 3.1. Conflict between proxy and UA 146 A significant problem area with ACH is interactions between proxies 147 (or B2BUAs) that perform ACH and UAs that perform ACH. The domain 148 proxy for a user is configured to treat incoming calls in a certain 149 way under certain conditions. One of the user's UAs is configured to 150 treat incoming calls in a different way under the same or overlapping 151 conditions. If the condition can be detected by the proxy without 152 presenting the call to the UA, the proxy will win and the user may 153 wonder why the action configured at the UA is not being taken. For 154 example, if the proxy detects a DND condition from a presence server 155 and forwards calls to voicemail, any script at the UA to forward 156 private calls to a mobile phone would never execute. This may or may 157 not be what the user (or his/her organization) desires to happen. 159 Alternatively, if a condition is detected by a UA before it is 160 detected at the proxy, the action determined by the UA will "win", 161 unless the proxy is somehow able to figure out what has happened and 162 apply its own action. For example, if a phone determines it is busy 163 and returns a 302 response code to forward the call elsewhere or 164 performs "call waiting" action, this might prevent the proxy taking 165 whatever action it would have taken on receipt of a 486 response. 166 This may or may not be what the user (or his/her organization) 167 desires to happen. 169 3.2. Conflict between UAs 171 Where an incoming call is forked to multiple UAs, there is potential 172 for different UAs to be configured to perform different actions under 173 the same or overlapping conditions. With parallel forking (where the 174 INVITE request is sent to each UA at approximately the same time), 175 results can be indeterminate and are likely to depend on which UA 176 responds first. With serial forking, this is likely to be more 177 deterministic, but UAs would need to be configured taking into 178 account the order in which the proxy presents calls to the UAs. 180 3.3. Obtaining information from UA for ACH at proxy 182 When ACH is performed at a proxy, it sometimes requires information 183 from the UA, in response to the INVITE request. If this information 184 does not arrive in the form expected by the proxy (e.g, a particular 185 response code), ACH will be adversely impacted. For example, if the 186 proxy is configured to perform forwarding on DND and relies on the 187 DND condition to be indicated in the INVITE response, it depends on 188 the UA indicating the condition in the form expected by the proxy. 189 As there is no standardized means of indicating DND in a response 190 (see [6]), this can be a problem. 192 3.4. Informing the calling UA 194 A related problem is informing the calling UA, and hence the caller, 195 what has happened. In the case where ACH results in rejection of the 196 call, this might be just a case of sending back an appropriate 197 response code. Considerations are similar to those for a proxy in 198 Section 3.3, except that privacy might require the proxy to send a 199 different response code rather than the one reflecting the condition 200 encountered. For example, the user might not wish the caller to know 201 about his absence. 203 The choice of response code might not be an interoperability issue if 204 the calling UA is relatively dumb, but might be an issue if there is 205 an application that takes the response code into account. 207 Where ACH results in forwarding (to a different AoR or a different 208 contact for the same AoR), this can be achieved by retargeting or 209 redirection. In the case of retargeting, the calling UA receives no 210 information, apart from a final response and perhaps identity from 211 the retargeted-to user. On the other hand, if redirection is used, 212 the calling UA will receive a 3xx response, the contact URI in which 213 could indicate the source of the redirection and the reason, in 214 accordance with RFC 4458 [5]. 216 3.5. Scope of conditions 218 When an INVITE request is forked to multiple UAs, the user may or may 219 not require a condition at one UA to be considered as applying to 220 other branches. This includes branches already active (through 221 parallel forking) or branches yet to be activated (through serial 222 forking). This can impact when to invoke ACH at the proxy, i.e., 223 whether to perform ACH when one UA reports an appropriate condition 224 (cancelling other active branches if necessary) or to wait for the 225 outcome on other branches. 227 Although to a large extent this issue can be handled by appropriate 228 scripting at the proxy, an important consideration is how to treat 229 the 6xx class of responses. For example, if a UA issues a 600 Busy 230 Everywhere response (as opposed to a 486 Busy response), what is the 231 scope of "everywhere"? A simple interpretation is that it literally 232 means "everywhere", and all other branches should be abandoned and 233 the 6xx response passed back to the caller if no other ACH is 234 prescribed for this condition. However, this interpretation is not 235 always reasonable. If a user has several phones, it might be 236 reasonable to interpret a 600 response from one phone as meaning that 237 all other phones are busy, but if the user also has voicemail it is 238 unlikely that that too should be treated as busy. Also, if ACH 239 requires forwarding to a different user (different AoR) on busy, it 240 might be expected that this would take place even on receipt of a 600 241 response from a UA. 243 Another example is the 603 Decline response code. This is often is 244 intended to be applied everywhere. 246 3.6. Configuring the proxy 248 If ACH is performed at the proxy, the user needs a means to configure 249 the proxy with the required rules. There is no SIP means of doing 250 this, but a number of mechanisms can perform the basis for this task, 251 e.g.: 253 o Via a web page. 254 o By uploading a CPL [3] script. 255 o Via a web services interface based on SOAP. 256 o Via Computer Supported Telecommunication Applications (CSTA) [8]. 258 Without a single standardized way of configuring a proxy, there is a 259 danger that the UA and proxy might not support a common method, 260 requiring the user to employ other means (e.g., using a different 261 device, contacting a support centre). Furthermore, it might lead the 262 user to configuring ACH at the UA when in practice ACH at the proxy 263 would serve the user's needs better. 265 Related to this is the means by which a UA (and hence the user) can 266 discover how the proxy is configured. 268 4. Discussion 270 4.1. Proxy versus UA 272 The end-to-end principle of SIP would suggest that ACH at the UA is 273 more appropriate than ACH at the proxy. However, certain 274 considerations make ACH at the proxy more viable or even essential. 276 ACH in the event that there is no registered contact obviously can 277 only be performed by the proxy. 279 A proxy is more easily able to take account of the state of other 280 UAs, e.g., by waiting for all branches of a forked call to respond 281 before invoking ACH. Although a UA can use techniques such as the 282 registration event package (RFC 3680 [2]) in combination with the 283 dialog event package (RFC 4235 [4]) to determine the state of other 284 UAs, this is complex, may not yield the information required, and may 285 suffer from timing-related inconsistencies. 287 A proxy needs to be configured once and can perform ACH independently 288 of the number of UAs involved. Obtaining consistent behaviour using 289 ACH at the UA may involve configuring multiple UAs and keeping their 290 configurations aligned. The UA configuration framework [7] may be a 291 suitable mechanism for this and would require a means for the user to 292 configure the profile delivery server. However, there can be no 293 guarantee that all UAs will download a revised configuration at the 294 same time, so it can lead to a time window when inconsistent 295 behaviour may occur. 297 With these considerations in mind, a proxy will often turn out to be 298 a more suitable place for performing ACH. 300 On the other hand, there may be situations in which UA-specific ACH 301 may be required, and it may not be feasible to configure the proxy to 302 provide this level of granularity. For example, it may be required 303 to take one action if the desk UA is busy but a different action if 304 the mobile UA is busy. Convincing use cases for this are hard to 305 find, but it cannot be ruled out. A possible approach here is to use 306 proxy-based ACH as the default handling for all UAs and UA-based ACH 307 for any UA-specific exceptions. 309 4.2. Avoiding inconsistent configurations 311 Given that there is frequently a need to perform ACH at the proxy, 312 problems can be avoided by turning off ACH at all UAs. There may be 313 exceptions to this, e.g., where there is need for a specific UA to 314 perform actions different from default actions carried out by the 315 proxy, or where there is a requirement for behavior not supported by 316 the proxy. Where ACH does need to be configured at one or more UAs, 317 care must be taken to avoid unintentional conflicts. Use of the SIP 318 configuration framework can help to ensure consistent handling at all 319 UAs. One consideration during the work on profiles for use with the 320 SIP configuration framework might be the downloading of policy 321 relating to ACH, such that ACH could be suppressed in order to ensure 322 that proxy-based ACH operates correctly. 324 4.3. Enterprise and carrier environments 326 Considerations for ACH will often differ between enterprise and 327 carrier environments. In enterprise environments, enterprise policy 328 will often govern what a user can and cannot do. This does not 329 necessarily mean that ACH will be done at a proxy, because the 330 enterprise will probably manage UAs too and ensure that they behave 331 in line with policy, although proxy-based ACH will often be easier to 332 accomplish. 334 In a carrier environment, everything can be expected to be under the 335 control of the user. Proxy-based ACH is still relevant, however, 336 particularly for mobile devices that are often out of reach or turned 337 off. 339 Handling such as team calls (where any team member can be selected 340 according to availability) is perhaps more likely in enterprise, 341 although in a residential environment it could be used for finding 342 any family member. 344 Despite these different considerations, requirements are similar to a 345 large extent and the same solution should be sought for both 346 environments. 348 5. Conclusions 350 The discussions above raise a number of questions, which need to be 351 addressed by the BLISS WG: 353 o Do we need to make any recommendations on proxy-based versus UA- 354 based ACH? 356 o Is provisioning (e.g, using the SIP configuration framework [7]) a 357 suitable solution for ensuring consistent behaviour between UAs 358 and between a UA and its proxy? 359 o Do we need to make any recommendations on error codes and other 360 information in responses in order to achieve good interoperability 361 between a UAS and its proxy? 362 o Do we need to make any recommendations concerning the meaning and 363 use of 6xx response codes? 364 o Do we need to specify a recommended or default method by which a 365 UA can configure its proxy and discover how its proxy is 366 configured? 367 o To what extent is it necessary to make recommendations concerning 368 keeping the calling UA informed of what is happening? 370 6. IANA considerations 372 None. 374 7. Security considerations 376 This document just discusses issues relating to DND. It does not 377 define any new protocol or practices and therefore does not introduce 378 any security issues, other than the possible user desire not to 379 disclose a DND condition to callers. 381 8. Ackowledgements 383 The author would like to acknowledge the assistance of Jason Fischl, 384 Shida Schubert and Srivatsa Srinivasan in writing this draft, and 385 also input on specific implementations from various members of the 386 BLISS WG. 388 9. Informative References 390 [1] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 391 Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: 392 Session Initiation Protocol", RFC 3880, June 2002. 394 [2] Rosenberg, J., "A Session Initiation Protocol (SIP) Event 395 Package for Registrations", RFC 3680, March 2004. 397 [3] Lennox, J., Wu, X., and H. Schulzrinne, "Call Processing 398 Language (CPL): A Language for User Control of Internet 399 Telephony Services", RFC 3880, October 2004. 401 [4] Rosenberg, J., Schulzrinne, H., and R. Mahy, "An INVITE- 402 Initiated Dialog Event Package for the Session Initiation 403 Protocol (SIP)", RFC 4235, November 2005. 405 [5] Jennings, C., Audet, F., and J. Elwell, "Session Initiation 406 Protocol (SIP) URIs for Applications such as Voicemail and 407 Interactive Voice Response (IVR)", RFC 4458, April 2006. 409 [6] Elwell, J. and M. Vakil, "SIP: Session Initiation Protocol", 410 draft-elwell-bliss-dnd-00 (work in progress), May 2007. 412 [7] Petrie, D. and S. Channabasappa, "A Framework for Session 413 Initiation Protocol User Agent Profile Delivery", 414 draft-ietf-sipping-config-framework-13 (work in progress), 415 October 2007. 417 [8] "International Standard ISO/IEC 18051 "Information Technology - 418 Telecommunications and information exchange between systems - 419 Services for Computer Supported Telecommunications Applications 420 (CSTA) Phase III"". 422 Author's Address 424 John Elwell 425 Siemens Enterprise Communications GmbH & Co KG 426 Hofmannstrasse 51 427 D-81379 Munich 428 Germany 430 Phone: +44 115 943 4989 431 Email: john.elwell@siemens.com 433 Full Copyright Statement 435 Copyright (C) The IETF Trust (2007). 437 This document is subject to the rights, licenses and restrictions 438 contained in BCP 78, and except as set forth therein, the authors 439 retain all their rights. 441 This document and the information contained herein are provided on an 442 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 443 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 444 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 445 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 446 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 447 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 449 Intellectual Property 451 The IETF takes no position regarding the validity or scope of any 452 Intellectual Property Rights or other rights that might be claimed to 453 pertain to the implementation or use of the technology described in 454 this document or the extent to which any license under such rights 455 might or might not be available; nor does it represent that it has 456 made any independent effort to identify any such rights. Information 457 on the procedures with respect to rights in RFC documents can be 458 found in BCP 78 and BCP 79. 460 Copies of IPR disclosures made to the IETF Secretariat and any 461 assurances of licenses to be made available, or the result of an 462 attempt made to obtain a general license or permission for the use of 463 such proprietary rights by implementers or users of this 464 specification can be obtained from the IETF on-line IPR repository at 465 http://www.ietf.org/ipr. 467 The IETF invites any interested party to bring to its attention any 468 copyrights, patents or patent applications, or other proprietary 469 rights that may cover technology that may be required to implement 470 this standard. Please address the information to the IETF at 471 ietf-ipr@ietf.org. 473 Acknowledgment 475 Funding for the RFC Editor function is provided by the IETF 476 Administrative Support Activity (IASA).