draft-sparks-sip-nit-problems-01.txt   draft-sparks-sip-nit-problems-02.txt 
Network Working Group R. Sparks Network Working Group R. Sparks
Internet-Draft dynamicsoft Internet-Draft Xten
Expires: January 13, 2005 July 15, 2004 Expires: July 2, 2005 Jan 2005
Problems identified associated with the Session Initiation Protocol's Problems identified associated with the Session Initiation Protocol's
non-INVITE Transaction non-INVITE Transaction
draft-sparks-sip-nit-problems-01 draft-sparks-sip-nit-problems-02
Status of this Memo Status of this Memo
By submitting this Internet-Draft, I certify that any applicable This document is an Internet-Draft and is subject to all provisions
patent or other IPR claims of which I am aware have been disclosed, of section 3 of RFC 3667. By submitting this Internet-Draft, each
and any of which I become aware will be disclosed, in accordance with 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 become aware will be disclosed, in accordance with
RFC 3668. RFC 3668.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as other groups may also distribute working documents as
Internet-Drafts. Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on January 13, 2005. This Internet-Draft will expire on July 2, 2005.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2004). All Rights Reserved. Copyright (C) The Internet Society (2005).
Abstract Abstract
This draft describes several problems that have been identified with This draft describes several problems that have been identified with
the Session Initiation Protocol's non-INVITE transaction. the Session Initiation Protocol's non-INVITE transaction.
Table of Contents Table of Contents
1. Problems under the current specifications . . . . . . . . . . 3 1. Problems under the current specifications . . . . . . . . . . 3
1.1 NITs must complete immediately or risk losing a race . . . 3 1.1 NITs must complete immediately or risk losing a race . . . 3
1.2 Provisional responses can delay recovery from lost 1.2 Provisional responses can delay recovery from lost
final responses . . . . . . . . . . . . . . . . . . . . . 4 final responses . . . . . . . . . . . . . . . . . . . . . 4
1.3 Delayed responses will temporarily blacklist an element . 5 1.3 Delayed responses will temporarily blacklist an element . 5
1.4 408 for non-INVITE is not useful . . . . . . . . . . . . . 6 1.4 408 for non-INVITE is not useful . . . . . . . . . . . . . 7
1.5 Non-INVITE timeouts doom forking proxies . . . . . . . . . 8 1.5 Non-INVITE timeouts doom forking proxies . . . . . . . . . 8
1.6 Mismatched timer values make winning the race harder . . . 8 1.6 Mismatched timer values make winning the race harder . . . 8
2. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9 2. Security Considerations . . . . . . . . . . . . . . . . . . . 9
3. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
4. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9
5. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9
Author's Address . . . . . . . . . . . . . . . . . . . . . . . 9 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 9
Intellectual Property and Copyright Statements . . . . . . . . 10 Intellectual Property and Copyright Statements . . . . . . . . 10
1. Problems under the current specifications 1. Problems under the current specifications
There are a number of unpleasant edge conditions created by the SIP There are a number of unpleasant edge conditions created by the SIP
non-INVITE transaction model's fixed duration. The negative aspects non-INVITE transaction (NIT) model's fixed duration. The negative
of some of these are exacerbated by the effect provisional responses aspects of some of these are exacerbated by the effect provisional
have on the non-INVITE transaction state machines as currently responses have on the non-INVITE transaction state machines as
defined. currently defined.
1.1 NITs must complete immediately or risk losing a race 1.1 NITs must complete immediately or risk losing a race
The non-INVITE transaction defined in RFC 3261 [1] is designed to The non-INVITE transaction defined in RFC 3261 [1] is designed to
have a fixed and finite duration (dependent on T1). A consequence of have a fixed and finite duration (dependent on T1). A consequence of
this design is that participants must strive to complete the this design is that participants must strive to complete the
transaction as quickly as possible. Consider the race condition transaction as quickly as possible. Consider the race condition
shown in Figure 1. shown in Figure 1.
UAC UAS UAC UAS
skipping to change at page 3, line 41 skipping to change at page 3, line 41
| | | | | | | |
| | | | | | | |
v | | | v | | |
timeout <=== --- | 200 OK | | timeout <=== --- | 200 OK | |
| .---| v | .---| v
| .---' | --- | .---' | ---
|<--' | |<--' |
Figure 1: NI Race Condition Figure 1: NI Race Condition
The UAS in this figure believes it has responded to the request in The User Agent Server (UAS) in this figure believes it has responded
time, and that the request succeeded. The UAC, on the other hand, to the request in time, and that the request succeeded. The User
believes the request has timed-out, hence failed. No longer having a Agent Client (UAC), on the other hand, believes the request has
matching client transaction, the UAC core will ignore what it timed-out, hence failed. No longer having a matching client
believes to be a spurious response. As far as the UAC is concerned, transaction, the UAC core will ignore what it believes to be a
it received no response at all to its request. The ultimate result spurious response. As far as the UAC is concerned, it received no
is the UAS and UAC have conflicting views of the outcome of the response at all to its request. The ultimate result is the UAS and
transaction. UAC have conflicting views of the outcome of the transaction.
Therefore, a UAS cannot wait until the last possible moment to send a Therefore, a UAS cannot wait until the last possible moment to send a
final response within a NIT. It must, instead, send its response so final response within a NIT. It must, instead, send its response so
that it will arrive at the UAC before that UAC times out. that it will arrive at the UAC before that UAC times out.
Unfortunately, the UAS has no way to accurately measure the Unfortunately, the UAS has no way to accurately measure the
propagation time of the request or predict the propagation time of propagation time of the request or predict the propagation time of
the response. The uncertainty it faces is compounded by each proxy the response. The uncertainty it faces is compounded by each proxy
that participates in the transaction. Thus, the UAS's only choice is that participates in the transaction. Thus, the UAS's only choice is
to send its final response as soon as it possibly can and hope for to send its final response as soon as it possibly can and hope for
the best. the best.
skipping to change at page 5, line 47 skipping to change at page 5, line 47
| | | | | | | |
Figure 2: Provisionals can harm recovery Figure 2: Provisionals can harm recovery
No additional delay is introduced if the first provisional response No additional delay is introduced if the first provisional response
is received after Timer E has reached its maximum reset interval of is received after Timer E has reached its maximum reset interval of
T2. T2.
1.3 Delayed responses will temporarily blacklist an element 1.3 Delayed responses will temporarily blacklist an element
A SIP element's use of SRV is specified in RFC 3263 [2]. That A SIP element's use of DNS SRV Resource Records [3] is specified in
specification discusses how SIP assures high availability by having RFC 3263 [2]. That specification discusses how SIP assures high
upstream elements detect failure of downstream elements. It proceeds availability by having upstream elements detect failure of downstream
to define several types of failure detection and instructions for elements. It proceeds to define several types of failure detection
failover. Two of the behaviors it describes are important to this and instructions for failover. Two of the behaviors it describes are
document: important to this document:
o Within a transaction, transport failure is detected either through o Within a transaction, transport failure is detected either through
an explicit report from the transport layer or through timeout. an explicit report from the transport layer or through timeout.
Note specifically that timeout will indicates transport failure Note specifically that timeout will indicates transport failure
regardless of the transport in use. When transport failure is regardless of the transport in use. When transport failure is
detected, the request is retried at the next element from the detected, the request is retried at the next element from the
sorted results of the SRV query. sorted results of the SRV query.
o Between transactions, locations reporting temporary failure o Between transactions, locations reporting temporary failure
(through 503/Retry-After for example) are not used until their (through 503/Retry-After for example) are not used until their
requested black-out period expires. requested black-out period expires.
The specification notes the benefit of caching locations that are The specification notes the benefit of caching locations that are
successfully contacted, but does not discuss how such a cache is successfully contacted, but does not discuss how such a cache is
maintained. It is unclear whether an element should stop using maintained. It is unclear whether an element should stop using
(temporarily blacklist) a location returned in the SRV query that (temporarily blacklist) a location returned in the SRV query that
results in a transport error. If it does, when should such a results in a transport error. If it does, when should such a
location be removed from the blacklist? location be removed from the blacklist?
Without such a blacklist (or equivalent mechanism), the intended Without such a blacklist (or equivalent mechanism), the intended
availability mechanism fails miserably. Consider traffic between two availability mechanism fails miserably. Consider traffic between two
domains. Proxy pA in domain A needs to forward a sequence of domains. Proxy pA in domain A needs to forward a sequence of
skipping to change at page 9, line 5 skipping to change at page 9, line 9
placing two elements with different configured values for T1 and T2 placing two elements with different configured values for T1 and T2
on the same network. Review of Figure 1 illustrates that the race on the same network. Review of Figure 1 illustrates that the race
failure is only made more likely in this misconfigured state (it may failure is only made more likely in this misconfigured state (it may
appear that shortening T1 at the element behaving as a UAS improves appear that shortening T1 at the element behaving as a UAS improves
this particular situation, but remember that these elements may trade this particular situation, but remember that these elements may trade
roles on the next request). Since the protocol provides no mechanism roles on the next request). Since the protocol provides no mechanism
for discovering/negotiating a peer's timer values, exceptional care for discovering/negotiating a peer's timer values, exceptional care
must be taken when deploying systems with non-defaults to ensure they must be taken when deploying systems with non-defaults to ensure they
will _never_ directly communicate with elements with default values. will _never_ directly communicate with elements with default values.
2. Acknowledgments 2. Security Considerations
This document describes problems with the SIP non-INVITE transaction,
including mentioning potential security vulnerabilities. It does not
make any changes to the SIP protocol.
3. IANA Considerations
This document requires no action by IANA.
4. Acknowledgments
This document captures many conversations about non-INVITE issues. This document captures many conversations about non-INVITE issues.
Significant contributers include Ben Campbell, Gonzalo Camarillo, Significant contributers include Ben Campbell, Gonzalo Camarillo,
Steve Donovan, Rohan Mahy, Dan Petrie, Adam Roach, Jonathan Steve Donovan, Rohan Mahy, Dan Petrie, Adam Roach, Jonathan
Rosenberg, and Dean Willis. Rosenberg, and Dean Willis.
3 References 5 References
[1] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., [1] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP: Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP:
Session Initiation Protocol", RFC 3261, June 2002. Session Initiation Protocol", RFC 3261, June 2002.
[2] Rosenberg, J. and H. Schulzrinne, "Session Initiation Protocol [2] Rosenberg, J. and H. Schulzrinne, "Session Initiation Protocol
(SIP): Locating SIP Servers", RFC 3263, June 2002. (SIP): Locating SIP Servers", RFC 3263, June 2002.
[3] Gulbrandsen, A., Vixie, P. and L. Esibov, "A DNS RR for [3] Gulbrandsen, A., Vixie, P. and L. Esibov, "A DNS RR for
specifying the location of services (DNS SRV)", RFC 2782, specifying the location of services (DNS SRV)", RFC 2782,
February 2000. February 2000.
Author's Address Author's Address
Robert J. Sparks Robert J. Sparks
dynamicsoft Xten
5100 Tennyson Parkway 5100 Tennyson Parkway
Suite 1200 Suite 1000
Plano, TX 75024 Plano, TX 75024
EMail: rsparks@dynamicsoft.com EMail: rsparks@xten.com
Intellectual Property Statement Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights 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 might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be on the procedures with respect to rights in RFC documents can be
skipping to change at page 10, line 41 skipping to change at page 10, line 41
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement Copyright Statement
Copyright (C) The Internet Society (2004). This document is subject Copyright (C) The Internet Society (2005). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights. except as set forth therein, the authors retain all their rights.
Acknowledgment Acknowledgment
Funding for the RFC Editor function is currently provided by the Funding for the RFC Editor function is currently provided by the
Internet Society. Internet Society.
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/