Subject: [sip-clf] Section 5 of the ipfix sip-clf draft

From: Hadriel Kaplan <[email-masked]>
Date: Sat, 27 Mar 2010 23:34:31 -0400

It was pointed out to me in Anaheim that I am guilty of an embarrassing faux-pas.

Although I contributed text and thought I reviewed the latest draft, apparently I missed a paragraph:
   [OPEN ISSUES WITH THIS IE SET: sip(Request|From|To)URI duplicate an
   enormous amount of information; is there value in parsing these out?
   For example, do they not always share a scheme?  What about the host
   part; to what extent are these shared by To and Request, and how
   often are From and the sourceIPv[46]address the same?  Do hosts need
   to be stored as names or will addresses suffice?  What is a "tag"
   (From and To), and should it be separated; what structure does it
   have?  What, if any, structure is there to sip(Server|
   Client)Transaction: is this always just an opaque ASCII string?  Same
   question for sipCallId.  Even if there are not "always" answers, we
   can leverage templates here to significantly increase the efficiency
   of common cases while still handling technically legal but weird
   ones.  I'll start the box are bytefield drawing once these questions
   are answered; for now, here are tables describing the records.  Here
   I'm specifying separate request and response records, but parsing
   these and tracking them based on transaction associations seems
   somewhat cumbersome.  Is it possible to also provide a unified
   request/response template for the common case?  Are sip(Server|
   Client)Transaction always necessary, or just for forking and for
   associating requests to responses; can we leave them off otherwise?]

Had I noticed it, I would have been able to resolve it before submitting. :)

The answers are, in order of the questions in the paragraph above:
1) No, their scheme isn't always the same (though they're rarely different in practice).  And we're only talking about 4 bytes usually.
2) The To and Request URI's are often not the same, for the username or host parts.  
3) The From and source-IPv4 address are often not the same.
4) For the host-portion of the message's URI's, it will frequently be a hostname (and often not as well).  But that's separate from the layer-3 source/dest IP:port. (Btw, the example is missing the port numbers)
5) For the Call-ID and transaction-ID's, they're an opaque string.  For the case where the transaction-identifiers are locally generated values never seen on the wire, they may indeed be numbers of some form depending on implementation, but we can't force a particular implementation and anyway it's simpler to keep it consistent with branch-id's which are strings.
6) The "tag" refers to the SIP Message's To and From header "tag" parameters, which are used to identify the dialog (along with the call-id).
7) Yes, it's just an opaque string.  If it's from the branch-id, then in 3261-compliant devices it will always start with "z9hG4bK", but there're still rfc2543 devices out there which won't.  Regardless, it'll have to be treated as a full string.
8) It is possible to provide a common template for request and response, but since IPFIX makes it easy to define separate templates, and not all the fields are in both, it may make more sense to keep them separate I think.  For example, there is no such thing as a Request-URI for responses, and no such thing as a response status-code for requests.  And anyway if you combined them you'd have to have an explicit field which indicated which type it is, which is implicit in the template id if you keep them separate instead.
9) The transactions are basically always necessary, or will be often enough it makes little sense to have a template without them, imo.

-hadriel