Example Call Flows of Race Conditions in the Session Initiation Protocol (SIP)
RFC 5407

Note: This ballot was opened for revision 06 and is now closed.

(Lisa Dusseault) Yes

(Jon Peterson) Yes

(Jari Arkko) No Objection

(Ron Bonica) No Objection

(Ross Callon) No Objection

(Lars Eggert) No Objection

Comment (2008-09-23 for -)
No email
send info
INTRODUCTION, paragraph 13:
>    This document gives examples call flows of race conditions in the
>    Session Initiation Protocol (SIP).  Race conditions are inherently
>    confusing and difficult to thwart; this document shows the best
>    practices to handle them.

  After reading the title, I was wondering why examples of race
  conditions are a BCP. I'd suggest to highlight in the title that the
  document also recommends practices to handle them.

Section 1.1., paragraph 2:
>    These flows do not assume specific underlying transport protocols
>    such as TCP, TLS, and UDP.  See the discussion in RFC 3261 [1] for
>    details of the transport issues for SIP.

  I believe this statement oversimplifies things. For example, the
  scenario in Section 3.1.1 shows the "180 F2" being lost and the
  following "200 F3" getting through. If SIP runs over TCP instead of
  UDP, this scenario is extremely unlikely, because an implementation is
  recommended to reuse the same TCP connection for subsequent SIP
  messages, which means that TCP will retransmit the "180 F2" until it
  is delivered, before it transmits the "200 F3". What I'm getting at is
  that the choice of transport will affect the likelihood of these race
  conditions. If some race conditions would be a less likely with
  SIP-over-TCP, it may be a good idea if this BCP document recommended
  SIP-over-TCP rather than SIP-over-UDP.

Section 200, paragraph 8:
>    /* F4 is a retransmission of F1.  They are exactly the same INVITE
>       request.  For UAs that have not dealt with bug report #769

  Where can the reader find bug report #769 and others? Please add a

(Pasi Eronen) (was Discuss) No Objection

(Russ Housley) No Objection

Comment (2008-10-09)
No email
send info
  The document title is could be more clear.  The document describes
  implementation pitfalls in SIP, not racing conditions.  The document
  suggests that implementation flaws can be avoided by paying attention
  to the asynchronous nature of the SIP message processing.  It seems
  that this document is similar to RFC 4718, IKEv2 Clarifications and
  Implementation Guidelines.  I suspect that a similar title that uses
  "clarifications" would be a better document title.

  Ben Campbell did a Gen-ART review of -05 and -06.  Some of his
  comments on -05 were addressed in -06, but some were not.  The 2nd
  review can be found at:


(Cullen Jennings) No Objection

(Chris Newman) No Objection

(Tim Polk) No Objection

Comment (2008-09-25 for -)
No email
send info
Section 3.1.4, para 3 seems to include conflicting recommendations.  In the first sentence,
"it is recommended that the UA return a 491..." but the next to last sentence states "This
example recommends that 200 be sent instead of 491..."

Perhaps the first recommendation was from some other document?

(Dan Romascanu) No Objection

(Mark Townsley) No Objection

(David Ward) No Objection

Magnus Westerlund No Objection

Comment (2008-10-09)
No email
send info
I have to support Lars's comment about the transport dependencies in some of these race condition. I would be happier if that was more explicitly pointed out.