One document matched: draft-ietf-sip-serverfeatures-02.txt
Differences from draft-ietf-sip-serverfeatures-01.txt
Internet Engineering Task Force SIP WG
Internet Draft J.Rosenberg,H.Schulzrinne
draft-ietf-sip-serverfeatures-02.txt dynamicsoft,Columbia U.
March 5, 2000
Expires: September, 2000
The SIP Supported Header
STATUS OF THIS MEMO
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
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.
Abstract
The Session Initiation Protocol (SIP) provides a mechanism that
allows a client to request that a particular protocol extension be
used to process the request. The server declines the request if it
does not support the extension. However, there is currently no way
for a server to determine which extensions are supported by the
client. Knowing about client-supported extensions allows the server
to tailor its response accordingly. Furthermore, SIP does not define
a way for a client to query a server about the extensions it
supports. This document defines a SIP extension that allows clients
to indicate, in a request, the set of extensions supported. We also
define a mechanism that allows clients, through an OPTIONS request,
to determine the extensions supported by a server.
1 Introduction
J.Rosenberg,H.Schulzrinne [Page 1]
Internet Draft supported March 5, 2000
The Session Initiation Protocol (SIP) [1] defines the Require and
Proxy-Require request headers that indicate to the server that it
should only process the request if it supports the features
enumerated. These headers include option tags. A UAS or proxy,
respectively, must understand the option tags in order to process a
request.
However, SIP provides no support for the reverse case. In this case,
a server wants to use a extension to process a request, but must
determine if the client supports it. In this scenario, the client
does not ask for the given extension, but the server wants to use the
extension in the response. As the response cannot be processed
without understanding this extension, the server needs a way to
determine which extensions are supported by the client. The server
also needs a way to signal to the client which extensions have been
applied in the response.
Very much related to this, there is currently no way for a client to
query a server to determine which extensions it supports. OPTIONS
allows a client to query a server about capabilities, such as support
for various methods and media types. However, the set of supported
extensions is not among the information returned in an OPTIONS
response.
This document defines an extension to SIP that enables the ability
for clients and servers to indicate support for extensions. This is
done through a new header, called Supported. Supported, like the
Unsupported header, contains a list of option tags supported by the
entity sending the message. This extension also allows the Require
header to appear in responses. It is used to indicate what options
must be understood by the UAC in order to process the response.
It is expected that this extension will be folded into the next
revision of the SIP specification.
2 Extension Syntax
2.1 Supported Header
This extension defines a new general header, Supported. The syntax
for this header is:
Supported = ( "Supported" | "k" ) ":" 0#option-tag
The BNF for option-tag is given in RFC 2543 [1]. The Supported
J.Rosenberg,H.Schulzrinne [Page 2]
Internet Draft supported March 5, 2000
general-header field enumerates all the capabilities of the client or
server. Clients that support any SIP extensions SHOULD include this
header in all requests excepting ACK. It MUST be included in the
response to OPTIONS requests, even if the UAS generating the response
doesn't support any extensions beyond this one.
Note that the BNF for the header explicitly allows for zero option
tags to be present. This will occur when a server responds to an
OPTIONS request, but it supports no extensions beyond this one
itself. This is needed to enable backwards compatibility. If the
response to OPTIONS contains no Supported header at all, it means the
server may support some extensions, but does not understand the
Supported header.
The following defines the entry for the Supported in Table 4 of RFC
2543. Table 4 lists the places where the Supported may appear:
where enc. e-e ACK BYE CAN INV OPT REG
___________________________________________________
Supported g c e - o o o o o
A compact form for the Supported header is defined. This is the
letter k, for "know".
2.2 Require Header
This extension also allows for the Require header to appear in
responses. It is used to indicate what options must be understood by
the UAC in order to process the response.
This implies that the row of Table 4 in RFC 2543 defining usage of
the Require header should read:
Require g e o o o o o o
2.3 421 (Extension Required) Response
This extension defines a new response status code - 421. The default
reason phrase for this status code is "Extension Required". This
response is used by a server when it needs a particular extension to
process the request, but this extension is not listed in a Supported
header in the request. Responses with this status code MUST contain a
Require header listing the required extensions.
J.Rosenberg,H.Schulzrinne [Page 3]
Internet Draft supported March 5, 2000
3 Usage in Requests
All requests, excepting ACK, generated by UACs conformant to this
specification SHOULD include the Supported header. This header MUST
list all those extensions supported by the UAC which the UAC is
willing to apply to the transaction.
Any server (UAS, proxy, redirect or registrar) that wishes to apply
some extension to the response, MUST only do so if support for that
extension is indicated in the Supported header. If the extension is
essential, and the server cannot send its desired response without
it, the server MAY send a 421 (Extension Required) response. This
response indicates that the proper response cannot be generated
without support of a specific extension. The needed extension(s) MUST
be included in a Require header in the response.
If the extension the server wishes to apply to the response is
supported, the server MUST include a Require header in the response
listing those extensions it applied to the response.
4 Usage with OPTIONS
User agent servers compliant to this specification MUST include a
Supported header in responses to OPTIONS requests. This header MUST
be present even if the server supports no extensions beyond the one
specified here. This means that the Supported header may be empty in
the response.
Clients MUST NOT treat absence of the Supported header in an OPTIONS
response to mean no extensions are supported. The presence of an
empty Supported header implies no extensions are supported.
5 Example Usage
This section gives an example call flow using this extension. UAC A
sends a request to UAS B. UAS B wishes to apply extension foo to the
response. Two cases are shown. In the first, foo is supported by A,
and in the second, is not.
5.1 A supports foo
The initial INVITE from A looks like (SDP omitted for clarity):
A->B: INVITE sip:jtoto@dynamicsoft.com SIP/2.0
Via: SIP/2.0/UDP bigmachine.dynamicsoft.com
Supported: foo
J.Rosenberg,H.Schulzrinne [Page 4]
Internet Draft supported March 5, 2000
From: sip:jdrosen@dynamicsoft.com
To: sip:jtoto@dynamicsoft.com
Call-ID: 70710@bigmachine.dynamicsoft.com
CSeq: 1 INVITE
Subject: Venture Capital
Since the desired extension is supported, B applies it to the
response (in this case, a redirect), and includes a Require header
indicating that the extension has been applied.
B->A: SIP/2.0 300 Moved
Via: SIP/2.0/UDP bigmachine.dynamicsoft.com
Require: foo
From: sip:jdrosen@dynamicsoft.com
To: sip:jtoto@dynamicsoft.com;tag=443322
Call-ID: 70710@bigmachine.dynamicsoft.com
CSeq: 1 INVITE
Foo: 9998h7asdh9
and A sends an ACK:
C->S: ACK sip:jtoto@dynamicsoft.com SIP/2.0
Via: SIP/2.0/UDP bigmachine.dynamicsoft.com
From: sip:jdrosen@dynamicsoft.com
To: sip:jtoto@dynamicsoft.com;tag=443322
Call-ID: 70710@bigmachine.dynamicsoft.com
CSeq: 1 ACK
Note that the Supported header is not included in the ACK.
5.2 A doesn't support foo
In this case, A doesn't support foo. It supports some other
extension, bar. The server wishes to apply foo, and is not willing to
proceed without it. So, it rejects the request.
A doesn't support foo, so it resubmits the request with an
Unsupported header included:
J.Rosenberg,H.Schulzrinne [Page 5]
Internet Draft supported March 5, 2000
A->B: INVITE sip:jtoto@dynamicsoft.com SIP/2.0
Via: SIP/2.0/UDP bigmachine.dynamicsoft.com
Supported: bar
From: sip:jdrosen@dynamicsoft.com
To: sip:jtoto@dynamicsoft.com
Call-ID: 70710@bigmachine.dynamicsoft.com
CSeq: 1 INVITE
Subject: Venture Capital
B->A: SIP/2.0 421 Extension Required
Via: SIP/2.0/UDP bigmachine.dynamicsoft.com
Require: foo
From: sip:jdrosen@dynamicsoft.com
To: sip:jtoto@dynamicsoft.com;tag=98765
Call-ID: 70710@bigmachine.dynamicsoft.com
CSeq: 1 INVITE
a sends an ACK:
A->B: ACK sip:jtoto@dynamicsoft.com SIP/2.0
Via: SIP/2.0/UDP bigmachine.dynamicsoft.com
From: sip:jdrosen@dynamicsoft.com
To: sip:jtoto@dynamicsoft.com;tag=98765
Call-ID: 70710@bigmachine.dynamicsoft.com
CSeq: 1 ACK
6 Security Considerations
This extension introduces no new security considerations beyond those
discussed in RFC 2543 [1].
7 Author's Addresses
Jonathan Rosenberg
dynamicsoft
200 Executive Drive
J.Rosenberg,H.Schulzrinne [Page 6]
Internet Draft supported March 5, 2000
Suite 120
West Orange, NJ 07052
email: jdrosen@dynamicsoft.com
Henning Schulzrinne
Columbia University
M/S 0401
1214 Amsterdam Ave.
New York, NY 10027-7003
email: schulzrinne@cs.columbia.edu
8 Bibliography
[1] M. Handley, H. Schulzrinne, E. Schooler, and J. Rosenberg, "SIP:
session initiation protocol," Request for Comments (Proposed
Standard) 2543, Internet Engineering Task Force, Mar. 1999.
J.Rosenberg,H.Schulzrinne [Page 7]
| PAFTECH AB 2003-2026 | 2026-04-24 02:23:11 |