INTERNET-DRAFT SIPPING WG
February 2003 Rajnish Jain
Expires: August 2003 Vijay K. Gurbani
Lucent Technologies
Requirements for Persistent Connection Management in the Session
Initiation Protocol (SIP)
draft-jain-sipping-persistent-conn-reqs-00.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 August 1, 2003.
Copyright Notice
Copyright ¨ The Internet Society (2003). All Rights Reserved.
Jain Expires - August 2003 [Page 1]
Internet-Draft Persistent Connection Reqs February 2003
Abstract
SIP over connection-oriented transport protocol based systems are
likely to face certain distinct performance and behavioral issues
that are not manifest when SIP is transported over connectionless
protocols. Allowing SIP entities to mutually conserve connections
over a predictable, extended period of time is one of the leading
requirements to help SIP entities deliver their optimal
performance in the network. Overall, this document contemplates
transport layer connection management issues relating to SIP.
Requirements and potential solutions for introducing a backward
compatible notion of persistent connections in SIP are presented.
Applicability Statement
The means and procedures described in this Internet-Draft are
most applicable in scenarios where there is a high volume of
signaling traffic between two SIP entities, or the need to
maintain a long-term trusted, peering relationship between them.
Examples of such scenarios are much-used signaling paths between
two proxies belonging to different service providers, or the
signaling path between a SIP User Agent Client (UAC) and its
default outbound proxy.
Table of Contents
1. Conventions used in this document.............................3
2. Introduction..................................................3
3. Connection utilization aspects of SIP RFC 3261 [1]............4
4. Connection utilization aspects of connect-reuse draft[2]......6
5. SIP Transport Layer Connection Management.....................7
6. Advantages of Persistent Connections.........................10
6.1 Performance Efficiency...................................10
6.2 Resources Efficiency.....................................10
6.3 Application Behavior Enabling............................10
7. Requirements.................................................11
8. Proposed Solutions...........................................11
8.1 New Via header field parameter...........................12
8.2 New SIP header...........................................12
8.3 New transport token......................................13
9. Security Considerations......................................13
10. IANA Considerations.........................................14
11. Acknowledgements............................................14
Jain Expires - August 2003 [Page 2]
Internet-Draft Persistent Connection Reqs February 2003
1. Conventions used in this document
In this document, the key words "MUST", "MUST NOT","REQUIRED",
"SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED",
"MAY", and "OPTIONAL" are to be interpreted as described in
RFC2119[2] and indicate requirement levels for compliant SIP
implementations.
2. Introduction
SIP [1] being an application layer protocol is stacked above the
transport layer in the Internet Protocol model. Although SIP
tends to be loosely coupled with transport layer, certain aspects
of SIP entities are somewhat influenced by (or can benefit from)
the workings of vastly diverse transport layer protocols. For
instance, connection-oriented transport protocols (such as TCP,
SCTP, and TLS over TCP) demand more systemic resources and
introduce latencies to provide their salient features in contrast
with their connectionless counterparts (such as UDP). As a
result, the dynamics of a connection oriented transport protocol
are likely to produce somewhat of a ripple effect on the entire
SIP entity. Evidently, in order to minimize the negative
performance and scaling impact caused by excessive connections,
SIP implementers may benefit from standardized mechanisms to
expend connections cautiously.
In general, SIP is currently quite liberal in setting up and
tearing down transport layer connections. Per [1], transport
layer connections should be opened, closed, and recycled at the
discretion of individual implementations. To prevent lingering of
low traffic connections, section 18 of [1] guides implementers to
close connections after an implementation-defined amount of idle
time. Depending on the interpretation of [1] by the implementer,
the idle time can range from 32s (T1*64) to infinity (thereby
keeping the connection open forever; however, there are problems
with this interpretation of "infinity", as will be discussed
later). In a multi-vendor SIP network, diverse SIP entities will
thus vastly differ in their discretion of connection idle timeout
periods and connection reuse policies. Such discrepancies will
manifest themselves into inter-operability chaos and inefficient
network performance. The connect-reuse Internet-Draft[2] presents
a few scenarios where performance degradation is evident.
Typically, connections between SIP entities frequently age out
due to sporadic traffic patterns, if they are maintained at all
beyond a transactionÆs lifetime. Connections are always deemed
ephemeral in nature and are shut down without any consensus
Jain Expires - August 2003 [Page 3]
Internet-Draft Persistent Connection Reqs February 2003
between interacting SIP entities. To that end, several
opportunities are missed where SIP entities would best serve the
network if they communicate over persistent connections that are
setup and torn down predictably. Unfortunately, connections are
currently torn down by either side due to lack of communication
of such intent from one entity to another using a SIP construct.
The need for persistent connections has been recognized by other
IETF protocols as well. The HTTP protocol provides a good
foundation for the need for persistent connections (see section
8.1 of [5]). In fact, an argument can be made that in HTTP, once
the client has downloaded a page with inline images and other
associated data from a server, subsequent requests may not go
back to the same server. This is not true in SIP, where once a
client has established a dialog with a server, subsequent
requests always go to the same server (or an intermediary proxy
if the proxy Record-RouteÆd or is the default outbound proxy).
Thus it appears that just as HTTP benefited from persistent
connections, so can SIP.
3. Connection utilization aspects of SIP RFC 3261 [1]
SIP currently supports a few scenarios that facilitate
connection conservation. Figure 1. below shows a typical SIP
trapezoid arrangement with end-points Ea and Eb and their default
out-bound proxy servers Pa and Pb, respectively.
--Ca2b-->
Pa . . . . . .Pb
. .
. .
Ea . . . . . . . . . Eb
Figure 1: Typical SIP trapezoid.
For illustration purpose it is assumed that Pa and Pb are in a
peering relationship and communicate over a connection-oriented
transport protocol. The call flow begins with Pa receiving an
INVITE from Ea (for Eb). As a result, Pa originates a transport
layer connection to Pb called Ca2b and puts call request to Pb
over that connection. Per SIP [1], the following message
exchanges will likely recycle connection Ca2b further down the
call flow:
1. Responses from Pb to Pa
2. New requests from Pa to Pb
Jain Expires - August 2003 [Page 4]
Internet-Draft Persistent Connection Reqs February 2003
It is worth noting that new requests from Pa to Pb will have the
opportunity to recycle connection Ca2b, only if the connection is
found active at the time new requests arrive. If there is a
significant time gap between two requests from Pa to Pb, it is
likely that connection Ca2b would age out and be closed before
the later request arrives. In this case, a new request from Pa to
Pb will have to trigger a new connection. This problem can be
alleviated by making PaÆs implementation-defined timer
substantially large. However, that approach manifests a bigger
scaling issue, as Pa would then tend to exhibit that behavior
universally with every SIP entity (including end-points) it
initiates a connection to. Furthermore, Pa and Pb may vastly
differ in their discretion of transport layer idle timeouts.
Assuming that Pa tends to be ôliberalö (smaller timeout) and Pb
ôconservativeö (larger timeout), when it comes to cycling through
transport connections, Pa can swamp Pb with transport layer
connection setup and tear down requests. This may negatively
influence overall functioning of Pb. Likewise, numerous under
utilized lingering connections may lend themselves to scaling and
performance issues. Therefore, some technique is required for
selectively making the implementation-defined timer large on a
per entity pair relationship basis.
Apart from transactions from Pa to Pb, new transactions initiated
from Pb to Pa are most unlikely to recycle connection Ca2b
despite of it being active. The reason is that normally SIP
treats connections as ephemeral, as indicated in the following
text from section 18 of [1]:
ôNote that, because the source port is often ephemeral, but it
cannot be known whether it is ephemeral or selected through
procedures in [4], connections accepted by the transport layer
will frequently not be reused. The result is that two proxies in
a "peering" relationship using a connection-oriented transport
frequently will have two connections in use, one for transactions
initiated in each direction.ö
Given the method described in [1], proxy server Pb is faced with
two subtly distinct dilemmas in recycling connection Ca2b.
Firstly, Pb cannot rely on the availability of the Ca2b
connection for a required time period as the connection was
originally created by Pa, and therefore can be preempted (torn
down) by Pa at PaÆs own discretion. Pb has no idea whether PaÆs
Ca2b connection is meant to be persistent or ephemeral. Giving
the benefit of doubt to the ephemeral case, Pb will be unable to
recycle connection Ca2b for transporting its transactions to Pa
(unless the implementer is willing to take the risk of mid-
transaction connection closure and handle consequences
thereafter).
Jain Expires - August 2003 [Page 5]
Internet-Draft Persistent Connection Reqs February 2003
Secondly, Pb has no way to know from Pa if it is welcome to (or
forced to) use the Ca2b connection for requests from Pb to Pa. It
is quite likely that an implementation of Pa may not be set up to
accept new requests within an existing dialog on any other port
than the standard SIP port numbers (5060 for UDP, TCP and SCTP,
5061 for TLS over TCP, or TLS over SCTP). If Pb were to use the
Ca2b connection for requests to Pa, the requests will arrive at
PaÆs source port for Ca2b connection, which may not necessarily
be a standard SIP port number.
Given that [1] does not provide a way for Pa and Pb to
communicate their connection usage methods, Pb will most likely
originate a new transport layer connection to Pa called Cb2a for
transport of Pb to Pa transactions. Figure 2 below shows
simultaneous existence of Ca2b and Cb2a connections.
--Ca2b-->
Pa . . . . . .Pb
. <--Cb2a-- .
. .
Ea . . . . . . . . . Eb
Figure 2. Two connections for SIP messages.
4. Connection utilization aspects of connect-reuse draft[2]
Quite likely, the Cb2a connection, as mentioned in previous
section, is unnecessary when Ca2b connection is active. Reference
[2] acknowledges this issue. It presents requirements and
proposes a mechanism for Ca2b connection reuse for transactions
initiated from Pb to Pa. It recommends that a new Via header
field parameter (called ôaliasö) be added in a request from Pa to
Pb, to imply that Pb is allowed to (and should) reuse the Ca2b
connection.
The technique presented in [2] is quite efficient and flexible in
eliminating the need for a Cb2a connection when Ca2b connection
is active. However, the technique tends to solve only the second
dilemma mentioned in section 3. While it enables Pa to tell Pb
that Pb is welcome to (and perhaps should) use the Ca2b
connection for Pb to Pa requests, it leaves out the connection
longevity aspect. Pb, under conformance to [2], still cannot rely
on the availability of Ca2b connection for a required time
period.
Furthermore, the technique presented in [2] ignores a potential
hint/forced aspect for connection reuse request. That is, does Pa
simply desire a connection reuse or absolutely require it when it
Jain Expires - August 2003 [Page 6]
Internet-Draft Persistent Connection Reqs February 2003
puts out the ôaliasö field in the Via header. On one hand, Pa may
want to hint Pb to reuse Ca2b connection (for performance
optimization e.g.). In this scenario Pb can somewhat leverage
itsÆ own judgment to honor or deny the request. On other hand, Pa
may want to force request Pb to reuse Ca2b connection (when Pa
is behind a NAT e.g.). A forced request may not guarantee that a
persistent connection will be granted. However, any notion and/or
vocabuluary for indicating hint/forced request would likely be
useful.
Evidently, a scheme that allows SIP entities to communicate their
transport layer connection reuse policy (including longevity and
hint/forced aspects) with each other is necessary. Such a scheme
would not only allow SIP implementations to cautiously expend
transport layer connections to provide optimal performance, but
also accomplish certain application layer requirements.
Accordingly, this draft goes beyond [2] and presents requirements
and proposals for introducing needful vocabulary in SIP the
management of persistent transport layer connections.
5. SIP Transport Layer Connection Management
Management of transport layer connections can be premised on
diverse stimuli and policies. Typically such discretions arise
from SIP traffic profiles, SIP entity relationships, application
behaviors, underlying platform support, etc. For instance, two
high throughput proxy servers in a peering relationship will
greatly benefit if they cautiously conserve intermediary
connections. Whereas, a SIP phone that occasionally places or
receives call is perhaps best suited to liberally expend
connections. The tradeoff between expending new connections
versus persisting and resusing connections will likely be driven
by the utilization rate of the connections.
In connection-oriented transport layer protocols, a connection
instance is somewhat mutually owned by both client and server
sides. Both sides commit their resources and maintain per
connection finite state machines. Therefore, broadly speaking,
connection management should be considered and allowed to be a
cooperative onus of the connected entities. Application entities
on the two sides of a connection should be allowed to communicate
their connection management information of mutual interest over
an application layer protocol. In SIP based networks with diverse
SIP entities, the connection management behaviors cannot be base-
lined; however, given that the roles of SIP entities are well
defined, a few broad classes of connection management can be
defined that represent every SIP entity in the network.
Jain Expires - August 2003 [Page 7]
Internet-Draft Persistent Connection Reqs February 2003
Based on SIP traffic profiles and application behaviors, diverse
requirements for connection management are expected to fall into
the following three classes:
1. Uni-directional ephemeral connections
2. Bi-directional ephemeral connections
3. Persistent connections
Uni-directional ephemeral connections carry transactions
initiated by one side only (the side that actively sought out the
connection). They age out at the isolated discretion of
individual implementations. Typically, connections that become
idle for an implementation-defined period of time are closed.
Either party is allowed to close such type of connections once a
transaction has completed and another one is not in progress.
Choosing a large connection idle time period on the originator
side alone does not guarantee that these connections will be
long-lived. Accordingly, SIP entities should inherently assume
these connections to be ephemeral in nature. These are
essentially the type of connections described in section 18 of
[1]. Connections Ca2b and Cb2a in figure 2 of this draft are
unidirectional ephemeral connections.
Bi-directional ephemeral connections carry transactions initiated
by both sides. These connections further leverage upon the fact
that at the transport layer, connections are inherently unbiased
(peer-to-peer) during data transfer phase. These connections
(also) age out at the isolated discretion of individual
implementations. Typically, connections that become idle for an
implementation-defined period of time are closed. Either party is
allowed to close such type of connections once a transaction has
completed and another one is not in progress. Choosing a large
connection idle time period on one side alone does not guarantee
that these connections will be long-lived. Since SIP does not
allow peering entities to communicate their connection idle time
periods, each SIP entity should, therefore, inherently assume
these connections to be ephemeral in nature. These are
essentially the ôaliasö parameter driven connections described in
[2].
Bi-directional ephemeral connections essentially start out as
uni-directional connections, but on solicitation from the
original uni-directional side to another they become bi-
directional. Bi-directional connections do not occur
automatically. They arise from a 2-way handshake, such that they
are firstly solicited by one side and succeed upon acceptance
from the other side. For instance, in the Pa/Pb example, Pb
should not generally deem Ca2b connection bi-directional unless
Pa requests it. Upon request, Pb is allowed to accept or deny the
Jain Expires - August 2003 [Page 8]
Internet-Draft Persistent Connection Reqs February 2003
request to reuse the connection. Figure 3 below shows a bi-
directional ephemeral connection between Pa and Pb called Ca+b.
<-Ca+b->
Pa . . . . . .Pb
. .
. .
Ea . . . . . . . . . Eb
Figure 3. Bi-directional ephemeral connections.
Persistent connections, in contrast with ephemeral connections,
do not age out due to connection idle timeouts typically caused
by sporadic SIP traffic patterns. Persistent connections are
driven by the application logic above SIP and therefore are most
predictable. Once established between two SIP entities as a
result of a dialog-initiating transaction, these connections
persist beyond the transaction's lifetime, and in fact, even
beyond the dialog's lifetime. Their closure may be expected
(scheduled downtime, TLS certificate expiration) or unexpected
(system crash), however, the remaining peer should construe any
such closure as an indication to release resources on its side of
the connection. Neither side explicitly closes these connections
under normal circumstances. These connections are expected to
endure regardless of SIP message traffic patterns. Their typical
usage would be between two SIP entities that are kind of ôhard
wiredö together based on the network architecture. Figure 4 below
shows a persistent connection between Pa and Pb called Ca&b.
<-Ca&b->
Pa . . . . . .Pb
. .
. .
Ea . . . . . . . . . Eb
Figure 4. Persistent Connections.
Note: Is there any need to further sub-divide persistent
connections into 2: uni-directional persistent connections and
bi-directional persistent connections? As a prelude to a
discussion, consider that a TCP socket, once opened, is bi-
directional. Thus, it would seem appropriate to carry over the
same semantics to a persistent connection. On the other hand,
certain SIP clients may want to assure the downstream server that
they will keep the connection persistent and not close it down
after the transaction is over (uni-directional persistent), but
Jain Expires - August 2003 [Page 9]
Internet-Draft Persistent Connection Reqs February 2003
if the downstream entity wants to send a new request, it can open
up a new uni-directional persistent connection on its own, which
will be honored.
6. Advantages of Persistent Connections
Persistent connections can potentially be advantageous in many
ways. This section presents some of their evident advantages.
6.1 Performance Efficiency
As mentioned earlier, connection establishment takes time,
contributes extra RTTs, and is subject to slow-start. TCP itself
requires a 3-way handshake to agree on window sizes and sequence
numbers before the first byte of payload data is exchanged
between peers. TLS over TCP endures an even longer delay as both
parties are authenticated. Such delays can vary from being
mildly irritable to causing signaling and media to become out of
lockstep (for example, subjecting a re-INVITE putting media on
hold to re-establish credentials between two or more intervening
proxies can add several round-trip times between the time a user
presses the "Hold" button to when the media is actually put on
hold). A persistent connection between signaling entities along
the path would alleviate the need to establish a new ephemeral
connection for such services.
6.2 Resources Efficiency
Every connection entails precious system resources. Each time a
socket is opened between peers, the hosts allocate control
blocks, buffers, descriptors and other resources in the kernel
for the subsequent exchange of data. Simultaneously,
implementation of TCP and SCTP layers instantiate and maintain
per connection finite state machines. Every active connection
entails processor cycles for connection state management for
maintaing timers etc. Additionally, connections closed by
application layer linger in TIME-WAIT state in transport layer,
and therefore consume resources. As the number of simultaneously
active connections rise, so does the burden on the transport
layer and therefore the entire entity. It would appear that in
peering arrangements (or in cases of a UAC and its default
outbound proxy), these machinations could be avoided since the
intent is to reuse the connection between the peers.
6.3 Application Behavior Enabling
Apart from facilitating efficiencies, persistent connections can
possibly enable certain application behaviors. For instance, if
Pa is behind a NAT, persistent connections (or even bi-
Jain Expires - August 2003 [Page 10]
Internet-Draft Persistent Connection Reqs February 2003
directional ephemeral connections) allow Pb to place calls to Pa
on the connection established by Pa.
Additionally, active persistent connections allow SIP entities
to somewhat rely on up-and-running state of their peers and
relative prompt delivery of messages. This aspect can be
considered by a SIP entity that intends to route an emergency
call. Evidently, preference can be given to active persistent
connections among other alternatives that all lead to the
intended destination.
Upon realizing graceless closure of a persistent connection, a
SIP entity can perhaps take certain proactive measures. For
instance, ingress calls arriving during new connection
establishment phase can promptly be egressed via other paths
allowed by the network.
7. Requirements
The following items present requirements on the SIP protocol for
connection management between two interacting SIP entities:
1. The mechanism provided for persistent connection management
should accommodate needs for diverse kinds of SIP entities.
2. The mechanism provided should allow SIP entities to utilize
persistent connections at their own discretion.
3. The mechanism provided should allow SIP entities to manage
connections in consultation with their peers.
4. The mechanism provided should allow SIP entities to request
unidirectional ephemeral, bi-directional ephemeral or
persistent connections.
5. The mechanism provided should prevent a SIP entity that
liberally expends connections from swamping another peer
entity.
6. The mechanism provided should be such that a SIP entity that
supports this Internet-Draft automatically honors requests
from entities supporting [2] and [1].
8. Proposed Solutions
This section presents three potential solutions to connection
management information exchange between two SIP entities. The
intent is to have one solution; however, such a solution would
Jain Expires - August 2003 [Page 11]
Internet-Draft Persistent Connection Reqs February 2003
benefit from a discussion involving a larger audience as
represented by the IETF SIPPING WG.
8.1 New Via header field parameter
The first solution is to extend the via-params parameter of the
Via header as follows:
via-params = via-ttl / via-maddr / via-received / via-branch /
via-connection
via-connection = "persistent"
The advantage of this solution is that the presence of the
"persistent" Via parameter serves as a hint to the server on the
intention of the originator of the connection. The originator
guarantees to leave the connection up beyond the transaction's
and the dialogÆs lifetime. It is now up to the server to either
honor the persistency and send subsequent requests (in the same
dialog or on separate dialogs) on the same socket, or to close
the socket after the transaction is over. In the event that the
server closes the socket after the transaction, the client
reverts to existing behavior by freeing up any resources and
attempting a new connection to the same downstream server on
subsequent requests.
The disadvantage of this solution is that it does not provide for
a negotiation on the time frame that the socket remains open.
The next solution addresses this very disadvantage.
8.2 New SIP header
The second solution is to implement an extension that allows for
negotiation for the acquiescence and longevity of a persistent
connection. Under this solution, a client that seeks a persistent
connection will:
(1) Insert a "Supported" header (to provide a hint) or a
ôRequiredö/ôProxy-Requiredö header (goes beyond a hint)
with the option tag "persistence", indicating support for
this extension.
(2) Insert a "persistent" Via parameter as described in the
previous section. The client MAY also include a header
called "Persistent-Timeout" to indicate an upper bound on
the time it will allow for the socket to remain open. If
this header is not present, a value of infinity is assumed
(i.e. the client will not, under normal operations, close
the socket).
Jain Expires - August 2003 [Page 12]
Internet-Draft Persistent Connection Reqs February 2003
A receiving server, if it supports the extension in this
Internet-Draft, can honor the request depending on its policies
with respect to persistent connections and the presence (or
absence) of the "Persistent-Timeout" header. If a server wants
to decrease (or increase) the timeout value, it will send a 4xx
response (exact number to be determined) along with a "Min-
Persistence" header that indicates its desire on the longevity of
the persistent connection. The client is expected to retry the
request again with the "Persistent-Timeout" parameter containing
a value of MIN("Persistence-Timeout", "Min-Persistence").
The advantage of this solution is that it allows the client to
force the server into accepting a persistence connection (through
the use of the ôRequiredö or ôProxy-Requiredö header). A server
can also simply provide a hint (by using ôSupportedö) and leave
it to the client to further use the persistent connection. The
client and server can also negotiate an upper bound on the time
the connection will be left persistence.
The disadvantage of this solution is that it goes beyond the
"hint" nature of a transparent solution. At this point, some
more discussion would be helpful to understand if such a
offer/counter-offer/answer mechanism is desired.
<BNF for "Supported", ôRequireö, ôProxy-Requireö, "Persistent-
Timeout" and "Min-Persistence" to be added later>.
8.3 New transport token
A third option is to use a new token called ôPTCPö for persistent
TCP in the transport position of the Via header:
Via: SIP/2.0/PTCP somehost.example.com
The advantage of this option is that clients can actively seek
out servers that support persistence connections by querying DNS
SRV records using the new transport designator.
The disadvantage is that no negotiation is provided for
negotiating longevity of the persistent connection; once opened,
it remains so until the server or client are brought down
normally (TLS certificate expiration, scheduled downtime), or
abnormally (system crash).
9. Security Considerations
Persistent connections provide more opportunities for denial-of-
service class of attacks if the server blindly accepts every such
connection request. As this I-D matures, some guidelines will
need to be established for accepting such connections. Obviously
authentication is not the only requiste for acceptance; a server
Jain Expires - August 2003 [Page 13]
Internet-Draft Persistent Connection Reqs February 2003
may successfully authenticate many downstream clients, but will
only want to establish persistent connections with a small subset
of these.
Other possible security aspects include session hi-jacking.
This section is thus a work in progress as the I-D matures.
10. IANA Considerations
<To be provided>
11. Acknowledgements
Thanks to Eric Colasanto, James Ford, Cullen Jennings, Aby
Kuriakose, Sarit Galanos Mekler, Sean Olson, and Victor Saverino
for providing valuable input on the issues addressed in this
draft.
Thanks to Rohan Mahy for writing connect-reuse Internet-Draft,
which provides foundation for this draft.
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] Mahy, R., "Requirements for Connection Reuse in the Session
Initiation Protocol (SIP)",
draft-ietf-sipping-connect-reuse-reqs00 (work in progress),
October 2002.
[3] Dierks, T., Allen, C., Treese, W., Karlton, P., Freier, A.
and P. Kocher, "The TLS Protocol Version 1.0", RFC 2246,
January 1999.
Informational References
[4] 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.
[5] R. Fielding, J. Gettys, J. Mogul, H. Frystyk, L. Masinter,
P.Leach and T. Berners-Lee, ôHyperText Transfer Protocol û
HTTP 1.1ö, IETF RFC 2616, June 1999.
Jain Expires - August 2003 [Page 14]
Internet-Draft Persistent Connection Reqs February 2003
Author's Addresses
Rajnish Jain
Lucent Technologies, Inc.
75 Perseverance Way,
Hyannis, MA 02601, US
Email: rajnishjain@lucent.com
Vijay K. Gurbani
Lucent Technologies, Inc.
2000 Lucent Lane
Rm 6G-440
Naperville, IL 60566, US
Email: vkg@lucent.com
Full Copyright Statement
Copyright (C) The Internet Society (2003). 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 assigns.
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 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY
IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR
PURPOSE.
Jain Expires - August 2003 [Page 15]