Subject: [Sipping] Summary: SIP CLF format discussion

From: "Vijay K. Gurbani" <[email-masked]>
Date: Fri, 13 Feb 2009 10:40:52 -0600

Folks: Some of you may remember the discussion Dale and I had
on the list last week around the SIP CLF draft.  I will like
to produce a summary of that discussion for those of you
who were following it.

First off, a great note of appreciation to Dale for taking his
time to provide in-depth comments.  The next revision will
include much of his comments.

Next, the main area of discussion in the thread was what
constitutes a message in the context of CLF logging: is
it how rfc3261 describes it?  That is, a SIP request is
one message, a response is another message, and so on?
Or does message = SIP request +
                   0 or more provisional responses +
                   1 final response

Dale was advocating uniformity in producing one line per
message (i.e., a request takes up a line, a response takes
up another line, and so on.)  I believe this is a good thing.

So, on the basic issue of what constitutes a message, we are
now in agreement (thanks, RjS!), and better yet, that
agreement sticks to the rfc3261 definition of a message.

The exact nature of logging the SIP CLF elements is complex.
It seems to me that in order to reduce the complexity, we can
say that a SIP CLF is composed of:

   sip-clf      :=  request-clf / response-clf
   request-clf  := %d %h %u %m %r %f %t %i "%c" %x %y
   response-clf := %d %x %y %s %t "%c"

Note, I have taken %s out of request-clf (i.e., we do not
put the response -- provisional or final -- in the
request-clf line.  It goes in the response-clf line.)

This way, the CLF entries are common across UAS, UAC, proxies,
B2BUAs, etc.  Each CLF entries for UAS and UAC would have exactly
one request-clf line (a message) and one or more
response-clf lines (messages).  CLF entries for proxies and
B2BUAs can have more than one request-clf lines and more than
one response-clf lines.

I will have a new revision out sometimes next week.

Thanks,

- 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/

---

From: "Dale Worley" <[email-masked]>
Date: Fri, 13 Feb 2009 17:13:20 -0500

>                    0 or more provisional responses +

"1 or more final responses"!

Or should that be "0 or more final responses", since we might not
receive a final response?

Dale

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Fri, 13 Feb 2009 16:27:53 -0600

> receive a final response?

Pedantically speaking, it should be "0 or 1 final response".
Under what condition would you get more than 1 final response
for the same transaction from a downstream forking proxy?

IIRC, we had a corner case in rfc2543 where proxies used to
forward a 6xx or a 2xx upstream immediately, whichever came
first.  So, if a 6xx came first and was forwarded, a 2xx
would also be forwarded if it arrived after the 6xx (since a
2xx-class response cannot be quashed at a proxy.)  This corner
case was fixed in rfc3261, so I'd be surprised if a rfc3261
forking proxy sends multiple final responses upstream.

Thanks,

- vijay

---

From: "Dale Worley" <[email-masked]>
Date: Mon, 16 Feb 2009 16:19:19 -0500

> for the same transaction from a downstream forking proxy?

If a call was parallel-forked to two UAs and both were answered at the
same instant, both UAs would send 200s upstream, and they would both
reach the UAC.

If a request was sent with "Request-Disposition: no-cancel", then we
expect to routinely receive multiple success responses.  And for
SUBSCRIBEs, a strong argument can be made that no-cancel should be the
default mode of processing -- we've considered doing so in sipX.

Dale

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Mon, 16 Feb 2009 16:29:55 -0600

> default mode of processing -- we've considered doing so in sipX.

Ah, OK -- you are talking about intermediaries implementing
rfc3841.

For SIP CLF, I am working with the base model of rfc3261 processing
in place where receiving multiple final responses is prohibited
from happening (unless a UAC forks off multiple requests itself
and is prepared to deal with the consequences.)

At this point, I am not sure what to do with rfc3841.  This
certainly adds a level of complexity -- not as much to the
production of SIP CLF, but rather to the training of various
automata.

Thanks,

- vijay

---

From: Robert Sparks <[email-masked]>
Date: Tue, 17 Feb 2009 09:45:07 -0600

You can have multiple 200-INVITEs without 3841. Its a race, but we  
show at SIPits that its not hard to realize the scenario under normal  
conditions.
Throw in some packetloss and it can even become a likely outcome.

RjS

On Feb 16, 2009, at 4:29 PM, Vijay K. Gurbani wrote:

> _______________________________________________
> Sipping mailing list  https://www.ietf.org/mailman/listinfo/sipping
> This list is for NEW development of the application of SIP
> Use [email-masked] for questions on current sip
> Use [email-masked] for new developments of core SIP

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Tue, 17 Feb 2009 10:00:50 -0600

Robert Sparks wrote:
> conditions. Throw in some packetloss and it can even become a likely
> outcome.

Yes, of course.  I had (conveniently) forgotten that all 2xx-class
responses to INVITE had to be forwarded upstream regardless of a
previous 2xx having been sent upstream.

Thanks,

- vijay