SIP WG R. Mahy
Internet-Draft Cisco Systems, Inc.
Expires: January 15, 2005 July 17, 2004
Connection Reuse in the Session Initiation Protocol (SIP)
draft-ietf-sip-connect-reuse-02.txt
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.
This Internet-Draft will expire on January 15, 2005.
Copyright Notice
Copyright (C) The Internet Society (2004). All Rights Reserved.
Abstract
When SIP entities use a connection oriented protocol to send a
request, they typically originate their connections from an ephemeral
port. The SIP protocol includes mechanisms which insure that
responses to a request, and new requests sent in the original
direction reuse an existing connection. However, new requests sent
in the opposite direction are unlikely to reuse the existing
connection. This frequently causes a pair of SIP entities to use one
connection for requests sent in each direction, and can result in
potential scaling and performance problems. This document proposes
requirements and a mechanism which address this deficiency.
Mahy Expires January 15, 2005 [Page 1]
Internet-Draft SIP Connection Reuse July 2004
Table of Contents
1. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Introduction and Problem Statement . . . . . . . . . . . . . . 3
2.1 Efficiency Concerns . . . . . . . . . . . . . . . . . . . 3
2.2 Directional Connectivity . . . . . . . . . . . . . . . . . 4
2.3 Clustering . . . . . . . . . . . . . . . . . . . . . . . . 5
2.4 Hop-by-hop reuse . . . . . . . . . . . . . . . . . . . . . 7
3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 7
4. Behavior . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
4.1 Authorizing an alias request . . . . . . . . . . . . . . . 9
4.1.1 Authorizing using TLS mutual authentication . . . . . 10
4.1.2 Authorization via Registration . . . . . . . . . . . . 10
4.2 Formal Syntax . . . . . . . . . . . . . . . . . . . . . . 12
5. Security Considerations . . . . . . . . . . . . . . . . . . . 12
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
8.1 Normative References . . . . . . . . . . . . . . . . . . . . 13
8.2 Informational References . . . . . . . . . . . . . . . . . . 13
Author's Address . . . . . . . . . . . . . . . . . . . . . . . 14
Intellectual Property and Copyright Statements . . . . . . . . 15
Mahy Expires January 15, 2005 [Page 2]
Internet-Draft SIP Connection Reuse July 2004
1. Conventions
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 [2].
2. Introduction and Problem Statement
SIP [1] entities can communicate using either unreliable/
connectionless (ex: UDP) or reliable/connection-oriented (ex: TCP,
SCTP [14]) transport protocols. When SIP entities use a
connection-oriented protocol (such as TCP or SCTP) to send a request,
they typically originate their connections from an ephemeral port.
In the following example, Entity A listens for SIP requests over TLS
[4] on TCP port 5061 (the default port for SIP over TLS over TCP),
but uses an ephemeral port (port 8293) for a new connection to Entity
B. These entities could be SIP User Agents or SIP Proxy Servers.
+-----------+ 8293 (UAC) 5061 (UAS) +-----------+
| |--------------------------->| |
| Entity | | Entity |
| A | | B |
| | 5061 (UAS) | |
+-----------+ +-----------+
The SIP protocol includes mechanisms which insure that responses to a
request reuse the existing connection which is typically still
available, and also includes provisions for reusing existing
connections for other requests sent by the originator of the
connection. However, new requests sent in the opposite direction
(routed from the target of the original connection toward the
originator of the original connection) are unlikely to reuse the
existing connection. This frequently causes a pair of SIP entities
to use one connection for requests sent in each direction, as shown
below.
+-----------+ 8293 5061 +-----------+
| |.......................>| |
| Entity | | Entity |
| A | 5061 9741 | B |
| |<-----------------------| |
+-----------+ +-----------+
2.1 Efficiency Concerns
This extra pair of connections can result in potential scaling and
Mahy Expires January 15, 2005 [Page 3]
Internet-Draft SIP Connection Reuse July 2004
performance problems. For example, each new connection using TLS
requires a TCP 3-way handshake, a handful of round-trips to establish
TLS, and (typically) expensive asymetric authentication and key
generation algorithms, and certificate verification. This
effectively doubles the load on each entity. Setting up a second
connection can also cause excessive delay (especially in networks
with long round-trip times) for subsequent requests, even requests in
the context of an existing dialog (for example a reINVITE or BYE
after an initial INVITE, or a NOTIFY after a SUBSCRIBE [11] or a
REFER [12]).
Consider the call flow shown below where Proxy A and Proxy B use the
Record-Route mechanism to stay involved in a dialog. Proxy B will
establish a new TLS connection just to send a BYE request.
INVITE -> create connection 1
<- 200 response over connection 1
ACK -> reuse connection 1
<- BYE create connection 2
-> 200 response over connection 2
ReINVITEs or UPDATE [8] requests are expected to be handled
automatically and rapidly in order to avoid media and session state
from being out of step. If a reINVITE requires a new TLS connection,
the reINVITE could be delayed by several extra round-trip times.
Depending on the round-trip time, this combined delay could be
perceptible or even annoying to a human user. This is especially
problematic for some common SIP call flows (for example, the
recommended example flow in figure number 4 in RFC3725 [9] (SIP
third-party call control) use many reINVITEs.
2.2 Directional Connectivity
Some SIP User Agents can initiate TCP or TLS connections, but for one
reason or another cannot usefully accept incoming connections. When
TLS connections are involved, many User Agents can accept incoming
TLS connections, but cannot provide a certificate that is likely to
be trusted by the TLS client. (The User Agent can only offer a
self-signed certificate for example.) This cause their connectivity
to fail
In other cases, a User Agent cannot accept incoming TCP connections
at all because they are behind a Firewall or NAT.
Mahy Expires January 15, 2005 [Page 4]
Internet-Draft SIP Connection Reuse July 2004
+---+
+-----------+ | | +-----------+
| |-----| |--------->| |
| User | | F | | Proxy |
| Agent A | | W | | Server |
| | | X<---------| |
+-----------+ | | +-----------+
+---+
Finally, some User Agents may be configured to refuse incoming TCP or
TLS connections, since it is difficult or impossible for some class
of User Agents to authorize such connections.
In all three of these cases, connection reuse is no longer simply an
efficiency improvement. It is mandatory to make TCP or TLS work for
a large class of SIP User Agents. For User Agents in this class,
incoming requests need to come from a proxy server with which the
User Agent has a persistent connection. Each User Agent in this
class of UAs also needs to have a SIP URI with GRUU [7] properties
that routes to a proxy server that knows how to forward requests over
this persistent connection already opened by the User Agent.
However, just using the GRUU mechanism by itself does not help a
proxy server determine which incoming persistent connection is
associated with a particular GRUU. An explicit connection reuse
mechanism is still needed between these User Agents and their
proxies.
For example, consider a standard SIP presence [10] subscription. An
instant messaging and presence client sends a SUBSCRIBE request for
the presence of a peer. The presence notifications are returned as
NOTIFY requests from the peer. If the subscribing User Agent wants
to use TLS, the NOTIFY request would cause a second (new) connection
back to the subscribing client. If the presence client doesn't have
a valid TLS certificate anchored in a well-known certificate
authority, the NOTIFY request will fail, and the presence client will
never receive any presence data.
SUBSCRIBE -> connection 1
<- 202 connection 1
<- NOTIFY connection 2
200 -> connection 2
2.3 Clustering
When clusters or farms of cooperating SIP servers (for example proxy
servers) are configured together, SIP entities have no way to prefer
a server with an existing connection. For example, Proxy server B
Mahy Expires January 15, 2005 [Page 5]
Internet-Draft SIP Connection Reuse July 2004
has no mechanism to choose an existing connection with Proxy cluster
A.
+-----------+
| |
| Proxy |
| A1 | +-----------+
| | | |
+-----------+ | Proxy |
+-----------+ 8293 5061 | B |
| |----------------------->| |
| Proxy | +-----------+
| A2 |
| |
+-----------+
As a result, Proxy B might open a new connection to another proxy
server for requests sent in the opposite direction.
+-----------+
| |
| Proxy |
| A1 | 5061 9741 +-----------+
| |<.......................| |
+-----------+ | Proxy |
+-----------+ 8293 5061 | B |
| |----------------------->| |
| Proxy | +-----------+
| A2 |
| |
+-----------+
The rules for handling the Transport layer described in Section 18 of
SIP [1] do not associate incoming connections with the listening port
which corresponds to the same SIP entity. If the Tranport layer had
some way to associate these connections, then request and responses
originated from either node could reuse existing connections as shown
below.
+-----------+ +-----------+
| | | |
| Node A | 8293 5061 | Node B |
| |<======================>| |
| | | |
+-----------+ +-----------+
Likewise, when when an "outbound-only" user agent opens a connection
to only one proxy server in the same cluster, there is no way for
Mahy Expires January 15, 2005 [Page 6]
Internet-Draft SIP Connection Reuse July 2004
this user agent to recieve incoming requests if the this particular
proxy goes down. In many scenarios, the user agent would not notice
the connection was unresponsive until it was time to refresh its SIP
registration. Some "outbound-only" user agents would like the
ability to open persistent connections to more than one proxy server
in a cluster, so that at least two proxy servers in the cluster can
forward incoming requests to the user agent.
2.4 Hop-by-hop reuse
All the examples presented above apply to a single hop as opposed to
a per-dialog route-set or other complete path. This is natural since
ordinary connections are managed on a hop-by-hop basis as well. In
addition, it is useful to note that "outbound-only" user agents
require connection reuse for any number of reuqests which may have
nothing in common other than the last hop. Likewise, proxy server to
proxy server connection reuse is likely to be much more efficient if
multiple dialogs or multiple users can use the same connection.
3. Requirements
1. A connection sharing mechanism SHOULD allow SIP entities to reuse
existing connections for requests and repsonses originated from
either peer in the connection.
2. A connection sharing mechanism SHOULD allow SIP entities to reuse
existing connections with closely coupled nodes which act as a
single SIP entity (for example a cluster of nodes acting as a
proxy server).
3. A connection sharing mechanism MUST NOT require UACs (clients) to
send all traffic from well-know SIP ports.
4. A connection sharing mechanism MUST NOT require configuring
ephemeral port numbers in DNS.
5. A connection sharing mechanism MUST prevent unauthorized
hijacking of other connections.
6. Connection sharing SHOULD persist across SIP transactions and
dialogs.
7. There is no requirement to share a complete path. Hop-by-hop
connection sharing is more appropriate.
4. Behavior
The proposed mechanism uses a new Via header field parameter. The
"alias" parameter is included in a Via header field value to indicate
that the originator of the request wants to create a transport layer
alias. The originator places their alias in the Via header field
value (in the "sent-by" production). This "alias" address becomes
mapped to the a actual IP address and port number observed as the
source address of the current connection.
Mahy Expires January 15, 2005 [Page 7]
Internet-Draft SIP Connection Reuse July 2004
Assuming the Via header field value shown below from the most recent
request arrived over a connection from 10.54.32.1 port 8241:
Via: SIP/2.0/TLS 10.54.32.1:5061;branch=z9hG4bKa7c8dze ;alias
The transport layer creates an alias, such that any requests going to
the "advertised address" (10.54.32.1 port 5061) are instead sent over
the existing connection (to the "target" of the alias) which is
coming from port 8241. This sharing continues as long as the target
connection stays up.
The SIP community recommends that servers keep connections up
unless they need to reclaim resources, and that clients keep
connections up as long as they are needed. Connection reuse works
best when the client and the server maintain their connections for
long periods of time. SIP entities therefore SHOULD NOT drop
connections on completion of a transaction or termination of a
dialog.
To implement connection aliases for explicit IP addresses and port
numbers, a SIP node could (for example) search an additional data
structure (the alias table) prior to opening a new connection, or
could modify the data structure in which it keeps active
connection state so that aliases, active connnections, and
blacklisted nodes are all discovered when looking for an active
connection.
Likewise when clusters or farms of cooperating SIP servers (for
example proxy servers) are configured together, this mechanism allows
a SIP entity to select a server with an existing connection. With
this mechanism, Proxy B sends requests for Proxy cluster A to node A2
with whom it already shares an existing connection.
+-----------+
| |
| Proxy |
| A1 | +-----------+
| | | |
+-----------+ | Proxy |
+-----------+ 8293 5061 | B |
| |<======================>| |
| Proxy | +-----------+
| A2 |
| |
+-----------+
For example, on receipt of a message with the topmost Via header
shown below, the transport layer creates an alias such that requests
going to the advertised address (proxy-farm-a.example.com) are sent
over the target connection (from 10.54.32.1:8241).
Mahy Expires January 15, 2005 [Page 8]
Internet-Draft SIP Connection Reuse July 2004
Via: SIP/2.0/TLS proxy-farm-a.example.com;branch=z9hG4bK7c8ze;alias
As a result, this has an important interaction with the DNS
resolution mechanisms for SIP described in RFC3263 [6]. When new
requests arrive for proxy-farm-a.example.com, proxy B still needs to
perform a DNS NAPTR lookup to select the transport. Once the
transport is selected, an SRV lookup would ordinarily occur to find
the appropriate port number. In this case, the transport layer uses
a connection reuse alias instead of performing the SRV query.
Below is a partial DNS zone file for atlanta.com.
; NAPTR queries for the current domain (example.com)
;
; order pref flags service regexp replacement
proxy-farm-a IN NAPTR 50 50 "s" "SIPS+D2T" "" _sips._tcp.
; SRV records for the proxy use 5060/5061
;
;; Priority Weight Port Target
_sips._tcp.proxy-farm-a IN SRV 0 1 5061 host-a1
_sips._tcp.proxy-farm-a IN SRV 0 1 5061 host-a2
host-a1 IN A 10.54.32.1
host-a2 IN A 10.54.32.2
The existence of an alias parameter in a Via header in a request is
treated as a request to the transport layer to create an alias (named
by the sent-by parameter) that points to the alias target (the
current connection)
This mechanism is fully backwards compatible with existing
implementations. If the proposed Via parameter is not understood by
the recipient, it will be ignored and the two implementations will
revert to current behavior (two connections).
4.1 Authorizing an alias request
Authorizing connection aliases is essential to prevent connection
hijacking. For example a program run by a malicious user of a
multiuser system could attempt to hijack SIP requests destined for
the well-known SIP port from a large relay proxy.
To correctly authorize an alias, the SIP node authorizing the request
needs to recognize both the active connection and the alias as the
same resource. The only way to accomplish this is if both the active
connection and the alias can be authenticated using the same
credentials. This could be accomplished using one of two mechanisms.
Mahy Expires January 15, 2005 [Page 9]
Internet-Draft SIP Connection Reuse July 2004
4.1.1 Authorizing using TLS mutual authentication
The first (and preferred) authorization mechanism is using TLS mutual
authentication, such that the subjectAltName of the originator
certificate corresponds to both the current connection and the target
address of the alias. The Via sent-by address needs to be within the
scope protected by the certificate presented by the originator during
TLS mutual authentication and the received IP address needs be a
valid IP address for the sent-by host or hosts. In other words, the
sent-by address MUST be resolvable from the subjectAltName of the
originator certificate, and the received IP address MUST be
resolvable from the sent-by address. This is in addition to other
requirements for TLS authentication and authorization discussed in
SIP [1] and Locating SIP Servers [6].
Following this logic step-by-step:
1. Verify that the certificate presented is not expired and is
rooted in a trusted certificate chain.
2. Verify that the subjectAltName in the certificate covers the
"advertised address" (the address in the Via sent-by production).
If the advertised address and the subjectAltName match exactly
then the certificate covers the address.
3. Use DNS to resolve if the advertised name is resolvable from the
subjectAltName (start by resolving the subjectAltName as if it
where a target URI according to the rules in RFC3263. That is,
if no port number is present perform an SRV lookup, then finally
resolve relevant address records). If any of the resolved
addresses (port numbers can be ignored in this case) matches the
advertised address, then the certificate covers the address.
4. Finally, Verify that the advertised address can resolve to the IP
address over which the connection was received.
For example, take the example in the previous section of proxy B
receiving an alias request from host-a2.example.com. Proxy B
verifies that the presented certificate is valid and trusted. Proxy
B checks that proxy-farm-a.example.com is both the advertised name
and the subjectAltName in the certificate. Finally, proxy B verifies
that this connection is coming from 10.54.32.2, which is one of the
addresses in DNS for host-a2.example.com, which in turn is mentioned
in an SRV record for _sips._tcp.proxy-farm-a.example.com.
4.1.2 Authorization via Registration
The second mechanism is to accept an alias if the target address of
the alias is equivalent (using SIP comparison rules) to a valid
Contact already registered by the same user. This user could be
authenticated through any SIP or TLS mechanism (ex: user certificate,
or Kerberos [13]), but would typically use Digest authentication [5].
Mahy Expires January 15, 2005 [Page 10]
Internet-Draft SIP Connection Reuse July 2004
For example, if Alice registers a Contact of 198.168.67.89:5061, she
could inform Proxy 1 of the existence of a connection to her from
Proxy 2. This would allow her to preemptively originate TLS
connections, as her user agent may not have access to a site
certificate with which to authenticate incoming TLS connections.
The Proxy takes the following steps to authorize these requests:
1. The Proxy authenticates or authorizes the sender for an otherwise
ordinary SIP request.
2. The Proxy looks for any Contacts in the location/registration
service which have a hostport and transport that matches exactly
the advertised address.
3. The Proxy checks if the user who sent the request would be
authorized to change the Contact found when looking up the
Contact URI in the location/registration service.
For example, Alice advertises the address "198.168.67.89:5061" in the
Via header field of a request sent over a connection from
"198.168.67.89:8293" to Proxy 2. The Proxy otherwise authenticates
Alice's request (for example an INVITE request). The Proxy looks up
198.168.67.89:5061 and finds the following Contact: "Alice"
<sips:reg2@198.168.67.89:5061>. Alice is authorized to modify
Alice's contact, so Alice is authorized to alias an advertised
address "reserved" by one of her Contacts. Alice then sends another
request (this time an OPTIONS request for example) to Proxy 1 from
"198.168.67.89.8672" with the same Via header. Proxy 1 similarly
authorizes Alice's request and stores the alias. Now if either proxy
receives a request for 198.168.67.89:5061, it will forward the
request over the appropriate existing connection with Alice.
Via: SIP/2.0/TLS 198.168.67.89:5061;branch=z9hG4bK7c8dze ;alias
+-----------+
| |
| Proxy |
+-----------+ 8672 5061 | 1 |
| |----------------------->| |
| Alice | +-----------+
| | +-----------+
| |----------------------->| |
+-----------+ 8293 5061 | Proxy |
| 2 |
| |
+-----------+
Mahy Expires January 15, 2005 [Page 11]
Internet-Draft SIP Connection Reuse July 2004
4.2 Formal Syntax
The following syntax specification uses the augmented Backus-Naur
Form (BNF) as described in RFC-2234 [3]. This document proposes to
extend via-params to include a new via-alias defined below.
via-params = via-ttl / via-maddr / via-received / via-branch /
via-alias / via-extension
via-alias = "alias"
5. Security Considerations
This document presents requirements and a mechanism for reusing
existing connections easily. Unauthorized connection reuse would
present many opportunities for rampant abuse and hijacking, but these
attacks can be prevented if the guidelines in Section 4.1 are
followed.
The mechanism in this document can significantly improve the security
of SIP networks, in that it makes SIP over TLS (and the sips: scheme)
practical for devices which do not have a certificate rooted in a
well-known certificate authority.
SIP Proxy Servers which implement this mechanism MUST implement TLS
mutual authentication. Digest authentication is already mandatory to
implement for all SIP implementations.
6. IANA Considerations
This document adds a parameter to the SIP header field parameters
registry:
Header field in which parameter can appear: Via
Name of the parameter: alias
Reference: This document
7. Acknowledgments
Thanks to Jon Peterson for helpful answers about certificate behavior
with SIP, Jonathan Rosenberg for his initial support of this concept,
and Cullen Jennings for providing a sounding board for this idea.
8. References
Mahy Expires January 15, 2005 [Page 12]
Internet-Draft SIP Connection Reuse July 2004
8.1 Normative References
[1] 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.
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[3] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 2234, November 1997.
[4] Dierks, T., Allen, C., Treese, W., Karlton, P., Freier, A. and
P. Kocher, "The TLS Protocol Version 1.0", RFC 2246, January
1999.
[5] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S.,
Leach, P., Luotonen, A. and L. Stewart, "HTTP Authentication:
Basic and Digest Access Authentication", RFC 2617, June 1999.
[6] Rosenberg, J. and H. Schulzrinne, "Session Initiation Protocol
(SIP): Locating SIP Servers", RFC 3263, June 2002.
[7] Rosenberg, J., "Obtaining and Using Globally Routable User Agent
(UA) URIs (GRUU) in the Session Initiation Protocol (SIP)",
draft-ietf-sip-gruu-02 (work in progress), July 2004.
8.2 Informational References
[8] Rosenberg, J., "The Session Initiation Protocol (SIP) UPDATE
Method", RFC 3311, October 2002.
[9] Rosenberg, J., Peterson, J., Schulzrinne, H. and G. Camarillo,
"Best Current Practices for Third Party Call Control (3pcc) in
the Session Initiation Protocol (SIP)", BCP 85, RFC 3725, April
2004.
[10] Rosenberg, J., "A Presence Event Package for the Session
Initiation Protocol (SIP)", draft-ietf-simple-presence-10 (work
in progress), January 2003.
[11] Roach, A., "Session Initiation Protocol (SIP)-Specific Event
Notification", RFC 3265, June 2002.
[12] Sparks, R., "The Session Initiation Protocol (SIP) Refer
Method", RFC 3515, April 2003.
[13] Kohl, J. and B. Neuman, "The Kerberos Network Authentication
Mahy Expires January 15, 2005 [Page 13]
Internet-Draft SIP Connection Reuse July 2004
Service (V5)", RFC 1510, September 1993.
[14] Stewart, R., Xie, Q., Morneault, K., Sharp, C., Schwarzbauer,
H., Taylor, T., Rytina, I., Kalla, M., Zhang, L. and V. Paxson,
"Stream Control Transmission Protocol", RFC 2960, October 2000.
Author's Address
Rohan Mahy
Cisco Systems, Inc.
5617 Scotts Valley Dr
Scotts Valley, CA 95066
USA
EMail: rohan@cisco.com
Mahy Expires January 15, 2005 [Page 14]
Internet-Draft SIP Connection Reuse July 2004
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
intellectual property 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; neither does it represent that it
has made any effort to identify any such rights. Information on the
IETF's procedures with respect to rights in standards-track and
standards-related documentation can be found in BCP-11. Copies of
claims of rights made available for publication 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 implementors or users of this specification can
be obtained from the IETF Secretariat.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to practice
this standard. Please address the information to the IETF Executive
Director.
Full Copyright Statement
Copyright (C) The Internet Society (2004). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assignees.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
Mahy Expires January 15, 2005 [Page 15]
Internet-Draft SIP Connection Reuse July 2004
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Mahy Expires January 15, 2005 [Page 16]
