draft-ietf-bliss-problem-statement-00.txt   draft-ietf-bliss-problem-statement-01.txt 
BLISS J. Rosenberg BLISS J. Rosenberg
Internet-Draft Cisco Internet-Draft Cisco
Intended status: Informational July 26, 2007 Intended status: Informational November 19, 2007
Expires: January 27, 2008 Expires: May 22, 2008
Basic Level of Interoperability for Session Initiation Protocol (SIP) Basic Level of Interoperability for Session Initiation Protocol (SIP)
Services (BLISS) Problem Statement Services (BLISS) Problem Statement
draft-ietf-bliss-problem-statement-00 draft-ietf-bliss-problem-statement-01
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware 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 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. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 35 skipping to change at page 1, line 35
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. 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 Notice
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2007).
Abstract Abstract
The Session Initiation Protocol (SIP) has been designed as a general The Session Initiation Protocol (SIP) has been designed as a general
purpose protocol for establishing and managing multimedia sessions. purpose protocol for establishing and managing multimedia sessions.
It provides many core functions and extensions in support of features It provides many core functions and extensions in support of features
skipping to change at page 3, line 7 skipping to change at page 3, line 7
5.4. BLISS Phase 4 - Minimum Interop Definition . . . . . . . . 15 5.4. BLISS Phase 4 - Minimum Interop Definition . . . . . . . . 15
6. Structure of the BLISS Final Deliverable . . . . . . . . . . . 16 6. Structure of the BLISS Final Deliverable . . . . . . . . . . . 16
7. Security Considerations . . . . . . . . . . . . . . . . . . . 17 7. Security Considerations . . . . . . . . . . . . . . . . . . . 17
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
9. Informative References . . . . . . . . . . . . . . . . . . . . 17 9. Informative References . . . . . . . . . . . . . . . . . . . . 17
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 17 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 17
Intellectual Property and Copyright Statements . . . . . . . . . . 19 Intellectual Property and Copyright Statements . . . . . . . . . . 19
1. Introduction 1. Introduction
The Session Initiation Protocol (SIP) [1] has been designed as a The Session Initiation Protocol (SIP) [RFC3261] has been designed as
general purpose protocol for establishing and managing multimedia a general purpose protocol for establishing and managing multimedia
sessions. In this role, it provides many core functions and sessions. In this role, it provides many core functions and
extensions to support "session management features". In this extensions to support "session management features". In this
context, session management features (or just features in this context, session management features (or just features in this
specification) are operations, typically invoked by the user, that specification) are operations, typically invoked by the user, that
provide some form value-added functionality within the context of a provide some form value-added functionality within the context of a
multimedia session. Examples of features include putting a call on multimedia session. Examples of features include putting a call on
hold (possibly with music), transferring calls, creating ad-hoc hold (possibly with music), transferring calls, creating ad-hoc
conferences, having calls automatically forwarded, and so on. conferences, having calls automatically forwarded, and so on.
The SIP specification itself includes primitives to support some of The SIP specification itself includes primitives to support some of
these features. For example, RFC 3264 [2] defines SDP signaling these features. For example, RFC 3264 [RFC3264] defines SDP
parameters for placing a call on hold. Numerous SIP extensions have signaling parameters for placing a call on hold. Numerous SIP
been developed which focus on functionality needed for session extensions have been developed which focus on functionality needed
management features. The REFER specification, RFC 3515 [3], defines for session management features. The REFER specification, RFC 3515
a primitive operation for a user agent to ask another user agent to [RFC3515], defines a primitive operation for a user agent to ask
send a SIP request, typically to initiate a session. REFER is used another user agent to send a SIP request, typically to initiate a
to support many features, such as transfer, park, and refer. The session. REFER is used to support many features, such as transfer,
Replaces specification, RFC 3891 [4], allows one dialog to replace park, and refer. The Replaces specification, RFC 3891 [RFC3891],
another. This header field is useful for consultation transfer allows one dialog to replace another. This header field is useful
features. The dialog event package, RFC 4235 [5], allows one UA to for consultation transfer features. The dialog event package, RFC
learn about the dialog states on another UA. This package is useful 4235 [RFC4235], allows one UA to learn about the dialog states on
for features such as shared line. another UA. This package is useful for features such as shared line.
However, despite this veritable plethora of specifications that can However, despite this veritable plethora of specifications that can
support session management features, in practice, interoperability 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. One user agents
from one vendor are connected to servers and user agents from other from one vendor are connected to servers and user agents from other
vendors, very few of these types of features actually work. In most vendors, very few of these types of features actually work. In most
cases, call hold and basic transfer are broadly interoperable, but cases, call hold and basic transfer are broadly interoperable, but
more advanced features such as park and resume, music-on-hold, and more advanced features such as park and resume, music-on-hold, and
shared line appearances, do not work. shared line appearances, do not work.
skipping to change at page 8, line 42 skipping to change at page 8, line 42
this INVITE to UA Y. The user does not answer. So, after a timeout, 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 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 with a Request-URI identifying Z. The proxy forwards this to Z, and
the call completes. the call completes.
3.1.4. Approach IV: Call Processing Language 3.1.4. Approach IV: Call Processing Language
In this approach, the proxy implements the call forwarding logic. In this approach, the proxy implements the call forwarding logic.
However, instead of the logic being configured through a web page, it However, instead of the logic being configured through a web page, it
has been uploaded to the proxy server through a Call Processing has been uploaded to the proxy server through a Call Processing
Language (CPL) [6] script that the UA included in its registration Language (CPL) [RFC3880] script that the UA included in its
request. registration request.
The basic call flow for this approach is shown in Figure 5. The basic call flow for this approach is shown in Figure 5.
UA X Proxy UA Y UA Z UA X Proxy UA Y UA Z
| |(1) REGISTER | | | |(1) REGISTER | |
| |with CPL | | | |with CPL | |
| |<-------------| | | |<-------------| |
| |(2) 200 OK | | | |(2) 200 OK | |
| |------------->| | | |------------->| |
|(3) INVITE Y | | | |(3) INVITE Y | | |
skipping to change at page 15, line 38 skipping to change at page 15, line 38
Indeed, if a particular functional primitive requires any Indeed, if a particular functional primitive requires any
functionality to be present in any node that goes beyond the "common" functionality to be present in any node that goes beyond the "common"
functions in RFC 3261, the recommendations need to state that. For functions in RFC 3261, the recommendations need to state that. For
example, if a particular feature can be implemented using S/MIME, and example, if a particular feature can be implemented using S/MIME, and
the group decides that S/MIME is the required everywhere for this the group decides that S/MIME is the required everywhere for this
feature to work, that recommendation should be clearly stated. feature to work, that recommendation should be clearly stated.
In some cases, only a part of a specification is required in order 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 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 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 CPL, RFC 3880 [RFC3880], the ability to support non-signalling
not neccesary to achieve an implementation of this feature group. controls is not neccesary to achieve an implementation of this
So, the recommendation could be that this part is not required. 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, Another key part of the recommendations that get made in this phase,
are recommendations around capability discovery. If a decision is are recommendations around capability discovery. If a decision is
made that says there are multiple different ways that a feature can 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 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 capability exchange is required. Consider once more CFNA. If the
recommendation of the group is that all proxies have to implement the recommendation of the group is that all proxies have to implement the
logic associated with the feature, but phones can also optionally do logic associated with the feature, but phones can also optionally do
it, the UA needs to determine whether it has to be responsible for 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 this feature or not. Otherwise, the failure mode in Section 3.1.5.2
skipping to change at page 17, line 19 skipping to change at page 17, line 20
Interoperability of security functions is also a critical part of the Interoperability of security functions is also a critical part of the
overall interoperability problem, and must be considered as well. overall interoperability problem, and must be considered as well.
8. IANA Considerations 8. IANA Considerations
There are no IANA considerations associated with this specification. There are no IANA considerations associated with this specification.
9. Informative References 9. Informative References
[1] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: A., Peterson, J., Sparks, R., Handley, M., and E.
Session Initiation Protocol", RFC 3261, June 2002. Schooler, "SIP: Session Initiation Protocol", RFC 3261,
June 2002.
[2] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model
Session Description Protocol (SDP)", RFC 3264, June 2002. 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. Method", RFC 3515, April 2003.
[4] Mahy, R., Biggs, B., and R. Dean, "The Session Initiation [RFC3891] Mahy, R., Biggs, B., and R. Dean, "The Session Initiation
Protocol (SIP) "Replaces" Header", RFC 3891, September 2004. 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 Initiated Dialog Event Package for the Session Initiation
Protocol (SIP)", RFC 4235, November 2005. 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 Language (CPL): A Language for User Control of Internet
Telephony Services", RFC 3880, October 2004. Telephony Services", RFC 3880, October 2004.
Author's Address Author's Address
Jonathan Rosenberg Jonathan Rosenberg
Cisco Cisco
Edison, NJ Edison, NJ
US US
 End of changes. 13 change blocks. 
33 lines changed or deleted 37 lines changed or added

This html diff was produced by rfcdiff 1.34. The latest version is available from http://tools.ietf.org/tools/rfcdiff/