idnits 2.17.1 draft-ietf-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 792. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 803. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 810. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 816. 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 26, 2007) is 6112 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 26, 2007 5 Expires: January 27, 2008 7 Basic Level of Interoperability for Session Initiation Protocol (SIP) 8 Services (BLISS) Problem Statement 9 draft-ietf-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 27, 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 . . . . . . . . 15 71 6. Structure of the BLISS Final Deliverable . . . . . . . . . . . 16 72 7. Security Considerations . . . . . . . . . . . . . . . . . . . 17 73 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 74 9. Informative References . . . . . . . . . . . . . . . . . . . . 17 75 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 17 76 Intellectual Property and Copyright Statements . . . . . . . . . . 19 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 No Answer (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) INVITE Z | | 319 | |<-------------| | 320 | |(4) INVITE Z | | 321 | |---------------------------->| 322 | |(5) 200 OK | | 323 | |<----------------------------| 324 | |(6) 200 OK | | 325 | |------------->| | 326 | |(7) 200 OK | | 327 | |<-------------| | 328 |(8) 200 OK | | | 329 |<-------------| | | 330 |(9) ACK | | | 331 |------------------------------------------->| 333 Figure 4: CFNA Approach III 335 UA X sends an INVITE to its proxy targeted for Y. The proxy sends 336 this INVITE to UA Y. The user does not answer. So, after a timeout, 337 the UA acts like a proxy and sends the INVITE back to P, this time 338 with a Request-URI identifying Z. The proxy forwards this to Z, and 339 the call completes. 341 3.1.4. Approach IV: Call Processing Language 343 In this approach, the proxy implements the call forwarding logic. 344 However, instead of the logic being configured through a web page, it 345 has been uploaded to the proxy server through a Call Processing 346 Language (CPL) [6] script that the UA included in its registration 347 request. 349 The basic call flow for this approach is shown in Figure 5. 351 UA X Proxy UA Y UA Z 352 | |(1) REGISTER | | 353 | |with CPL | | 354 | |<-------------| | 355 | |(2) 200 OK | | 356 | |------------->| | 357 |(3) INVITE Y | | | 358 |------------->| | | 359 | |(4) INVITE Y | | 360 | |------------->| | 361 | | |No Answer | 362 | |(5) CANCEL | | 363 | |------------->| | 364 | |(6) 200 CANCEL| | 365 | |<-------------| | 366 | |(7) 487 | | 367 | |<-------------| | 368 | |(8) ACK | | 369 | |------------->| | 370 | |(9) INVITE Z | | 371 | |---------------------------->| 372 | |(10) 200 OK | | 373 | |<----------------------------| 374 |(11) 200 OK | | | 375 |<-------------| | | 376 |(12) ACK | | | 377 |------------------------------------------->| 379 Figure 5: CFNA Approach IV 381 This flow is nearly identical to the one in Figure 3, however, the 382 logic in the proxy is guided by the CPL script. 384 3.1.5. Failure Cases 386 We have now described four different call forwarding implementations. 387 All four are compliant to RFC 3261. All four assume some form of 388 "feature logic" in some of the components in order to realize this 389 feature. For Approach I, this logic is entirely in the UA, and 390 consists of the activation of the feature, configuration of the 391 forward-to URI, execution of the timer, and then causing of a 392 redirect to the forward-to URI. In approach I, no other logic beyond 393 RFC 3261 compliance is needed. For approach II, the logic is 394 entirely in the proxy, and consists of the activation of the feature 395 through the web, configuration of the forward-to URI through the web, 396 execution of the timer, and then causing of CANCEL and sequential 397 fork to the forward-to URI. In approach II, no other "feature logic" 398 is required on any other component. In approach III, all of the 399 logic exists on the UA, and consists of the activation of the 400 feature, configuration of the forward-to URI, execution of the timer, 401 and then causing of a proxy to the forward-to URI. In approach IV, 402 all of the feature logic is in the proxy, but it is implemented by 403 CPL, and the UA has a CPL implementation that establishes the 404 forwarding number configuration. 406 If one considers several different combinations of implementation, 407 several error cases arise. 409 3.1.5.1. No One Implements 411 In this case, the UA assumes approach II (that is, it assumes the 412 proxy handles call forwarding), while the proxy assumes approaches I 413 or III (that is, the UA handles call forwarding). In this case, the 414 call will arrive at the proxy, which forwards it to UA Y, where it 415 rings indefinitely. The feature does not get provided at all. 417 3.1.5.2. Both Implement 419 In this case, the UA assumes approach I (that is, it assumes that it 420 handles call forwarding), and the proxy assumes approach II (that it, 421 it assumes that it handles call forwarding). In this case, assuming 422 that the forwarding number ends up being provisioned in both places, 423 the actual behavior of the system is a race condition. If the timer 424 fires first at the proxy, the call is forwarded to the number 425 configured on the proxy. If the timer fires first on the UA, the 426 call is forwarded to the number configured on the UA. If these 427 forwarding numbers are different, this results in highly confusing 428 behavior. 430 3.1.5.3. Missing Half 432 In this case, the UA implements CPL, but the proxy does not. Or, the 433 proxy implements CPL, but the UA does not. In either case, the logic 434 for the forwarding feature cannot be configured, and the feature does 435 not work. 437 4. Solution Considerations 439 There are many ways this interoperability problem can be solved. The 440 most obvious solution is to actually enumerate every specific feature 441 that we wish to support with SIP (Call Forward No Answer, Call 442 Forward Busy, Hold, Music-on-hold, and so on). Then, for each 443 feature, identify a specific call flow that realizes it, and describe 444 the exact functionality required in each component of the system. In 445 the case of call forward no answer, for example, we would choose one 446 of the four approaches, define the information that needs to be 447 configured (timeout, activation state, call forwarding URI), and 448 describe the timer and how it operates. This approach would actually 449 lead to excellent interoperability, but would come at high cost. The 450 set of interoperable features would be limited to only those which we 451 explicitly specify, and there would be little room for innovation. 453 To avoid this pitfall and others like it, a proper solution to the 454 interoperability has to be structured in such a way that it achieves 455 the following goals: 457 Avoid Enumeration: One of the main goals of SIP is to provide a rich 458 set of features. If it requires a specification to be developed 459 for each and every feature, this goal of SIP is lost. Instead, 460 SIP will be limited to a small number of features and it will be 461 hard to add new ones. Therefore, any solution to the 462 interoperability problem must avoid the need to enumerate each and 463 every feature and document something about it. 465 Allow Variability in Definition: It should not be necessary to 466 rigorously define the behavior of any particular feature. It is 467 possible for variations to occur that do not affect 468 interoperability. For example, a variation on CFNA is that a 469 provisional response can be sent back to the originator informing 470 them that the call was forwarded. This variation can be 471 implemented without impacting interoperability at all; if the 472 originator can render or utilize the provisional response, things 473 work. If they can't things still work on the originator simply 474 doesn't get that part of the feature. We should allow this kind 475 of localized variability in what each feature does, to preserve 476 innovation. 478 Assume Multimedia: Though many of the features discussed so far are 479 very telephony centric, they all apply and can be used with any 480 number of media types. In addition, it is important that the 481 solution to the interoperability problem not assume a particular 482 media type. Unless the feature is specifically about a media type 483 (instant message logging for example), it must be possible for it 484 to work with all media types. 486 Allow Variability in Implementation: Whenever possible, the solution 487 to the interoperability problem should strive to allow variations 488 in how the implementations work, while preserving 489 interoperability. For example, in the case of call forwarding, 490 the central source of interoperability failure is that is unclear 491 whether the UAs or proxies have responsibility for the forwarding 492 logic. If the decision was made that this logic is in the UA, 493 then either Approach I or Approach III will work. Consequently, 494 it is not necessary to specify which of those two approaches is to 495 be implemented; just that the UA performs the implementation. 497 Support a Multiplicity of Environments: SIP is utilized in a broad 498 set of environments. These include large service providers 499 targeted to consumers, enterprises with business phones, and peer- 500 to-peer systems where there is no central server at all. SIP is 501 utilized in wireless networks with limited bandwidth and high 502 packet loss, and in high-bandwidth wired environments. It is the 503 goal of this process that interoperability be possible using the 504 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 Care must be taken not to define the functional primitive in such a 561 way as to eliminate the possibility of any but a defined and 562 enumerated set of features from being included. The functional 563 primitive should clearly cover features which are in existence today, 564 and of interest, but allow for future ones that could be covered by 565 the primitive. This avoids the perils of enumeration as discussed in 566 Section 4. 568 5.2. Phase II - Submit Feature Flows 570 With the functional primitive identified and a shared understanding 571 of which features fit within it, the next step is for working group 572 participants to document how their implementations implement features 573 in the group. This takes the form of call flows along with 574 explanatory text that clearly articulates what kind of logic, 575 specific to that feature, is assumed in each component of the system. 576 The approaches for CFNA documented in Section 3.1 are exactly what is 577 required at this stage. Ideally, there would be a document submitted 578 to the working group for each implementation. For example, "Company 579 Foo Flows for Call Forward" would be a document submitted by an 580 employee of company Foo, documenting their flow for call forward. 581 THis document can include flows for each variation that the 582 implementation supports. For example, it might have a separate call 583 flow documented for CFNA, for CFB, and for CFU. 585 Obviously, other documentation procedures are possible. A single 586 editor can work with a team, and the team all suggest specific flows 587 that are accumulated into one document. This avoids the need for 588 vendor-specific documents. Participants can also suggest flows they 589 think might exist or might work, even if there is no known 590 implementation of the flow. That is fine too. The primary objective 591 of this phase is to collect as many flows as possible for features 592 that are covered by the feature group definition. 594 It is a decision of the working group as to whether to actually 595 publish these flows as an RFC, or to use the flows as working 596 documents. The flows themselves are not actually the output of the 597 BLISS process; they are only an intermediate step. If the flows are 598 to be published as an RFC, it is suggested that a single document be 599 published for each functional primitive. The title of the document 600 would be something like, "Enumeration of Existing Practices for Foo" 601 where "Foo" is some moniker for the functional primitive. Such a 602 document must be clear that it is NOT a best practice. It would 603 strictly be informational. The document would have subsections for 604 each flow contributed and considered by the group. 606 5.3. BLISS Phase III - Problem Definition 608 With flows for a particular feature group collected, the next step in 609 the process is to an analysis on the flows. The analysis considers 610 each permutation of implementation of logic from the flows submitted 611 in the previous phase, and determines which combinations work, and 612 which ones do not. 614 General speaking, this analysis is performed by taking the components 615 associated with the feature (for example, in the case of CFNA, there 616 are four components - three UA and one proxy), and for each one 617 considering what happens when it implements one of the logical 618 behaviors identified in the flow documents from the previous phase. 619 Thus, if four variations on a feature have been submitted to the 620 group, and that feature has four components, there are 16 possible 621 deployment scenarios that can be considered. In practice, many of 622 these are equivalent or moot, and therefore the number in practice 623 will be much smaller. The group should work to identify those cases 624 that are going to be of interest, and then based on the logic in each 625 component, figure out where interoperability failures occur. 627 This phase can be accomplished using documents that contain flows, or 628 can be purely a thinking exercise carried out on the mailing list. 629 In all likelihood, it will depend on the feature group and the level 630 of complexity. Regardless of the intermediate steps, the end goal of 631 this phase should be an enumeration of combinations with known 632 interoperability problems. This output would look exactly like the 633 contents of Section 3.1.5, which describe several failure modes that 634 are possible. 636 5.4. BLISS Phase 4 - Minimum Interop Definition 638 The final step in the BLISS process is to repair the interopreability 639 failures identified in the previous phase. This is done by coming up 640 with a set of recommendations on behaviors of various components, 641 such that, were those rules to be followed, those interoperability 642 failure cases would not have occurred. 644 In some cases, these recommendations identify a place in the network 645 where something has to happen. Again, considering our CFNA example, 646 the primary recommendation that needs to be made is where the logic 647 for call handling should happen - in the UA, in the proxy, or both. 648 This is likely to be a contentious topic, and the right thing will 649 certainly be a function of participant preference and use cases that 650 are considered important. But, no one ever said life is easy. 652 In other cases, these recommendations take the form of a 653 specification that needs to be implemented. For example, CFNA can be 654 implemented using CPL, in which case both the UA and proxy need to 655 support it. If the group should decide that CPL is the main way to 656 implement these features, the recommendation should clearly state 657 that CPL is required in both places. 659 Indeed, if a particular functional primitive requires any 660 functionality to be present in any node that goes beyond the "common" 661 functions in RFC 3261, the recommendations need to state that. For 662 example, if a particular feature can be implemented using S/MIME, and 663 the group decides that S/MIME is the required everywhere for this 664 feature to work, that recommendation should be clearly stated. 666 In some cases, only a part of a specification is required in order 667 for the features in a feature group to be interoperable. In that 668 case, the group should identify which parts it is. In the example of 669 CPL, RFC 3880 [6], the ability to support non-signalling controls is 670 not neccesary to achieve an implementation of this feature group. 671 So, the recommendation could be that this part is not required. 673 Another key part of the recommendations that get made in this phase, 674 are recommendations around capability discovery. If a decision is 675 made that says there are multiple different ways that a feature can 676 work, and it is necessary to know which one is in use, some kind of 677 capability exchange is required. Consider once more CFNA. If the 678 recommendation of the group is that all proxies have to implement the 679 logic associated with the feature, but phones can also optionally do 680 it, the UA needs to determine whether it has to be responsible for 681 this feature or not. Otherwise, the failure mode in Section 3.1.5.2 682 may still happen. This particular problem can be resolved, for 683 example, by the use of a feature tag in the Require header field that 684 would inform the proxy whether it should or should not provide the 685 feature. The BLISS recommendations for this phase need to include 686 these kinds of things, if they are necessary for the feature group. 688 The recommendations in this phase, covering specific protocols or 689 pieces of protocols, places where functionality needs to reside, and 690 capability negotiations and controls, are all the final output of the 691 BLISS process. If the group has done its job well, with these 692 recommendations, a (potentially large) class of features will 693 interoperate, yet there will be room for innovation. 695 6. Structure of the BLISS Final Deliverable 697 This section describes a recommended template for the final BLISS 698 deliverable - the recommendations of Section 5.4. 700 There will typically be a document produced per functional primitive. 701 The title of the document must clearly articulate the functional 702 primitive that is being addressed. For example, if the functional 703 group is forwarding, an appropriate title would be, "Best Practices 704 for Interoperability of Forwarding Features in the Session Initiation 705 Protocol". It is important that the feature group be well 706 articulated in the title, so that implementors seeking guidance on 707 these features can find it. 709 Similarly, the abstract of the document is very important. It has to 710 contain several sentences that more clearly articulate the functional 711 primitive definition. In addition, the abstract should contain 712 example features, by name or description, that are defined by the 713 functional primitive. Again, this is important so that people 714 looking to understand why feature foo doesn't work, can find the 715 right specification that tells them what they need to do to make it 716 work. 718 The body of the document needs to first clearly and fully define the 719 functional primitive. It must then enumerate features that are in 720 the group. Next, the document should summarize the problems that 721 have arisen in practice that led to the interoperability failures. 722 This would basically be a summarization of the results of phase III 723 of the BLISS process. If the feature group were call forwarding, 724 this part of the document would discuss how the primary problem is 725 where in the network the actual feature logic lives - UA or proxy, 726 and that the interop problems occur because of inconsistent choices 727 between UA and proxy. The final part of the document is explicit 728 recommendations. This would typically be broken out by component 729 types - a section for UA, a section for proxies or "servers" more 730 generally (so that it is clear that B2BUAs aren't excused from the 731 interoperability requirements). This section would clearly state the 732 requirements for this feature group - specifications, portions of 733 specifications, and capability behaviors that are required. 735 7. Security Considerations 737 Interoperability of security functions is also a critical part of the 738 overall interoperability problem, and must be considered as well. 740 8. IANA Considerations 742 There are no IANA considerations associated with this specification. 744 9. Informative References 746 [1] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 747 Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: 748 Session Initiation Protocol", RFC 3261, June 2002. 750 [2] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with 751 Session Description Protocol (SDP)", RFC 3264, June 2002. 753 [3] Sparks, R., "The Session Initiation Protocol (SIP) Refer 754 Method", RFC 3515, April 2003. 756 [4] Mahy, R., Biggs, B., and R. Dean, "The Session Initiation 757 Protocol (SIP) "Replaces" Header", RFC 3891, September 2004. 759 [5] Rosenberg, J., Schulzrinne, H., and R. Mahy, "An INVITE- 760 Initiated Dialog Event Package for the Session Initiation 761 Protocol (SIP)", RFC 4235, November 2005. 763 [6] Lennox, J., Wu, X., and H. Schulzrinne, "Call Processing 764 Language (CPL): A Language for User Control of Internet 765 Telephony Services", RFC 3880, October 2004. 767 Author's Address 769 Jonathan Rosenberg 770 Cisco 771 Edison, NJ 772 US 774 Phone: +1 973 952-5000 775 Email: jdrosen@cisco.com 776 URI: http://www.jdrosen.net 778 Full Copyright Statement 780 Copyright (C) The IETF Trust (2007). 782 This document is subject to the rights, licenses and restrictions 783 contained in BCP 78, and except as set forth therein, the authors 784 retain all their rights. 786 This document and the information contained herein are provided on an 787 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 788 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 789 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 790 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 791 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 792 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 794 Intellectual Property 796 The IETF takes no position regarding the validity or scope of any 797 Intellectual Property Rights or other rights that might be claimed to 798 pertain to the implementation or use of the technology described in 799 this document or the extent to which any license under such rights 800 might or might not be available; nor does it represent that it has 801 made any independent effort to identify any such rights. Information 802 on the procedures with respect to rights in RFC documents can be 803 found in BCP 78 and BCP 79. 805 Copies of IPR disclosures made to the IETF Secretariat and any 806 assurances of licenses to be made available, or the result of an 807 attempt made to obtain a general license or permission for the use of 808 such proprietary rights by implementers or users of this 809 specification can be obtained from the IETF on-line IPR repository at 810 http://www.ietf.org/ipr. 812 The IETF invites any interested party to bring to its attention any 813 copyrights, patents or patent applications, or other proprietary 814 rights that may cover technology that may be required to implement 815 this standard. Please address the information to the IETF at 816 ietf-ipr@ietf.org. 818 Acknowledgment 820 Funding for the RFC Editor function is provided by the IETF 821 Administrative Support Activity (IASA).