idnits 2.17.1 draft-rosenberg-bliss-problem-statement-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 784. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 795. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 802. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 808. 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 (July 2, 2007) is 6137 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 July 2, 2007 5 Expires: January 3, 2008 7 Basic Level of Interoperability for Session Initiation Protocol (SIP) 8 Services (BLISS) Problem Statement 9 draft-rosenberg-bliss-problem-statement-00 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 January 3, 2008. 36 Copyright Notice 38 Copyright (C) The IETF Trust (2007). 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 . . . . . . . . . . . . . . . 7 60 3.1.4. Approach IV: Call Processing Language . . . . . . . . 8 61 3.1.5. Failure Cases . . . . . . . . . . . . . . . . . . . . 9 62 3.1.5.1. No One Implements . . . . . . . . . . . . . . . . 10 63 3.1.5.2. Both Implement . . . . . . . . . . . . . . . . . . 10 64 3.1.5.3. Missing Half . . . . . . . . . . . . . . . . . . . 10 65 4. Solution Considerations . . . . . . . . . . . . . . . . . . . 10 66 5. BLISS Solution Framework . . . . . . . . . . . . . . . . . . . 12 67 5.1. Phase I - Identify a Feature Group . . . . . . . . . . . . 12 68 5.2. Phase II - Submit Feature Flows . . . . . . . . . . . . . 13 69 5.3. BLISS Phase III - Problem Definition . . . . . . . . . . . 14 70 5.4. BLISS Phase 4 - Minimum Interop Definition . . . . . . . . 14 71 6. Structure of the BLISS Final Deliverable . . . . . . . . . . . 16 72 7. Security Considerations . . . . . . . . . . . . . . . . . . . 16 73 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 74 9. Informative References . . . . . . . . . . . . . . . . . . . . 17 75 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 17 76 Intellectual Property and Copyright Statements . . . . . . . . . . 18 78 1. Introduction 80 The Session Initiation Protocol (SIP) [1] has been designed as a 81 general purpose protocol for establishing and managing multimedia 82 sessions. In this role, it provides many core functions and 83 extensions to support "session management features". In this 84 context, session management features (or just features in this 85 specification) are operations, typically invoked by the user, that 86 provide some form value-added functionality within the context of a 87 multimedia session. Examples of features include putting a call on 88 hold (possibly with music), transferring calls, creating ad-hoc 89 conferences, having calls automatically forwarded, and so on. 91 The SIP specification itself includes primitives to support some of 92 these features. For example, RFC 3264 [2] defines SDP signaling 93 parameters for placing a call on hold. Numerous SIP extensions have 94 been developed which focus on functionality needed for session 95 management features. The REFER specification, RFC 3515 [3], defines 96 a primitive operation for a user agent to ask another user agent to 97 send a SIP request, typically to initiate a session. REFER is used 98 to support many features, such as transfer, park, and refer. The 99 Replaces specification, RFC 3891 [4], allows one dialog to replace 100 another. This header field is useful for consultation transfer 101 features. The dialog event package, RFC 4235 [5], allows one UA to 102 learn about the dialog states on another UA. This package is useful 103 for features such as shared line. 105 However, despite this veritable plethora of specifications that can 106 support session management features, in practice, interoperability 107 has been quite poor for these kinds of functions. One user agents 108 from one vendor are connected to servers and user agents from other 109 vendors, very few of these types of features actually work. In most 110 cases, call hold and basic transfer are broadly interoperable, but 111 more advanced features such as park and resume, music-on-hold, and 112 shared line appearances, do not work. 114 In some cases, these interoperability failures are the fault of poor 115 implementations. In other cases, they are purposeful failures, meant 116 to ensure that third party equipment is not utilized in a vendor's 117 solution. However, in many cases the problem is with the 118 specifications. There are two primary specification problems that 119 can cause interoperability failure: 121 o A feature requires functionality that is not defined in any 122 specification. Therefore, the feature cannot be implemented in an 123 interoperable way. 125 o A feature can be implemented in many different ways, each one 126 using different specifications or different call flows, and 127 assuming different functionality in each participating component 128 of the system. However, each component in a particular deployment 129 each chose a different way, and therefore the overall system lacks 130 interoperability. 132 This latter problem is the primary focus of this document. Section 2 133 describes the problem in architectural and more abstract terms. 134 Section 3 then gives several concrete examples that demonstrate the 135 problem. Section 4 then proposes a general framework for resolving 136 the interoperability problem. Finally, Section 6 defines a template 137 that can be utilized by specifications for addressing this 138 interoperability problem. 140 2. The Confusion of Tongues 142 SIP is typically deployed in environments a large number of user 143 agents and some number of servers, such as proxy servers, registrars, 144 feature servers, and so on. Put together, these form a distributed 145 system used to realize a multimedia communications network. 147 Architecturally, a SIP-based multimedia network can be though of as a 148 distributed state machine. Each node in the network implements a 149 state machine, and messages sent by the protocol serve the purpose of 150 synchronizing the state machines across nodes. If one considers 151 these session management features (hold, transfer, park, etc.), each 152 of them is ultimately trying to achieve a change in states in the 153 state machines of two or more nodes in the network. Call hold, for 154 example, attempts to change the state of media transfer between a 155 pair of user agents. More complex features, such as transfer, are an 156 attempt to synchronize dialog and call states across three or more 157 user agents. In all cases, SIP messaging is used between these 158 agents to change the state machinery of the protocol. 160 If we consider a particular feature, the protocol machinery for 161 accomplishing the feature requires logic on each node involved in the 162 feature. Let us say that feature X can be implemented using two 163 different techniques - X.1 and X.2. Each technique is composed of a 164 series of message exchanges and associated state machine processing 165 in each affected node. If all affected nodes implement the same 166 logic - say the logic for X.1 - the feature works. Similarly, if all 167 implement the logic for X.2, the feature works. However, if some of 168 the nodes implement the logic for X.1, and others have implemented 169 the logic for X.2, the outcome is unpredicable and the feature may 170 not interoperate. 172 We call this problem "the confusion of tongues". It arises whenever 173 there is more than one way to implement a particular feature amongst 174 a set of nodes. While each approach is, by itself, conformant to the 175 specifications, there are interoperability failures because of a 176 heterogeneous selection of methodologies within a particular 177 deployment. 179 3. Concrete Examples 181 Several concrete examples can be demonstrated which show this 182 problem. 184 3.1. Call Forward No Answer 186 Call Forward Unconditional (CFNA), is a very basic feature. In this 187 feature, user X calls user Y. If user Y is not answering, the call is 188 forwarded to another user, user Z. Typically this forwarding takes 189 place after a certain amount of time. 191 Even for a simple feature like this, there are several ways of 192 implementing it. Consider the reference architecture in Figure 1. 194 +---------+ 195 | | 196 | | 197 | Proxy | 198 | | 199 | | 200 +---------+ 201 // | \ 202 // | \ 203 // | \\ 204 // | \ 205 // | \ 206 // | \\ 207 / | \ 208 | \ 209 +-------+ +-------+ +-------+ 210 | | | | | | 211 | UA X | | UA Y | | UA Z | 212 | | | | | | 213 | | | | | | 214 +-------+ +-------+ +-------+ 216 Figure 1: Call Forward Use Case 218 In this simple network, there are four "nodes" that are cooperating 219 to implement this feature. There are three user agents, UA X, UA Y 220 and UA Z. All three user agents are associated with a single proxy. 221 When UA X makes a call to UA Y, the INVITE is sent to the proxy which 222 delivers it to UA Y. 224 3.1.1. Approach 1: UA Redirects 226 In this approach, the call forwarding functionality is implemented in 227 the user agents. The user agents have a field on the user interface 228 that a user can enable to cause calls to be forwarded on no-answer. 229 The user can also set up the forward-to URI through the user 230 interface. 232 The basic call flow for this approach is shown in Figure 2. 234 UA X Proxy UA Y UA Z 235 |(1) INVITE Y | | | 236 |------------->| | | 237 | |(2) INVITE Y | | 238 | |------------->| | 239 | | |No Answer | 240 | |(3) 302 Z | | 241 | |<-------------| | 242 | |(4) ACK | | 243 | |------------->| | 244 | |(5) INVITE Z | | 245 | |---------------------------->| 246 | |(6) 200 OK | | 247 | |<----------------------------| 248 |(7) 200 OK | | | 249 |<-------------| | | 250 |(8) ACK | | | 251 |------------------------------------------->| 253 Figure 2: CFNA Approach I 255 When the call from UA X arrives at the proxy, it is forwarded to UA 256 Y. User Y is not there, so UA Y rings for a time. After the call 257 forward timeout has elapsed, UA Y generates a 302 response. This 258 response contains a Contact header field containing the forward-to 259 URI (sip:Z@example.com). This is received by the proxy, which 260 recurses on the 3xx, causing the call to be forwarded to Z. 262 3.1.2. Approach II: Proxy Forwards 264 In this approach, the call forwarding functionality is implemented in 265 the proxy. The proxy has a web interface that allows the user to set 266 up the call forwarding feature and specify the forward-to URI. 268 The basic call flow for this approach is shown in Figure 3. 270 UA X Proxy UA Y UA Z 271 |(1) INVITE Y | | | 272 |------------->| | | 273 | |(2) INVITE Y | | 274 | |------------->| | 275 | | |No Answer | 276 | |(3) CANCEL | | 277 | |------------->| | 278 | |(4) 200 CANCEL| | 279 | |<-------------| | 280 | |(5) 487 | | 281 | |<-------------| | 282 | |(6) ACK | | 283 | |------------->| | 284 | |(7) INVITE Z | | 285 | |---------------------------->| 286 | |(8) 200 OK | | 287 | |<----------------------------| 288 |(9) 200 OK | | | 289 |<-------------| | | 290 |(10) ACK | | | 291 |------------------------------------------->| 293 Figure 3: CFNA Approach II 295 When the call from UA X arives at the proxy, the proxy sends the 296 INVITE to UA Y. UA Y rings for a time. The call timeout timer runs 297 on the proxy. After the timeout has elapsed, the proxy generates a 298 CANCEL, causing the call to stop ringing at UA X. It then consults 299 its internal configuration, notes that call forwarding on no-answer 300 is configured for user Y. It obtains the forward-to URI, and sends an 301 INVITE to it. User Z ansers and the call proceeds. 303 3.1.3. Approach III: UA Proxies 305 In this last approach, the user agent implements the call forwarding, 306 but does so by acting as a proxy, forwarding the call to Z on its 307 own. As in Approach I, the UA would have an interface on its UI for 308 enabling call forwarding and entering the forward-to URI. 310 The basic call flow for this approach is shown in Figure 4. 312 UA X Proxy UA Y UA Z 313 |(1) INVITE Y | | | 314 |------------->| | | 315 | |(2) INVITE Y | | 316 | |------------->| | 317 | | |No Answer | 318 | |(3) CANCEL | | 319 | |------------->| | 320 | |(4) 200 CANCEL| | 321 | |<-------------| | 322 | |(5) 487 | | 323 | |<-------------| | 324 | |(6) ACK | | 325 | |------------->| | 326 | |(7) INVITE Z | | 327 | |---------------------------->| 328 | |(8) 200 OK | | 329 | |<----------------------------| 330 |(9) 200 OK | | | 331 |<-------------| | | 332 |(10) ACK | | | 333 |------------------------------------------->| 335 Figure 4: CFNA Approach III 337 UA X sends an INVITE to its proxy targeted for Y. The proxy sends 338 this INVITE to UA Y. The user does not answer. So, after a timeout, 339 the UA acts like a proxy and sends the INVITE back to P, this time 340 with a Request-URI identifying Z. The proxy forwards this to Z, and 341 the call completes. 343 3.1.4. Approach IV: Call Processing Language 345 In this approach, the proxy implements the call forwarding logic. 346 However, instead of the logic being configured through a web page, it 347 has been uploaded to the proxy server through a Call Processing 348 Language (CPL) [6] script that the UA included in its registration 349 request. 351 The basic call flow for this approach is shown in Figure 5. 353 UA X Proxy UA Y UA Z 354 | |(1) REGISTER | | 355 | |with CPL | | 356 | |<-------------| | 357 | |(2) 200 OK | | 358 | |------------->| | 359 |(3) INVITE Y | | | 360 |------------->| | | 361 | |(4) INVITE Y | | 362 | |------------->| | 363 | | |No Answer | 364 | |(5) CANCEL | | 365 | |------------->| | 366 | |(6) 200 CANCEL| | 367 | |<-------------| | 368 | |(7) 487 | | 369 | |<-------------| | 370 | |(8) ACK | | 371 | |------------->| | 372 | |(9) INVITE Z | | 373 | |---------------------------->| 374 | |(10) 200 OK | | 375 | |<----------------------------| 376 |(11) 200 OK | | | 377 |<-------------| | | 378 |(12) ACK | | | 379 |------------------------------------------->| 381 Figure 5: CFNA Approach IV 383 This flow is nearly identical to the one in Figure 3, however, the 384 logic in the proxy is guided by the CPL script. 386 3.1.5. Failure Cases 388 We have now described three different call forwarding 389 implementations. All three are compliant to RFC 3261. All three 390 assume some form of "feature logic" in some of the components in 391 order to realize this feature. For Approach I, this logic is 392 entirely in the UA, and consists of the activation of the feature, 393 configuration of the forward-to URI, execution of the timer, and then 394 causing of a redirect to the forward-to URI. In approach I, no other 395 logic beyond RFC 3261 compliance is needed. For approach II, the 396 logic is entirely in the proxy, and consists of the activation of the 397 feature through the web, configuration of the forward-to URI through 398 the web, execution of the timer, and then causing of CANCEL and 399 sequential fork to the forward-to URI. In approach II, no other 400 "feature logic" is required on any other component. In approach III, 401 all of the logic exists on the UA, and consists of the activation of 402 the feature, configuration of the forward-to URI, execution of the 403 timer, and then causing of a proxy to the forward-to URI. In 404 approach IV, all of the feature logic is in the proxy, but it is 405 implemented by CPL, and the UA has a CPL implementation that 406 establishes the forwarding number configuration. 408 If one considers several different combinations of implementation, 409 several error cases arise. 411 3.1.5.1. No One Implements 413 In this case, the UA assumes approach II (that is, it assumes the 414 proxy handles call forwarding), while the proxy assumes approaches I 415 or III (that is, the UA handles call forwarding). In this case, the 416 call will arrive at the proxy, which forwards it to UA Y, where it 417 rings indefinitely. The feature does not get provided at all. 419 3.1.5.2. Both Implement 421 In this case, the UA assumes approach I (that is, it assumes that it 422 handles call forwarding), and the proxy assumes approach II (that it, 423 it assumes that it handles call forwarding). In this case, assuming 424 that the forwarding number ends up being provisioned in both places, 425 the actual behavior of the system is a race condition. If the timer 426 fires first at the proxy, the call is forwarded to the number 427 configured on the proxy. If the timer fires first on the UA, the 428 call is forwarded to the number configured on the UA. If these 429 forwarding numbers are different, this results in highly confusing 430 behavior. 432 3.1.5.3. Missing Half 434 In this case, the UA implements CPL, but the proxy does not. Or, the 435 proxy implements CPL, but the UA does not. In either case, the logic 436 for the forwarding feature cannot be configured, and the feature does 437 not work. 439 4. Solution Considerations 441 There are many ways this interoperability problem can be solved. The 442 most obvious solution is to actually enumerate every specific feature 443 that we wish to support with SIP (Call Forward No Answer, Call 444 Forward Busy, Hold, Music-on-hold, and so on). Then, for each 445 feature, identify a specific call flow that realizes it, and describe 446 the exact functionality required in each component of the system. In 447 the case of call forward no answer, for example, we would choose one 448 of the three approaches, define the information that needs to be 449 configured (timeout, activation state, call forwarding URI), and 450 describe the timer and how it operates. This approach would actually 451 lead to excellent interoperability, but would come at high cost. The 452 set of interoperable features would be limited to only those which we 453 explicitly specify, and there would be little room for innovation. 455 To avoid this pitfall and others like it, a proper solution to the 456 interoperability has to be structured in such a way that it achieves 457 the following goals: 459 Avoid Enumeration: One of the main goals of SIP is to provide a rich 460 set of features. If it requires a specification to be developed 461 for each and every feature, this goal of SIP is lost. Instead, 462 SIP will be limited to a small number of features and it will be 463 hard to add new ones. Therefore, any solution to the 464 interoperability problem must avoid the need to enumerate each and 465 every feature and document something about it. 467 Allow Variability in Definition: It should not be necessary to 468 rigorously define the behavior of any particular feature. It is 469 possible for variations to occur that do not affect 470 interoperability. For example, a variation on CFNA is that a 471 provisional response can be sent back to the originator informing 472 them that the call was forwarded. This variation can be 473 implemented without impacting interoperability at all; if the 474 originator can render or utilize the provisional response, things 475 work. If they can't things still work on the originator simply 476 doesn't get that part of the feature. We should allow this kind 477 of localized variability in what each feature does, to preserve 478 innovation. 480 Assume Multimedia: Though many of the features discussed so far are 481 very telephony centric, they all apply and can be used with any 482 number of media types. In addition, it is important that the 483 solution to the interoperability problem not assume a particular 484 media type. Unless the feature is specifically about a media type 485 (instant message logging for example), it must be possible for it 486 to work with all media types. 488 Allow Variability in Implementation: Whenever possible, the solution 489 to the interoperability problem should strive to allow variations 490 in how the implementations work, while preserving 491 interoperability. For example, in the case of call forwarding, 492 the central source of interoperability failure is that is unclear 493 whether the UAs or proxies have responsibility for the forwarding 494 logic. If the decision was made that this logic is in the UA, 495 then either Approach I or Approach III will work. Consequently, 496 it is not necessary to specify which of those two approaches is to 497 be implemented; just that the UA performs the implementation. 499 Support a Multiplicity of Environments: SIP is utilized in a broad 500 set of environments. These include large service providers 501 targeted to consumers, enterprises with business phones, and peer- 502 to-peer systems where there is no central server at all. It is 503 the goal of this process that interoperability be possible using 504 the same set of specifications for all cases. The problem is not 505 restricted to just enterprises, even though many advanced features 506 typically get associated with enterprise. 508 5. BLISS Solution Framework 510 The framework for solving this interoperability dilemma is called 511 BLISS - Basic Level of Interoperability for SIP Services. This 512 solution is actually a process that a working group can follow to 513 identify interoperability problems and then develop solutions. 515 5.1. Phase I - Identify a Feature Group 517 The first step is to identify a set of features which have been known 518 to be problematic in actual deployments. These features are 519 collected into bundles called a feature group. A feature group is a 520 collection of actual features that all have a similar flow, and for 521 which it is believed the source of interoperability failures may be 522 common. For example, Call Forward No Answer, Call Forward Busy, Call 523 Forward Unconditional are all very similar, and clearly all have the 524 same interoperability problem described in Section 3.1. However, the 525 root issue with these flows is that there needs to be a common 526 understanding of where call treatment feature logic is executed, and 527 how the desired treatment is signaled from the user to the place 528 where it is implemented. Thus, other features that are similar, in 529 that they make a decision on call handling based on user input or 530 conditions, will likely also benefit from consideration. 532 Thus, a feature group is defined by a characteristic that identifies 533 a large (and in fact, possibly infinite) number of actual "features" 534 that all belong to the group. This characteristic is called its 535 functional primitive. The first step in the BLISS process is to 536 identify feature groups and their functional primitives that are 537 narrow enough so they are meaningful, yet broad enough that they are 538 not overly constraining. This is not exact, and the initial 539 definitions do not need to be exact. They can be refined as the 540 BLISS process proceeds. In the case of CFNA, clearly a functional 541 primitive of "call forwarding features that execute on no-answer" is 542 too narrow. A functional primitive of "features that handle an 543 initial INVITE" is too broad. An ideal starting point would probably 544 be, "features that result in a retargeting or response operation that 545 depend on user-specified criteria". This covers all of the call 546 forwarding variations, but also includes features like Do-Not- 547 Disturb. 549 Each feature group should be defined in a similar way, through the 550 definition of a functional primitive by which one could decide 551 whether or not a particular feature was included. As part of this 552 definition, the group can consider specific features and agree 553 whether or not they are covered by the primitive. For example, would 554 "send call to voicemail" be covered by the functional primitive 555 "features that result in a retargeting or response operation that 556 depend on user-specified criteria"? The answer is yes in this case. 557 Discussion of what features are covered by a functional primitive is 558 part of the discussion in this phase. 560 5.2. Phase II - Submit Feature Flows 562 With the functional primitive identified and a shared understanding 563 of which features fit within it, the next step is for working group 564 participants to document how their implementations implement features 565 in the group. This takes the form of call flows along with 566 explanatory text that clearly articulates what kind of logic, 567 specific to that feature, is assumed in each component of the system. 568 The approaches for CFNA documented in Section 3.1 are exactly what is 569 required at this stage. Ideally, there would be a document submitted 570 to the working group for each implementation. For example, "Company 571 Foo Flows for Call Forward" would be a document submitted by an 572 employee of company Foo, documenting their flow for call forward. 573 THis document can include flows for each variation that the 574 implementation supports. For example, it might have a separate call 575 flow documented for CFNA, for CFB, and for CFU. 577 Obviously, other documentation procedures are possible. A single 578 editor can work with a team, and the team all suggest specific flows 579 that are accumulated into one document. This avoids the need for 580 vendor-specific documents. Participants can also suggest flows they 581 think might exist or might work, even if there is no known 582 implementation of the flow. That is fine too. The primary objective 583 of this phase is to collect as many flows as possible for features 584 that are covered by the feature group definition. 586 It is a decision of the working group as to whether to actually 587 publish these flows as an RFC, or to use the flows as working 588 documents. The flows themselves are not actually the output of the 589 BLISS process; they are only an intermediate step. If the flows are 590 to be published as an RFC, it is suggested that a single document be 591 published for each functional primitive. The title of the document 592 would be something like, "Enumeration of Existing Practices for Foo" 593 where "Foo" is some moniker for the functional primitive. Such a 594 document must be clear that it is NOT a best practice. It would 595 strictly be informational. The document would have subsections for 596 each flow contributed and considered by the group. 598 5.3. BLISS Phase III - Problem Definition 600 With flows for a particular feature group collected, the next step in 601 the process is to an analysis on the flows. The analysis considers 602 each permutation of implementation of logic from the flows submitted 603 in the previous phase, and determines which combinations work, and 604 which ones do not. 606 General speaking, this analysis is performed by taking the components 607 associated with the feature (for example, in the case of CFNA, there 608 are four components - three UA and one proxy), and for each one 609 considering what happens when it implements one of the logical 610 behaviors identified in the flow documents from the previous phase. 611 Thus, if four variations on a feature have been submitted to the 612 group, and that feature has four components, there are 16 possible 613 deployment scenarios that can be considered. In practice, many of 614 these are equivalent or moot, and therefore the number in practice 615 will be much smaller. The group should work to identify those cases 616 that are going to be of interest, and then based on the logic in each 617 component, figure out where interoperability failures occur. 619 This phase can be accomplished using documents that contain flows, or 620 can be purely a thinking exercise carried out on the mailing list. 621 In all likelihood, it will depend on the feature group and the level 622 of complexity. Regardless of the intermediate steps, the end goal of 623 this phase should be an enumeration of combinations with known 624 interoperability problems. This output would look exactly like the 625 contents of Section 3.1.5, which describe several failure modes that 626 are possible. 628 5.4. BLISS Phase 4 - Minimum Interop Definition 630 The final step in the BLISS process is to repair the interopreability 631 failures identified in the previous phase. This is done by coming up 632 with a set of recommendations on behaviors of various components, 633 such that, were those rules to be followed, those interoperability 634 failure cases would not have occurred. 636 In some cases, these recommendations identify a place in the network 637 where something has to happen. Again, considering our CFNA example, 638 the primary recommendation that needs to be made is where the logic 639 for call handling should happen - in the UA, in the proxy, or both. 640 This is likely to be a contentious topic, and the right thing will 641 certainly be a function of participant preference and use cases that 642 are considered important. But, no one ever said life is easy. 644 In other cases, these recommendations take the form of a 645 specification that needs to be implemented. For example, CFNA can be 646 implemented using CPL, in which case both the UA and proxy need to 647 support it. If the group should decide that CPL is the main way to 648 implement these features, the recommendation should clearly state 649 that CPL is required in both places. 651 Indeed, if a particular functional primitive requires any 652 functionality to be present in any node that goes beyond the "common" 653 functions in RFC 3261, the recommendations need to state that. For 654 example, if a particular feature can be implemented using S/MIME, and 655 the group decides that S/MIME is the required everywhere for this 656 feature to work, that recommendation should be clearly stated. 658 In some cases, only a part of a specification is required in order 659 for the features in a feature group to be interoperable. In that 660 case, the group should identify which parts it is. In the example of 661 CPL, RFC 3880 [6], the ability to support non-signalling controls is 662 not neccesary to achieve an implementation of this feature group. 663 So, the recommendation could be that this part is not required. 665 Another key part of the recommendations that get made in this phase, 666 are recommendations around capability discovery. If a decision is 667 made that says there are multiple different ways that a feature can 668 work, and it is necessary to know which one is in use, some kind of 669 capability exchange is required. Consider once more CFNA. If the 670 recommendation of the group is that all proxies have to implement the 671 logic associated with the feature, but phones can also optionally do 672 it, the UA needs to determine whether it has to be responsible for 673 this feature or not. Otherwise, the failure mode in Section 3.1.5.2 674 may still happen. This particular problem can be resolved, for 675 example, by the use of a feature tag in the Require header field that 676 would inform the proxy whether it should or should not provide the 677 feature. The BLISS recommendations for this phase need to include 678 these kinds of things, if they are necessary for the feature group. 680 The recommendations in this phase, covering specific protocols or 681 pieces of protocols, places where functionality needs to reside, and 682 capability negotiations and controls, are all the final output of the 683 BLISS process. If the group has done its job well, with these 684 recommendations, a (potentially large) class of features will 685 interoperate, yet there will be room for innovation. 687 6. Structure of the BLISS Final Deliverable 689 This section describes a recommended template for the final BLISS 690 deliverable - the recommendations of Section 5.4. 692 There will typically be a document produced per functional primitive. 693 The title of the document must clearly articulate the functional 694 primitive that is being addressed. For example, if the functional 695 group is forwarding, an appropriate title would be, "Best Practices 696 for Interoperability of Forwarding Features in the Session Initiation 697 Protocol". It is important that the feature group be well 698 articulated in the title, so that implementors seeking guidance on 699 these features can find it. 701 Similarly, the abstract of the document is very important. It has to 702 contain several sentences that more clearly articulate the functional 703 primitive definition. In addition, the abstract should contain 704 example features, by name or description, that are defined by the 705 functional primitive. Again, this is important so that people 706 looking to understand why feature foo doesn't work, can find the 707 right specification that tells them what they need to do to make it 708 work. 710 The body of the document needs to first clearly and fully define the 711 functional primitive. It must then enumerate features that are in 712 the group. Next, the document should summarize the problems that 713 have arisen in practice that led to the interoperability failures. 714 This would basically be a summarization of the results of phase III 715 of the BLISS process. If the feature group were call forwarding, 716 this part of the document would discuss how the primary problem is 717 where in the network the actual feature logic lives - UA or proxy, 718 and that the interop problems occur because of inconsistent choices 719 between UA and proxy. The final part of the document is explicit 720 recommendations. This would typically be broken out by component 721 types - a section for UA, a section for proxies or "servers" more 722 generally (so that it is clear that B2BUAs aren't excused from the 723 interoperability requirements). This section would clearly state the 724 requirements for this feature group - specifications, portions of 725 specifications, and capability behaviors that are required. 727 7. Security Considerations 729 Interoperability of security functions is also a critical part of the 730 overall interoperability problem, and must be considered as well. 732 8. IANA Considerations 734 There are no IANA considerations associated with this specification. 736 9. Informative References 738 [1] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 739 Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: 740 Session Initiation Protocol", RFC 3261, June 2002. 742 [2] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with 743 Session Description Protocol (SDP)", RFC 3264, June 2002. 745 [3] Sparks, R., "The Session Initiation Protocol (SIP) Refer 746 Method", RFC 3515, April 2003. 748 [4] Mahy, R., Biggs, B., and R. Dean, "The Session Initiation 749 Protocol (SIP) "Replaces" Header", RFC 3891, September 2004. 751 [5] Rosenberg, J., Schulzrinne, H., and R. Mahy, "An INVITE- 752 Initiated Dialog Event Package for the Session Initiation 753 Protocol (SIP)", RFC 4235, November 2005. 755 [6] Lennox, J., Wu, X., and H. Schulzrinne, "Call Processing 756 Language (CPL): A Language for User Control of Internet 757 Telephony Services", RFC 3880, October 2004. 759 Author's Address 761 Jonathan Rosenberg 762 Cisco 763 Edison, NJ 764 US 766 Phone: +1 973 952-5000 767 Email: jdrosen@cisco.com 768 URI: http://www.jdrosen.net 770 Full Copyright Statement 772 Copyright (C) The IETF Trust (2007). 774 This document is subject to the rights, licenses and restrictions 775 contained in BCP 78, and except as set forth therein, the authors 776 retain all their rights. 778 This document and the information contained herein are provided on an 779 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 780 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 781 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 782 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 783 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 784 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 786 Intellectual Property 788 The IETF takes no position regarding the validity or scope of any 789 Intellectual Property Rights or other rights that might be claimed to 790 pertain to the implementation or use of the technology described in 791 this document or the extent to which any license under such rights 792 might or might not be available; nor does it represent that it has 793 made any independent effort to identify any such rights. Information 794 on the procedures with respect to rights in RFC documents can be 795 found in BCP 78 and BCP 79. 797 Copies of IPR disclosures made to the IETF Secretariat and any 798 assurances of licenses to be made available, or the result of an 799 attempt made to obtain a general license or permission for the use of 800 such proprietary rights by implementers or users of this 801 specification can be obtained from the IETF on-line IPR repository at 802 http://www.ietf.org/ipr. 804 The IETF invites any interested party to bring to its attention any 805 copyrights, patents or patent applications, or other proprietary 806 rights that may cover technology that may be required to implement 807 this standard. Please address the information to the IETF at 808 ietf-ipr@ietf.org. 810 Acknowledgment 812 Funding for the RFC Editor function is provided by the IETF 813 Administrative Support Activity (IASA).