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 30, 2009.

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.

Table of Contents

1.  Introduction
2.  The SIP Implementation Gap
3.  Implications of the Gap
    3.1.  Low Adoption Rate of Specifications
    3.2.  Unaddressed Problems
    3.3.  Declining Participation
4.  A Modest Proposal
    4.1.  Recognize the Realities
    4.2.  Effort Proportional to Deployments
    4.3.  Less is More
5.  Conclusion
6.  Security Considerations
7.  Acknowledgements
8.  Informational References
§  Author's Address
§  Intellectual Property and Copyright Statements

1.  Introduction

The Session Initiation Protocol (SIP) [RFC3261] (Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, “SIP: Session Initiation Protocol,” June 2002.), 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 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:

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] (Rosenberg, J., “Obtaining and Using Globally Routable User Agent (UA) URIs (GRUU) in the Session Initiation Protocol (SIP),” October 2007.) 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] (Hilt, V., Camarillo, G., and J. Rosenberg, “A Framework for Session Initiation Protocol (SIP) Session Policies,” February 2010.) and related specifications [I‑D.ietf‑sipping‑media‑policy‑dataset] (Hilt, V., Worley, D., Camarillo, G., and J. Rosenberg, “A User Agent Profile Data Set for Media Policy,” March 2010.), [I‑D.ietf‑sipping‑policy‑package] (Hilt, V. and G. Camarillo, “A Session Initiation Protocol (SIP) Event Package for Session-Specific Session Policies.,” March 2010.), 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] (Peterson, J. and C. Jennings, “Enhancements for Authenticated Identity Management in the Session Initiation Protocol (SIP),” August 2006.) 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 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] (Burger, E. and M. Dolly, “A Session Initiation Protocol (SIP) Event Package for Key Press Stimulus (KPML),” November 2006.)), 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.

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] (Rosenberg, J. and H. Schulzrinne, “Guidelines for Authors of Extensions to the Session Initiation Protocol (SIP),” May 2006.) to reference the above informative document, and based on it, present additional guidelines - e.g., take into account SBCs, and so on.
3. The RAI area revise RFC 3427 [RFC3427] (Mankin, A., Bradner, S., Mahy, R., Willis, D., Ott, J., and B. Rosen, “Change Process for the Session Initiation Protocol (SIP),” December 2002.) (the SIP change process). Work was begun on this [I‑D.peterson‑rai‑rfc3427bis] (Peterson, J., Jennings, C., and R. Sparks, “Change Process for the Session Initiation Protocol (SIP) and the Real- time Applications and Infrastructure Area,” October 2009.), 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.

     |
     |
     |
     |
     |                                  SIP
  A  |
  d  |                                   |
  o  |                                   |
  p  |                                   |
  t  |                                   V
  i  |                        **********
  o  |                      **   |     **
  n  |                    **     |      **
     |                   **      |       **
     |                  *        |        **
     |                 **        |         *
     |                 *         |         **
     |                **         |          *
     |               **          |          **
     |             **            |           **
     |           *** |           |          | ***
     |         ***   |           |          |    ***
     |       ***     | Early     |  Late    |      **********
     | ******* Early | Majority  |  Majority|                ***
     |      |Adopter |           |          |  Laggards
     |
  ---+---------------------------------------------------------
     |
     |                    time

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:

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.

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] (Channabasappa, S., “A Framework for Session Initiation Protocol User Agent Profile Delivery,” February 2010.). 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] (Andreasen, F., “SDP Capability Negotiation,” March 2010.). 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.

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

Author's Address

Full Copyright Statement

Copyright © 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.