One document matched: draft-burger-sip-info-00.txt
SIP E. Burger
Internet-Draft BEA Systems, Inc.
Updates: RFC 2976 July 1, 2007
(if approved)
Intended status: Standards Track
Expires: January 2, 2008
Session Initiation Protocol (SIP) INFO Method Context
draft-burger-sip-info-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 January 2, 2008.
Copyright Notice
Copyright (C) The IETF Trust (2007).
Abstract
The purpose of the INFO request for the Session Initiation Protocol
(SIP), as described by RFC 2976, is to provide mid-session SIP User
Agent (UA)-to-SIP UA application data transport. In the years since
the introduction of the INFO request, experience with the use of the
INFO request indicates a number of problems. This document explains
why there are INFO-based, proprietary protocols in the wild; the
Burger Expires January 2, 2008 [Page 1]
Internet-Draft INFO Context July 2007
flaws of using INFO; and explains why it is not possible to create a
framework to rescue INFO for general purpose use. Thus, this
document restricts the use of INFO to that described in RFC 3372
(SIP-T).
Conventions Used in this Document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [1].
The snippets of ABNF assume the definitions found in SIP [2].
1. Introduction
There is a need for mid-session, Session Initiation Protocol (SIP)
User Agent (UA)-to-SIP User Agent session layer signaling. Examples
of such signaling include the following.
o Transporting foreign, non-SIP protocol messages for ISUP call
setup
o Transport of supplemental dialled digits for ISUP or other call
setup
o Transport of user stimulus to proxies and UAs
o SIP media server control
o SIP video encoding control
o SIP floor control
o Transport of application-specific data
The INFO [3] request transports mid-session signaling between two
User Agents. These messages follow the signaling path established by
the SIP INVITE, including visiting proxies that inserted themselves
in the Record-Route path.
All of the examples above have implementations using the INFO
request. There have been numerous Internet Drafts proposing the
transport of DTMF using INFO. Likewise, there have been Internet
Drafts describing the use of INFO for video encoding control (such as
fast frame refresh requests) and conference floor control. RFC 3372
[4] describes the use of INFO for ISUP and QSIG, also known as SIP-T.
RFC 4722 [5] describes a use of INFO for media server control.
It is clear there are existence proofs for the use of INFO. However,
there is a serious flaw with the INFO request. The INFO request
itself has neither a context for interpreting any given message nor a
negotiation method for accepting different INFO request types. One
of the main reasons why INFO appears to work is most of the uses to
date have been in limited or controlled deployments. For example,
Burger Expires January 2, 2008 [Page 2]
Internet-Draft INFO Context July 2007
application servers, in a session with a media server, will not
expect to receive user stimulus. Likewise, a routing proxy, such as
the 3GPP IMS S-CSCF, will not expect to receive media server control
messages. However, with the further adoption of SIP, such collisions
and misinterpretation of context becomes highly likely.
This document first describes the flaws with INFO. Then it offers
alternatives for INFO that cover most of the use cases for which the
work group has seen Internet Drafts in the past. This document
describes how one can unambiguously create application session
signaling that does require proxy traversal by using new SIP methods.
Lastly, this document formally restricts the use of INFO to that
described by RFC 3372 [4].
2. Flaws With INFO
There is no programmatic way of determining what the content of an
INFO request means. From the User Agent's point of view, a INFO
request appears. Is this INFO request conveying a DTMF digit, a
SIP-T encapsulated message, or a video update request? There is an
argument saying the User Agent can figure it out. The content of the
INFO request will have a MIME type. For example, SIP-T messages will
have a MIME type of application/ISUP [6], while MSCML messages will
have a MIME type of application/mediaservercontrol+xml.
However, as we learned in the messaging community [7], relying on the
MIME type alone is not sufficient to determine the context of the
message. Clearly, as shown in the previous paragraph, the message
content type relates to the message context. However, it is quite
easy to imagine situations where the same content type has multiple
meanings for a User Agent. For example, a DTMF digit type could be
for user stimulus, post-dial digit collection, simple transport of a
digit (no signaling context), or a mistake.
An interesting issue is every INFO request traverses the same proxy
path as any other dialog-related SIP request. Proxies in the path
that have no interest in INFO requests still must process the
request. This may put undue load on those proxies. What makes this
issue interesting, and not necessarily a proxy, is one may wish the
request to traverse the proxy. The problem is there is no way for
proxies to not whether or not they have an interest in INFO requests.
Getting the requests is an all-or-nothing proposition, driven by
Record-Route.
Burger Expires January 2, 2008 [Page 3]
Internet-Draft INFO Context July 2007
3. INFO Alternatives
What if you think you need UA-to-UA application session signaling?
There are four broad classes of session signaling available. The
choice depends on the circumstances.
o State updates
o User stimulus
o Direct signaling channel
o Proxy-aware signaling
3.1. State Updates
This is the broad class of one User Agent updating another with
changes in state. Clearly, state updates are the provenance of the
SUBSCRIBE/NOTIFY [8] event framework.
3.2. User Stimulus: Touch Tones and Others
This is the class of the user entering stimulus at one User Agent,
and the User Agent transporting that stimulus to the other. A key
thing to realize is key presses on the telephone keypad is user
stimulus. Thus, the appropriate mechanism to use here is KPML [9].
3.3. Direct Signaling Channel
State updates and user stimulus tend to have relatively few messages
per session. Sometimes, User Agents have a need for exchanging a
relatively high number of messages. In addition, User Agents may
have a need for a relatively low-latency exchange of messages. In
this latter case, the User Agent may not be able to tolerate the
latency introduced by intermediate proxies. Likewise, the
intermediate proxies may have no interest in processing all of that
data.
In this case, establishing a separate, direct control channel, as in
MSRP [10] or MRCPv2 [11] is appropriate.
3.4. Proxy-Aware Signaling
Sometimes, one does want proxies to be in the signaling path for UA-
to-UA application signaling. In this case, the use of a SIP request
is appropriate. To date, there are no mechanisms for completely
disambiguating INFO requests. For example, one could create a
registry of INFO packages. The definition of the package would
define the contexts for the various MIME Content-Types, as well as
the context of the request itself. However, a package can have
multiple content types. Moreover, having the context, or package
identifier, at the SIP level precludes bundling multiple contexts
Burger Expires January 2, 2008 [Page 4]
Internet-Draft INFO Context July 2007
responding in the same INFO request. For example, a User Agent might
want to bundle two different responses in a multipart/mixed MIME body
type.
Because there is no difference in either the protocol machinery or
registration process due to these factors, we will not create an INFO
framework. If one needs a SIP User Agent-to-SIP User Agent
application session signaling transport protocol that touches all
Record-Route proxies in a path, one MUST create a new SIP method as
described in Section 27.4 of RFC 3261 [2].
4. INFO Use Clarification
There is no way to unambiguously use the INFO request in a general
framework. The IETF has already standardized use of INFO for SIP-T
[4]. Thus we will not deprecate the use of INFO for that purpose.
However, this document explicitly updates INFO [3], in that one MUST
NOT use the INFO request for anything other than the use described by
SIP-T.
In recognition of existing, proprietary use of INFO, proxies MUST NOT
take any action other than that described by RFC 3261 and RFC 2976
with respect to handling INFO requests.
OPEN ISSUE: Do we bow to reality, and say, "INFO is the Port 80 of
the 2000's. SBC's will never keep up with newly minted SIP method
requests, so we keep INFO so we can have a poliferation of
protocols tunneled over SIP?"
5. Security Considerations
By eliminating the multiple uses of INFO messages without adequate
community review, and by eliminating the possibility for rogue SIP
User Agents from confusing another User Agent by purposely sending
unrelated INFO messages, we expect the INFO use clarification to
improve the security of the Internet.
6. IANA Considerations
None.
7. References
Burger Expires January 2, 2008 [Page 5]
Internet-Draft INFO Context July 2007
7.1. Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", RFC 2119, BCP 14, March 1997.
[2] 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.
[3] Donovan, S., "The SIP INFO Method", RFC 2976, October 2000.
7.2. Informative References
[4] Vemuri, A. and J. Peterson, "Session Initiation Protocol for
Telephones (SIP-T): Context and Architectures", BCP 63,
RFC 3372, September 2002.
[5] Van Dyke, J., Burger, E., and A. Spitzer, "Media Server Control
Markup Language (MSCML) and Protocol", RFC 4722, November 2006.
[6] Zimmerer, E., Peterson, J., Vemuri, A., Ong, L., Audet, F.,
Watson, M., and M. Zonoun, "MIME media types for ISUP and QSIG
Objects", RFC 3204, December 2001.
[7] Burger, E., Candell, E., Eliot, C., and G. Klyne, "Message
Context for Internet Mail", RFC 3458, January 2003.
[8] Roach, A., "Session Initiation Protocol (SIP)-Specific Event
Notification", RFC 3265, June 2002.
[9] Burger, E. and M. Dolly, "A Session Initiation Protocol (SIP)
Event Package for Key Press Stimulus (KPML)", RFC 4730,
November 2006.
[10] Campbell, B., , R., and C. Jennings, "The Message Session Relay
Protocol", draft-ietf-simple-message-sessions-19 (work in
progress), February 2005.
[11] Shanmugham, S. and D. Burnett, "Media Resource Control Protocol
Version 2 (MRCPv2)", draft-ietf-speechsc-mrcpv2-12 (work in
progress), March 2005.
Appendix A. Acknowledgements
Standing on the shoulders of giants. Jonathan Rosenberg did the
original "INFO Considered Harmful" on 26 December 2002, which
influenced the work group and this document. Likewise, Dean Willis
Burger Expires January 2, 2008 [Page 6]
Internet-Draft INFO Context July 2007
influenced the text from his "Packaging and Negotiation of INFO
Methods for the Session Initiation Protocol" of 15 January 2003. My,
we have been working on this for a long time!
Author's Address
Eric W. Burger
BEA Systems, Inc.
USA
Email: eburger@standardstrack.com
URI: http://www.standardstrack.com
Burger Expires January 2, 2008 [Page 7]
Internet-Draft INFO Context July 2007
Full Copyright Statement
Copyright (C) The IETF Trust (2007).
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).
Burger Expires January 2, 2008 [Page 8]
| PAFTECH AB 2003-2026 | 2026-04-23 09:35:22 |