Skip to main content

A Hitchhiker's Guide to the Session Initiation Protocol (SIP)


(Cullen Jennings)
(David Ward)
(Ron Bonica)

No Objection

(Chris Newman)
(Mark Townsley)
(Tim Polk)

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

Cullen Jennings Former IESG member
Yes () Unknown

Dan Romascanu Former IESG member
Yes (2008-10-23) Unknown
I believe that this is a very useful document. The following comments would IMO give more clarity: 

1. The document refers to a number of work-in-progress specifications, and for this reason I think that defining it in the Introduction as 'a guide to the SIP RFC series' is slightly mis-leading without noting that the document reflects a snapshot of the SIP standardization at the time of the publication and that some of the specifications refered here are work-in-progress and thus subject to change if and until they become RFCs. 

2. I think that it would be useful to provide more clarity to the last paragraph in the introduction that makes clear what the document is not. 

>  This document itself is not an update to RFC 3261 or an extension to
   SIP.  It is an informational document, meant to guide newcomers,
   implementors and deployers to the many of the specifications
   associated with SIP.

I would suggest to add something on the lines of 'This document does not define any minimal or maximal or other kind of profile for compliance for SIP or SIP-based applications'.

3. I think that the references sections would benefit from some kind of sorting. For a document that tries to make some order in the SIP jungle it is odd thaty there are like eight pages of references without any sorting (or any sorting I could make sense of). Sorting RFCs according to numbers and I-Ds alphabetically would ease the task of the reader who tries to find a reference without necessarily using t3ext search.

4. Section 11 should also include the SIP MIB (RFC 4780)
David Ward Former IESG member
Yes () Unknown

Ron Bonica Former IESG member
Yes () Unknown

Chris Newman Former IESG member
No Objection
No Objection () Unknown

Jari Arkko Former IESG member
No Objection
No Objection (2008-10-23) Unknown
Review by Christian Vogt:

Review of draft-ietf-sip-hitchhikers-guide-05

The SIP Hitchhikers Guide is a very useful synopsis of important
SIP-related specifications.  The RFC numbering scheme makes it difficult
to identify specifications of a common subject, so documents such as
this are of great help for navigating through large protocol suits such
as that of SIP.

This Hitchhiker's Guide certainly has publication quality, and it should
be published as soon as possible.  I do, however, have three suggestions
for increasing the usefulness of this document even further.  Perhaps
these could be taken into account before publication:

- The scoping of the Hitchhiker's Guide in section 2, which identifies
  the types of documents that are considered by the guide, is a bit
  complex because it consists of several rules and several exceptions.
  I would assume that the average reader couldn't tell, after all,
  whether documents for a particular purpose are in-scope or not.  Of
  course, I do acknowledge that, with the large set of SIP-related
  documents, it is not easy to come up with a crisp definition of
  which documents are "relevant" and which are not.  But perhaps a
  very simple approach would do the job:  I would suggest to simply
  state that those documents are included that are relevant to SIP or
  SDP in general, or to a large class of applications, and documents
  for a specific application are not.

- Why are neither requirements nor architecture documents in-scope of
  the Hitchhiker's Guide?  Requirements can be essential for defining
  the applicability of a method.  Architectures are important to
  understand how multiple methods fit together.  Shouldn't
  requirements and architecture documents therefore be in-scope of the
  Hitchhiker's Guide?  Of course, not all such documents can be listed
  due to their large number.  But perhaps the most relevant can.

- The first bullet in section 2 defines a SIP "extension" as a
  mechnanism that "changes or updates" SIP.  Since this definition
  differs from the common meaning of the word "extension", I suggest
  using the term "modification" instead.  This would also avoid
  confusion with later parts of the Hitchhiker's Guide, where the term
  "extension" is used in its common meaning.
Magnus Westerlund Former IESG member
No Objection
No Objection (2008-10-23) Unknown
Regarding RFC 3890, we know it is broken from a offer/answer perspective. Becuase TIAS values only makes fully sense in a sending direction and the reference to the handling of the other b= parameters makes it becomes a what I can receive. The text should maybe mention this.
Mark Townsley Former IESG member
No Objection
No Objection () Unknown

Pasi Eronen Former IESG member
No Objection
No Objection (2008-10-22) Unknown
Excellent work!

One comment about Section 15 (security mechanisms): should it 
mention Digest AKA (RFC 3310/4169)? Although technically it's an 
HTTP authentication mechanism, all the examples in RFC 3310 use SIP 
(and it has some details that don't actually work so well with HTTP).

For someone trying to understand the SIP security better, other
important pieces of information would be e.g. the "ipsec-3gpp"
mechanism (defined in 33.203 but mentioned in RFC 3329), MIKEY,
Kerberos/NTLM authentication for SIP (publicly documented, but 
not in IETF document AFAIK), and RFC 5090 (with many SIP-specific 
parts) -- but  I guess the scope has to be limited somehow (covering 
all SIP-related 3GPP specs would certainly reach the critical mass 
for a black hole :-)
Russ Housley Former IESG member
No Objection
No Objection (2008-10-23) Unknown
  The Gen-ART Review from Suresh Krishnan said: "This document is well
  written and well categorized. I do have a nagging feeling that this
  document will be outdated by the time it will be published."  So, the
  inclusion of some introduction text that warns readers that this is a
  It is possible to include some text that says something like snapshot
  of the relevant specifications and that updated versions of this
  document will be published periodically.
Tim Polk Former IESG member
No Objection
No Objection () Unknown