One document matched: draft-burger-sip-info-01.txt
Differences from draft-burger-sip-info-00.txt
SIP E. Burger
Internet-Draft BEA Systems, Inc.
Updates: RFC 2976 August 7, 2007
(if approved)
Intended status: Standards Track
Expires: February 8, 2008
Session Initiation Protocol (SIP) INFO Method Use
draft-burger-sip-info-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
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 February 8, 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 February 8, 2008 [Page 1]
Internet-Draft INFO Use August 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 call establishment signaling,
as 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 dialed digits for ISUP or other call
setup
o Transport of user stimulus to proxies and UAs
o Transport of generic DTMF digit entry
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, also known as SIP-T. ECMA-
355 describes a similar use of INFO for QSIG. RFC 4722 [5] describes
a use of INFO for media server control.
Clearly, there must be some advantages to using INFO, or people would
not be using it. First and foremost, for many of these uses, INFO
was the only option at the time. For example, MSCML's inception
predated SUBSCRIBE/NOTIFY by 18 months. Moreover, one of the driving
Burger Expires February 8, 2008 [Page 2]
Internet-Draft INFO Use August 2007
concepts in MSCML is the concept of doing an operation on "this" leg.
It is much easier to send a message on the SIP dialog, following an
already established routing path, than to establish another end-to-
end communication channel, such as a new SIP dialog, and referencing
the target dialog.
One advantage of using any method in the signaling plane is reliable
delivery. A common service provider customer service issue is end
user devices not being able to transmit DTMF tones reliably across
the service network. This is because the media plane does not have
reliable delivery characteristics. This is by design, as the goal is
to trade-off network latency and jitter for reliable packet delivery.
Another advantage is that if the endpoint is only interested in the
user signaling, they only need a signaling stack and access to the
much lower packet rate signaling channel, as opposed to having a
media stack and receiving all of the media.
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, where one entity
controls the endpoints. For example, 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 be scaled to receive media server control messages, as that
can be independent of subscriber size (call volume). Furthermore, a
Voice-over-IP service provider may supply or strictly mandate the
manufacturer and firmware for customer-premises equipment such as
terminal adapters. 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 covers 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
Burger Expires February 8, 2008 [Page 3]
Internet-Draft INFO Use August 2007
argument saying the User Agent can figure it out. The content of the
INFO request will have a MIME type. For example, SIP-T [6] messages
will have a MIME type of application/ISUP, while MSCML [5] messages
will have a MIME type of application/mediaservercontrol+xml.
Likewise, the endpoints can negotiate what MIME types they support,
thus advertising their capabilities.
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 message sent by mistake.
In addition, there are times when an endpoint will be hosting a
number of different applications, each looking for different DTMF
patterns. For example, a call management application may be looking
for a long "#", while a messaging application may be looking for
digits. Using INFO, or named tones, for that matter, each
application has to examine each digit. Using subscription-based
protocols such as KPML, one can limit the traffic and processing to
only the tones the application has interest.
For that matter, there are application scenarios where an application
separate from the endpoint needs to monitor for user stimulus. For
example, a calling card application might want to monitor for a re-
origination signal. Likewise, a lawful intercept trap and trace
application wants to monitor only the user's entered digits. With
the INFO method, that application must insert itself in the signaling
path. This requires the application to become a Back-to-Back User
Agent (B2BUA), which means that it must handle all of the state
transactions in the dialogs, as well as intrusively be in the call
path.
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, is one may wish the request to traverse the proxy.
The problem is there is no way for proxies to know whether or not
they have an interest in INFO requests. Getting the requests is an
all-or-nothing proposition, driven by Record-Route.
Let us consider these issues with respect to DTMF transport.
First of all, if the end device is using a compressed codec, the
Burger Expires February 8, 2008 [Page 4]
Internet-Draft INFO Use August 2007
device will most likely use named tones [8]. If the device also
sends DTMF in INFO messages, the device will be sending the digits
multiple times. This would not be a problem if the endpoints could
negotiate the use of INFO for DTMF transport. If they could, then
each device would know to ignore the named tone packets, which do not
have reliable delivery characteristics. However, since there is no
negotiation, the endpoints have to assume, when they receive a named
tone packet, the packet represents DTMF user stimulus. When an INFO
arrives with DTMF in it, the endpoint will double detect the digit.
One might argue that upon receipt of an INFO message with DTMF in it,
the recipient could ignore named tone packets in the media stream.
However, in almost all scenarios, the media stream will reach the end
device well before an INFO will. A negotiation mechanism would solve
this problem. If the endpoints explicitly agree to transport user
signaling in the signaling channel, then they can safely ignore named
tones in the media stream.
Unless the signaling path is secure, using S/MIME or sips, user digit
entry is in the clear. This has clear security and privacy
implications with respect to credit card numbers, account numbers,
personal identification numbers, and so on.
One argument often heard for using INFO for DTMF is that it is easy
and does not use very much bandwidth. However, studies of, for
example, KPML versus INFO for DTMF [9], show significantly better
bandwidth utilization for KPML [10], even with the supposed overhead
of the SUBSCRIBE / NOTIFY [11] mechanism. This is because sending
tones digit-by-digit in an INFO message is very inefficient.
There is no throttling mechanism for INFO. Consider that most call
signaling occurs on the order of 3 messages per minute. DTMF tones
occur in bursts at a rate of 240 messages per minute. This is a
considerably higher rate than for call signaling.
3. INFO Alternatives
What alternatives to INFO are there for 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
Burger Expires February 8, 2008 [Page 5]
Internet-Draft INFO Use August 2007
3.1. State Updates
This is the broad class of one User Agent updating another with
changes in state. The design goal of the SUBSCRIBE/NOTIFY [11] event
framework is to meet just this need.
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 [10].
3.3. Direct Signaling Channel
State updates and user stimulus tend to have relatively few messages
per session. Sometimes, User Agents need to exchange 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 [12] or MRCPv2 [13] is appropriate.
In addition, not every situation requires a SIP solution. Some
signaling is really just one-shot to third-party endpoints. That
situation may better be handled using an appropriate protocol, such
as HTTP [14].
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
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
Burger Expires February 8, 2008 [Page 6]
Internet-Draft INFO Use August 2007
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].
3.5. Example: Malicious Indicator
Take the case of Malicious Indicator. This is where a subscriber
receives a call, realizes it is a malicious call (threatening, SPIT,
etc.). They then press the SPIT button (or press *xx), which tells
their service provider to mark the UAC as a bad actor. One might be
tempted to think that INFO would be a great option for this service.
It follows the return path of the INVITE, and so the INFO will hit
the caller's inbound proxy, which it can learn the caller is
(statistically) a bad actor. That way the inbound proxy can do stuff
like notify law enforcement, add a vote to "this is a SPIT source,"
or other useful action.
However, consider a few issues. First, since INFO lives exclusively
within an established dialog, there is no way to assert this message
after the call completes. Second, this mechanism *relies* on an
active service provider topology. If there is no proxy in the chain
that will eat the INFO, the caller will see the "this is a bad guy"
message, which may have consequences in the real world. Third, there
is no a'priori way for the UAS to know whether or not it can issue
the INFO. The caller CERTAINLY will not advertise, "please tell me
if I am bad, particularly I know in advance that I *am* a bad actor."
One approach is for the service provider's proxy to SUBSCRIBE for the
SPIT event at the UAS. At this point, life is good, interoperable,
and works across networks. This enables events after the dialog is
torn down, as presumably the SPIT event will refer not to, "this
dialog," which does not exist, but to "that dialog identifier," which
exists (and is theoretically unique) forever.
Another approach that saves considerably on the overhead of
subscriptions would be for the service provider to insert a HTTP URI
in the initial INVITE, noting it is for reporting malicious behavior.
When the subscriber presses the SPIT button, an HTTP POST gets
executed, delivering the call information to the service provider.
The service provider can encode basic call information in the HTTP
URI and can instruct the device to send whatever arbitrary data is
necessary in the POST. This method has the added benefit of being
entirely outside the real-time SIP proxy network.
Burger Expires February 8, 2008 [Page 7]
Internet-Draft INFO Use August 2007
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 [4] for ISUP and ECMA-355 for QSIG.
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 proliferation 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
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.
[4] Vemuri, A. and J. Peterson, "Session Initiation Protocol for
Telephones (SIP-T): Context and Architectures", BCP 63,
Burger Expires February 8, 2008 [Page 8]
Internet-Draft INFO Use August 2007
RFC 3372, September 2002.
7.2. Informative References
[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] Schulzrinne, H. and T. Taylor, "RTP Payload for DTMF Digits,
Telephony Tones, and Telephony Signals", RFC 4733,
December 2006.
[9] Burger, E., "A Novel System for Remote Control of Household
Devices Using Digital IP Phones", Transactions on Consumer
Electronics 52(2), May 2006.
[10] Burger, E. and M. Dolly, "A Session Initiation Protocol (SIP)
Event Package for Key Press Stimulus (KPML)", RFC 4730,
November 2006.
[11] Roach, A., "Session Initiation Protocol (SIP)-Specific Event
Notification", RFC 3265, June 2002.
[12] Campbell, B., , R., and C. Jennings, "The Message Session Relay
Protocol", draft-ietf-simple-message-sessions-19 (work in
progress), February 2005.
[13] Shanmugham, S. and D. Burnett, "Media Resource Control Protocol
Version 2 (MRCPv2)", draft-ietf-speechsc-mrcpv2-12 (work in
progress), March 2005.
[14] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L.,
Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol --
HTTP/1.1", RFC 2616, June 1999.
Appendix A. Acknowledgements
Standing on the shoulders of giants. Jonathan Rosenberg did the
original "INFO Considered Harmful" on Inernet Draft on 26 December
2002, which influenced the work group and this document. Likewise,
Dean Willis influenced the text from his Internet Draft, "Packaging
Burger Expires February 8, 2008 [Page 9]
Internet-Draft INFO Use August 2007
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!
John Elwell and Francois Audet helped with QSIG references. Adam
Roach, Dale Worley, Dean Willis, Hadriel Kaplan, Jeroen van Bemmel,
Johnathan Rosenberg, Martin Dolly, Paul Kyzivat, Roland Jesske, Sam
Ganesan, Spencer Dawkins, and Xavier Marjou gave valuable feedback,
commentary and suggested text. Christer Holmberg provided numerous
counter examples that helped hone the message of this document.
Author's Address
Eric W. Burger
BEA Systems, Inc.
USA
Email: eburger@standardstrack.com
URI: http://www.standardstrack.com
Burger Expires February 8, 2008 [Page 10]
Internet-Draft INFO Use August 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 February 8, 2008 [Page 11]
| PAFTECH AB 2003-2026 | 2026-04-23 03:56:18 |