Dale Worley wrote:
It would help if you replace "method" with "request" throughout,
since "method" seems to be normally used to refer to only the method
specified in a request, not the request as a whole.
Dale: Sure, that is a good suggestion (and I must really thank
you for going through the draft with a fine toothcomb. More inline.)
That makes sense, but I don't see a statement up front saying "one
CLF line is generated upon the receipt of each SIP message (request
or response) and one CLF is generated upon the transmission of each
SIP message". One has to deduce from various examples that these are
the events that generate CLF lines.
Hmm ... our operating model was that a CLF generated by
UASes (i.e., not proxies or proxy-like B2BUAs) will result in one
line that contains all the necessary information elements (including
the response. This, of course means, that for an INVITE, the
UAS may not generate a CLF until a final response is sent out;
and a UAC may not generate a CLF until a final response is
received.)
Practically, this means that a UAC that received multiple
provisional responses for an INVITE will not log these individually,
and a UAS that sends multiple provisional responses for an
INVITE will not log these individually. I think it is a safe
bet to go this route and reduce some complexity when a CLF
for a UAC or UAS is being produced. What do others think?
I am assuming here that all provisional responses (received and sent)
are to be logged.
For a proxy or proxy-like B2BUA, yes; all provisionals are
logged, as are all final responses received in case of forking.
But perhaps I am running up against a philosophical problem -- Is the
intention to log SIP *messages*, or to log *transactions*? In the
Ah, good question. Our intent was that for UAC and UAS, we will
log *messages*. Because a proxy (or a proxy-like B2BUA) is a
transactional entity, and because such an entity may not know
the exact nature of the response until some transformation on
the request has been made, they have to be *transactional*
entities.
The idea of using one line to give both request and response data is
natural for an HTTP server, where both happen at nearly the same
moment. But in SIP, in at least half its actions, even a UA will be a
client, where the request and response may be separated by a
substantial time.
Right; but this is true only for the INVITE request; it is this
request that is allowed to pend in SIP. The remaining requests
elicit a quick final response; thus for UAS and UAC, it makes sense
to use one line for the request and response (and take a bit of a
hit in form of a delay for the INVITE request.)
The entity to which a request is sent downstream is not reliably
identified by the R-URI, due to all the rules in RFC 3263.
True, and it gets even murkier than this when you consider that
the topmost Route -- if present -- is used to route the requests,
thereby by-passing the R-URI completely. But regardless, we
felt that logging the R-URI is sufficient since it demonstrates
the intent of where the request was destined to. Presumably
to figure out the problem you mention below ...
(Consider an element sending a request sequentially to several
different resolutions of the R-URI in attempt to find a server that
is functioning.) Given our experience with sipX, I would strongly
recommend that the triple "transport/host IP address/port" be logged
for all sent messages. Otherwise CLF will be useless for diagnosing
routing actions at the RFC 3263 level.
there would be some other debugging hooks in the code. In other
words, I don't think that it is fruitful to turn the CLF in a
debugging aid. What do you think? Other opinions?
But it doesn't look like %c is the contact URIs, but rather the
contact name-addrs, based on the second example in section 4.1.4. In
that case, there is a lot more trouble, because a name-addr can
contain a quote.
Consider the particularly ugly example:
Contact: <sip:123@xxxxxxxxxxx>;param=" value1 value2 "
Hmmm ... yes, you are right. One way would be to use other
symbols in the CLF to delimit %c. [ and ] come to mind.
But there is no way for a CLF parser that supports extensions to
determine which extensions are present, other than heuristically.
Maybe that this is particularly important. Perhaps we could require
that extensions start with a field formatted "token[" and end with a
field "]", so a parser could identify the start, end, and type of
each extension without specific knowledge of all extensions?
If it is deemed that adding other fields to the CLF is required,
and that a off-the-shelf CLF parser should not choke on these
fields, then we could certainly do what you suggest. I would
go further and say that such "extensions" should appear after
the the normal CLF fields have taken up their positions on a
line.
Given that %x and %y are present in response lines, and those
identify the other requests/responses in the transaction, and
indirectly the dialog, why is the to-tag (in %t) needed?
Because it may not be the case that the To-tag has been set
when the provisional response is sent out. Thus we cannot
always depend on the To-tag being part of the request CLF
line if the request CLF line only contains a provisional.
Looking at %x and %y, the server and client transaction identifiers,
I see six cases:
[...]
Based on this, it seems like the "FORK/" and "CLIENT/" are redundant,
and %y could be defined as "'-' for server transactions and the
transaction identifier for client transactions".
I believe that retaining FORK and CLIENT directive make the intent
apparent for a human reader. The syntax, if not the intent, of
these are modeled after the Squid web proxy CLF format.
Also, the definitions given in 4.1.1 aren't quite correct. E.g., one
example shows a REGISTER server transaction with no server
transaction id given (because the transmitted response is folded into
the same CLF line that logs the request), but the description of %x
doesn't say that it can be omitted in that circumstance.
OK ... we can tighten up the text to say that %x can be omitted
if the final response is on the request-CLF line.
Thanks, once again, Dale for your thorough read-through.
- vijay
--
Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60566 (USA)
Email: vkg@{alcatel-lucent.com,bell-labs.com,acm.org}
Web: http://ect.bell-labs.com/who/vkg/
_______________________________________________
Sipping mailing list https://www.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors@xxxxxxxxxxxxxxx for questions on current sip
Use sip@xxxxxxxx for new developments of core SIP
