SIP WG R. Mahy
Internet-Draft SIP Edge LLC
Expires: August 5, 2006 V. Gurbani, Ed.
Lucent Technologies, Inc./Bell
Laboratories
B. Tate
BroadSoft
February 2006
Connection Reuse in the Session Initiation Protocol (SIP)
draft-ietf-sip-connect-reuse-05.txt
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 August 5, 2006.
Copyright Notice
Copyright (C) The Internet Society (2006).
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
Mahy, et al. Expires August 5, 2006 [Page 1]
Internet-Draft SIP Connection Reuse February 2006
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 in
environments where the connection could be opened in either
direction.
Table of Contents
1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Applicability Statement . . . . . . . . . . . . . . . . . . 3
3. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
4. Benefits of Connection Reuse . . . . . . . . . . . . . . . . 5
5. Overview of Operation . . . . . . . . . . . . . . . . . . . 6
6. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 8
7. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . 8
8. Normative Behavior . . . . . . . . . . . . . . . . . . . . . 8
8.1 Client Behavior . . . . . . . . . . . . . . . . . . . . . 9
8.2 Server Behavior . . . . . . . . . . . . . . . . . . . . . 10
9. Security Considerations . . . . . . . . . . . . . . . . . . 11
9.1 Authenticating TLS Client Connections . . . . . . . . . . 11
9.2 Authenticating TLS Server Connections . . . . . . . . . . 11
9.3 Security Considerations for the TCP Transport . . . . . . 11
10. Connection Reuse and SRV Interaction . . . . . . . . . . . . 13
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . 13
12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 14
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 14
13.1 Normative References . . . . . . . . . . . . . . . . . . 14
13.2 Informational References . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 15
Intellectual Property and Copyright Statements . . . . . . . 16
Mahy, et al. Expires August 5, 2006 [Page 2]
Internet-Draft SIP Connection Reuse February 2006
1. 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 [3].
Additional terminology used in this document:
Advertised address: The address that occurs in the Via sent-by
production rule, including the port number and transport.
Alias: A transport layer connection associated with a resolved
address.
Resolved address: The address of a user agent (including port
number and transport) retrieved from the DNS resolution contained
in RFC3263 [5].
2. Applicability Statement
The applicability of the mechanism described in this document is for
two adjacent SIP entities to reuse connections when they are agnostic
about the direction of the connection, i.e., either end can initiate
the connection. SIP entities that can only open a connection in a
specific direction -- perhaps because of Network Address Translation
(NAT) and firewall reasons -- reuse their connections using the
mechanism described in [1].
The connect reuse mechanism described in this document is defined
only for Transport Layer Security (TLS) transports. Specifically,
implementations MUST NOT use this mechanism for the TCP transport due
to the possible attacks that can be launched with connection reuse
over TCP. Such attacks and alternative methods for connection reuse
over TCP are described in Section 9.3.
3. Introduction
SIP [2] entities can communicate using either unreliable/
connectionless (e.g., UDP) or reliable/connection-oriented (e.g.,
TCP, SCTP [11]) 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.
Mahy, et al. Expires August 5, 2006 [Page 3]
Internet-Draft SIP Connection Reuse February 2006
+-----------+ 8293 (UAC) 5061 (UAS) +-----------+
| |--------------------------->| |
| Entity | | Entity |
| A | | B |
| | 5061 (UAS) | |
+-----------+ +-----------+
Figure 1: Uni-directional connection for requests from A to B.
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 --
in the example above, requests from B destined to A -- 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 |
| |<-----------------------| |
+-----------+ +-----------+
Figure 2: Two connections for requests between A and B.
Opening an extra connection where an existing one is sufficient can
result in potential scaling and performance problems. 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.
Mahy, et al. Expires August 5, 2006 [Page 4]
Internet-Draft SIP Connection Reuse February 2006
Proxy A Proxy B
| |
Create connection 1 +---INV--->|
| |
|<---200---+ Response over connection 1
| |
Re-use connection 1 +---ACK--->|
| |
= =
| |
|<---BYE---+ Create connection 2
| |
Response over +---200--->|
connection 2
Figure 3: Multiple connections for requests.
Thus, it is advantageous to reuse connections whenever possible.
4. Benefits of Connection Reuse
Opening an extra connection where an existing one is sufficient can
result in potential scaling and performance problems. For example,
each new connection using TLS requires a TCP 3-way handshake, a
handful of round-trips to establish TLS, typically expensive
asymmetric authentication and key generation algorithms, and
certificate verification. This effectively doubles the load on each
entity. Setting up a second connection (from B to A above) for
subsequent requests, even requests in the context of an existing
dialog (e.g., re-INVITE or BYE after an initial INVITE, or a NOTIFY
after a SUBSCRIBE [10] or a REFER [9]), can also cause excessive
delay (especially in networks with long round-trip times).
ReINVITEs or UPDATE [7] 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 [8] use many
reINVITEs).
The mechanism described in this document can mitigate the delays
associated with subsequent requests.
Mahy, et al. Expires August 5, 2006 [Page 5]
Internet-Draft SIP Connection Reuse February 2006
5. Overview of Operation
This section is tutorial in nature, and does not specify any
normative behavior.
The act of reusing a connection is initiated by an user agent client
(UAC, or the proxy half of the UAC) when it adds an "alias" parameter
to the added Via header (the parameter itself is defined later).
When a user agent server (UAS, or the proxy half of the UAS) receives
the request, it examines the topmost Via header. If the header
contained an "alias" parameter, the UAS establishes a binding such
that subsequent requests going to the UAC will reuse the connection.
We now explain this working in more detail in the context of
communication between two adjacent proxies. Without any loss of
generality, it should be clear that the same technique can be used
for connection reuse between a UAC and an edge proxy, or between an
edge proxy and a UAS, or between an UAC and an UAS.
P1 and P2 are proxies responsible for routing SIP requests through
user agents that use them as edge proxies (see Figure 4).
P1 P2
p1.example.com p2.example.com
(192.0.2.1) (192.0.2.128)
Figure 4: Proxy setup.
This document is concerned with specifying an extension to SIP for
connection reuse at the receiving end; i.e., reusing the connection
when P2 wants to send a request to P1. However, it should be clear
that P1 can reuse a connection previously established with P2. In
fact, the SIP community recommends that clients reuse a connection
previously established with a server for subsequent transactions
going to the same resolved address. Thus, the reuse property of a
connection, once it is established, is bi-directional and alias
tables may be maintained at both P1 and P2.
P1 gets a request from one of its upstream user agents, and after
performing RFC3263 server selection, arrives at a destination address
of P2. P1 maintains an alias table, and it populates the alias table
with the IP address, port number, and transport of P2 as determined
through RFC3263 server selection. P1 adds an "alias" parameter to
the topmost Via header (inserted by it) before sending the request to
P2. The value in the sent-by production rule of the Via header
(including the port number), and the transport over which the request
was sent becomes the advertised address of P1:
Via: SIP/2.0/TLS p1.example.com;branch=z9hG4bKa7c8dze;alias
Mahy, et al. Expires August 5, 2006 [Page 6]
Internet-Draft SIP Connection Reuse February 2006
Assuming that P1 does not have an existing aliased connection with
P2, P1 now opens a connection with P2. Upon connection
authentication and acceptance, it adds P2s to its alias table. P1's
alias table now looks like:
Destination Destination Destination Alias Connection
IP Address Port Transport Descriptor
...
192.0.2.128 5061 TLS 25
Subsequent requests that traverse from P1 to P2 will reuse this
connection; i.e., the requests will be sent over the descriptor 25.
When P2 receives the request, it may add a "received" parameter to
the topmost Via and examines the topmost Via to determine whether P1
supports aliased connections. The Via at P2 now looks like:
Via: SIP/2.0/TLS p1.example.com;branch=z9hG4bKa7c8dze;alias;
received=192.0.2.1
The presence of the "alias" parameter indicates that P1 does support
aliasing. P2 now authenticates the connection and if the
authentication was successful, P2 creates an alias to P1 using the
advertised address in the topmost Via. P2's alias table looks like:
Destination Destination Destination Alias Connection
IP Address Port Transport Descriptor
...
192.0.2.1 5061 TLS 18
There are two items of interest here:
1. Note that the entry in the last column for P2's alias table is
the descriptor over which the connection was passively accepted.
When P2 gets a request from one of its user agents, and
determines through RFC3263 server resolution that the request
should be sent to P1 over TLS using the default port (5061), it
will reuse the aliased connection accessible to it through
descriptor 18 instead of opening a new connection.
2. The network address inserted in the "Destination IP Address"
column should be the source address as seen by P2 (i.e., the
"received" parameter). It could be the case that the host name
of P1 resolves to different IP addresses due to round-robin DNS.
However, the aliased connection is to be established with the
original sender of the request.
To implement connection aliases for resolved addresses, 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
Mahy, et al. Expires August 5, 2006 [Page 7]
Internet-Draft SIP Connection Reuse February 2006
structure in which it keeps active connection state so that aliases,
active connections, and blacklisted nodes are all discovered when
looking for an active connection.
6. Requirements
1. A connection sharing mechanism SHOULD allow SIP entities to reuse
existing connections for requests and responses originated from
either peer in the connection.
2. A connection sharing mechanism MUST NOT require UACs (clients) to
send all traffic from well-know SIP ports.
3. A connection sharing mechanism MUST NOT require configuring
ephemeral port numbers in DNS.
4. A connection sharing mechanism MUST prevent unauthorized
hijacking of other connections.
5. Connection sharing SHOULD persist across SIP transactions and
dialogs.
6. There is no requirement to share a complete path for ordinary
connection reuse. Hop-by-hop connection sharing is more
appropriate.
7. Formal Syntax
The following syntax specification uses the augmented Backus-Naur
Form (BNF) as described in RFC 4234 [6]. This document extends the
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"
8. Normative Behavior
This document specifies how to reuse connections. 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 automatically drop connections on
completion of a transaction or termination of a dialog.
An alias is formed at the receiver of a request when it gets a
request with the "alias" parameter in the topmost Via header. If the
receiver decides to accept the alias, then the alias corresponds to
the source IP address, transport, and port (if one exists in the Via
sent-by, or the default port if it does not) of the sender of the
Mahy, et al. Expires August 5, 2006 [Page 8]
Internet-Draft SIP Connection Reuse February 2006
request. Whenever the RFC3263 server selection mechanism executed at
the receiver results in the choice of this IP address, port, and
transport tuple, the alias MUST be used instead.
Note that at the receiver, the responses are sent over the same
connection as specified by RFC3261. The aliasing mechanism at the
receiver allows subsequent requests going from the receiver to the
original sender of the request to reuse the same connection.
An alias is formed at the sender of the request when it executes the
RFC3263 server selection mechanism to arrive at an IP address, port,
and transport tuple to send a request to. Subsequent requests going
to the same destination address MUST use the alias instead.
Only one alias SHOULD exist for the resolved address. If more than
one alias is requested because of race conditions (or any other
reasons), the receiver SHOULD consider the latest alias to be the
desired alias. The receiver MUST NOT interpret the situation as a
desire for load balancing between the aliases.
Because an alias connection might be reclaimed during a transaction,
clients SHOULD NOT enforce the RFC 3261 requirement of sending CANCEL
and ACK (for non 2xx responses) to the same port. If the alias
connection no longer exists, the client SHOULD open a new connection
to the resolved address and send the CANCEL or ACK there instead.
The newly opened connection MAY be inserted into the alias table.
8.1 Client 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 client wants to create a transport layer alias. The client
places its advertised address in the Via header field value (in the
"sent-by" production).
The implications of placing an "alias" parameter in the topmost Via
header of a request must be understood by the client. Specifically,
this means that the client MUST keep the connection open for as long
as the resources on the host operating system allow it to, and that
it MUST accept requests over this connection -- as opposed to a
default listening port -- from its downstream peer. And furthermore,
it MUST reuse the connection when subsequent requests in the same or
different transactions are destined to the same resolved address.
Note that RFC3261 states that a response should arrive over the
same connection that was opened for a request.
Whether or not to allow an aliased connection ultimately depends on
Mahy, et al. Expires August 5, 2006 [Page 9]
Internet-Draft SIP Connection Reuse February 2006
the recepient of the request. Thus, clients MUST NOT assume that the
acceptance of a request by a server automatically enables connection
aliasing. They MUST continue receiving requests on their default
port.
Clients must be prepared for the case that the connection no longer
exists when they are ready to send a subsequent request over it.
This may happen if the peer ran out of operating system resources and
had to close the connection. In such a case, a new connection MUST
be opened to the resolved address and the alias table updated
accordingly.
Clients must authenticate the connection before forming an alias.
Section 9.1 discusses the authentication steps in more detail.
8.2 Server Behavior
When a server receives a request whose topmost Via header contains an
"alias" parameter, it signifies that the upstream client will leave
the connection open beyond the transaction and dialog lifetime, and
that subsequent transactions and dialogs that are destined to a
resolved address that matches the identifiers in the advertised
address in the topmost Via header can reuse this connection.
Whether or not to honor an aliased connection ultimately depends on
the policies of the server. It MAY choose to honor it, and thereby
send subsequent requests over the aliased connection. If the server
chooses not to honor an aliased connection, it MUST allow the request
to proceed as though the "alias" parameter was not present in the
topmost Via header.
This assures interoperability with RFC3261 server behavior.
Clients should feel comfortable including the "alias" parameter
without fear that the server will reject the SIP request because
of its presence.
Servers MUST be prepared to deal with the case that the aliased
connection no longer exist when they are ready to send a subsequent
request over it. This may happen if the peer ran out of operating
system resources and had to close the connection. In such a case, a
new connection MUST be opened to the resolved address and the alias
table updated accordingly.
If the Via sent-by contains a port, it MUST be used as a destination
port. Otherwise the default port is the destination port.
Servers must authenticate the connection before forming an alias.
Section 9.2 discusses the authentication steps in more detail.
Mahy, et al. Expires August 5, 2006 [Page 10]
Internet-Draft SIP Connection Reuse February 2006
9. Security Considerations
This document presents requirements and a mechanism for reusing
existing connections easily. Unauthenticated connection reuse would
present many opportunities for rampant abuse and hijacking.
Authenticating 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.
9.1 Authenticating TLS Client Connections
When a TLS client establishes a connection with a server, it is
presented with the server's X.509 certificate. The client MUST
ensure that the canonical host name of the server is present either
as the distinguished name (DN) of the Subject field or as a DNS URI
in the subjectAltName X.509v3 extension before updating its alias
table with the resolved address.
9.2 Authenticating TLS Server Connections
A TLS server conformant to this specification MUST ask for a client
certificate; if the client possesses a certificate, it will be
presented to the server for mutual authentication. The server MUST
ensure that the canonical host name of the client is present either
as the distinguished name (DN) of the Subject field or as a DNS URI
in the subjectAltName X.509v3 extension before updating its alias
table. If the client does not have a certificate, it is RECOMMENDED
that servers issue a 403 response with the reason phrase set to
"Certificate Required for Alias" to provide a more descriptive reason
for rejection to a human user. The TLS connection should be closed
immediately since accepting such a connection and establishing an
alias would be tantamount to using an encrypted channel for TCP but
still exposing the server to the same types of attacks described in
Section 9.3.
9.3 Security Considerations for the TCP Transport
Connection reuse over TCP is inherently insecure. Because the nature
of the aliasing mechanism is such that it redirects requests destined
for one port at a host to another port, service hi-jacking can result
if adequate care is not taken to ensure that the redirected port is
indeed authorized to receive the requests that would normally have
gone to another, authorized port. Consider the following scenario to
understand the service hi-jacking attack that can be mounted when
using connection reuse over TCP.
A TCP server receives a request with the "alias" parameter as follows
Mahy, et al. Expires August 5, 2006 [Page 11]
Internet-Draft SIP Connection Reuse February 2006
(the "received" parameter is added by the server after getting the
request):
Via: SIP/2.0/TCP uac.example.com;branch=z9hG4bKa7c8dze;alias;
received=192.0.4.33
From the server's perspective, its alias table is updated such that
whenever a request is destined to 192.0.4.33, port 5060, it will
instead be sent to the peer at the end of the aliased connection.
The security attack can now be mounted as follows: assume a malware
program is running on a multi-user computer. The malware program
knows that a user on the computer runs a SIP user agent, but the SIP
user agent is currently not active (possibly by scanning ports on the
local machine to seek a busy port 5060). Note that the malware
program does not need to wait until the legitimate user agent was not
running, however, doing so increases the chances that the server will
not reject the malware program's request. Once the malware program
decides that a legitimate user agent is not running, it sends sends a
request to the server with an "alias" parameter. The server believes
it is accepting a request from a legitimate user agent and sends
subsequent requests to the aliased connection. The SIP service on
the computer has now effectively been hi-jacked for the default port.
The malware program does not need administrative privileges to
execute, and in fact, can masquerade as any user (legitimate or not)
of the computer.
Later on, when the legitimate user agent is started, it may also send
a request with an "alias" parameter to the server, which may detect
that it now has two aliased connections. Making matters much worse,
it cannot determine which of the two is the legitimate one and may
well reject the request from the legitimate user.
In another form of this attack, the legitimate user agent may not
support connection aliasing, but the malware program may use the
mechanism to usurp the SIP service on the computer.
In yet another form of an attack, the malware program uses the
aliasing mechanism to shortcut registering with a proxy to receive
requests. In this case, it sends a request to the edge proxy (who
may also substitute as the inbound proxy with access to a location
service for that domain). In the request is a bogus request URI that
will cause the edge proxy to fail the request, however, the edge
proxy keeps the connection open and any subsequent requests destined
to that host on the default port are instead sent to the malware
program. Registration is thus not needed in order to receive
incoming requests.
HTTP Digest is useful to mitigate only a subset of these attacks over
Mahy, et al. Expires August 5, 2006 [Page 12]
Internet-Draft SIP Connection Reuse February 2006
TCP. For instance, HTTP Digest helps in authenticating a user agent
to a proxy server before the alias table is updated. However, HTTP
Digest is of no help when one proxy desires to enter an aliasing
agreement with another downstream proxy.
Keeping in view the possible attacks for TCP connection reuse
documented here and the limited help provided by HTTP Digest to
mitigate these attacks, it is recommended that TCP peers that want to
avail of connection reuse do so such that each peer actively opens up
a TCP connection in the direction of the other (as depicted in Figure
2). This manner of opening connections, while still not secure, is
at least much more apparent and direct than using the connection
reuse mechanism over TCP in an unauthenticated fashion.
10. Connection Reuse and SRV Interaction
Connection reuse has an interaction with the DNS SRV load balancing
mechanism. To understand the interaction, consider the following
figure:
/+---- S1
+-------+/
| Proxy |------- S2
+-------+\
\+---- S3
Figure 5: Load balancing.
Here, the proxy uses DNS SRV to load balance across the three
servers, S1, S2, and S3. Using the connect reuse mechanism specified
in this document, over time the proxy will maintain a distinct
aliased connection to each of the servers. However, once this is
done, subsequent traffic is load balanced across the three downstream
servers in the normal manner.
11. 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
Mahy, et al. Expires August 5, 2006 [Page 13]
Internet-Draft SIP Connection Reuse February 2006
12. 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.
13. References
13.1 Normative References
[1] Jennings, C. and R. Mahy, "Managing Client Initiated Connections
in the Session Initiation Protocol (SIP)",
draft-ietf-sip-outbound-01.txt (work in progress), October 2005.
[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] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", RFC 2119, March 1997.
[4] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",
RFC 2246, January 1999.
[5] Rosenberg, J. and H. Schulzrinne, "Session Initiation Protocol
(SIP): Locating SIP Servers", RFC 3263, June 2002.
[6] Crocker, D. and P. Overell, "ABNF for Syntax
Specifications'>Augmented BNF for Syntax Specifications: ABNF",
RFC 4234, October 2005.
13.2 Informational References
[7] Rosenberg, J., "The Session Initiation Protocol (SIP) UPDATE
Method", RFC 3311, September 2002.
[8] Rosenberg, J., Peterson, J., Schulzrinne, H., and H. Camarillo,
"Best Current Practices for Third Party Call Control (3pcc) in
the Session Initiation Protocol (SIP)", RFC 3725, April 2004.
[9] Sparks, R., "The Session Initiation Protocol (SIP) Refer
Method", RFC 3515, April 2003.
[10] Roach, A., "The Session Initiation Protocol (SIP)-Specific
Event Notification", RFC 3265, June 2002.
[11] Stewart, R., Xie, Q., Morneault, K., Sharp, C., Schwarzbauer,
H., Taylor, T., Rytina, I., Kalla, M., Zhang, L., and V.
Mahy, et al. Expires August 5, 2006 [Page 14]
Internet-Draft SIP Connection Reuse February 2006
Paxson, "The Session Initiation Protocol (SIP)-Specific Event
Notification", RFC 2960, October 2000.
Authors' Addresses
Rohan Mahy
SIP Edge LLC
Email: rohan@ekabal.com
Vijay K. Gurbani (editor)
Lucent Technologies, Inc./Bell Laboratories
Email: vkg at acm dot org
Brett Tate
BroadSoft
Email: brett@broadsoft.com
Mahy, et al. Expires August 5, 2006 [Page 15]
Internet-Draft SIP Connection Reuse February 2006
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.
Disclaimer of Validity
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 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.
Copyright Statement
Copyright (C) The Internet Society (2006). 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.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Mahy, et al. Expires August 5, 2006 [Page 16]
