idnits 2.17.1 draft-ietf-bliss-problem-statement-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.i or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) 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 contain a disclaimer for pre-RFC5378 work, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, you can and should remove the disclaimer; otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (March 9, 2009) is 5499 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 BLISS J. Rosenberg 3 Internet-Draft Cisco 4 Intended status: Informational March 9, 2009 5 Expires: September 10, 2009 7 Basic Level of Interoperability for Session Initiation Protocol (SIP) 8 Services (BLISS) Problem Statement 9 draft-ietf-bliss-problem-statement-04 11 Status of this Memo 13 This Internet-Draft is submitted to IETF in full conformance with the 14 provisions of BCP 78 and BCP 79. This document may contain material 15 from IETF Documents or IETF Contributions published or made publicly 16 available before November 10, 2008. The person(s) controlling the 17 copyright in some of this material may not have granted the IETF 18 Trust the right to allow modifications of such material outside the 19 IETF Standards Process. Without obtaining an adequate license from 20 the person(s) controlling the copyright in such materials, this 21 document may not be modified outside the IETF Standards Process, and 22 derivative works of it may not be created outside the IETF Standards 23 Process, except to format it for publication as an RFC or to 24 translate it into languages other than English. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF), its areas, and its working groups. Note that 28 other groups may also distribute working documents as Internet- 29 Drafts. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 The list of current Internet-Drafts can be accessed at 37 http://www.ietf.org/ietf/1id-abstracts.txt. 39 The list of Internet-Draft Shadow Directories can be accessed at 40 http://www.ietf.org/shadow.html. 42 This Internet-Draft will expire on September 10, 2009. 44 Copyright Notice 46 Copyright (c) 2009 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents in effect on the date of 51 publication of this document (http://trustee.ietf.org/license-info). 52 Please review these documents carefully, as they describe your rights 53 and restrictions with respect to this document. 55 Abstract 57 The Session Initiation Protocol (SIP) has been designed as a general 58 purpose protocol for establishing and managing multimedia sessions. 59 It provides many core functions and extensions in support of features 60 such as transferring of calls, parking calls, and so on. However, 61 interoperability of more advanced features between different vendors 62 has been poor. This document describes the reason behind these 63 interoperability problems, and presents a framework for addressing 64 them. 66 Table of Contents 68 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 69 2. The Confusion of Tongues . . . . . . . . . . . . . . . . . . . 5 70 3. Concrete Examples . . . . . . . . . . . . . . . . . . . . . . 6 71 3.1. Call Forward No Answer . . . . . . . . . . . . . . . . . . 6 72 3.1.1. Approach 1: UA Redirects . . . . . . . . . . . . . . . 7 73 3.1.2. Approach II: Proxy Forwards . . . . . . . . . . . . . 8 74 3.1.3. Approach III: UA Proxies . . . . . . . . . . . . . . . 9 75 3.1.4. Approach IV: Call Processing Language . . . . . . . . 10 76 3.1.5. Failure Cases . . . . . . . . . . . . . . . . . . . . 11 77 3.1.5.1. No One Implements . . . . . . . . . . . . . . . . 12 78 3.1.5.2. Both Implement . . . . . . . . . . . . . . . . . . 12 79 3.1.5.3. Missing Half . . . . . . . . . . . . . . . . . . . 12 80 4. Solution Considerations . . . . . . . . . . . . . . . . . . . 12 81 5. BLISS Solution Framework . . . . . . . . . . . . . . . . . . . 14 82 5.1. Phase I - Identify a Feature Group . . . . . . . . . . . . 14 83 5.2. Phase II - Gather Data . . . . . . . . . . . . . . . . . . 16 84 5.3. BLISS Phase III - Problem Definition . . . . . . . . . . . 16 85 5.4. BLISS Phase 4 - Minimum Interop Definition . . . . . . . . 17 86 6. Structure of the BLISS Final Deliverable . . . . . . . . . . . 18 87 7. Security Considerations . . . . . . . . . . . . . . . . . . . 19 88 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 89 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 19 90 10. Informative References . . . . . . . . . . . . . . . . . . . . 19 91 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 20 93 1. Introduction 95 The Session Initiation Protocol (SIP) [RFC3261] has been designed as 96 a general purpose protocol for establishing and managing multimedia 97 sessions. In this role, it provides many core functions and 98 extensions to support "session management features". In this 99 context, session management features (or just features in this 100 specification) are operations, typically invoked by the user, that 101 provide some form value-added functionality within the context of a 102 multimedia session. Examples of features include putting a call on 103 hold (possibly with music), transferring calls, creating ad-hoc 104 conferences, having calls automatically forwarded, and so on. 106 The SIP specification itself includes primitives to support some of 107 these features. For example, RFC 3264 [RFC3264] defines SDP 108 signaling parameters for placing a call on hold. Numerous SIP 109 extensions have been developed which focus on functionality needed 110 for session management features. The REFER specification, RFC 3515 111 [RFC3515], defines a primitive operation for a user agent to ask 112 another user agent to send a SIP request, typically to initiate a 113 session. REFER is used to support many features, such as transfer, 114 park, and hold. The Replaces specification, RFC 3891 [RFC3891], 115 allows one dialog to replace another. This header field is useful 116 for consultation transfer features. The dialog event package, RFC 117 4235 [RFC4235], allows one UA to learn about the dialog states on 118 another UA. This package is useful for features such as shared line. 120 However, despite this veritable plethora of specifications that can 121 support session management features, in practice, interoperability 122 has been quite poor for these kinds of functions. When user agents 123 from one vendor are connected to servers and user agents from other 124 vendors, very few of these types of features actually work. In most 125 cases, call hold and basic transfer are broadly interoperable, but 126 more advanced features such as park and resume, music-on-hold, and 127 shared line appearances, do not work. 129 In some cases, these interoperability failures are the fault of poor 130 implementations. In other cases, they are purposeful failures, meant 131 to ensure that third party equipment is not utilized in a vendor's 132 solution. However, in many cases the problem is with the 133 specifications. There are two primary specification problems that 134 can cause interoperability failure: 136 o A feature requires functionality that is not defined in any 137 specification. Therefore, the feature cannot be implemented in an 138 interoperable way. 140 o A feature can be implemented in many different ways, each one 141 using different specifications or different call flows, and 142 assuming different functionality in each participating component 143 of the system. However, each component in a particular deployment 144 each chose a different way, and therefore the overall system lacks 145 interoperability. 147 This latter problem is the primary focus of this document. Section 2 148 describes the problem in architectural and more abstract terms. 149 Section 3 then gives several concrete examples that demonstrate the 150 problem. Section 4 then proposes a general framework for resolving 151 the interoperability problem. Finally, Section 6 defines a template 152 that can be utilized by specifications for addressing this 153 interoperability problem. 155 2. The Confusion of Tongues 157 SIP is typically deployed in environments a large number of user 158 agents and some number of servers, such as proxy servers, registrars, 159 feature servers, and so on. Put together, these form a distributed 160 system used to realize a multimedia communications network. 162 Architecturally, a SIP-based multimedia network can be though of as a 163 distributed state machine. Each node in the network implements a 164 state machine, and messages sent by the protocol serve the purpose of 165 synchronizing the state machines across nodes. If one considers 166 these session management features (hold, transfer, park, etc.), each 167 of them is ultimately trying to achieve a state change in the state 168 machines of two or more nodes in the network. Call hold, for 169 example, attempts to change the state of media transfer between a 170 pair of user agents. More complex features, such as transfer, are an 171 attempt to synchronize dialog and call states across three or more 172 user agents. In all cases, SIP messaging is used between these 173 agents to change the state machinery of the protocol. 175 If we consider a particular feature, the protocol machinery for 176 accomplishing the feature requires logic on each node involved in the 177 feature. Let us say that feature X can be implemented using two 178 different techniques - X.1 and X.2. Each technique is composed of a 179 series of message exchanges and associated state machine processing 180 in each affected node. If all affected nodes implement the same 181 logic - say the logic for X.1 - the feature works. Similarly, if all 182 implement the logic for X.2, the feature works. However, if some of 183 the nodes implement the logic for X.1, and others have implemented 184 the logic for X.2, the outcome is unpredicable and the feature may 185 not interoperate. 187 We call this problem "the confusion of tongues". It arises whenever 188 there is more than one way to implement a particular feature amongst 189 a set of nodes. While each approach is, by itself, conformant to the 190 specifications, there are interoperability failures because of a 191 heterogeneous selection of methodologies within a particular 192 deployment. 194 This problem is ameliorated when the logic required for a particular 195 feature exists almost entirely within a single node. Any feature 196 involving multiple parties ultimately requires some form of logic in 197 other nodes. However, when the logic required for a feature requires 198 that the other nodes only support for the basic SIP specs - [RFC3261] 199 and [RFC3263] - we call this a single ended feature. Single-ended 200 features tend to be more interoperable because they rely on just the 201 lingua franca - basic SIP - from everyone else. An example of a 202 single-ended feature is mute, which can be done locally within a node 203 without any signaling at all. Another feature is basic hold (without 204 music), which requires only that the other side support [RFC3263]. 206 Unfortunately, many features are fundamentally not single ended. A 207 feature that is not single ended is called a multi-ended feature. 208 Examples include transfer (which relies on at least support for 209 REFER) and music-on-hold. 211 3. Concrete Examples 213 Several concrete examples can be demonstrated which demonstrate the 214 confusion of tongues. 216 3.1. Call Forward No Answer 218 Call Forward No Answer (CFNA), is a very basic feature. In this 219 feature, user X calls user Y. If user Y is not answering, the call is 220 forwarded to another user, user Z. Typically this forwarding takes 221 place after a certain amount of time. 223 Even for a simple feature like this, there are several ways of 224 implementing it. Consider the reference architecture in Figure 1. 226 +---------+ 227 | | 228 | | 229 | Proxy | 230 | | 231 | | 232 +---------+ 233 // | \ 234 // | \ 235 // | \\ 236 // | \ 237 // | \ 238 // | \\ 239 / | \ 240 | \ 241 +-------+ +-------+ +-------+ 242 | | | | | | 243 | UA X | | UA Y | | UA Z | 244 | | | | | | 245 | | | | | | 246 +-------+ +-------+ +-------+ 248 Figure 1: Call Forward Use Case 250 In this simple network, there are four "nodes" that are cooperating 251 to implement this feature. There are three user agents, UA X, UA Y 252 and UA Z. All three user agents are associated with a single proxy. 253 When UA X makes a call to UA Y, the INVITE is sent to the proxy which 254 delivers it to UA Y. 256 3.1.1. Approach 1: UA Redirects 258 In this approach, the call forwarding functionality is implemented in 259 the user agents. The user agents have a field on the user interface 260 that a user can enable to cause calls to be forwarded on no-answer. 261 The user can also set up the forward-to URI through the user 262 interface. 264 The basic call flow for this approach is shown in Figure 2. 266 UA X Proxy UA Y UA Z 267 |(1) INVITE Y | | | 268 |------------->| | | 269 | |(2) INVITE Y | | 270 | |------------->| | 271 | | |No Answer | 272 | |(3) 302 Z | | 273 | |<-------------| | 274 | |(4) ACK | | 275 | |------------->| | 276 | |(5) INVITE Z | | 277 | |---------------------------->| 278 | |(6) 200 OK | | 279 | |<----------------------------| 280 |(7) 200 OK | | | 281 |<-------------| | | 282 |(8) ACK | | | 283 |------------------------------------------->| 285 Figure 2: CFNA Approach I 287 When the call from UA X arrives at the proxy, it is forwarded to UA 288 Y. User Y is not there, so UA Y rings for a time. After the call 289 forward timeout has elapsed, UA Y generates a 302 response. This 290 response contains a Contact header field containing the forward-to 291 URI (sip:Z@example.com). This is received by the proxy, which 292 recurses on the 3xx, causing the call to be forwarded to Z. 294 3.1.2. Approach II: Proxy Forwards 296 In this approach, the call forwarding functionality is implemented in 297 the proxy. The proxy has a web interface that allows the user to set 298 up the call forwarding feature and specify the forward-to URI. 300 The basic call flow for this approach is shown in Figure 3. 302 UA X Proxy UA Y UA Z 303 |(1) INVITE Y | | | 304 |------------->| | | 305 | |(2) INVITE Y | | 306 | |------------->| | 307 | | |No Answer | 308 | |(3) CANCEL | | 309 | |------------->| | 310 | |(4) 200 CANCEL| | 311 | |<-------------| | 312 | |(5) 487 | | 313 | |<-------------| | 314 | |(6) ACK | | 315 | |------------->| | 316 | |(7) INVITE Z | | 317 | |---------------------------->| 318 | |(8) 200 OK | | 319 | |<----------------------------| 320 |(9) 200 OK | | | 321 |<-------------| | | 322 |(10) ACK | | | 323 |------------------------------------------->| 325 Figure 3: CFNA Approach II 327 When the call from UA X arives at the proxy, the proxy sends the 328 INVITE to UA Y. UA Y rings for a time. The call timeout timer runs 329 on the proxy. After the timeout has elapsed, the proxy generates a 330 CANCEL, causing the call to stop ringing at UA X. It then consults 331 its internal configuration, notes that call forwarding on no-answer 332 is configured for user Y. It obtains the forward-to URI, and sends an 333 INVITE to it. User Z ansers and the call proceeds. 335 3.1.3. Approach III: UA Proxies 337 In this last approach, the user agent implements the call forwarding, 338 but does so by acting as a proxy, forwarding the call to Z on its 339 own. As in Approach I, the UA would have an interface on its UI for 340 enabling call forwarding and entering the forward-to URI. 342 The basic call flow for this approach is shown in Figure 4. 344 UA X Proxy UA Y UA Z 345 |(1) INVITE Y | | | 346 |------------->| | | 347 | |(2) INVITE Y | | 348 | |------------->| | 349 | | |No Answer | 350 | |(3) INVITE Z | | 351 | |<-------------| | 352 | |(4) INVITE Z | | 353 | |---------------------------->| 354 | |(5) 200 OK | | 355 | |<----------------------------| 356 | |(6) 200 OK | | 357 | |------------->| | 358 | |(7) 200 OK | | 359 | |<-------------| | 360 |(8) 200 OK | | | 361 |<-------------| | | 362 |(9) ACK | | | 363 |------------------------------------------->| 365 Figure 4: CFNA Approach III 367 UA X sends an INVITE to its proxy targeted for Y. The proxy sends 368 this INVITE to UA Y. The user does not answer. So, after a timeout, 369 the UA acts like a proxy and sends the INVITE back to P, this time 370 with a Request-URI identifying Z. The proxy forwards this to Z, and 371 the call completes. 373 3.1.4. Approach IV: Call Processing Language 375 In this approach, the proxy implements the call forwarding logic. 376 However, instead of the logic being configured through a web page, it 377 has been uploaded to the proxy server through a Call Processing 378 Language (CPL) [RFC3880] script that the UA included in its 379 registration request. 381 The basic call flow for this approach is shown in Figure 5. 383 UA X Proxy UA Y UA Z 384 | |(1) REGISTER | | 385 | |with CPL | | 386 | |<-------------| | 387 | |(2) 200 OK | | 388 | |------------->| | 389 |(3) INVITE Y | | | 390 |------------->| | | 391 | |(4) INVITE Y | | 392 | |------------->| | 393 | | |No Answer | 394 | |(5) CANCEL | | 395 | |------------->| | 396 | |(6) 200 CANCEL| | 397 | |<-------------| | 398 | |(7) 487 | | 399 | |<-------------| | 400 | |(8) ACK | | 401 | |------------->| | 402 | |(9) INVITE Z | | 403 | |---------------------------->| 404 | |(10) 200 OK | | 405 | |<----------------------------| 406 |(11) 200 OK | | | 407 |<-------------| | | 408 |(12) ACK | | | 409 |------------------------------------------->| 411 Figure 5: CFNA Approach IV 413 This flow is nearly identical to the one in Figure 3, however, the 414 logic in the proxy is guided by the CPL script. 416 3.1.5. Failure Cases 418 We have now described four different call forwarding implementations. 419 All four are compliant to RFC 3261. All four assume some form of 420 "feature logic" in some of the components in order to realize this 421 feature. For Approach I, this logic is entirely in the UA, and 422 consists of the activation of the feature, configuration of the 423 forward-to URI, execution of the timer, and then causing of a 424 redirect to the forward-to URI. This implementation of the feature 425 is single ended. For approach II, the logic is entirely in the 426 proxy, and consists of the activation of the feature through the web, 427 configuration of the forward-to URI through the web, execution of the 428 timer, and then causing of CANCEL and sequential fork to the 429 forward-to URI. This implementation approach is also single-ended. 431 In approach III, all of the logic exists on the UA, and consists of 432 the activation of the feature, configuration of the forward-to URI, 433 execution of the timer, and then causing of a proxy to the forward-to 434 URI. This approach is also single-ended. In approach IV, all of the 435 feature logic is in the proxy, but it is implemented by CPL, and the 436 UA has a CPL implementation that establishes the forwarding number 437 configuration. Consequently, this approach is multi-ended. 439 If one considers several different combinations of implementation, 440 several error cases arise. 442 3.1.5.1. No One Implements 444 In this case, the UA assumes approach II (that is, it assumes the 445 proxy handles call forwarding), while the proxy assumes approaches I 446 or III (that is, the UA handles call forwarding). In this case, the 447 call will arrive at the proxy, which forwards it to UA Y, where it 448 rings indefinitely. The feature does not get provided at all. 450 3.1.5.2. Both Implement 452 In this case, the UA assumes approach I (that is, it assumes that it 453 handles call forwarding), and the proxy assumes approach II (that it, 454 it assumes that it handles call forwarding). In this case, assuming 455 that the forwarding number ends up being provisioned in both places, 456 the actual behavior of the system is a race condition. If the timer 457 fires first at the proxy, the call is forwarded to the number 458 configured on the proxy. If the timer fires first on the UA, the 459 call is forwarded to the number configured on the UA. If these 460 forwarding numbers are different, this results in highly confusing 461 behavior. 463 3.1.5.3. Missing Half 465 In this case, the UA implements CPL, but the proxy does not. Or, the 466 proxy implements CPL, but the UA does not. In either case, the logic 467 for the forwarding feature cannot be configured, and the feature does 468 not work. 470 4. Solution Considerations 472 There are many ways this interoperability problem can be solved. The 473 most obvious solution is to actually enumerate every specific feature 474 that we wish to support with SIP (Call Forward No Answer, Call 475 Forward Busy, Hold, Music-on-hold, and so on). Then, for each 476 feature, identify a specific call flow that realizes it, and describe 477 the exact functionality required in each component of the system. In 478 the case of call forward no answer, for example, we would choose one 479 of the four approaches, define the information that needs to be 480 configured (timeout, activation state, call forwarding URI), and 481 describe the timer and how it operates. This approach would actually 482 lead to excellent interoperability, but would come at high cost. The 483 set of interoperable features would be limited to only those which we 484 explicitly specify, and there would be little room for innovation. 486 To avoid this pitfall and others like it, a proper solution to the 487 interoperability has to be structured in such a way that it achieves 488 the following goals: 490 Covers Everything: Ultimately, the goal of the solution is to make 491 things work in reality. This means that the solution has to cover 492 all aspects of the feature that can be a source of 493 interoperability problems. This includes traditional signaling, 494 media, and even provisioning and configuration issues. For 495 example, the failure of Section 3.1.5.3 was caused by an 496 inconsistent provisioning mechanism between the UA and the server. 497 Consequently, interoperability requires this mechanism to be 498 agreed upon to the degree required for interop. The objective of 499 BLISS is that the resulting specifications ensure that you can 500 take a UA from one vendor, plug it into the server of another, and 501 it works - full stop. 503 Avoid Enumeration: One of the main goals of SIP is to provide a rich 504 set of features. If it requires a specification to be developed 505 for each and every feature, this goal of SIP is lost. Instead, 506 SIP will be limited to a small number of features and it will be 507 hard to add new ones. Therefore, any solution to the 508 interoperability problem must avoid the need to enumerate each and 509 every feature and document something about it. 511 Allow Variability in Definition: It should not be necessary to 512 rigorously define the behavior of any particular feature. It is 513 possible for variations to occur that do not affect 514 interoperability. For example, a variation on CFNA is that a 515 provisional response can be sent back to the originator informing 516 them that the call was forwarded. This variation can be 517 implemented without impacting interoperability at all; if the 518 originator can render or utilize the provisional response, things 519 work. If they can't things still work on the originator simply 520 doesn't get that part of the feature. We should allow this kind 521 of localized variability in what each feature does, to preserve 522 innovation. 524 Assume Multimedia: Though many of the features discussed so far are 525 very telephony centric, they all apply and can be used with any 526 number of media types. In addition, it is important that the 527 solution to the interoperability problem not assume a particular 528 media type. Unless the feature is specifically about a media type 529 (instant message logging for example), it must be possible for it 530 to work with all media types. 532 Allow Variability in Implementation: Whenever possible, the solution 533 to the interoperability problem should strive to allow variations 534 in how the implementations work, while preserving 535 interoperability. For example, in the case of call forwarding, 536 the central source of interoperability failure is that is unclear 537 whether the UAs or proxies have responsibility for the forwarding 538 logic. If the decision was made that this logic is in the UA, 539 then either Approach I or Approach III will work. Consequently, 540 it is not necessary to specify which of those two approaches is to 541 be implemented; just that the UA performs the implementation. 543 Support a Multiplicity of Environments: SIP is utilized in a broad 544 set of environments. These include large service providers 545 targeted to consumers, enterprises with business phones, and peer- 546 to-peer systems where there is no central server at all. SIP is 547 utilized in wireless networks with limited bandwidth and high 548 packet loss, and in high-bandwidth wired environments. It is the 549 goal of this process that interoperability be possible using the 550 same set of specifications for all cases. The problem is not 551 restricted to just enterprises, even though many advanced features 552 typically get associated with enterprise. 554 5. BLISS Solution Framework 556 The framework for solving this interoperability dilemma is called 557 BLISS - Basic Level of Interoperability for SIP Services. This 558 solution is actually a process that a working group can follow to 559 identify interoperability problems and then develop solutions. 561 5.1. Phase I - Identify a Feature Group 563 The first step is to identify a feature or set of features which have 564 been known to be problematic in actual deployments. These features 565 are collected into bundles called a feature group. A feature group 566 is a collection of actual features that all have a similar flow, and 567 for which it is believed the source of interoperability failures may 568 be common. A feature group can also have just one feature. For 569 example, Call Forward No Answer, Call Forward Busy, Call Forward 570 Unconditional are all very similar, and clearly all have the same 571 interoperability problem described in Section 3.1. However, the root 572 issue with these flows is that there needs to be a common 573 understanding of where call treatment feature logic is executed, and 574 how the desired treatment is signaled from the user to the place 575 where it is implemented. Thus, other features that are similar, in 576 that they make a decision on call handling based on user input or 577 conditions, will likely also benefit from consideration. 579 Thus, a feature group is defined by a characteristic that identifies 580 a large (and in fact, possibly infinite) number of actual "features" 581 that all belong to the group. This characteristic is called its 582 functional primitive. The first step in the BLISS process is to 583 identify feature groups and their functional primitives that are 584 narrow enough so they are meaningful, yet broad enough that they are 585 not overly constraining. This is not exact, and the initial 586 definitions do not need to be exact. They can be refined as the 587 BLISS process proceeds. Indeed, in many cases, investigations can 588 start with a single feature - for example call park - and analysis 589 can proceed with just one. As work proceeds, the definition of the 590 feature group can be broadened. In the case of CFNA, clearly a 591 functional primitive of "call forwarding features that execute on no- 592 answer" is too narrow. A functional primitive of "features that 593 handle an initial INVITE" is too broad. An ideal starting point 594 would probably be, "features that result in a retargeting or response 595 operation that depend on user-specified criteria". This covers all 596 of the call forwarding variations, but also includes features like 597 Do-Not-Disturb. 599 Each feature group should be defined in a similar way, through the 600 definition of a functional primitive by which one could decide 601 whether or not a particular feature was included. As part of this 602 definition, the group can consider specific features and agree 603 whether or not they are covered by the primitive. For example, would 604 "send call to voicemail" be covered by the functional primitive 605 "features that result in a retargeting or response operation that 606 depend on user-specified criteria"? The answer is yes in this case. 607 Discussion of what features are covered by a functional primitive is 608 part of the discussion in this phase. 610 Care must be taken not to define the functional primitive in such a 611 way as to eliminate the possibility of any but a defined and 612 enumerated set of features from being included. The functional 613 primitive should clearly cover features which are in existence today, 614 and of interest, but allow for future ones that could be covered by 615 the primitive. This avoids the perils of enumeration as discussed in 616 Section 4. 618 5.2. Phase II - Gather Data 620 With the functional primitive identified and a shared understanding 621 of which features fit within it, the next step is for working group 622 participants to document how their implementations implement features 623 in the group. 625 This can be done any number of ways. Ideally, call flows would be 626 collected that document the mechanism implemented by each vendor. 627 However, experience has shown that vendors frequently consider this 628 information proprietary or sensitive. An alternate model is to 629 define a survey which asks high level questions about how the feature 630 or feature group is implemented. Yet another model is to merely ask 631 vendors to submit freeform text which describes their implementation. 633 It is a decision of the working group as to whether to actually 634 publish the collected information as an RFC, use them as a working 635 internet draft, or just keep them on a web page. The gathered data 636 is not an output of the BLISS process; they are only an intermediate 637 step. If the information is to be published as an RFC, it is 638 suggested that a single document be published for each functional 639 primitive. The title of the document would be something like, 640 "Enumeration of Existing Practices for Foo" where "Foo" is some 641 moniker for the functional primitive. Such a document must be clear 642 that it is NOT a best practice. It would strictly be informational. 644 5.3. BLISS Phase III - Problem Definition 646 With current practice for a particular feature group collected, the 647 next step in the process is to an analyze the data. The analysis 648 considers each permutation of implementation of logic from the data 649 gathered in the previous phase, and determines which combinations 650 work, and which ones do not. 652 General speaking, this analysis is performed by taking the components 653 associated with the feature (for example, in the case of CFNA, there 654 are four components - three UA and one proxy), and for each one 655 considering what happens when it implements one of the logical 656 behaviors identified in the cases identified from the previous phase. 657 Thus, if four variations on a feature have been submitted to the 658 group, and that feature has four components, there are 16 possible 659 deployment scenarios that can be considered. In practice, many of 660 these are equivalent or moot, and therefore the number in practice 661 will be much smaller. The group should work to identify those cases 662 that are going to be of interest, and then based on the logic in each 663 component, figure out where interoperability failures occur. 665 This phase can be accomplished using documents that contain flows, or 666 can be purely a thinking exercise carried out on the mailing list or 667 in a design team. In all likelihood, it will depend on the feature 668 group and the level of complexity. Regardless of the intermediate 669 steps, the end goal of this phase should be an enumeration of 670 combinations with known interoperability problems. One possible 671 output would look exactly like the contents of Section 3.1.5, which 672 describe several failure modes that are possible. 674 5.4. BLISS Phase 4 - Minimum Interop Definition 676 The final step in the BLISS process is to repair the interopreability 677 failures identified in the previous phase. This is done by coming up 678 with a set of recommendations on behaviors of various components, 679 such that, were those rules to be followed, those interoperability 680 failure cases would not have occurred. 682 In some cases, these recommendations identify a place in the network 683 where something has to happen. Again, considering our CFNA example, 684 the primary recommendation that needs to be made is where the logic 685 for call handling should happen - in the UA, in the proxy, or both. 686 This is likely to be a contentious topic, and the right thing will 687 certainly be a function of participant preference and use cases that 688 are considered important. But, no one ever said life is easy. 690 In other cases, these recommendations take the form of a 691 specification that needs to be implemented. For example, CFNA can be 692 implemented using CPL, in which case both the UA and proxy need to 693 support it. If the group should decide that CPL is the main way to 694 implement these features, the recommendation should clearly state 695 that CPL is required in both places. 697 Indeed, if a particular functional primitive requires any 698 functionality to be present in any node that goes beyond the "common" 699 functions in RFC 3261, the recommendations need to state that. For 700 example, if a particular feature can be implemented using S/MIME, and 701 the group decides that S/MIME is the required everywhere for this 702 feature to work, that recommendation should be clearly stated. 704 In some cases, only a part of a specification is required in order 705 for the features in a feature group to be interoperable. In that 706 case, the group should identify which parts it is. In the example of 707 CPL, RFC 3880 [RFC3880], the ability to support non-signalling 708 controls is not neccesary to achieve an implementation of this 709 feature group. So, the recommendation could be that this part is not 710 required. 712 Another key part of the recommendations that get made in this phase, 713 are recommendations around capability discovery. If a decision is 714 made that says there are multiple different ways that a feature can 715 work, and it is necessary to know which one is in use, some kind of 716 capability exchange is required. Consider once more CFNA. If the 717 recommendation of the group is that all proxies have to implement the 718 logic associated with the feature, but phones can also optionally do 719 it, the UA needs to determine whether it has to be responsible for 720 this feature or not. Otherwise, the failure mode in Section 3.1.5.2 721 may still happen. This particular problem can be resolved, for 722 example, by the use of a feature tag in the Require header field that 723 would inform the proxy whether it should or should not provide the 724 feature. The BLISS recommendations for this phase need to include 725 these kinds of things, if they are necessary for the feature group. 727 The recommendations in this phase, covering specific protocols or 728 pieces of protocols, places where functionality needs to reside, and 729 capability negotiations and controls, are all the final output of the 730 BLISS process. If the group has done its job well, with these 731 recommendations, a (potentially large) class of features will 732 interoperate, yet there will be room for innovation. 734 6. Structure of the BLISS Final Deliverable 736 This section describes a recommended template for the final BLISS 737 deliverable - the recommendations of Section 5.4. 739 There will typically be a document produced per functional primitive. 740 The title of the document must clearly articulate the functional 741 primitive that is being addressed. For example, if the functional 742 group is forwarding, an appropriate title would be, "Best Practices 743 for Interoperability of Forwarding Features in the Session Initiation 744 Protocol". It is important that the feature group be well 745 articulated in the title, so that implementors seeking guidance on 746 these features can find it. 748 Similarly, the abstract of the document is very important. It has to 749 contain several sentences that more clearly articulate the functional 750 primitive definition. In addition, the abstract should contain 751 example features, by name or description, that are defined by the 752 functional primitive. Again, this is important so that people 753 looking to understand why feature foo doesn't work, can find the 754 right specification that tells them what they need to do to make it 755 work. 757 The body of the document needs to first clearly and fully define the 758 functional primitive. It must then enumerate features that are in 759 the group. Next, the document should summarize the problems that 760 have arisen in practice that led to the interoperability failures. 762 This would basically be a summarization of the results of phase III 763 of the BLISS process. If the feature group were call forwarding, 764 this part of the document would discuss how the primary problem is 765 where in the network the actual feature logic lives - UA or proxy, 766 and that the interop problems occur because of inconsistent choices 767 between UA and proxy. The final part of the document is explicit 768 recommendations. This would typically be broken out by component 769 types - a section for UA, a section for proxies or "servers" more 770 generally (so that it is clear that B2BUAs aren't excused from the 771 interoperability requirements). This section would clearly state the 772 requirements for this feature group - specifications, portions of 773 specifications, and capability behaviors that are required. 775 7. Security Considerations 777 Interoperability of security functions is also a critical part of the 778 overall interoperability problem, and must be considered as well. 780 8. IANA Considerations 782 There are no IANA considerations associated with this specification. 784 9. Acknowledgements 786 I'd like to thank Shida Schubert, Jason Fischl, and John Elwell for 787 actually running the BLISS process and providing feedback on its 788 effectiveness. 790 10. Informative References 792 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 793 A., Peterson, J., Sparks, R., Handley, M., and E. 794 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 795 June 2002. 797 [RFC3263] Rosenberg, J. and H. Schulzrinne, "Session Initiation 798 Protocol (SIP): Locating SIP Servers", RFC 3263, 799 June 2002. 801 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 802 with Session Description Protocol (SDP)", RFC 3264, 803 June 2002. 805 [RFC3515] Sparks, R., "The Session Initiation Protocol (SIP) Refer 806 Method", RFC 3515, April 2003. 808 [RFC3891] Mahy, R., Biggs, B., and R. Dean, "The Session Initiation 809 Protocol (SIP) "Replaces" Header", RFC 3891, 810 September 2004. 812 [RFC4235] Rosenberg, J., Schulzrinne, H., and R. Mahy, "An INVITE- 813 Initiated Dialog Event Package for the Session Initiation 814 Protocol (SIP)", RFC 4235, November 2005. 816 [RFC3880] Lennox, J., Wu, X., and H. Schulzrinne, "Call Processing 817 Language (CPL): A Language for User Control of Internet 818 Telephony Services", RFC 3880, October 2004. 820 Author's Address 822 Jonathan Rosenberg 823 Cisco 824 Iselin, NJ 825 US 827 Email: jdrosen@cisco.com 828 URI: http://www.jdrosen.net