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