One document matched: draft-rosenberg-rai-modest-proposal-00.txt
SIP J. Rosenberg
Internet-Draft Cisco
Intended status: Informational October 26, 2008
Expires: April 29, 2009
A Modest Proposal for Session Initiation Protocol (SIP) Work in the IETF
draft-rosenberg-rai-modest-proposal-00
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
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
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 April 29, 2009.
Copyright Notice
Copyright (C) The IETF Trust (2008).
Abstract
The Session Initiation Protocol (SIP) has become widely deployed on
the Internet, covering a wide range of usages from toll bypass to
instant messaging, from service provider to enterprise. However, its
realization in actual deployments differs in important ways from the
specifications. This has created a gulf between existing and ongoing
standards work, and real live deployments. This document argues that
the RAI area should focus on solving real world interoperability
issues and address real world functional gaps.
Rosenberg Expires April 29, 2009 [Page 1]
Internet-Draft Modest Proposal October 2008
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. The SIP Implementation Gap . . . . . . . . . . . . . . . . . . 3
3. Implications of the Gap . . . . . . . . . . . . . . . . . . . 4
3.1. Low Adoption Rate of Specifications . . . . . . . . . . . 4
3.2. Unaddressed Problems . . . . . . . . . . . . . . . . . . . 5
3.3. Declining Participation . . . . . . . . . . . . . . . . . 6
4. A Modest Proposal . . . . . . . . . . . . . . . . . . . . . . 6
4.1. Recognize the Realities . . . . . . . . . . . . . . . . . 7
4.2. Effort Proportional to Deployments . . . . . . . . . . . . 8
4.3. Less is More . . . . . . . . . . . . . . . . . . . . . . . 11
5. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 11
6. Security Considerations . . . . . . . . . . . . . . . . . . . 12
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12
8. Informational References . . . . . . . . . . . . . . . . . . . 12
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 13
Intellectual Property and Copyright Statements . . . . . . . . . . 14
Rosenberg Expires April 29, 2009 [Page 2]
Internet-Draft Modest Proposal October 2008
1. Introduction
The Session Initiation Protocol (SIP) [RFC3261], is a wildly
successful protocol by any metric. It has seen widespread deployment
on the Internet. It is used primarily in Voice over IP deployments,
and carries billions and billions of minutes of traffic each year.
It is used by enterprises big and small, by services providers far
and wide, for a wide range of communications applications.
However, like any large piece of work, some of the SIP specifications
have seen widespread usage, and others have not. Indeed, in the past
few years, there has been an increase in the gap between
implementations and standards, with an increasing number of
specifications being produced with limited use in the industry. At
the same time, the industry is facing a whole host of
interoperability and SIP problems, which are not being addressed by
IETF.
This document proposes that the SIP working group (and the RAI area
at large), recognize this gap, and begin work on addressing the real
needs of real SIP deployments.
2. The SIP Implementation Gap
The SIP implementation gap is the increasing difference between SIP
as defined by the IETF, across its many specifications, and SIP in
use within the industry. This gap manifests itself in several key
ways - specifications that are not implemented or used by most
vendors or networks, non-standard solutions to problems, and networks
whose architectures differ from the models conceived by the IETF
specifications. The latter gap appears to be one of the primary
contributors to the implementation gap. This architecture gap
consists of three primary areas:
Proxies vs. B2BUA: The SIP specifications would lead a reader to
believe that SIP networks are full of these things called proxies,
and that these proxies are principally concerned about call
routing and are totally ignorant of call state. In reality, many
if not most of the intermediaries in vendor products and networks
are B2BUAs. These include SBCs, IP PBXs, softswitches, and so on,
all of which are B2BUA.
Endpoint vs. Network Features: The SIP architecture envisions a
model where the majority of features live in the endpoints, and a
smaller number live in the network. Network features are
primarily limited to routing features - such as call forwarding
and follow-me - which live in proxies. Though this is true for
Rosenberg Expires April 29, 2009 [Page 3]
Internet-Draft Modest Proposal October 2008
some networks (it is a foundational principle in P2P networks),
most operational SIP deployments do not work this way. In
reality, many products implement a much larger set of features in
the network. Indeed, there appears to be a wide variation in this
area, from one extreme (for P2P, all features in the endpoints) to
another (using SIP as an MGCP alternative, passing digits and
stimulus over INFO or DTMF to a call agent which implements all
features). Unsurprisingly, this variation is a consequence of the
software architecture of many products that existed prior to
adding SIP, and in a desire not to re-architect products, features
remain where they were and SIP gets added on.
Email vs. Number Identifiers: The SIP specifications support both
email-style and phone number identifiers. However, the focus - in
examples, in specifications, and in use cases - is for email-style
addressing. However, many deployments still utilize traditional
phone numbers, and represent them using a SIP URI whose domain
part is ignored, irrelevant, or used merely for determining the
next hop target for the request.
Open Federation: The SIP specifications assume an email-style open-
Internet interconnection - a user in example.com can send an
INVITE to a user in a completely different domain - example.edu,
and using basic DNS lookups, the call can be completed between
domains without prior arrangement. While this remains a laudable
goal, in practice it has not happened. SIP is deployed widely
within individual domains, but interconnections between domains,
when they do exist, are through managed federations.
3. Implications of the Gap
There are several consequences of this gap that are important for
IETF.
3.1. Low Adoption Rate of Specifications
Because of the implementation gap, IETF has produced many
specifications which target problems in networks or deployments which
represent only a small minority of real systems. As a consequence,
these specifications have seen poor adoption and support. The cost
to IETF is one of opportunity; time we could have spent on problems
important to a large number of deployments, are spent on problems
important to only a few.
Interestingly, many of these relate to B2BUAs. The following
specifications, all of which have seen relatively limited adoption,
are all important only in networks with proxies and not B2BUAs:
Rosenberg Expires April 29, 2009 [Page 4]
Internet-Draft Modest Proposal October 2008
GRUU: In networks with proxies, the proxy cannot modify the Contact
header field in dialog forming requests and responses. This
necessitates the mechanism in GRUU [I-D.ietf-sip-gruu] whereby a
UA can obtain and utilize URIs for use in the Contact header
field. However, since a B2BUA does maintain call state, it can
merely rewrite the Contact header field to one that has the GRUU
property. That can be done without specification, and is indeed a
common practice in B2BUA. Results from SIPIt 23 indicate that
GRUU was supported by only 9% of implementations present, despite
thet fact that it has been done for many years.
Session Policies: In networks with proxies, the proxy cannot modify
the SDP to enforce network policies on things like codecs or media
intermediaries. This necessitates a mechanism, via the session
policy framework [I-D.ietf-sip-session-policy-framework] and
related specifications [I-D.ietf-sipping-media-policy-dataset],
[I-D.ietf-sipping-policy-package], that allow a proxy and UA to
communicate policies to each other. However, in a network with
B2BUA, the B2BUAs can just modify the SDP and other parts of the
signaling to enforce policy. This requires no specification and
is commonly done. There were no implementations of session policy
at SIPit 23.
SIP Identity: SIP identity [RFC4474] assumes an interconnection of
proxies which do not rewrite key fields in the SIP message (which
are covered by signatures) and which make user of email-style
identifiers. Consequently, although the problem space it
addresses is highly relevant to deployments with B2BUA and proxies
alike, the mechanism itself is not compatible with B2BUAs or phone
numbers, both of which are common. Only two implementations at
SIPit 23 (out of 50 present) had RFC 4474 support.
3.2. Unaddressed Problems
SIP has seen widespread deployment, and as a consequence, many
interoperability issues have arisen in actual networks. Many of
these are areas where additional standards work could help improve
the situation. In addition, there remain areas where there are no
standards, and useful work could be done, but is not being done
because the problems don't make sense in the original SIP
architecture.
Several meetings ago, the SIP forum hosted an interoperability
session during a lunch break. The session included presentations
from many vendors and network operators listing real issues that they
were having. These included problems with DTMF interoperability,
phone number representation, SDP incompatibilities, and so on. Yet,
IETF has not responded with work to address these issues. In some
Rosenberg Expires April 29, 2009 [Page 5]
Internet-Draft Modest Proposal October 2008
cases, the problem is that the IETF standards-based solutions for
these problems have not been adopted by the industry. Sometimes, its
jut a matter of time. In other cases, the proposed solutions, while
architecturally pure and elegant, have simply been too complicated
for the use cases for which they were targeted. For example, despite
the IETF's production of a standard for signaling-based carriage of
DTMF (KPML, RFC 4730 [RFC4730]), it has seen relatively little
adoption. Rather, most deployments use an INFO-based solution that
is not standards based, but has been found to be much simpler for
actual implementors. Only at the most recent IETF was there
agreement to adopt a framework for INFO.
3.3. Declining Participation
Some RAI gourps have seen a decline in participation from folks with
real implementations who have real problems to solve. More and more,
folks seem to be busy with day jobs with little time for IETF. This
has resulted in increasing timelines to complete drafts as editors
struggle to get a revision done per meeting. While there is
certainly no consensus that this is the only or even primary part of
the problem, I do believe lack of participation and slow editors is a
part of it.
Why is that? Why are folks more busy with day jobs with less time
for IETF? Perhaps its due to the fact that the IETF simply isn't
producing documents that are actually relevant to their day jobs -
said day jobs presumably being tied to real products with real
implementations and real deployments. If, however, IETF work were
tied to the actual implementation issues those product teams were
facing, we might see an increase in participation from implementors.
4. A Modest Proposal
Unsurprisingly, my modest proposal is the following is to do three
primary things:
1. Recognize the realities of SIP operational networks and take them
into account.
2. Weigh our efforts proportionally with the number of affected
networks.
3. Less is More.
Rosenberg Expires April 29, 2009 [Page 6]
Internet-Draft Modest Proposal October 2008
4.1. Recognize the Realities
The RAI area needs to formally recognize that B2BUAs, phone numbers,
and intra-domain focused implementations are common, and are part of
SIP's architecture. As an example, DHCP is an intra-domain only
protocol, yet it was specified by IETF and is absolutely a standards
track.
Consequently, we should formally design our specifications to work in
those environments when appropriate, and perhaps even be optimized
for them based on engineering analysis. If a particular feature
needs to work one way in a proxy environment, and a different but
much simpler way in a B2BUA environment, the IETF should consider
that perhaps the much simpler solution, which is likely to be broadly
applicable, is superior. Session policies is a great example of
that; with an SBC, the solution of modifying SDP is much simpler than
defining a protocol framework for negotiation between UA and servers
in the network. IETF is, after all, the Internet *Engineering* Task
Force, and engineering involves minimizing resources for maximal
match of requirements.
Of course, nothing is absolute and all things are subject to
engineering analysis; but we should stop ruling out solutions that
require B2BUA, and consider them fully in our efforts. Furthemore,
SIP is nothing if not diverse. Some features are targeted at
networks, like P2PSIP, which lack central servers by design. As part
of our engineering analysis, we need to factor in whether a feature
is relevant in such networks, and whether their properties impact the
engineering choice on the mechanism.
To support this end, I propose the following specific steps:
1. The RAI area produce an informative document which shows pictures
of several exemplary real operational SIP networks, covering
service providers, enterprises, consumer and residential
services, presence/IM networks, and so on. Such pictures would
omit vendor names but be clear about what kinds of components are
in the network (B2BUA, gateways, proxies, UAs of various sorts),
what the scale is, and what types of protocols are in use. That
will provide a clear framework to measure how easily our
specifications 'fit' into the real networks that are out there
today. We can update that document regularly as real networks
change. We should invite architects of such networks or vendors
of key components in those networks to help draft the document.
2. The RAI area update the guidelines for authors of SIP extensions
[RFC4485] to reference the above informative document, and based
on it, present additional guidelines - e.g., take into account
Rosenberg Expires April 29, 2009 [Page 7]
Internet-Draft Modest Proposal October 2008
SBCs, and so on.
3. The RAI area revise RFC 3427 [RFC3427] (the SIP change process).
Work was begun on this [I-D.peterson-rai-rfc3427bis], but the
draft is now expired. That revision should remove the "P-header"
punishment for specifications which do not work on the public
Internet. IETF should recognize that intra-domain and multi-
domain but closed federations are real, and valid deployments of
SIP. Standards defined to address problems in those deployments
are no less 'real' than ones meant for SIP on the Internet.
4.2. Effort Proportional to Deployments
SIP, like all other technologies, has gone through an adoption
lifecycle. This lifecycle, called the technology adoption life
cycle, looks at the rate of adoption of new technologies over time.
Within the VoIP market, SIP is currently in the late majority phase;
most vendors have it, it is widely deployed and operational.
Rosenberg Expires April 29, 2009 [Page 8]
Internet-Draft Modest Proposal October 2008
|
|
|
|
| SIP
A |
d | |
o | |
p | |
t | V
i | **********
o | ** | **
n | ** | **
| ** | **
| * | **
| ** | *
| * | **
| ** | *
| ** | **
| ** | **
| *** | | | ***
| *** | | | ***
| *** | Early | Late | **********
| ******* Early | Majority | Majority| ***
| |Adopter | | | Laggards
|
---+---------------------------------------------------------
|
| time
Figure 1: Technology Lifecycle
It is well understood in product marketing that your strategies for
building and selling products vary tremendously as a technology
crosses through these phases. During the innovation and early
adopter phases, the technology can be rough, hard to manage and use.
But, the focus is on new capabilities and benefits to the user. As
technologies mature, the importance of 'new' diminishes, and instead,
ease of use, ease of purchase, and reduction in operational cost,
become more and more important.
I would assert that, the same applies to standardization processes.
In the beginning, when a technology is new, the right thing is to
focus on cool new capabilities, innovations, and wild new
capabilities. As a technology matures, the standards activities need
to shift focus as well, moving more towards real problems in real
networks. The golden rule is:
Rosenberg Expires April 29, 2009 [Page 9]
Internet-Draft Modest Proposal October 2008
The work IETF spends on a topic should be proportional to the
number of operational networks in which that topic is important.
The SIP working group and RAI area at large invest their energies in
problems proportionally to the scope of the networks and deployments
with those problems. A problem, like SDP interoperability, which
affects a large number of real operational networks, should be given
priority over one with a limited audience. It is important to note
that audience refers NOT to implementations, and NOT to other SDOs,
but to current or planned networks. Oftentimes, folks have an
implementation but it is a prototype or research activity. Those
implementations should count less in our prioritization than ones in
actual large-scale operational networks. Similarly, oftentimes a
specification is needed by another SDO, for their own standards.
While the SDO and its specifications are important, we should weight
such work by looking at the current or planned real implementations
of our specification that come about through that SDO.
How do we make this determination of what is important? One
suggestion is that the SIP and/or SIPPING groups review the
contributions to the SIP forum session a few IETFs back, and begin
working the top issues identified there. The inclination is often to
say, "oh, thats just an implementation problem", or, "well they were
just being lazy". However, for problems that are systemic - where
several vendors would appear to be lazy or getting it wrong, this
points to an issue - either the specifications are overly complex and
the industry has decided not to use them, or they are unclear and
hard to get correct. Both of these are problems that can be
addressed by additional standards work. So the suggestion is to lean
towards, "its the IETF's fault" when doing this analysis.
Another suggestion is that the SIP and/or SIPPING working groups
approach vendors with SIP implementations and deployments and solicit
requests for areas of standards work that they would like to see
addressed. Those folks should also be invited to participate in the
IETF with welcome arms. We can set up mentoring programs were
existing long-time participants help new folks learn the ropes and
show them how to participate on the lists and bring ideas forward.
Collection of input on standards work could happen via a web survey,
for example, much like was done for the BLISS working group.
Indeed, since IETF is ultimately a volunteer organization, any
proposal that requires a change in focus, requires bringing in
participants who are interested in that focus. We should therefore
try and identify steps which lead to increased participation from
implementors and deployers.
Rosenberg Expires April 29, 2009 [Page 10]
Internet-Draft Modest Proposal October 2008
4.3. Less is More
IETF overall, and RAI in particular, has a tendency to produce
specifications which are fairly large and complex (indeed I
personally have contributed much to this). The focus has been to
have broad solutions that provide general purpose, framework-type
capabilities. As SIP has matured and become deployed, it is now part
of many products and networks for which big large changes are hard.
Consequently, it is becoming increasingly important to aim low, and
produce specifications that provide incremental features for only a
small increment of work. This is not always possible of course, but
our focus should be, "less is more", especially when weighing the
features of the specification relative to the current reality of
networks.
One such example of this is the configuration framework
[I-D.ietf-sipping-config-framework]. It is a very rich and complex
specification, supporting composition of configuration policies,
roaming and home networks, change notifications and enrollment. In
reality, many consumer products just periodically poll a config file
from a defined URL, and thats it. A much simpler configuration
mechanism, that is easy to add ontop of what is out there today,
would probably be more welcome in the marketplace. Note that, at
SIPit 23, there were no implementations of the configuration
framework.
Another example of this is the relatively new SDP capability
negotiation framework [I-D.ietf-mmusic-sdp-capability-negotiation].
This work was driven primarily to solve one key industry problem -
negotiating SRTP vs. RTP. So, the decision factor is, should we
define a general purpose framework or an incremental solution just
for RTP/SRTP? The IETF chose a general purpose framework, and that
brings with it a certain level of complexity. Will implementors use
this just to solve that one problem? I am concerned the cost/benefit
ratio is too high.
5. Conclusion
In conclusion, IETF needs to adapt to the realities of SIP. The IETF
should focus on reall engineering problems that enable building
interoperability systems that will see significant deployment. The
RAI area needs to admit the things like SBCs and phone numbers and
private federations are real, and design solutions for them. Those
networks are our customers.
Rosenberg Expires April 29, 2009 [Page 11]
Internet-Draft Modest Proposal October 2008
Insanity: doing the same thing over and over again and expecting
different results.
--Albert Einstein
6. Security Considerations
This document does not have any security implications for the
Internet.
7. Acknowledgements
The author would like to thank Paul Kyzivat, Dan Wing, Cullen
Jennings, James Polk and Mary Barnes for their comments on this
document.
8. Informational 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.
[I-D.ietf-sip-gruu]
Rosenberg, J., "Obtaining and Using Globally Routable User
Agent (UA) URIs (GRUU) in the Session Initiation Protocol
(SIP)", draft-ietf-sip-gruu-15 (work in progress),
October 2007.
[RFC4474] Peterson, J. and C. Jennings, "Enhancements for
Authenticated Identity Management in the Session
Initiation Protocol (SIP)", RFC 4474, August 2006.
[I-D.ietf-sip-session-policy-framework]
Hilt, V., Camarillo, G., and J. Rosenberg, "A Framework
for Session Initiation Protocol (SIP) Session Policies",
draft-ietf-sip-session-policy-framework-03 (work in
progress), April 2008.
[I-D.ietf-sipping-media-policy-dataset]
Hilt, V., "A User Agent Profile Data Set for Media
Policy", draft-ietf-sipping-media-policy-dataset-05 (work
in progress), November 2007.
[I-D.ietf-sipping-policy-package]
Rosenberg Expires April 29, 2009 [Page 12]
Internet-Draft Modest Proposal October 2008
Hilt, V. and G. Camarillo, "A Session Initiation Protocol
(SIP) Event Package for Session-Specific Session
Policies", draft-ietf-sipping-policy-package-04 (work in
progress), August 2007.
[I-D.ietf-sipping-config-framework]
Channabasappa, S., "A Framework for Session Initiation
Protocol User Agent Profile Delivery",
draft-ietf-sipping-config-framework-15 (work in progress),
February 2008.
[RFC4730] Burger, E. and M. Dolly, "A Session Initiation Protocol
(SIP) Event Package for Key Press Stimulus (KPML)",
RFC 4730, November 2006.
[RFC4485] Rosenberg, J. and H. Schulzrinne, "Guidelines for Authors
of Extensions to the Session Initiation Protocol (SIP)",
RFC 4485, May 2006.
[RFC3427] Mankin, A., Bradner, S., Mahy, R., Willis, D., Ott, J.,
and B. Rosen, "Change Process for the Session Initiation
Protocol (SIP)", BCP 67, RFC 3427, December 2002.
[I-D.peterson-rai-rfc3427bis]
Peterson, J. and C. Jennings, "Change Process for the
Session Initiation Protocol (SIP)",
draft-peterson-rai-rfc3427bis-00 (work in progress),
February 2008.
[I-D.ietf-mmusic-sdp-capability-negotiation]
Andreasen, F., "SDP Capability Negotiation",
draft-ietf-mmusic-sdp-capability-negotiation-08 (work in
progress), December 2007.
Author's Address
Jonathan Rosenberg
Cisco
Iselin, NJ
US
Email: jdrosen@cisco.com
URI: http://www.jdrosen.net
Rosenberg Expires April 29, 2009 [Page 13]
Internet-Draft Modest Proposal October 2008
Full Copyright Statement
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
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Rosenberg Expires April 29, 2009 [Page 14]
| PAFTECH AB 2003-2026 | 2026-04-23 15:09:37 |