--- 1/draft-ietf-bliss-problem-statement-00.txt 2007-11-19 16:15:48.000000000 +0100 +++ 2/draft-ietf-bliss-problem-statement-01.txt 2007-11-19 16:15:48.000000000 +0100 @@ -1,19 +1,19 @@ BLISS J. Rosenberg Internet-Draft Cisco -Intended status: Informational July 26, 2007 -Expires: January 27, 2008 +Intended status: Informational November 19, 2007 +Expires: May 22, 2008 Basic Level of Interoperability for Session Initiation Protocol (SIP) Services (BLISS) Problem Statement - draft-ietf-bliss-problem-statement-00 + draft-ietf-bliss-problem-statement-01 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,21 +24,21 @@ 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 January 27, 2008. + This Internet-Draft will expire on May 22, 2008. Copyright Notice Copyright (C) The IETF Trust (2007). 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 @@ -70,44 +70,44 @@ 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 1. Introduction - The Session Initiation Protocol (SIP) [1] has been designed as a - general purpose protocol for establishing and managing multimedia + 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 multimedia session. Examples of features include putting a call on hold (possibly with music), transferring calls, creating ad-hoc conferences, having calls automatically forwarded, and so on. The SIP specification itself includes primitives to support some of - these features. For example, RFC 3264 [2] 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 [3], 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 [4], allows one dialog to replace - another. This header field is useful for consultation transfer - features. The dialog event package, RFC 4235 [5], allows one UA to - learn about the dialog states on another UA. This package is useful - for features such as shared line. + 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], + 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 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. @@ -335,22 +335,22 @@ this INVITE to UA Y. The user does not answer. So, after a timeout, the UA acts like a proxy and sends the INVITE back to P, this time with a Request-URI identifying Z. The proxy forwards this to Z, and the call completes. 3.1.4. Approach IV: Call Processing Language In this approach, the proxy implements the call forwarding logic. However, instead of the logic being configured through a web page, it has been uploaded to the proxy server through a Call Processing - Language (CPL) [6] script that the UA included in its registration - request. + Language (CPL) [RFC3880] script that the UA included in its + registration request. The basic call flow for this approach is shown in Figure 5. UA X Proxy UA Y UA Z | |(1) REGISTER | | | |with CPL | | | |<-------------| | | |(2) 200 OK | | | |------------->| | |(3) INVITE Y | | | @@ -658,23 +658,24 @@ Indeed, if a particular functional primitive requires any functionality to be present in any node that goes beyond the "common" functions in RFC 3261, the recommendations need to state that. For example, if a particular feature can be implemented using S/MIME, and the group decides that S/MIME is the required everywhere for this feature to work, that recommendation should be clearly stated. In some cases, only a part of a specification is required in order for the features in a feature group to be interoperable. In that case, the group should identify which parts it is. In the example of - CPL, RFC 3880 [6], the ability to support non-signalling controls is - not neccesary to achieve an implementation of this feature group. - So, the recommendation could be that this part is not required. + CPL, RFC 3880 [RFC3880], the ability to support non-signalling + controls is not neccesary to achieve an implementation of this + feature group. So, the recommendation could be that this part is not + required. Another key part of the recommendations that get made in this phase, are recommendations around capability discovery. If a decision is made that says there are multiple different ways that a feature can work, and it is necessary to know which one is in use, some kind of capability exchange is required. Consider once more CFNA. If the recommendation of the group is that all proxies have to implement the logic associated with the feature, but phones can also optionally do it, the UA needs to determine whether it has to be responsible for this feature or not. Otherwise, the failure mode in Section 3.1.5.2 @@ -735,38 +736,41 @@ 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 - [1] 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. + [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. - [2] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with - Session Description Protocol (SDP)", RFC 3264, June 2002. + [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model + with Session Description Protocol (SDP)", RFC 3264, + June 2002. - [3] Sparks, R., "The Session Initiation Protocol (SIP) Refer + [RFC3515] Sparks, R., "The Session Initiation Protocol (SIP) Refer Method", RFC 3515, April 2003. - [4] Mahy, R., Biggs, B., and R. Dean, "The Session Initiation - Protocol (SIP) "Replaces" Header", RFC 3891, September 2004. + [RFC3891] Mahy, R., Biggs, B., and R. Dean, "The Session Initiation + Protocol (SIP) "Replaces" Header", RFC 3891, + September 2004. - [5] Rosenberg, J., Schulzrinne, H., and R. Mahy, "An INVITE- + [RFC4235] Rosenberg, J., Schulzrinne, H., and R. Mahy, "An INVITE- Initiated Dialog Event Package for the Session Initiation Protocol (SIP)", RFC 4235, November 2005. - [6] Lennox, J., Wu, X., and H. Schulzrinne, "Call Processing + [RFC3880] Lennox, J., Wu, X., and H. Schulzrinne, "Call Processing Language (CPL): A Language for User Control of Internet Telephony Services", RFC 3880, October 2004. Author's Address Jonathan Rosenberg Cisco Edison, NJ US