One document matched: draft-kaplan-sip-info-events-01.txt
Differences from draft-kaplan-sip-info-events-00.txt
SIP Working Group H. Kaplan
Internet Draft Acme Packet
Intended status: Standards Track C. Holmberg
Expires: August 25, 2008 Ericsson
E. Burger
BEA Systems, Inc.
February 25, 2008
The SIP INFO Method and Info Package Framework
draft-kaplan-sip-info-events-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/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 August 25, 2008.
Copyright Notice
Copyright (C) The IETF Trust (2008).
Kaplan, et al. Expires August 25, 2007 [Page 1]
The SIP INFO Method and Info Packages February 2008
Abstract
This document defines the INFO method and a mechanism for defining,
negotiating and exchanging Info Packages in it. INFO requests are
used within SIP INVITE-created dialogs, for applications which need
to exchange session-related information inside the INVITE-created
dialog. This draft addresses issues and open items from RFC 2976,
and replaces it.
Table of Contents
1. Introduction..........................................3
1.1. Background............................................4
2. Terminology...........................................4
3. Applicability.........................................5
4. The INFO Method Request...............................5
4.1. Responses to the INFO Request Method..................6
4.2. Message Body Inclusion................................6
4.3. Behavior of SIP User Agents...........................7
4.4. Behavior of SIP Proxy and Redirect Servers............7
4.4.1 Proxy Server..........................................7
4.4.2 Forking Proxy Server..................................7
4.4.3 Redirection Server....................................7
4.5. INFO Message Bodies...................................7
5. Info Package Negotiation..............................8
5.1. Info Package Negotiation Overview.....................8
5.2. UAC Behavior..........................................8
5.3. UAS Behavior..........................................9
6. General..............................................10
6.1. Re-Invites and usages and forks, oh my!..............10
6.2. Detecting support for INFO and Info Packages.........11
7. Legacy Uses of INFO..................................11
8. Info Packages........................................12
8.1. Appropriateness of Usage.............................12
8.1.1 Dialog Fate-Sharing..................................12
8.1.2 Messaging Rates and Volume...........................13
8.1.3 Proxy-path Signaling.................................13
8.1.4 Is there a better alternative?.......................13
8.2. Info Package Responsibilities........................14
8.2.1 Info Package Name....................................14
8.2.2 Info Package Parameters..............................14
8.2.3 INFO Bodies..........................................14
8.2.4 UA generation of INFO requests.......................15
8.2.5 UA processing of INFO requests.......................15
8.2.6 Rate of notifications................................15
8.2.7 Examples.............................................15
9. Syntax...............................................15
9.1. New Method...........................................16
9.1.1 INFO Method..........................................17
Kaplan, et al. Expires - August 2008 [Page 2]
The SIP INFO Method and Info Packages February 2008
9.2. New Headers..........................................17
9.2.1 "Info-Package" header................................17
9.2.2 "Send-Info" header...................................18
9.2.3 "Recv-Info" header...................................18
9.3. Augmented BNF Definitions............................18
10. Example Exchange.....................................19
11. Security Considerations..............................20
12. IANA Considerations..................................20
13. Acknowledgements.....................................20
14. References...........................................21
14.1. Normative References.................................21
14.2. Informative References...............................21
Authors' Addresses..........................................22
Full Copyright Statement....................................23
Intellectual Property Statement.............................23
Acknowledgment..............................................23
1. Introduction
The SIP protocol described in [RFC3261] defines session control
messages used during the setup and tear down stages of a SIP
controlled session. In addition, the SIP re-INVITE and UPDATE can
be used during a session to change the characteristics of the
session. This is generally to change the properties of media flows
related to the session or to update the SIP session timer per
[RFC4028]. The purpose of the INFO message, on the other hand, is
to carry application level information along the SIP signaling path.
The INFO method is not used to change the state of SIP calls, or the
parameters of the sessions SIP initiates. It merely sends optional
application layer information, generally related to the session.
It is necessary that the mid-dialog signaling information traverse
the post session setup SIP signaling path. This is the path taken
by SIP re-INVITEs, BYEs and other SIP requests that are tied to an
individual dialog. This allows SIP proxy servers to receive, and
potentially act on, the mid-dialog signaling information. The SIP
INFO method was defined in [RFC2976] to convey such session related
control information inside an INVITE-created dialog. This draft is
meant to replace [RFC2976] SIP INFO.
While INFO use has been widely adopted for specific application use
cases, such as ISUP and DTMF exchange, the original RFC did not
define a negotiation mechanism nor a means by which to explicitly
indicate the type of application information contained in the INFO.
This led to problems associated with static configuration, and
potential interoperability problems due to undefined content syntax
and semantics. This draft aims at addressing those deficiencies, to
Kaplan, et al. Expires - August 2008 [Page 3]
The SIP INFO Method and Info Packages February 2008
provide a framework for explicit negotiation of capabilities and
content context using "Info Packages".
This document does not describe any specific Info Package type
extensions which may be used directly; it must be extended by other
documents (herein referred to as "Info Packages"). In object-
oriented design terminology, it may be thought of as an abstract
base class which must be derived into an instantiated class by
further extensions. Guidelines for creating these extensions are
described in section 8.
1.1. Background
The INFO method as defined in [RFC2976] did not provide any context
for the information which it carries. While it may sometimes be
clear what the content is, based on the Content-Type, such is only
true while only one contextual usage of the content-type is ever
employed. For example, if the Content-Type were "image/jpeg", it
would be clear that the MIME-attached content was a JPEG image, but
not what its purpose was. It could be being sent as a caller-id
picture, or as a contact-icon, or whatever. The sender is not sure
which JPEG to give the receiver if it supports a JPEG content-type,
and the receiver does not know which JPEG is being sent if it
supports receiving more than one. Thus there needs to be a well-
defined and documented statement of what the information sent is
for. Event Packages, as defined in [RFC3265] perform that role for
Subscription-based events, whereas this document provides a similar
framework for INVITE-based information exchange. However this
document does NOT use the Events Package semantics of Subscriptions,
and is wholly unrelated to [RFC3265].
Unlike [RFC3265], the mechanism defined in this draft is not based
on the usage of the SUBSCRIBE and NOTIFY methods, and does not
create a separate subscription dialog or a subscription usage within
an existing dialog. Instead, it uses the INVITE method and its
responses to indicate and negotiate supported Info Packages, and the
INFO method to convey the Info Packages. This mechanism is not
appropriate for IANA-registered Subscribe Event package types, and
support for this mechanism should be explicitly indicated in future
Info Package definitions and registrations.
2. Terminology
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. The
terminology in this document conforms to RFC 2828, "Internet
Security Glossary".
Kaplan, et al. Expires - August 2008 [Page 4]
The SIP INFO Method and Info Packages February 2008
3. Applicability
This draft proposes replacing the [RFC2976] SIP INFO method document
to include explicit negotiation of supported Info Packages in the
INVITE transaction, and indication of the indicated Info Package
using a new header field in the INFO request.
4. The INFO Method Request
The INFO method is used for communicating mid-session signaling
information along the signaling path for the call. The INFO method
is not used to change the state of SIP calls, nor does it change the
state of sessions initiated by SIP. Rather, it provides additional
optional information which can further enhance the application using
SIP. There are some types of application information for which
using INFO messages is inappropriate - a discussion of this can be
found in section 8.1.
This draft creates a new, mandatory header field for INFO requests:
the "Info-Package" header field. The "Info-Package" header field
value in an INFO request will contain a single Info Package token
name which is being signaled by the INFO request. The token in the
"Info-Package" header field value MUST match one of the Info Package
tokens received in the "Recv-Info" header field value in the
received INVITE for the UAS, or response for the UAC. In other
words one can only send what the other end is willing to receive.
The INFO method can only be used within an INVITE-generated dialog
(early or full) and usage. It has no lifetime or usage of its own,
as it is inexorably linked to that of the INVITE. When the INVITE-
created dialog is terminated, the lifetime of the negotiated Info
Packages is also terminated. Any INFO message received after a BYE
or CANCEL has been sent MUST be responded to with a 481 Call Does
Not Exist.
The dialog identifiers defined in [RFC3261] must match those of the
provisional or final responses to the INVITE, and as a result INFO
requests do not fork. INFO requests may be sent in either
direction, once the UAC or UAS has received the Send-Info/Recv-Info
header field value indications of what the far-end supports. For
the UAS, it MUST receive the ACK for the INVITE's 200-ok, or the
PRACK for a provisional response, before sending an INFO request.
In other words it must know the far-end UAC has received its
indication of what Info Packages it is willing to send before it
sends them.
The signaling path for the INFO method is the signaling path
established as a result of the call setup. This can be either
Kaplan, et al. Expires - August 2008 [Page 5]
The SIP INFO Method and Info Packages February 2008
direct signaling between the calling and called user agents or a
signaling path involving SIP proxy servers that were involved in the
call setup and added themselves to the Record-Route header on the
initial INVITE message.
The mid-session information can be communicated in either an INFO
message header or as part of an INFO message body. The definition
of the message body and/or message headers used to carry the mid-
session information is defined by the specific named Info Package
definition. The semantics are derived from the specific Info
Package extension documented for usage in INFO.
4.1. Responses to the INFO Request Method
If a server receives an INFO request it MUST send a final response.
A 200 OK response MUST be sent by a UAS for an INFO request with no
message body if the INFO request was successfully received for an
existing call. Beyond that, no additional operations are
required.
A 481 Call Leg/Transaction Does Not Exist message MUST be sent by a
UAS if the INFO request does not match any existing call leg.
If a server receives an INFO request with a body it understands, but
it has no knowledge of Info Package associated processing rules for
the body, the body MAY be rendered and displayed to the user. The
INFO is responded to with a 200 OK.
If the INFO request contains a body that the server does not
understand then, in the absence of Info Package associated
processing rules for the body, the server MUST respond with a 415
Unsupported Media Type message.
If the INFO request indicates an Info Package type that the server
does not understand, then the server MUST respond with a [TBD: 405
or 501 seem most appropriate, and do not terminate the INVITE
dialog].
Bodies which imply a change in the SIP call state or the sessions
initiated by SIP MUST NOT be sent in an INFO message. Other request
failure (4xx), Server Failure (5xx) and Global Failure (6xx)
responses MAY be sent for the INFO Request.
4.2. Message Body Inclusion
The INFO request MAY contain a message body, which MUST be specified
by the Info Package type extension document. INFO bodies are
expected to provide additional details about the nature of the
Kaplan, et al. Expires - August 2008 [Page 6]
The SIP INFO Method and Info Packages February 2008
information being exchanged and the resultant resource state, if
any.
4.3. Behavior of SIP User Agents
Unless stated otherwise, the protocol rules for the INFO request
governing the usage of tags, Route and Record-Route, retransmission
and reliability, CSeq incrementing and message formatting follow
those in [RFC3261] as defined for the BYE request.
An INFO request MAY be cancelled. A UAS receiving a CANCEL for an
INFO request SHOULD respond to the INFO with a "487 Request
Cancelled" response if a final response has not been sent to the
INFO and then behave as if the request were never received.
However, the INFO message MUST NOT change the state of the SIP call,
or the INVITE sessions initiated by SIP. The only exception to this
rule is for specific failure responses as documented in [RFC5057],
which may cause the INVITE dialog to terminate.
4.4. Behavior of SIP Proxy and Redirect Servers
[Do we still need to handle 3 different types of Proxies this way?
This is from RFC2976]
4.4.1 Proxy Server
Unless stated otherwise, the protocol rules for the INFO request at
a proxy are identical to those for a BYE request as specified in
[RFC3261].
4.4.2 Forking Proxy Server
Unless stated otherwise, the protocol rules for the INFO request at
a proxy are identical to those for a BYE request as specified in
[RFC3261].
4.4.3 Redirection Server
Unless stated otherwise, the protocol rules for the INFO request at
a proxy are identical to those for a BYE request as specified in
[RFC3261].
4.5. INFO Message Bodies
The purpose of the INFO message is to carry mid-session information
between SIP user agents. This information will generally be carried
Kaplan, et al. Expires - August 2008 [Page 7]
The SIP INFO Method and Info Packages February 2008
in message bodies, although it can be carried in headers in the INFO
message.
The definition of the message bodies or any new headers created for
the INFO method MUST be defined by separately documented Info
Package extensions. Info Packages MUST define semantics associated
with the body of their INFO requests.
In addition, the INFO method does not define additional mechanisms
for ensuring in-order delivery. While the CSeq header will be
incremented upon the transmission of new INFO messages, this should
not be used to determine the sequence of INFO information. This is
due to the fact that there could be gaps in the INFO message CSeq
count caused by a user agent sending re-INVITES or other SIP
messages.
5. Info Package Negotiation
5.1. Info Package Negotiation Overview
The general concept is that the UAC generating an INVITE request
includes the Info Package types it supports sending and receiving,
in two new header fields: Send-Info and Recv-Info. If the UAS
supports this mechanism, it responds with the Info Packages it
wishes to actually receive and send in the same named header fields
(in reverse), in the provisional and final responses. When either
side has indication of what the far-end supports, it may send the
information defined by the Info Packages in an INFO request,
following the same INVITE-created dialog and usage. The INFO
request indicates the specific Info Package it is associated with,
using an "Info-Package" header field with the Info Package type
name, and any associated MIME-attached body defined for that Info
Package.
The UAC and UAS MUST negotiate which Info Packages are supported and
will be used in which direction, before sending an INFO message for
any specific Info Package. Negotiation always starts with the UAC
indicating which Info Packages it supports and wishes to send or
receive, using the two new header fields "Send-Info" and "Recv-
Info", in the INVITE request. The UAS always indicates which Info
Packages, of those offered by the UAC, it wishes to accept for
sending and receiving to/from the UAC in its responses.
5.2. UAC Behavior
A UAC supporting this draft MAY indicate one or more Info Packages
it wishes to support sending during the Invite dialog, by including
their RFC-defined names in the "Send-Info" header field value in the
INVITE request. Not including the Send-Info header field in the
Kaplan, et al. Expires - August 2008 [Page 8]
The SIP INFO Method and Info Packages February 2008
INVITE means the UAC does not have an intention, and MUST NOT, send
any Info Packages during the dialog.
The UAC MAY indicate one or more Info Packages it wishes to support
receiving during the Invite-created dialog, by including their Info
Package names in the "Recv-Info" header field in the INVITE request.
Not including the Recv-Info header field in the INVITE means the UAC
will not accept Info Packages during the dialog.
When the UAC receives a Recv-Info header field in any provisional
1xx or 2xx response, it is an indication from the far-end UAS that
it (the UAS) supports receiving the Info Packages indicated in the
header field value. Any indicated Info Packages in the Recv-Info
header field value from the UAS which were not offered by the UAC in
a Send-Info header field value MUST be ignored, and MUST NOT
constitute a protocol failure. In other words such mismatches do
not fail the negotiation - the extraneous Info Packages are merely
ignored.
When the UAC receives a Send-Info header field in any provisional
1xx or 2xx final response, it is an indication from the far-end UAS
that it (the UAS) supports sending Info Package(s) named in the
header field value. Any indicated Send-Info header field values
from the UAS which were not offered by the UAC in a Recv-Info header
field value MUST be ignored, and MUST NOT constitute a protocol
failure.
Once an early dialog is established, through a 1xx provisional
response with To-tags, and the UAC has received a Recv-Info header
field values from the UAS in the response, the UAC MAY send any Info
Packages supported by the UAS in an INFO message. The 2xx final
response updates the state of the supported Info Packages, such that
the 2xx contains the full and final list of Send-Info and Recv-Info
Info Packages. If the 2xx does not contain a Send-Info header
field, the UAS is indicating it will not send any, and if it does
not contain a Recv-Info header field, the UAS will not accept any,
regardless of what a previous 1xx response might have indicated. At
this point negotiation is considered complete.
5.3. UAS Behavior
When a UAS receives an INVITE request, it checks for a Send-Info and
Recv-Info header fields. One or both may exist. For each Info
Package name in the received Send-Info header field value, the UAS
decides if it wishes to accept receiving such Info Packages from the
UAC. If so, it MUST copy the type token name(s) of those acceptable
Info Packages into a Recv-Info header field value in any, and all
subsequent, provisional 1xx and final 2xx responses.
Kaplan, et al. Expires - August 2008 [Page 9]
The SIP INFO Method and Info Packages February 2008
For each Info Package name listed in the received Recv-Info header
field value, the UAS decides if it wishes to send such Info Packages
to the UAC. If so, it MUST copy the name(s) of those Info Packages
it wishes to generate into a Send-Info header field value in any,
and all subsequent, provisional 1xx and final 2xx responses.
Note that "any, and all subsequent," means that the UAS MAY decide
not to indicate any Info Packages in early 1xx responses; but once
it indicates such in a 1xx, it MUST continue to do so in subsequent
responses including the final 2xx response in order to keep the Info
Package support state the same. If the UAS no longer wishes to
support them after the provisional response, it MUST indicate such
by removing them from the Send-Info or Recv-Info header field values
in any subsequent provisional and the 2xx final response, and if no
Info Packages are remaining then by not including the appropriate
header field(s).
The UAS MUST NOT send any INFO messages with Info Packages until it
has received an acknowledgement (e.g. PRACK for a provisional
response, or an ACK for a final response it sent) that the UAC has
received the SIP response sent by the UAS, indicating that the UAC
has received the Send-Info header field values from the UAS. This
assures the UAC can perform any necessary logic it needs to in order
to receive the Info Package, and can associate the INFO message and
associated Info Package with the proper dialog.
NOTE: Unlike the NOTIFY method, the INFO method CAN NOT be used to
establish a dialog.
6. General
6.1. Re-Invites and usages and forks, oh my!
A Re-INVITE or UPDATE request MUST NOT contain any Send-Info or
Recv-Info header fields, and such header fields MUST be ignored on
reception. The Info Package negotiation is performed during the
initial INVITE transaction, and there is no re-negotiation.
[Is that ok? Is there a need to have re-negotiation? (is there a
use case?) It sure makes it simple not to have things change in the
middle of a session. Adam points out 3PCC needs it - TBD by SIP-WG]
There is no separate "usage" for the INFO request, as defined by
[RFC5057]. The INFO is related to but not integral to the Invite
usage, such that some failure responses to an INFO request do not
affect the INVITE usage whatsoever, as described in [RFC5057].
Other failures may terminate the usage or dialog completely. The
lifetime of Info Packages is exactly the same as that of the INVITE.
Kaplan, et al. Expires - August 2008 [Page 10]
The SIP INFO Method and Info Packages February 2008
If an INVITE usage fails or is terminated, the Info Package-based
state no longer exists, and an INFO request MUST NOT be sent.
The original INVITE request may be forked along the path, resulting
in multiple 1xx provisional responses, each with a separate set of
send/receive Info Packages supported. It is typically up to local-
policy to determine how to handle such situations, however it should
be clear that an INFO request does not itself fork, since it uses
the dialog identifiers and follows [RFC3261] and thus follows the
path to a specific fork.
6.2. Detecting support for INFO and Info Packages
INFO does not necessitate the use of "Require" or "Proxy-Require"
headers; similarly, there is no token defined for "Supported"
headers. If necessary, clients may probe for the support of INFO
using the OPTIONS request defined in SIP [RFC3261].
The presence of the "Send-Info" or "Recv-Info" header in a message
is sufficient to indicate support for INFO.
The "methods" parameter for Contact may also be used to
specifically announce support for INFO messages when
registering. (See [CALLER-PREFS] for details on the "methods"
parameter).
For Info Packages, this draft does not provide a means of requiring
support for a specific Info Package. If the far-end UA does not
indicate support for an Info Package that the local server requires,
the server MAY terminate the session with a CANCEL or BYE request.
[TBD: do we need a Require option-tag or similar mechanism?]
7. Legacy Uses of INFO
Several RFC-defined and other standards-defined uses of [RFC2976]
INFO exist and are in use, as well as numerous proprietary uses. By
definition, such uses have relied on either static local
configuration, or implicit context determination based on the body
Content-Type or Content-Disposition value, or some proprietary
mechanism. This draft cannot forbid nor avoid such uses, since
local configuration can always override standardized mechanisms.
To maintain backward compatibility with the standardized uses of
INFO, a server MAY interpret an INFO request with no "Info-Package"
header as being of such legacy use. [TBD: what response if not
supported?]
It should be noted that such legacy use will not "break" the
mechanism in this draft. For example, if a UA supports [SIP-T] use
Kaplan, et al. Expires - August 2008 [Page 11]
The SIP INFO Method and Info Packages February 2008
previously, it did so based on static local configuration or based
on acceptance of the application/isup body. If it adds support for
this draft's Info Package negotiation mechanism, the local
configuration would still apply, and the UA will send/receive INFO
messages based on [SIP-T] regardless of the Info Package
negotiation. It will also be able to send/receive INFO messages
based on the Info Packages it negotiated. If, at some future time,
an Info Package is defined for [SIP-T], the UA can indicate such in
the negotiation, and again local configuration would supersede if
need be. The UA would not lose the ability to use [SIP-T] with
legacy devices - it would gain the ability to use it with devices
which support this draft and with which it did not have such local
configuration set, and could avoid failures related to unsupported
bodies.
It is the hope of this draft's authors that vendors which implement
proprietary INFO uses submit their mechanisms as Info Package
extension documents, and follow the Info Package negotiation
mechanism defined in this draft.
8. Info Packages
This section covers several issues which should be taken into
consideration when new Info Packages are proposed.
8.1. Appropriateness of Usage
When designing an Info Package using the method described in this
document for information exchange, it is important to consider: is
INFO and, more importantly, is signaling within a SIP dialog, an
appropriate mechanism for the problem set? Is it because it is the
most reasonable and appropriate choice, or merely because "it's
easy"?
These are difficult issues to consider, especially when presented
with real-world deadlines and implementation cost issues. However,
choosing to use INFO for inappropriate uses *will* lead to issues in
the real world, not the least of which are certain types of
middleboxes which will remove the device from the network if it is
found to cause damage to other SIP nodes.
Therefore, the following sections try to provide consideration
guidelines and alternatives to INFO use.
8.1.1 Dialog Fate-Sharing
INFO, by design, is a method within an INVITE dialog usage.
[RFC5057] enumerates the problems with using dialogs for multiple
usages, and we strongly urge the reader to review RFC 5057. The
Kaplan, et al. Expires - August 2008 [Page 12]
The SIP INFO Method and Info Packages February 2008
most relevant issue is a failure of transmission or processing of an
INFO may render the INVITE dialog terminated, depending on the type
of failure. Prior to [RFC5057] it was underspecified if the INFO
usage was a separate usage or not. However, RFC 5057 clarifies the
INFO method is always part of the INVITE usage.
Some uses of INFO can tolerate this fate sharing of the INFO message
over the entire dialog. For example, in the SIP-T usage, it may be
acceptable for a call to fail, or to tear down the call, if one
cannot deliver the associated SS7 information; likewise for DTMF.
However, it may not be acceptable for a call to fail if, for
example, a DTMF buffer overflows. Then again, for some services,
that may be the exact desired behavior.
8.1.2 Messaging Rates and Volume
There is no throttling mechanism for INFO. Consider that most call
signaling occurs on the order of 7-10 messages per 3 minutes,
although with a burst of 5-7 messages in one second. DTMF tones
occur in bursts at a rate of up to 20 messages per second. This is
a considerably higher rate than for call signaling, but at least it
is infrequent in nature during the duration of a call. Sending
constant GPS location updates, on the other hand, would incur an
undue burden on SIP Proxies along the path.
Furthermore, SIP messages tend to be relatively small, on the order
of 500 Bytes to 32K Bytes. SIP is a poor mechanism for direct
exchange of bulk data beyond these limits, which is more appropriate
for [MSRP], [COMEDIA], or HTTP.
8.1.3 Proxy-path Signaling
Using INFO means all Record-Routing proxies, and B2BUA's, in the
path between the UA's will receive the INFO messages. For some
applications, such as DTMF, this may be desirable, while for others
this may have no benefit whatsoever. If there is no benefit, then
it is imposing unnecessary processing burden on the proxies. 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.
8.1.4 Is there a better alternative?
The design goal of the SUBSCRIBE/NOTIFY [RFC3265] event framework is
to meet the general need of periodic state notifications/updates.
Subscribes have their own dialog or usage, and thus can outlive an
Kaplan, et al. Expires - August 2008 [Page 13]
The SIP INFO Method and Info Packages February 2008
INVITE one, but they can also follow the path of the INVITE-based
dialog.
The MESSAGE method in [RFC3428] was defined for one-time instant
message exchange, typically for sending MIME contents which should
be rendered to the user.
[MSRP] was created for session-based instant messaging, as well as
bulk file transfer, and other such large-volume uses. It is part of
an INVITE-based session, similar to other media. Unlike INFO, it
follows a more direct media-plan path, rather than the SIP signaling
one.
8.2. Info Package Responsibilities
Info packages are not required to reiterate any of the behavior
described in this document, although they may choose to do so for
clarity or emphasis. In general, though, such packages are expected
to describe only the behavior that extends or modifies the behavior
described in this document.
Note that any behavior designated with "SHOULD" or "MUST" in this
document is not allowed to be weakened by extension documents;
however, such documents may elect to strengthen "SHOULD"
requirements to "MUST" strength if required by their application.
In addition to the normal sections expected in standards-track RFCs
and SIP extension documents, authors of Info Packages need to
address each of the issues detailed in the following subsections,
whenever applicable.
8.2.1 Info Package Name
This section, which MUST be present, defines the token name to be
used to designate the Info Package. It MUST include the information
which appears in the IANA registration of the token. For
information on registering such types, see section 12.
8.2.2 Info Package Parameters
If parameters are to be used on the "Info-Package" header to modify
the behavior of the Info Package, the syntax and semantics of such
parameters MUST be clearly defined.
8.2.3 INFO Bodies
Each Info Package MUST define what type or types of bodies are
expected in INFO requests. Such packages MUST specify or cite
Kaplan, et al. Expires - August 2008 [Page 14]
The SIP INFO Method and Info Packages February 2008
detailed specifications for the syntax and semantics associated with
such a body.
Info Packages also MUST define which MIME type is to be assumed if
none are specified in the "Accept" header of the INVITE request.
8.2.4 UA generation of INFO requests
This section of an Info Package describes the process by which a UA
generates and sends an INFO request. This includes detailed
information about what events cause INFO to be sent. Such a section
is required.
This section may optionally describe the behavior used to process
the subsequent response.
8.2.5 UA processing of INFO requests
This section of an Info Package describes the process followed by
the UA upon receipt of an INFO request.
8.2.6 Rate of notifications
Each Info Package is expected to define a requirement (SHOULD or
MUST strength) which defines an absolute maximum on the rate at
which INFO messages are allowed to be generated for the package by a
UA in a dialog.
Each package MAY further define a throttle mechanism which allows
UAs to further limit the rate of INFO messages.
8.2.7 Examples
Info Packages SHOULD include several demonstrative message flow
diagrams paired with several typical, syntactically correct, and
complete messages.
It is RECOMMENDED that documents describing Info Packages clearly
indicate that such examples are informative and not normative, with
instructions that implementers refer to the main text of the
document for exact protocol details.
9. Syntax
This section describes the syntax extensions required for event
notification in SIP. Semantics are described in previous sections.
Note that the formal syntax definitions described in this document
are expressed in the ABNF format used in SIP [RFC3261], and contain
references to elements defined therein.
Kaplan, et al. Expires - August 2008 [Page 15]
The SIP INFO Method and Info Packages February 2008
9.1. New Method
This document describes one new SIP method: INFO.
This table expands on tables 2 and 3 in SIP [RFC3261].
Header Where INFO
------ ----- ----
Accept R o
Accept-Encoding R o
Accept-Language R o
Allow 200 -
Allow 405 o
Authorization R o
Call-ID gc m
Contact R o
Contact 1xx -
Contact 2xx -
Contact 3xx -
Contact 485 -
Content-Encoding e o
Content-Length e o
Content-Type e *
CSeq gc m
Date g o
Encryption g o
Expires g o
From gc m
Hide R o
Max-Forwards R o
Organization g o
Priority R o
Proxy-Authenticate 407 o
Proxy-Authorization R o
Proxy-Require R o
Require R o
Retry-After R -
Retry-After 404,480,486 o
Retry-After 503 o
Retry-After 600,603 o
Response-Key R o
Record-Route R o
Record-Route 2xx o
Route R o
Server r o
Subject R o
Timestamp g o
To gc(1) m
Kaplan, et al. Expires - August 2008 [Page 16]
The SIP INFO Method and Info Packages February 2008
Unsupported 420 o
User-Agent g o
Via gc(2) m
Warning r o
WWW-Authenticate 401 o
Table 1 Summary of header fields
9.1.1 INFO Method
"INFO" is added to the definition of the element "Method" in the SIP
message grammar.
Like all SIP method names, the INFO method name is case sensitive.
The INFO method is used to transmit session-related information
within an INVITE-based dialog.
9.2. New Headers
This table expands on tables 2 and 3 in SIP [RFC3261].
[Should the new header fields be optional for OPTIONS and REGISTER?
TBD by SIP-WG]
Header field where ACK BYE CAN INV OPT REG PRA INF MSG UPD SUB NOT
--------------------------------------------------------------------
Info-Package R - - - - - - - m - - - -
Info-Package r - - - - - - - o - - - -
Send-Info R - - - o - o - - - - - -
Send-Info 2xx - - - o o - - - - - - -
Send-Info 1xx - - - o o - - - - - - -
Send-Info r - - - - o - - - - - - -
Recv-Info R - - - o - o - - - - - -
Recv-Info 2xx - - - o o - - - - - - -
Recv-Info 1xx - - - o o - - - - - - -
Recv-Info r - - - - o - - - - - - -
9.2.1 "Info-Package" header
Info-Package is added to the definition of the element "message-
header" in the SIP message grammar.
For the purposes of matching Info Package types indicated in Send-
Info or Recv-Info with those in the Info-Package header field value,
the Info-package-name portion of the Info-package-type portion of
the "Info-Package" header is compared byte-by-byte with that of the
Kaplan, et al. Expires - August 2008 [Page 17]
The SIP INFO Method and Info Packages February 2008
same in the "Send-Info" or "Recv-Info" header values. In other
words, the Info-package-param is not used for comparison checking.
This document does not define values for Info-Package-types. These
values will be defined by individual Info Packages, and MUST be
registered with the IANA.
There MUST be exactly one Info Package type listed per Info-Package
header. Multiple Info-Packages per INFO message are disallowed.
9.2.2 "Send-Info" header
Send-Info is added to the definition of the element "general-header"
in the SIP [RFC3261] message grammar. Its usage is described in
section 5.
9.2.3 "Recv-Info" header
Recv-Info is added to the definition of the element "general-header"
in the SIP [RFC3261] message grammar. Its usage is described in
section 5.
9.3. Augmented BNF Definitions
The Augmented BNF definitions for the various new and modified
syntax elements follows. The notation is as used in SIP [RFC3261],
and any elements not defined in this section are as defined in SIP
and the documents to which it refers.
INFOm = %x49.4E.46.4F ; INFO in caps
extension-method = INFOm / token
Info-Package = "Info-Package" HCOLON Info-package-type
Send-Info = "Send-Info" HCOLON Info-package-type
*( COMMA Info-package-type )
Recv-Info = "Send-Info" HCOLON Info-package-type
*( COMMA Info-package-type )
Info-package-type = Info-package-name *( "." Info-package-param)
Info-package-name = token-nodot
token-nodot = 1*( alphanum / "-" / "!" / "%" / "*"
/ "_" / "+" / "`" / "'" / "~" ) ;rfc3265
Info-package-param = generic-param ;this doesn't work due to dot!
Kaplan, et al. Expires - August 2008 [Page 18]
The SIP INFO Method and Info Packages February 2008
10. Example Exchange
In the following example, Alice initiates a call to Bob. Alice can
support sending or receiving "foo" Info Packages, and sending "bar"
Info Packages.
Alice generates the following: (note: much has been left out for
simplicity)
INVITE sip:bob@example.com SIP/2.0
Via: SIP/2.0/UDP 192.0.2.1:5060;branch=z9hG4bKnashds10
From: Alice <sip:alice@example.net>;tag=1234567
To: Bob <sip:bob@example.com>
Call-Id: 123456mcmxcix
CSeq: 1 INVITE
Contact: <sip:alice@192.0.2.1>
Send-Info: foo, bar
Recv-Info: foo
Bob checks the header field values, can support sending but not
receiving "foo", and sending but not receiving "bar". Note that
since Bob does not support receiving anything Alice can send, the
response does not list any Recv-Info packages.
SIP/2.0 180 Ringing
Via: SIP/2.0/UDP 192.0.2.1:5060;branch=z9hG4bKnashds10
From: Alice <sip:alice@example.net>;tag=1234567
To: Bob <sip:bob@example.com>;tag=abcdefg
Call-Id: 123456mcmxcix
CSeq: 1 INVITE
Send-Info: foo
Since he sent the Send-Info header field value in the 180, and still
wishes to support it, Bob also sends it in the 200 response.
SIP/2.0 200 OK
Via: SIP/2.0/UDP 192.0.2.1:5060;branch=z9hG4bKnashds10
From: Alice <sip:alice@example.net>;tag=1234567
To: Bob <sip:bob@example.com>;tag=abcdefg
Call-Id: 123456mcmxcix
CSeq: 1 INVITE
Contact: <sip:bob@192.0.2.2>
Send-Info: foo
Alice can send an Info Package as soon as she received the 180, but
in this example she would not have been able to do so since Bob
didn't say he could receive any Info Packages in his 180 response.
Bob must wait to receive the ACK before sending any "foo" packages
(ACK not shown), at which point he sends the following:
Kaplan, et al. Expires - August 2008 [Page 19]
The SIP INFO Method and Info Packages February 2008
INFO sip:alice@192.0.2.1 SIP/2.0
Via: SIP/2.0/UDP 192.0.2.2:5060;branch=z9hG4bKnabcdef
To: Alice <sip:alice@example.net>;tag=1234567
From: Bob <sip:bob@example.com>;tag=abcdefg
Call-Id: 123456mcmxcix
CSeq: 2 INFO
Contact: <sip:bob@192.0.2.2>
Info-Package: foo
11. Security Considerations
There are no specific security issues for this mechanism, beyond
those already applicable to SIP-based session signaling. In
particular, if the SIP signaling is not protected from
eavesdropping, authentication and repudiation, for example by using
TLS transport, then the INFO request and its contents will not be
protected either. Even with SIP/TLS, any SIP hop along the path
from UAC to UAS can view, modify, or intercept INFO requests, as
they can any SIP request.
One interesting property of Info Package use is that the same
digest-challenge mechanism used for INVITE-based authentication can
be reused for the INFO request. For example one could use a
quality-of-protection (qop) value of authentication with integrity
(auth-int), to challenge the request and its body, and prevent
intermediate devices from modifying the body. However this assumes
the device which knows the credentials in order to perform the
INVITE challenge is still in the path for the INFO, or that the far-
end UAS knows such credentials.
12. IANA Considerations
This document will define an Info Package-type namespace, the
specifics of which are TBD. Should this draft move forward, the
body chosen for this coordination would be the Internet Assigned
Numbers Authority (IANA).
13. Acknowledgements
The authors wish to thank Brian Stucker, Francois Audet, Paul
Kyzivat, Adam Roach, Eric Burger, and Robert Sparks for their
suggestions and comments; and for Dean Willis, who was ahead of his
time, having submitted a similar draft 5 years ago. Special thanks
goes to Adam Roach for writing [RFC3265], from which several
sections of text were directly copied into this draft.
Kaplan, et al. Expires - August 2008 [Page 20]
The SIP INFO Method and Info Packages February 2008
14. References
14.1. Normative References
[RFC2976] Donovan, S., "The SIP INFO Method", RFC 2976, October
2000.
[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.
14.2. Informative References
[RFC3265] Roach, A., "Session Initiation Protocol (SIP)-Specific
Event Notification", RFC 3265, June 2002
[SIP-T] Vemuri, A., Peterson, J., "Session Initiation Protocol for
Telephones (SIP-T): Context and Architectures", RFC 3372,
September 2002.
[RFC3428] Campbell, B., et al, "Session Initiation Protocol (SIP)
Extension for Instant Messaging", RFC 3428, December 2002.
[CALLER-PREFS] Rosenberg, J., Schulzrinne, H., Kyzivat, P., "Caller
Preferences for the Session Initiation Protocol (SIP)",
RFC 3841, August 2004.
[RFC4028] Donavan, S., Rosenberg, J., "Session Timers in the Session
Initiation Protocol (SIP)", RFC 4028, April 2005.
[COMEDIA] Yon, D. and G. Camarillo, "TCP-Based Media Transport in
the Session Description Protocol (SDP)", RFC 4145, September 2005.
[MSRP] Campbell, B., Mahy, R., Jennings, C., "The Message Session
Relay Protocol (MSRP)", RFC 4975, September 2007.
[RFC5057] Sparks, R., "Multiple Dialog Usages in the Session
Initiation Protocol", RFC 5057, February 2007
[info-harmful] Burger, E., "Session Initiation Protocol (SIP) INFO
Method Use", draft-burger-sip-info-02.txt, November 2007.
Kaplan, et al. Expires - August 2008 [Page 21]
The SIP INFO Method and Info Packages February 2008
Authors' Addresses
Hadriel Kaplan
Acme Packet
71 Third Ave.
Burlington, MA 01803
USA
Email: hkaplan@acmepacket.com
Christer Holmberg
Ericsson
Hirsalantie 11
Jorvas 02420
Finland
Email: christer.holmberg@ericsson.com
Eric W. Burger
BEA Systems, Inc.
USA
Email: eburger@standardstrack.com
Kaplan, et al. Expires - August 2008 [Page 22]
The SIP INFO Method and Info Packages February 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 Statement
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).
Kaplan, et al. Expires - August 2008 [Page 23]| PAFTECH AB 2003-2026 | 2026-04-24 01:23:11 |