idnits 2.17.1 draft-ietf-bliss-ach-analysis-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. 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 and authors 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 (March 8, 2010) is 5125 days in the past. Is this intentional? Checking references for intended status: Best Current Practice ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-18) exists of draft-ietf-sipping-config-framework-17 Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 2 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: BCP March 8, 2010 5 Expires: September 9, 2010 7 An Analysis of Automatic Call Handling (ACH) Implementation Issues in 8 the Session Initiation Protocol (SIP) 9 draft-ietf-bliss-ach-analysis-06.txt 11 Abstract 13 This discusses problems associated with automatic call handling (ACH) 14 when using the Session Initiation Protocol (SIP) and specifies some 15 best practices to help achieve interoperability. 17 This work is being discussed on the bliss@ietf.org mailing list. 19 Status of this Memo 21 This Internet-Draft is submitted to IETF in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF), its areas, and its working groups. Note that 26 other groups may also distribute working documents as Internet- 27 Drafts. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 The list of current Internet-Drafts can be accessed at 35 http://www.ietf.org/ietf/1id-abstracts.txt. 37 The list of Internet-Draft Shadow Directories can be accessed at 38 http://www.ietf.org/shadow.html. 40 This Internet-Draft will expire on September 9, 2010. 42 Copyright Notice 44 Copyright (c) 2010 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 60 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 61 3. Examples of ACH . . . . . . . . . . . . . . . . . . . . . . . 4 62 4. Known problem areas with ACH . . . . . . . . . . . . . . . . . 6 63 4.1. Conflict between proxy and UA . . . . . . . . . . . . . . 6 64 4.2. Conflict between UAs . . . . . . . . . . . . . . . . . . . 7 65 4.3. Obtaining information from UA for ACH at proxy . . . . . . 7 66 4.4. Informing the calling UA . . . . . . . . . . . . . . . . . 8 67 4.5. Scope of conditions . . . . . . . . . . . . . . . . . . . 8 68 4.6. Configuring the proxy . . . . . . . . . . . . . . . . . . 9 69 5. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . 10 70 5.1. Proxy versus UA . . . . . . . . . . . . . . . . . . . . . 10 71 5.2. Avoiding inconsistent configurations . . . . . . . . . . . 11 72 5.3. Enterprise and carrier environments . . . . . . . . . . . 11 73 6. Potential measures that could be taken . . . . . . . . . . . . 12 74 6.1. Conflict between proxy and UA . . . . . . . . . . . . . . 12 75 6.2. Conflict between UAs . . . . . . . . . . . . . . . . . . . 14 76 6.3. Obtaining information from UA for ACH at proxy . . . . . . 14 77 6.3.1. Reason for rejection . . . . . . . . . . . . . . . . . 14 78 6.3.2. Desired scope of rejection . . . . . . . . . . . . . . 15 79 6.4. Informing the calling UA . . . . . . . . . . . . . . . . . 16 80 6.5. Scope of conditions . . . . . . . . . . . . . . . . . . . 16 81 6.6. Configuring the proxy . . . . . . . . . . . . . . . . . . 16 82 7. Best practices for ACH . . . . . . . . . . . . . . . . . . . . 17 83 7.1. Avoiding conflict between ACH at proxy and ACH at UA . . . 17 84 7.2. Use of response codes for reporting ACH-related 85 conditions . . . . . . . . . . . . . . . . . . . . . . . . 17 86 7.3. UA configuration of ACH at the proxy . . . . . . . . . . . 18 87 7.4. Notifying a UA of an ACH configuration change at the 88 proxy . . . . . . . . . . . . . . . . . . . . . . . . . . 18 89 8. IANA considerations . . . . . . . . . . . . . . . . . . . . . 18 90 9. Security considerations . . . . . . . . . . . . . . . . . . . 18 91 Appendix A. Survey results . . . . . . . . . . . . . . . . . . . 18 92 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 24 93 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24 94 11.1. Normative References . . . . . . . . . . . . . . . . . . . 24 95 11.2. Informative References . . . . . . . . . . . . . . . . . . 24 97 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 25 99 1. Introduction 101 The Session Initiation Protocol (SIP) [RFC3261] establishes calls or 102 sessions for real-time communication between users. When a call is 103 targeted at a called user, often the call is subject to some 104 automatic treatment to determine whether to present the call to the 105 user or take some alternative action such as forwarding to voicemail. 106 Similarly, if some condition arises after presenting a call to the 107 called user but before answer, automatic treatment can lead to some 108 alternative action. Automatic treatment is in accordance with policy 109 determined in advance by the user or the user's organization. This 110 automatic treatment of incoming calls is referred to as automatic 111 call handling (ACH) in this document. 113 In order to encourage innovation, ACH is deliberately not specified 114 in RFC 3261 or in RFCs that specify extensions to SIP. However, the 115 flexibility that this affords has sometimes led to problems, where 116 different implementations have approached the issue in different 117 ways, leading to unexpected and often unwanted behavior when those 118 implementations are deployed together. This document analyses the 119 sources of problems with ACH and specifies some best practices to 120 help achieve interoperability. 122 A number of other Standards Development Organisations (SDO) (e.g., 123 3GPP, ETSI) have specified specific features or "services" that 124 involve specific forms of ACH. 126 A survey was conducted prior to IETF70 to get a feeling for what are 127 common practices in this area. Although the number of responses was 128 disappointingly small (see results [1]), in some cases it did give a 129 clue as to the most common practices. In the remainder of this 130 document, this is referred to as "the survey". 132 2. Terminology 134 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 135 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 136 document are to be interpreted as described in [RFC2119]. 138 3. Examples of ACH 140 ACH can occur prior to or instead of presenting an incoming call to a 141 called user or after presentation but before the called user answers 142 the call. The particular treatment applied to a call is generally 143 dependent on a number of factors, examples of which are as follows: 145 o Whether there are other registered contacts that can handle the 146 call (e.g., a registered audio User Agent (UA) for an audio call). 148 o Whether the user's UA (or UAs) is known to be busy on another 149 call. 151 o Whether the user has failed to answer the call within a given 152 number of seconds. 154 o Whether the user is known to be unwilling to receive calls at the 155 present time (a condition often known as Do Not Disturb, DND). 157 o Whether the user is known not to be available (e.g., on vacation). 159 o Whether an alternative user (e.g., a colleague, an assistant, 160 another family member) is known to be available. 162 o Whether the Address Of Record (AOR) at which the call is targeted 163 represents a single user or a team or group of users. 165 o Time of day, day of the week, date, etc.. 167 o The type of call (e.g., audio, audio plus video, messaging, etc.). 169 o The source of the call (e.g., whether the caller is anonymous, 170 whether the caller is blacklisted or whitelisted, which 171 organization the caller belongs to, etc.). 173 The conditions above are detected though local information at the 174 entity performing ACH, by access to presence information or through 175 information received via SIP signalling (e.g., a UA's response to an 176 INVITE request). 178 Examples of particular treatment to be applied to a call if 179 appropriate conditions are met are as follows: 181 o Reject the call, with an appropriate indication to the caller. 182 This indication may or may not reveal the actual condition that 183 led to rejection. 185 o Forward the call to another UA serving that user (e.g., voicemail, 186 a mobile UA, a UA at another location). 188 o Forward the call to another user, e.g., the next member of a team, 189 an assistant. 191 o Modify the nature of the call (e.g., downgrade from audio to 192 messaging). 194 o Any of the above, but impacting presentation of the call at a 195 given UA, without impacting presentation at other UAs serving the 196 user. 198 A user can specify quite complex sets of rules for ACH. For example, 199 "if presence indicates I am in a meeting, or if my desk phone is 200 busy, or if I do not reply within 15 seconds, forward calls to my 201 assistant between the hours of 09.00 and 17.00, Monday to Friday, but 202 at other times forward to my voicemail, unless the call is from my 203 home or my partner's mobile phone, in which case forward to my mobile 204 phone". 206 4. Known problem areas with ACH 208 4.1. Conflict between proxy and UA 210 A significant problem area with ACH is interactions between proxies 211 (or Back-To-Back User Agents, B2BUAs) that perform ACH and UAs that 212 perform ACH. The domain proxy for a user is configured to treat 213 incoming calls in a certain way under certain conditions. One of the 214 user's UAs is configured to treat incoming calls in a different way 215 under the same or overlapping conditions. If the condition can be 216 detected by the proxy without presenting the call to the UA, the 217 proxy will win and the user may wonder why the action configured at 218 the UA is not being taken. For example, if the proxy detects a DND 219 condition from a presence server and forwards calls to voicemail, any 220 script at the UA to forward private calls to a mobile phone would 221 never execute. This may or may not be what the user (or his/her 222 organization) desires to happen. 224 Alternatively, if a condition is detected by a UA before it is 225 detected at the proxy, the action determined by the UA will "win", 226 unless the proxy is somehow able to figure out what has happened and 227 apply its own action. For example, if a phone determines it is busy 228 and returns a 302 response code to forward the call elsewhere or 229 performs "call waiting" action, this might prevent the proxy taking 230 whatever action it would have taken on receipt of a 486 response. 231 This may or may not be what the user (or his/her organization) 232 desires to happen. 234 If a UA attempts ACH, it may be possible for the proxy to override 235 it, e.g., by taking account of the response code returned or, in the 236 case of a 3xx response code, whether the UA has provided further 237 information concerning the reason for redirection in accordance with 238 RFC 4458 [RFC4458]. 240 The survey showed that the majority of proxies perform ACH without 241 first presenting the call to the UA, at least for certain types of 242 ACH. 244 The survey also showed that the majority of UAs implement some form 245 of ACH. This does seem to confirm the potential for conflict between 246 proxy and UA. If, as a result of ACH at the UA, the call required 247 redirection, 302 was the response code used in the majority of 248 situations. Only a minority of such implementations used RFC 4458 to 249 provide more information about the reason for redirection. 251 4.2. Conflict between UAs 253 Where an incoming call is forked to multiple UAs, there is potential 254 for different UAs to be configured to perform different ACH actions 255 under the same or overlapping conditions. With parallel forking 256 (where the INVITE request is sent to each UA at approximately the 257 same time), results can be indeterminate and might depend on which UA 258 responds first. With serial forking, this is likely to be more 259 deterministic, but UAs would need to be configured taking into 260 account the order in which the proxy presents calls to the UAs. 262 When a proxy forks a call, it can invoke ACH based on the first UA to 263 respond, can wait for all UAs to respond or behave in some other way 264 (e.g., act immediately on certain response codes). The survey did 265 not show a bias towards any one behavior. 267 4.3. Obtaining information from UA for ACH at proxy 269 When ACH is performed at a proxy, it sometimes requires information 270 from the UA, in response to the INVITE request. If this information 271 does not arrive in the form expected by the proxy (e.g, a particular 272 response code), ACH will be adversely impacted. For example, if the 273 proxy is configured to perform forwarding on DND and relies on the 274 DND condition to be indicated in the INVITE response, it depends on 275 the UA indicating the condition in the form expected by the proxy. 276 As there is no standardized means of indicating DND in a response 277 (see [I-D.elwell-bliss-dnd]), this can be a problem. Furthermore, 278 there might be more than one flavour of DND (e.g., with/without 279 forwarding to voicemail), requiring different responses. 281 The survey showed that 486 (Busy Here) is the response code most 282 commonly expected by proxies for indicating DND, but that accounted 283 for less than half of the responses. Other known response codes in 284 use include 406 (Not Acceptable), 480 (Temporarily Unavailable), 600 285 (Busy Everywhere) and 603 (Decline). 287 The survey also showed that even for the busy condition, proxies 288 expected different response codes. Although a small majority 289 expected 486 (Busy Here), other expectations included 480 290 (Temporarily Unavailable) and 600 (Busy Everywhere). 292 The survey did not yield significant information concerning response 293 codes issued by UAs. 295 4.4. Informing the calling UA 297 A related problem is informing the calling UA, and hence the caller, 298 what has happened. In the case where ACH results in rejection of the 299 call, this might be just a case of sending back an appropriate 300 response code. Considerations are similar to those for a proxy in 301 Section 4.3, except that privacy might require the proxy to send a 302 different response code rather than the one reflecting the condition 303 encountered. For example, the user might not wish the caller to know 304 about his absence. 306 The choice of response code might not be an interoperability issue if 307 the calling UA is relatively dumb, but might be an issue if there is 308 an application that takes the response code into account. Where 309 there is forking proxy between the entity performing ACH and the 310 calling UA, information may be lost because of the Heterogeneous 311 Error Response Forking Problem (HERFP). 313 Where ACH results in forwarding (to a different AOR or a different 314 contact for the same AOR), this can be achieved by retargeting or 315 redirection. In the case of retargeting, the calling UA receives no 316 information, apart from a final response and perhaps identity from 317 the retargeted-to user. On the other hand, if redirection is used, 318 the calling UA will receive a 3xx response, the contact Universal 319 Resource Identifier (URI) in which could indicate the source of the 320 redirection and possibly the reason, in accordance with RFC 4458 321 [RFC4458]. 323 4.5. Scope of conditions 325 When an INVITE request is forked to multiple UAs, the user may or may 326 not require a condition at one UA to be considered as applying to 327 other branches. This includes branches already active (through 328 parallel forking) or branches yet to be activated (through serial 329 forking). This can impact when to invoke ACH at the proxy, i.e., 330 whether to perform ACH when one UA reports an appropriate condition 331 (cancelling other active branches if necessary) or to wait for the 332 outcome on other branches. 334 Although to a large extent this issue can be handled by appropriate 335 scripting at the proxy, an important consideration is how to treat 336 the 6xx class of responses. For example, if a UA issues a 600 Busy 337 Everywhere response (as opposed to a 486 Busy response), what is the 338 scope of "everywhere"? A simple interpretation is that it literally 339 means "everywhere", and all other branches should be abandoned and 340 the 6xx response passed back to the caller if no other ACH is 341 prescribed for this condition. However, other interpretations might 342 seem reasonable. If a user has several phones, it might be 343 reasonable to interpret a 600 response from one phone as meaning that 344 all other phones are busy, but if the user also has voicemail it is 345 unlikely that that too should be treated as busy. Also, if ACH 346 requires forwarding to a different user (different AOR) on busy, it 347 might be expected that this would take place even on receipt of a 600 348 response from a UA. 350 Another example is the 603 Decline response code. This is often 351 intended to be applied everywhere. 353 There is also a question of whether a proxy should trust a UA to 354 decide that all other branches need to be abandoned, particularly in 355 applications like call centres, where the different branches might be 356 different agents, rather than leading to different devices belonging 357 to the same user. It might be wise to consider this a policy matter. 359 The survey gave only a very small number of answers on the issue of 360 handling 6xx responses, with no conclusions to be drawn other than 361 that forwarding to voice mail is sometimes allowed following a 6xx 362 response. 364 4.6. Configuring the proxy 366 If ACH is performed at the proxy, the user needs a means to configure 367 the proxy with the required rules. There is no SIP means of doing 368 this, but a number of mechanisms can perform the basis for this task, 369 e.g.: 371 o Via a web page. 373 o By uploading a CPL [RFC3880] script. 375 o Via a web services interface based on SOAP. 377 o Via Computer Supported Telecommunication Applications (CSTA) 378 [CSTA]. 380 o Via XCAP [RFC4825] 382 o Using standard Hyper-Text Transfer Protocol (HTTP) primitives, a 383 technique commonly known as REpresentational State Transfer 384 (REST). 386 The survey showed that web pages and SOAP-based web services were the 387 most common mechanisms supported by proxies, but the sample was very 388 small. The majority of UA implementations provided a web user 389 interface. 391 Related to this is the means by which a UA (and hence the user) can 392 discover how the proxy is configured. Most of the mechanisms listed 393 above are applicable, and also a SIP SUBSCRIBE/NOTIFY mechanism could 394 be used. The survey indicated that only a minority of proxies 395 provided support in this respect. 397 Some of the above mechanisms (e.g., a web page) are unsuitable for 398 automatic use by the UA (as opposed to direct interaction between the 399 user and the proxy). For example, suppose the UA has a button that 400 can be pressed to activate or deactivate forwarding, and an 401 associated lamp or icon to show that forwarding is active. In order 402 to support ACH at the proxy, the UA would need a means for 403 instructing the proxy to activate or deactivate forwarding, and also 404 a means to obtain from the proxy the current forwarding state for 405 controlling the lamp or icon. A web page would be unsuitable for 406 this purpose, but most of the other mechanisms might be suitable. 408 Without a single standardized way for a UA to configure a proxy for 409 ACH and obtain a proxy's ACH configuration, there is a danger that 410 the UA and proxy might not support a common method, requiring the 411 user to employ other means (e.g., using a different device, 412 contacting a support centre). Furthermore, it might lead the user to 413 configuring ACH at the UA when in practice ACH at the proxy would 414 serve the user's needs better. 416 5. Discussion 418 5.1. Proxy versus UA 420 The end-to-end principle of SIP would suggest that ACH at the UA is 421 more appropriate than ACH at the proxy. However, certain 422 considerations make ACH at the proxy more viable or even essential. 424 ACH in the event that there is no registered contact obviously can 425 only be performed by the proxy. 427 A proxy is more easily able to take account of the state of other 428 UAs, e.g., by waiting for all branches of a forked call to respond 429 before invoking ACH. Although a UA can use techniques such as the 430 registration event package [RFC3680] in combination with the dialog 431 event package [RFC4235] to determine the state of other UAs, this is 432 complex, may not yield the information required, and may suffer from 433 timing-related inconsistencies. 435 A proxy needs to be configured once and can perform ACH independently 436 of the number of UAs involved. Obtaining consistent behaviour using 437 ACH at the UA may involve configuring multiple UAs and keeping their 438 configurations aligned. The UA configuration framework 439 [I-D.ietf-sipping-config-framework] may be a suitable mechanism for 440 this and would require a means for the user to configure the profile 441 delivery server. However, there can be no guarantee that all UAs 442 will download a revised configuration at the same time, so it can 443 lead to a time window when inconsistent behaviour may occur. 445 With these considerations in mind, a proxy will often turn out to be 446 a more suitable place for performing ACH. 448 On the other hand, there may be situations in which UA-specific ACH 449 may be required, and it may not be feasible to configure the proxy to 450 provide this level of granularity. For example, it may be required 451 to take one action if the desk UA is busy but a different action if 452 the mobile UA is busy. Convincing use cases for this are hard to 453 find, but it cannot be ruled out. A possible approach here is to use 454 proxy-based ACH as the default handling for all UAs and UA-based ACH 455 for any UA-specific exceptions. 457 5.2. Avoiding inconsistent configurations 459 Given that there is frequently a need to perform ACH at the proxy, 460 problems can be avoided by turning off ACH at all UAs. There may be 461 exceptions to this, e.g., where there is need for a specific UA to 462 perform actions different from default actions carried out by the 463 proxy, or where there is a requirement for behavior not supported by 464 the proxy. Where ACH does need to be configured at one or more UAs, 465 care must be taken to avoid unintentional conflicts. Use of the SIP 466 configuration framework can help to ensure consistent handling at all 467 UAs. One consideration during the work on profiles for use with the 468 SIP configuration framework might be the downloading of policy 469 relating to ACH, such that ACH could be suppressed in order to ensure 470 that proxy-based ACH operates correctly. 472 5.3. Enterprise and carrier environments 474 Considerations for ACH will often differ between enterprise and 475 carrier environments. In enterprise environments, enterprise policy 476 will often govern what a user can and cannot do. This does not 477 necessarily mean that ACH will be done at a proxy, because the 478 enterprise will probably manage UAs too and ensure that they behave 479 in line with policy, although proxy-based ACH will often be easier to 480 accomplish for other reasons discussed in Section 5.1. 482 In a carrier environment, everything can be expected to be under the 483 control of the user. Proxy-based ACH is still relevant, however, 484 particularly for mobile devices that are often out of reach or turned 485 off. 487 Handling such as team calls (where any team member can be selected 488 according to availability) is perhaps more likely in enterprise, 489 although in a residential environment it could be used for finding 490 any family member. 492 Despite these different considerations, requirements are similar to a 493 large extent and the same solution should be sought for both 494 environments. 496 6. Potential measures that could be taken 498 In this section we explore potential measures that can be taken to 499 some of the problems identified above. 501 6.1. Conflict between proxy and UA 503 This appears to be an important problem to solve, in order to have 504 proxies and UAs from mixed vendors. 506 One approach is to specify particular features that must or must not 507 be implemented in a proxy and particular features that must or must 508 not be implemented in UA. This is likely to fail for a number of 509 reasons: 511 o There are far too many possible features, and enumerating and 512 standardizing individual features is contrary to the philosophy of 513 SIP and likely to inhibit innovation. 515 o For a given feature, there will be some deployments where it makes 516 sense to do it at the proxy and other deployments where it makes 517 sense to do it at the UA. It will often be impracticable to 518 choose one. 520 o Proxy vendors and UA vendors will want to provide as many features 521 as possible on their products and are likely to ignore any 522 recommendation not to implement a particular feature. 524 Stipulating that ACH as a whole must always be done at the proxy or 525 must always be done at the UA is clearly out of the question, because 526 each has some advantages, depending on circumstances, and also 527 because vendors of one or the other will not be prepared to give up 528 producing features that play an important part in differentiating 529 their products. 531 Therefore it has to be accepted that ACH will be implemented on 532 proxies and UAs, with feature overlap between the two. The challenge 533 then is to ensure that, when deployed, the two can co-exist in a 534 sensible way. 536 It should be possible to control whether a proxy defers to a UA or 537 vice versa. For a proxy to defer to a UA, it requires the proxy to 538 deliver an INVITE request to a UA before taking any ACH action. 539 Depending on the response of the UA, the proxy may then perform its 540 own ACH action. For a UA to defer to a proxy, it should report any 541 conditions back to the proxy (e.g., by means of a suitable response 542 to the INVITE request) rather than taking unilateral action such as 543 redirecting or placing the call in a waiting state. In other words, 544 it should be possible to turn off ACH at a UA. 546 There are several ways to achieve this control: 548 o Configure the UA and proxy independently. The SIP configuration 549 framework [I-D.ietf-sipping-config-framework] is one possible 550 means of configuring the UA. 552 o Configure the UA (e.g., by means of the SIP configuration 553 framework [I-D.ietf-sipping-config-framework]) and use SIP to 554 instruct the proxy (e.g., by means of an indicator in REGISTER 555 requests). 557 o Configure the proxy and use SIP to instruct the UA (e.g., by means 558 of an indicator in inbound INVITE requests or in the 200 response 559 to a REGISTER request). 561 The configuration approach is the simplest and does not require any 562 enhancements to the SIP protocol. In general, positive action has to 563 be taken to configure any sort of ACH, i.e., ACH is turned off by 564 default. Therefore by default there should not be a problem, because 565 ACH will be turned off in both places. If the user is in control of 566 ACH at the UA and ACH at the proxy, it is the user's responsibility 567 not to configure conflicting behaviours. 569 The situation is slightly different where there is more than one 570 authority involved, e.g., if the user is able to configure the UA but 571 some other authority is responsible for configuring the proxy. This 572 might arise in an enterprise environment, where the enterprise 573 administration might configure the proxy. In this case, the UA user 574 could potentially configure the UA in a conflicting way. In such 575 cases it would be useful if the administration could prevent the user 576 configuring ACH at the UA, i.e., place ACH configuration under 577 administration control. Many UAs aimed at the enterprise market have 578 this form of control already. In future there might be a 579 standardised way of doing this based on the SIP configuration 580 framework [I-D.ietf-sipping-config-framework] . There does not seem 581 to be a need for BLISS to specify anything further to address this 582 issue at present. 584 6.2. Conflict between UAs 586 This can really only be addressed by configuration. The SIP 587 configuration framework can help here. In fact, that would normally 588 configure all UAs having the same AOR with the same information. 589 Configuration outside this framework (e.g., local actions at the 590 device) might introduce differences (intentional or otherwise). 591 There seems little action that BLISS can take to address this issue. 593 6.3. Obtaining information from UA for ACH at proxy 595 There seems to be a case for more precisely defining or at least 596 recommending information given to the proxy when rejecting an inbound 597 call, in order to assist the proxy in providing the most relevant 598 ACH, if any. Ideally this information needs to be given as a SIP 599 response code, although potentially a response code could be 600 supplemented by a header field. In choosing a particular response 601 code, two factors need to be taken into account: 603 o the reason for rejection; 605 o the desired scope of rejection. 607 The following sub-sections discuss these two factors. Best practices 608 in Section 7.2 propose the use of existing response codes for the 609 conditions identified, avoiding the need to specify new response 610 codes. 612 6.3.1. Reason for rejection 614 The most relevant reasons for rejection (from an ACH perspective) are 615 as follows: 617 o Busy. UA resources are busy as a result of another call and 618 further calls cannot be accepted until resources become free. The 619 condition may also be visible via a presence system. 621 o Explicit rejection. The user has indicated an unwillingness to 622 accept the call at the present time. The user may have indicated 623 this in advance, so that any incoming calls (or those fulfilling 624 certain conditions) would be rejected in this way (a feature often 625 known as "do not disturb"). The user may impose such a condition 626 during a meeting or while working on a critical task. The user 627 may indicate in advance a time at which she expects the condition 628 to be lifted. The condition may also be visible via a presence 629 system. Alternatively the user may indicate an unwillingness to 630 accept a particular call in response to being alerted. 632 o Silent rejection. The user has responded to this call by 633 rejecting it, but does not wish the reason to be revealed to the 634 caller. A user would use this facility when not currently in a 635 position to answer a particular call or when she feels that it 636 would be better handled elsewhere (e.g., by voicemail, by an 637 assistant). 639 Note that silent rejection could also be achieved by returning a 180 640 response to the INVITE request, and then waiting (without alerting 641 the user) until the call is cleared or times out. In the meantime, 642 the proxy would be unaware of what is happening and would be unable 643 to take other action, such as cancelling other branches. On the 644 other hand, indicating silent rejection relies on the proxy to take 645 alternative ACH action (e.g., waiting for a certain time before 646 forwarding to voice mail or reporting to the caller that the call has 647 timed out), rather than revealing silent rejection to the caller. 648 Therefore silent rejection is suitable for use only when it is known 649 that the proxy will take appropriate action. 651 6.3.2. Desired scope of rejection 653 When rejecting a call the user (or the UA on the user's behalf) may 654 desire the rejection to have one of the following scopes: 656 o Local. Rejection impacts only the branch concerned or any 657 branches to the user's other devices. Forwarding to voicemail or 658 to an assistant, for example, is not prevented and may be 659 instigated by the proxy as a result of receiving a local 660 rejection. 662 o Global. Rejection impacts all branches, including voicemail. 664 It is a matter for the proxy to determine what ACH to perform for a 665 local rejection or a global rejection (although this may be based on 666 per-user settings, which the user may have some control over, e.g., 667 via a web page, see Section 6.6). For local rejection the proxy 668 might, for example, cancel other branches (to the user's other 669 devices) and forward immediately to voicemail or to an assistant. On 670 the other hand it may leave other branches unaffected. For global 671 rejection the proxy might reject the call outright, cancelling all 672 other branches, although policy might require a less severe action to 673 be taken. For example, in a call centre there might be a requirement 674 that all calls be answered. 676 4xx response codes are appropriate for local rejection and 6xx 677 response codes are appropriate for global rejection. 679 6.4. Informing the calling UA 681 Whilst this might be interesting, it is unlikely to impact 682 interoperability and is not seen as a priority issue for BLISS. 684 6.5. Scope of conditions 686 In view what is specified in [RFC3261] for 6xx response codes and 687 with some, but not all existing practice, it is safest to regard 6xx 688 response codes as impacting all branches of a forked INVITE request. 689 If this is not the desired behaviour when a particular condition 690 arises at the UA (e.g., if forwarding to voicemail is desired), a 4xx 691 response code should be used instead. The proposals in Section 6.3 692 take this into account. 694 6.6. Configuring the proxy 696 General methods for configuring proxies (including synchronization of 697 multiple proxies serving a domain) are considered outside the scope 698 of BLISS work. 700 However, a means is required for a UA to view and modify ACH 701 configuration at a proxy. Although several methods are used in 702 practice, some of these being mentioned in Section 4.6, the one that 703 is perhaps simplest and in line with industry trends is HTTP using a 704 REST architecture. With this approach, different URIs represent 705 different resources, and standard HTTP methods such as GET, PUT, POST 706 and DELETE are used to manipulate those resources. More information 707 is available in [I-D.zourzouvillys-bliss-ach-http-api] 709 OPEN ISSUE. The above reference to be replaced by whatever is 710 adopted as work item for a framework for RESTful configuration. 712 Under some circumstances a setting can change other than by action of 713 the UA, and therefore if the UA relies on knowing the value of a 714 setting (e.g., to provide a continuous indication to the user), the 715 UA needs to be informed if the setting changes. One example is where 716 there are two or more UAs registered as contacts for an AOR. If one 717 of the UAs changes a setting, the other UAs might wish to know. 718 Another example is where a user or administrator changes a setting 719 from a web page. For such situations it would be useful to have an 720 event package whereby the UA can subscribe to receive notifications 721 of changes to ACH settings. The notification would only need to 722 indicate that a change has occurred, and the UA could then issue GET 723 requests to pull down the new settings. A possible solution to this 724 is specified in [I-D.roach-sip-http-subscribe]. 726 7. Best practices for ACH 728 7.1. Avoiding conflict between ACH at proxy and ACH at UA 730 A UA MUST be able to be configured to operate when ACH is provided by 731 the proxy. Typically this means being able to be configured with all 732 ACH features turned off, which typically would be the default 733 configuration. 735 A proxy MUST be able to be configured to operate when ACH is provided 736 by the registered UA or UAs for a given address of record. Typically 737 this means being able to be configured with all ACH features turned 738 off for a given address of record, which typically would be the 739 default configuration. 741 7.2. Use of response codes for reporting ACH-related conditions 743 UAs and MUST use the following response codes for rejecting INVITE 744 requests encountering ACH-related conditions and proxies MUST 745 interpret these response codes accordingly. 747 The following response codes are for local rejection: 749 o Response code 486 for busy/local. As indicated in RFC 3261, this 750 can be accompanied by a Retry-After header field to indicate when 751 the user expects to be available again. 753 o Response code 480 for explicit rejection/local. As indicated in 754 RFC 3261, this can be accompanied by a Retry-After header field to 755 indicate when the user expects to be available again. 757 o Response code 487 for silent rejection/local. This is the same 758 response code that would be used if a proxy were to issue a CANCEL 759 request. 761 The following response codes are for global rejection: 763 o Response code 600 for busy/global. As indicated in RFC 3261, this 764 can be accompanied by a Retry-After header field to indicate when 765 the user expects to be available again. 767 o Response code 603 for explicit rejection/global. As indicated in 768 RFC 3261, this can be accompanied by a Retry-After header field to 769 indicate when the user expects to be available again. 771 No code is specified for silent rejection/global. It is not clear 772 what use cases exist for this. One possible use case, however, is 773 for dealing with SPIT, where the user can determine (e.g., from 774 caller ID) that the call is unwanted and does not wish the call to go 775 to voicemail even. In this case, other issues arise, such as 776 indicating the SPIT status to an entity responsible for handling 777 SPIT. This should be pursued as part of anti-SPIT measures and is 778 outside the scope of BLISS. 780 7.3. UA configuration of ACH at the proxy 782 OPEN ISSUE. To specify ACH-specific use of the REST framework, when 783 available, by specifying URL structures for forwarding, DND, etc. and 784 giving examples. 786 7.4. Notifying a UA of an ACH configuration change at the proxy 788 OPEN ISSUE. To specify ACH-specific use of event package, when 789 available. 791 8. IANA considerations 793 None. 795 9. Security considerations 797 This document just discusses interoperability issues relating to ACH. 798 It does not define any new protocol or practices and therefore does 799 not introduce any security issues, other than the possible user 800 desire not to disclose ACH actions to callers. 802 Appendix A. Survey results 804 In the tables below, the "Question" column shows the questions that 805 were asked. In the case of multi-choice questions, the "Answer" 806 column indicates the choices and the "No." column indicates the 807 number of responses for the given choice. For other questions the 808 "Answer" column contains the free-text answers received. 810 Survey responses for proxy implementations are shown in Table 1. 812 +--------------------------+----------------------------------+-----+ 813 | Question | Answer | No. | 814 +--------------------------+----------------------------------+-----+ 815 | Q1A Configuration | Web UI | 7 | 816 | mechanism that are | | | 817 | supported | | | 818 | | XCAP | 1 | 819 | | FTP/FTPS/SFTP | 0 | 820 | | SOAP | 6 | 821 | | CPL | 1 | 822 | | CSTA | 1 | 823 | | Others | 4 | 824 | | Not applicable | 1 | 825 | Q1B Most commonly | Web UI | 4 | 826 | supported mechanism for | | | 827 | configuration | | | 828 | | SOAP | 2 | 829 | | Not applicable | 1 | 830 | Q2A Status Code used for | 406 | 1 | 831 | Indicating DND | | | 832 | | 486 | 5 | 833 | | 480 | 2 | 834 | | 600 | 1 | 835 | | 603 | 1 | 836 | | Others | 3 | 837 | | Not applicable | 1 | 838 | Q2B Status Code used for | 486 | 7 | 839 | Indicating Busy | | | 840 | | 480 | 3 | 841 | | 600 | 1 | 842 | | Others | 1 | 843 | Q3 When does ACH | ASAP | e | 844 | initiates when multiple | | | 845 | contacts are registered | | | 846 | for the target AoR | | | 847 | | When all responds | 2 | 848 | | Others | 2 | 849 | | Not applicable | 1 | 850 | Q3A If indicated others | - If a 302 or 603 response is | | 851 | for Q3 describe | received, then all other | | 852 | | contacts are cancelled and the | | 853 | | 302/603 is handled. Such | | 854 | | responses are considered user | | 855 | | initiated/configured. On the | | 856 | | other hand, if a 480, 486, 606 | | 857 | | etc response is received, then | | 858 | | the B2BUA waits for all the | | 859 | | other contacts to respond. And | | 860 | | then takes a decision. | | 861 | | - Depending upon the service | | 862 | | instantiated, the UA may | | 863 | | generate no response but stop | | 864 | | alerting, generate a 486 | | 865 | | response which would kill that | | 866 | | fork, or a 603 which would kill | | 867 | | all forks. 600 would kill all | | 868 | | forks and go to voicemail. | | 869 | Q4 If two different | A priority list among the | | 870 | responses were received | response received is followed. | | 871 | which can initiate | | | 872 | different ACH what then? | | | 873 | | - Whichever response arrives | | 874 | | first | | 875 | | - Priority list is used | | 876 | | - Priority on return codes will | | 877 | | lead to only one action | | 878 | | - The 3xx responses are | | 879 | | redirected The 4XX/5XX/6XX | | 880 | | responses are canceled | | 881 | | - Individual responses are | | 882 | | followed until one accepts the | | 883 | | request. For example, an INVITE | | 884 | | that is 300 redirected by one | | 885 | | contact and 180 ringing by | | 886 | | another, the redirected contact | | 887 | | is handled internally and | | 888 | | attempted at the new contact. | | 889 | | - SIP response code order of | | 890 | | precedence and order of arrival | | 891 | | are considered. Upstream | | 892 | | proxies may normalize some | | 893 | | response codes generated by end | | 894 | | clients or gateways into a 480 | | 895 | | response code. | | 896 | Q5 Support for | Yes | 2 | 897 | discovering where to | | | 898 | configure ACH? | | | 899 | | No | 5 | 900 | Q5A How is it done? | - Depending on the | | 901 | | manufacturer's UA, at least two | | 902 | | ways: IP phone display client | | 903 | | "toolbar" for the UA using SOAP | | 904 | | - Device Configuration | | 905 | Q6 Do Proxy/B2BUA | Yes | 8 | 906 | execute ACH without | | | 907 | routing the call first | | | 908 | to the contact? | | | 909 | | No | 1 | 910 | Q6A If you answered Yes | | | 911 | to Q6, when is it | | | 912 | executed? | | | 913 | | - Call Forward Always.? Call | | 914 | | Forward Busy in some cases | | 915 | | - If the provisioned user | | 916 | | configuration in the database | | 917 | | tells this (the DB content is | | 918 | | normally adjustable via a web | | 919 | | interface). | | 920 | | - Unconditional forward. Call | | 921 | | screening. Not available ( not | | 922 | | registered ) Forward | | 923 | | - The proxy (app server) is also | | 924 | | a B2BUA, if the automatic | | 925 | | handling is configured there, it | | 926 | | will handle the call. | | 927 | | - A contact can be behind | | 928 | | another proxy (address | | 929 | | configured statically) and hence | | 930 | | will route to that Proxy. | | 931 | | - For the Call Forward | | 932 | | unconditional case. | | 933 | | - Screening depending upon other | | 934 | | conditions such as time of day, | | 935 | | calling party ID, etc. | | 936 | Q7A How does it treat | - A 6xx response is considered a | | 937 | 6xx response if there | terminal failure, equivalent to | | 938 | are multiple contacts | all other terminal failures. | | 939 | registered for the | The automatic handling continues | | 940 | target AoR? | as configured (e.g. try another | | 941 | | ITSP or CO, forward to operator | | 942 | | or voicemail, etc). | | 943 | | - As Proxy:? Forward the | | 944 | | message. As B2BUA: Treated as | | 945 | | final response and no further | | 946 | | action performed. | | 947 | | - The B2BUA follows configured | | 948 | | re-routing rules or have a | | 949 | | specific treatment? | | 950 | | - Will stop processing further | | 951 | | routes. May forward to | | 952 | | voicemail for 600 response, or | | 953 | | not for 603 response. | | 954 | Q7B How does it treat | - A 6xx response is considered a | | 955 | 6xx response if other | terminal failure, equivalent to | | 956 | contact outside the | all other terminal failures. | | 957 | domain is registered | The automatic handling continues | | 958 | | as configured (e.g. try another | | 959 | | ITSP or CO, forward to operator | | 960 | | or voicemail, etc). | | 961 | | - As Proxy:? Forward the | | 962 | | message. As B2BUA: Treated as | | 963 | | final response and no further | | 964 | | action performed. | | 965 | | - The B2BUA follows configured | | 966 | | re-routing rules or have a | | 967 | | specific treatment? | | 968 | | - Certain features allow the | | 969 | | proxy to route the call to an | | 970 | | alternate endpoint. (e.g. backup | | 971 | | SIP trunk on a disaster recovery | | 972 | | scenario) | | 973 | | - Will stop processing further | | 974 | | routes. May forward to | | 975 | | voicemail for 600 response, or | | 976 | | not for 603 response. | | 977 | Q8 Is there a way to | - No, the B2BUA hides all of the | | 978 | communicate the current | contact information from the UA | | 979 | setting of ACH to the | and performs all automatic | | 980 | UA? | handling silently. | | 981 | | - Subscribe/Notify mechanism. | | 982 | | Synchronizes the call forward | | 983 | | state between the endpoint and | | 984 | | the B2BUA server. The phone | | 985 | | subscribes for the services it | | 986 | | is interested in (e.g., DND, | | 987 | | CFA, CFB, CFNA). Notifies are | | 988 | | sent either way when the service | | 989 | | is modified. | | 990 | | - Yes, via uaCSTA | | 991 | | - Yes, in some cases. Mechanism | | 992 | | varies. | | 993 | Q9 Does it override the | Yes | 4 | 994 | 302 response without | | | 995 | considering RFC 4458? | | | 996 | | No | 5 | 997 +--------------------------+----------------------------------+-----+ 999 Table 1 1001 Survey responses for UA implementations are shown in Table 2. 1003 +----------------------------+--------------------------------+-----+ 1004 | Question | Answer | No. | 1005 +----------------------------+--------------------------------+-----+ 1006 | Q1 Does UA implement ACH | Yes | 7 | 1007 | | No | 2 | 1008 | Q1A If 3xx used for ACH | 300 | 1 | 1009 | which code? | | | 1010 | | 301 | 1 | 1011 | | 302 | 7 | 1012 | | Not applicable | 2 | 1013 | Q1ex: Does it use RFC | Yes | 2 | 1014 | 4458? | | | 1015 | | No | 6 | 1016 | Q1B If 4-6xx used which | 400 | 1 | 1017 | code? | | | 1018 | | 403 | 1 | 1019 | | 404 | 1 | 1020 | | 405 | 1 | 1021 | | 408 | 1 | 1022 | | 415 | 1 | 1023 | | 420 | 1 | 1024 | | 480 | 1 | 1025 | | 481 | 1 | 1026 | | 482 | 1 | 1027 | | 486 | 2 | 1028 | | 491 | 1 | 1029 | | 500 | 1 | 1030 | | 600 | 1 | 1031 | | 603 | 2 | 1032 | | Not applicable | 7 | 1033 | Q2 Can the UA configure | Web UI | 5 | 1034 | the proxy remotely via | | | 1035 | local UI? | | | 1036 | | SOAP | 2 | 1037 | | CSTA | 1 | 1038 | | Not applicable | 2 | 1039 | Q3 How does UA indiate | 480 | 1 | 1040 | DND? | | | 1041 | | 486 | 2 | 1042 +----------------------------+--------------------------------+-----+ 1044 Table 2 1046 10. Acknowledgements 1048 The author would like to acknowledge the assistance of Francois 1049 Audet, Martin Dolly, Jason Fischl, Jonathan Rosenberg, Shida 1050 Schubert, Srivatsa Srinivasan and Theo Zourzouvillys in writing this 1051 draft, and also input on specific implementations from various 1052 members of the BLISS WG. 1054 11. References 1056 11.1. Normative References 1058 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1059 Requirement Levels", BCP 14, RFC 2119, March 1997. 1061 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 1062 A., Peterson, J., Sparks, R., Handley, M., and E. 1063 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 1064 June 2002. 1066 11.2. Informative References 1068 [RFC3680] Rosenberg, J., "A Session Initiation Protocol (SIP) Event 1069 Package for Registrations", RFC 3680, March 2004. 1071 [RFC3880] Lennox, J., Wu, X., and H. Schulzrinne, "Call Processing 1072 Language (CPL): A Language for User Control of Internet 1073 Telephony Services", RFC 3880, October 2004. 1075 [RFC4235] Rosenberg, J., Schulzrinne, H., and R. Mahy, "An INVITE- 1076 Initiated Dialog Event Package for the Session Initiation 1077 Protocol (SIP)", RFC 4235, November 2005. 1079 [RFC4458] Jennings, C., Audet, F., and J. Elwell, "Session 1080 Initiation Protocol (SIP) URIs for Applications such as 1081 Voicemail and Interactive Voice Response (IVR)", RFC 4458, 1082 April 2006. 1084 [RFC4825] Rosenberg, J., "The Extensible Markup Language (XML) 1085 Configuration Access Protocol (XCAP)", RFC 4825, May 2007. 1087 [I-D.elwell-bliss-dnd] 1088 Elwell, J. and S. Srinivasan, "An Analysis of Do Not 1089 Disturb (DND) Implementations in the Session Initiation 1090 Protocol (SIP)", draft-elwell-bliss-dnd-01 (work in 1091 progress), November 2007. 1093 [I-D.ietf-sipping-config-framework] 1094 Channabasappa, S., "A Framework for Session Initiation 1095 Protocol User Agent Profile Delivery", 1096 draft-ietf-sipping-config-framework-17 (work in progress), 1097 February 2010. 1099 [I-D.zourzouvillys-bliss-ach-http-api] 1100 Zourzouvillys, T., "Basic HTTP API interface for ACH", 1101 draft-zourzouvillys-bliss-ach-http-api-01 (work in 1102 progress), March 2009. 1104 [I-D.roach-sip-http-subscribe] 1105 Roach, A., "A SIP Event Package for Subscribing to Changes 1106 to an HTTP Resource", draft-roach-sip-http-subscribe-07 1107 (work in progress), February 2010. 1109 [CSTA] "International Standard ISO/IEC 18051 "Information 1110 Technology - Telecommunications and information exchange 1111 between systems - Services for Computer Supported 1112 Telecommunications Applications (CSTA) Phase III"". 1114 URIs 1116 [1] 1118 Author's Address 1120 John Elwell 1121 Siemens Enterprise Communications 1123 Phone: +44 1908 855608 1124 Email: john.elwell@siemens-enterprise.com