--- 1/draft-ietf-bliss-problem-statement-01.txt 2008-02-24 17:12:13.000000000 +0100 +++ 2/draft-ietf-bliss-problem-statement-02.txt 2008-02-24 17:12:13.000000000 +0100 @@ -1,19 +1,19 @@ BLISS J. Rosenberg Internet-Draft Cisco -Intended status: Informational November 19, 2007 -Expires: May 22, 2008 +Intended status: Informational February 24, 2008 +Expires: August 27, 2008 Basic Level of Interoperability for Session Initiation Protocol (SIP) Services (BLISS) Problem Statement - draft-ietf-bliss-problem-statement-01 + draft-ietf-bliss-problem-statement-02 Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that @@ -24,63 +24,64 @@ and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. - This Internet-Draft will expire on May 22, 2008. + This Internet-Draft will expire on August 27, 2008. Copyright Notice - Copyright (C) The IETF Trust (2007). + Copyright (C) The IETF Trust (2008). Abstract The Session Initiation Protocol (SIP) has been designed as a general purpose protocol for establishing and managing multimedia sessions. It provides many core functions and extensions in support of features such as transferring of calls, parking calls, and so on. However, interoperability of more advanced features between different vendors has been poor. This document describes the reason behind these interoperability problems, and presents a framework for addressing them. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. The Confusion of Tongues . . . . . . . . . . . . . . . . . . . 4 3. Concrete Examples . . . . . . . . . . . . . . . . . . . . . . 5 3.1. Call Forward No Answer . . . . . . . . . . . . . . . . . . 5 3.1.1. Approach 1: UA Redirects . . . . . . . . . . . . . . . 6 3.1.2. Approach II: Proxy Forwards . . . . . . . . . . . . . 7 - 3.1.3. Approach III: UA Proxies . . . . . . . . . . . . . . . 7 - 3.1.4. Approach IV: Call Processing Language . . . . . . . . 8 - 3.1.5. Failure Cases . . . . . . . . . . . . . . . . . . . . 9 - 3.1.5.1. No One Implements . . . . . . . . . . . . . . . . 10 - 3.1.5.2. Both Implement . . . . . . . . . . . . . . . . . . 10 - 3.1.5.3. Missing Half . . . . . . . . . . . . . . . . . . . 10 - 4. Solution Considerations . . . . . . . . . . . . . . . . . . . 10 - 5. BLISS Solution Framework . . . . . . . . . . . . . . . . . . . 12 - 5.1. Phase I - Identify a Feature Group . . . . . . . . . . . . 12 - 5.2. Phase II - Submit Feature Flows . . . . . . . . . . . . . 13 - 5.3. BLISS Phase III - Problem Definition . . . . . . . . . . . 14 - 5.4. BLISS Phase 4 - Minimum Interop Definition . . . . . . . . 15 - 6. Structure of the BLISS Final Deliverable . . . . . . . . . . . 16 - 7. Security Considerations . . . . . . . . . . . . . . . . . . . 17 - 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 - 9. Informative References . . . . . . . . . . . . . . . . . . . . 17 - Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 17 - Intellectual Property and Copyright Statements . . . . . . . . . . 19 + 3.1.3. Approach III: UA Proxies . . . . . . . . . . . . . . . 8 + 3.1.4. Approach IV: Call Processing Language . . . . . . . . 9 + 3.1.5. Failure Cases . . . . . . . . . . . . . . . . . . . . 10 + 3.1.5.1. No One Implements . . . . . . . . . . . . . . . . 11 + 3.1.5.2. Both Implement . . . . . . . . . . . . . . . . . . 11 + 3.1.5.3. Missing Half . . . . . . . . . . . . . . . . . . . 11 + 4. Solution Considerations . . . . . . . . . . . . . . . . . . . 11 + 5. BLISS Solution Framework . . . . . . . . . . . . . . . . . . . 13 + 5.1. Phase I - Identify a Feature Group . . . . . . . . . . . . 13 + 5.2. Phase II - Gather Data . . . . . . . . . . . . . . . . . . 15 + 5.3. BLISS Phase III - Problem Definition . . . . . . . . . . . 15 + 5.4. BLISS Phase 4 - Minimum Interop Definition . . . . . . . . 16 + 6. Structure of the BLISS Final Deliverable . . . . . . . . . . . 17 + 7. Security Considerations . . . . . . . . . . . . . . . . . . . 18 + 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 + 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18 + 10. Informative References . . . . . . . . . . . . . . . . . . . . 18 + Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 19 + Intellectual Property and Copyright Statements . . . . . . . . . . 20 1. Introduction The Session Initiation Protocol (SIP) [RFC3261] has been designed as a general purpose protocol for establishing and managing multimedia sessions. In this role, it provides many core functions and extensions to support "session management features". In this context, session management features (or just features in this specification) are operations, typically invoked by the user, that provide some form value-added functionality within the context of a @@ -89,29 +90,29 @@ conferences, having calls automatically forwarded, and so on. The SIP specification itself includes primitives to support some of these features. For example, RFC 3264 [RFC3264] defines SDP signaling parameters for placing a call on hold. Numerous SIP extensions have been developed which focus on functionality needed for session management features. The REFER specification, RFC 3515 [RFC3515], defines a primitive operation for a user agent to ask another user agent to send a SIP request, typically to initiate a session. REFER is used to support many features, such as transfer, - park, and refer. The Replaces specification, RFC 3891 [RFC3891], + park, and hold. The Replaces specification, RFC 3891 [RFC3891], allows one dialog to replace another. This header field is useful for consultation transfer features. The dialog event package, RFC 4235 [RFC4235], allows one UA to learn about the dialog states on another UA. This package is useful for features such as shared line. However, despite this veritable plethora of specifications that can support session management features, in practice, interoperability - has been quite poor for these kinds of functions. One user agents + has been quite poor for these kinds of functions. When user agents from one vendor are connected to servers and user agents from other vendors, very few of these types of features actually work. In most cases, call hold and basic transfer are broadly interoperable, but more advanced features such as park and resume, music-on-hold, and shared line appearances, do not work. In some cases, these interoperability failures are the fault of poor implementations. In other cases, they are purposeful failures, meant to ensure that third party equipment is not utilized in a vendor's solution. However, in many cases the problem is with the @@ -142,22 +143,22 @@ SIP is typically deployed in environments a large number of user agents and some number of servers, such as proxy servers, registrars, feature servers, and so on. Put together, these form a distributed system used to realize a multimedia communications network. Architecturally, a SIP-based multimedia network can be though of as a distributed state machine. Each node in the network implements a state machine, and messages sent by the protocol serve the purpose of synchronizing the state machines across nodes. If one considers these session management features (hold, transfer, park, etc.), each - of them is ultimately trying to achieve a change in states in the - state machines of two or more nodes in the network. Call hold, for + of them is ultimately trying to achieve a state change in the state + machines of two or more nodes in the network. Call hold, for example, attempts to change the state of media transfer between a pair of user agents. More complex features, such as transfer, are an attempt to synchronize dialog and call states across three or more user agents. In all cases, SIP messaging is used between these agents to change the state machinery of the protocol. If we consider a particular feature, the protocol machinery for accomplishing the feature requires logic on each node involved in the feature. Let us say that feature X can be implemented using two different techniques - X.1 and X.2. Each technique is composed of a @@ -169,24 +170,41 @@ the logic for X.2, the outcome is unpredicable and the feature may not interoperate. We call this problem "the confusion of tongues". It arises whenever there is more than one way to implement a particular feature amongst a set of nodes. While each approach is, by itself, conformant to the specifications, there are interoperability failures because of a heterogeneous selection of methodologies within a particular deployment. + This problem is ameliorated when the logic required for a particular + feature exists almost entirely within a single node. Any feature + involving multiple parties ultimately requires some form of logic in + other nodes. However, when the logic required for a feature requires + that the other nodes only support for the basic SIP specs - [RFC3261] + and [RFC3263] - we call this a single ended feature. Single-ended + features tend to be more interoperable because they rely on just the + lingua franca - basic SIP - from everyone else. An example of a + single-ended feature is mute, which can be done locally within a node + without any signaling at all. Another feature is basic hold (without + music), which requires only that the other side support [RFC3263]. + + Unfortunately, many features are fundamentally not single ended. A + feature that is not single ended is called a multi-ended feature. + Examples include transfer (which relies on at least support for + REFER) and music-on-hold. + 3. Concrete Examples - Several concrete examples can be demonstrated which show this - problem. + Several concrete examples can be demonstrated which demonstrate the + confusion of tongues. 3.1. Call Forward No Answer Call Forward No Answer (CFNA), is a very basic feature. In this feature, user X calls user Y. If user Y is not answering, the call is forwarded to another user, user Z. Typically this forwarding takes place after a certain amount of time. Even for a simple feature like this, there are several ways of implementing it. Consider the reference architecture in Figure 1. @@ -381,33 +400,34 @@ logic in the proxy is guided by the CPL script. 3.1.5. Failure Cases We have now described four different call forwarding implementations. All four are compliant to RFC 3261. All four assume some form of "feature logic" in some of the components in order to realize this feature. For Approach I, this logic is entirely in the UA, and consists of the activation of the feature, configuration of the forward-to URI, execution of the timer, and then causing of a - redirect to the forward-to URI. In approach I, no other logic beyond - RFC 3261 compliance is needed. For approach II, the logic is - entirely in the proxy, and consists of the activation of the feature - through the web, configuration of the forward-to URI through the web, - execution of the timer, and then causing of CANCEL and sequential - fork to the forward-to URI. In approach II, no other "feature logic" - is required on any other component. In approach III, all of the - logic exists on the UA, and consists of the activation of the - feature, configuration of the forward-to URI, execution of the timer, - and then causing of a proxy to the forward-to URI. In approach IV, - all of the feature logic is in the proxy, but it is implemented by - CPL, and the UA has a CPL implementation that establishes the - forwarding number configuration. + redirect to the forward-to URI. This implementation of the feature + is single ended. For approach II, the logic is entirely in the + proxy, and consists of the activation of the feature through the web, + configuration of the forward-to URI through the web, execution of the + timer, and then causing of CANCEL and sequential fork to the + forward-to URI. This implementation approach is also single-ended. + + In approach III, all of the logic exists on the UA, and consists of + the activation of the feature, configuration of the forward-to URI, + execution of the timer, and then causing of a proxy to the forward-to + URI. This approach is also single-ended. In approach IV, all of the + feature logic is in the proxy, but it is implemented by CPL, and the + UA has a CPL implementation that establishes the forwarding number + configuration. Consequently, this approach is multi-ended. If one considers several different combinations of implementation, several error cases arise. 3.1.5.1. No One Implements In this case, the UA assumes approach II (that is, it assumes the proxy handles call forwarding), while the proxy assumes approaches I or III (that is, the UA handles call forwarding). In this case, the call will arrive at the proxy, which forwards it to UA Y, where it @@ -446,20 +466,33 @@ configured (timeout, activation state, call forwarding URI), and describe the timer and how it operates. This approach would actually lead to excellent interoperability, but would come at high cost. The set of interoperable features would be limited to only those which we explicitly specify, and there would be little room for innovation. To avoid this pitfall and others like it, a proper solution to the interoperability has to be structured in such a way that it achieves the following goals: + Covers Everything: Ultimately, the goal of the solution is to make + things work in reality. This means that the solution has to cover + all aspects of the feature that can be a source of + interoperability problems. This includes traditional signaling, + media, and even provisioning and configuration issues. For + example, the failure of Section 3.1.5.3 was caused by an + inconsistent provisioning mechanism between the UA and the server. + Consequently, interoperability requires this mechanism to be + agreed upon to the degree required for interop. The objective of + BLISS is that the resulting specifications ensure that you can + take a UA from one vendor, plug it into the server of another, and + it works - full stop. + Avoid Enumeration: One of the main goals of SIP is to provide a rich set of features. If it requires a specification to be developed for each and every feature, this goal of SIP is lost. Instead, SIP will be limited to a small number of features and it will be hard to add new ones. Therefore, any solution to the interoperability problem must avoid the need to enumerate each and every feature and document something about it. Allow Variability in Definition: It should not be necessary to rigorously define the behavior of any particular feature. It is @@ -506,138 +539,130 @@ 5. BLISS Solution Framework The framework for solving this interoperability dilemma is called BLISS - Basic Level of Interoperability for SIP Services. This solution is actually a process that a working group can follow to identify interoperability problems and then develop solutions. 5.1. Phase I - Identify a Feature Group - The first step is to identify a set of features which have been known - to be problematic in actual deployments. These features are - collected into bundles called a feature group. A feature group is a - collection of actual features that all have a similar flow, and for - which it is believed the source of interoperability failures may be - common. For example, Call Forward No Answer, Call Forward Busy, Call - Forward Unconditional are all very similar, and clearly all have the - same interoperability problem described in Section 3.1. However, the - root issue with these flows is that there needs to be a common + The first step is to identify a feature or set of features which have + been known to be problematic in actual deployments. These features + are collected into bundles called a feature group. A feature group + is a collection of actual features that all have a similar flow, and + for which it is believed the source of interoperability failures may + be common. A feature group can also have just one feature. For + example, Call Forward No Answer, Call Forward Busy, Call Forward + Unconditional are all very similar, and clearly all have the same + interoperability problem described in Section 3.1. However, the root + issue with these flows is that there needs to be a common understanding of where call treatment feature logic is executed, and how the desired treatment is signaled from the user to the place where it is implemented. Thus, other features that are similar, in that they make a decision on call handling based on user input or conditions, will likely also benefit from consideration. Thus, a feature group is defined by a characteristic that identifies a large (and in fact, possibly infinite) number of actual "features" that all belong to the group. This characteristic is called its functional primitive. The first step in the BLISS process is to identify feature groups and their functional primitives that are narrow enough so they are meaningful, yet broad enough that they are not overly constraining. This is not exact, and the initial definitions do not need to be exact. They can be refined as the - BLISS process proceeds. In the case of CFNA, clearly a functional - primitive of "call forwarding features that execute on no-answer" is - too narrow. A functional primitive of "features that handle an - initial INVITE" is too broad. An ideal starting point would probably - be, "features that result in a retargeting or response operation that - depend on user-specified criteria". This covers all of the call - forwarding variations, but also includes features like Do-Not- - Disturb. + BLISS process proceeds. Indeed, in many cases, investigations can + start with a single feature - for example call park - and analysis + can proceed with just one. As work proceeds, the definition of the + feature group can be broadened. In the case of CFNA, clearly a + functional primitive of "call forwarding features that execute on no- + answer" is too narrow. A functional primitive of "features that + handle an initial INVITE" is too broad. An ideal starting point + would probably be, "features that result in a retargeting or response + operation that depend on user-specified criteria". This covers all + of the call forwarding variations, but also includes features like + Do-Not-Disturb. Each feature group should be defined in a similar way, through the definition of a functional primitive by which one could decide whether or not a particular feature was included. As part of this definition, the group can consider specific features and agree whether or not they are covered by the primitive. For example, would "send call to voicemail" be covered by the functional primitive "features that result in a retargeting or response operation that depend on user-specified criteria"? The answer is yes in this case. Discussion of what features are covered by a functional primitive is part of the discussion in this phase. Care must be taken not to define the functional primitive in such a way as to eliminate the possibility of any but a defined and enumerated set of features from being included. The functional primitive should clearly cover features which are in existence today, and of interest, but allow for future ones that could be covered by the primitive. This avoids the perils of enumeration as discussed in Section 4. -5.2. Phase II - Submit Feature Flows +5.2. Phase II - Gather Data With the functional primitive identified and a shared understanding of which features fit within it, the next step is for working group participants to document how their implementations implement features - in the group. This takes the form of call flows along with - explanatory text that clearly articulates what kind of logic, - specific to that feature, is assumed in each component of the system. - The approaches for CFNA documented in Section 3.1 are exactly what is - required at this stage. Ideally, there would be a document submitted - to the working group for each implementation. For example, "Company - Foo Flows for Call Forward" would be a document submitted by an - employee of company Foo, documenting their flow for call forward. - THis document can include flows for each variation that the - implementation supports. For example, it might have a separate call - flow documented for CFNA, for CFB, and for CFU. + in the group. - Obviously, other documentation procedures are possible. A single - editor can work with a team, and the team all suggest specific flows - that are accumulated into one document. This avoids the need for - vendor-specific documents. Participants can also suggest flows they - think might exist or might work, even if there is no known - implementation of the flow. That is fine too. The primary objective - of this phase is to collect as many flows as possible for features - that are covered by the feature group definition. + This can be done any number of ways. Ideally, call flows would be + collected that document the mechanism implemented by each vendor. + However, experience has shown that vendors frequently consider this + information proprietary or sensitive. An alternate model is to + define a survey which asks high level questions about how the feature + or feature group is implemented. Yet another model is to merely ask + vendors to submit freeform text which describes their implementation. It is a decision of the working group as to whether to actually - publish these flows as an RFC, or to use the flows as working - documents. The flows themselves are not actually the output of the - BLISS process; they are only an intermediate step. If the flows are - to be published as an RFC, it is suggested that a single document be - published for each functional primitive. The title of the document - would be something like, "Enumeration of Existing Practices for Foo" - where "Foo" is some moniker for the functional primitive. Such a - document must be clear that it is NOT a best practice. It would - strictly be informational. The document would have subsections for - each flow contributed and considered by the group. + publish the collected information as an RFC, use them as a working + internet draft, or just keep them on a web page. The gathered data + is not an output of the BLISS process; they are only an intermediate + step. If the information is to be published as an RFC, it is + suggested that a single document be published for each functional + primitive. The title of the document would be something like, + "Enumeration of Existing Practices for Foo" where "Foo" is some + moniker for the functional primitive. Such a document must be clear + that it is NOT a best practice. It would strictly be informational. 5.3. BLISS Phase III - Problem Definition - With flows for a particular feature group collected, the next step in - the process is to an analysis on the flows. The analysis considers - each permutation of implementation of logic from the flows submitted - in the previous phase, and determines which combinations work, and - which ones do not. + With current practice for a particular feature group collected, the + next step in the process is to an analyze the data. The analysis + considers each permutation of implementation of logic from the data + gathered in the previous phase, and determines which combinations + work, and which ones do not. General speaking, this analysis is performed by taking the components associated with the feature (for example, in the case of CFNA, there are four components - three UA and one proxy), and for each one considering what happens when it implements one of the logical - behaviors identified in the flow documents from the previous phase. + behaviors identified in the cases identified from the previous phase. Thus, if four variations on a feature have been submitted to the group, and that feature has four components, there are 16 possible deployment scenarios that can be considered. In practice, many of these are equivalent or moot, and therefore the number in practice will be much smaller. The group should work to identify those cases that are going to be of interest, and then based on the logic in each component, figure out where interoperability failures occur. This phase can be accomplished using documents that contain flows, or - can be purely a thinking exercise carried out on the mailing list. - In all likelihood, it will depend on the feature group and the level - of complexity. Regardless of the intermediate steps, the end goal of - this phase should be an enumeration of combinations with known - interoperability problems. This output would look exactly like the - contents of Section 3.1.5, which describe several failure modes that - are possible. + can be purely a thinking exercise carried out on the mailing list or + in a design team. In all likelihood, it will depend on the feature + group and the level of complexity. Regardless of the intermediate + steps, the end goal of this phase should be an enumeration of + combinations with known interoperability problems. One possible + output would look exactly like the contents of Section 3.1.5, which + describe several failure modes that are possible. 5.4. BLISS Phase 4 - Minimum Interop Definition The final step in the BLISS process is to repair the interopreability failures identified in the previous phase. This is done by coming up with a set of recommendations on behaviors of various components, such that, were those rules to be followed, those interoperability failure cases would not have occurred. In some cases, these recommendations identify a place in the network @@ -734,27 +760,37 @@ 7. Security Considerations Interoperability of security functions is also a critical part of the overall interoperability problem, and must be considered as well. 8. IANA Considerations There are no IANA considerations associated with this specification. -9. Informative References +9. Acknowledgements + + I'd like to thank Shida Schubert, Jason Fischl, and John Elwell for + actually running the BLISS process and providing feedback on its + effectiveness. + +10. Informative References [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002. + [RFC3263] Rosenberg, J. and H. Schulzrinne, "Session Initiation + Protocol (SIP): Locating SIP Servers", RFC 3263, + June 2002. + [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, June 2002. [RFC3515] Sparks, R., "The Session Initiation Protocol (SIP) Refer Method", RFC 3515, April 2003. [RFC3891] Mahy, R., Biggs, B., and R. Dean, "The Session Initiation Protocol (SIP) "Replaces" Header", RFC 3891, September 2004. @@ -773,21 +809,21 @@ Cisco Edison, NJ US Phone: +1 973 952-5000 Email: jdrosen@cisco.com URI: http://www.jdrosen.net Full Copyright Statement - Copyright (C) The IETF Trust (2007). + Copyright (C) The IETF Trust (2008). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF