Subject: [Sip] bis-07 comments

From: "Bob Penfield" <[email-masked]>
Date: Wed, 13 Feb 2002 10:35:40 -0500

First I would like to express my appreciation for all the hard work of the
editors and the authors. Given the effort required to review this spec, I
can barely imagine the immense effort that has gone into producing this
document and incorporating the massive amount of comments and last minute
changes and features. This spec is truly light-years ahead of the early bis
versions in its organization and understandability. It is making the jobs of
all of us implementers easier. Thank you.

Now that you are sufficiently buttered up (: , here are my comments. I
apologize for any repeats.

Sec 8.1.1.3: (very minor nit) line 1011 says that the From should not
contain FQDNs, but the example at line 1025 has a FQDN.

sec 8.1.1.7: line 1070 says CANCEL is an exception to the unique branch id
rule. Isn't ACK also an exception?

sec 8.1.1.8: line 1103. Should the standard-track RFC rule also apply to
Proxy-Require?

sec 8.1.3.2: lines 1140-1144. 1xx needs to be an exception to the x00 rule
since 100 has many special rules that should not apply to 101-199.

sec 12.2.1.1: line 1888. change "and MUST a Route header" to "and MUST add a
Route header"

sec 12.2: line 1857-1861. If the open issue (#113) of allowing overlapping
non-INVITEs is still open, I vote we should allow them.

lines 2698-2702 describes Timer C as being a client transaction timer, yet
it no longer appears in the INVITE client transaction FSM in figure 5. Is
this really a TU timer? Would the removal of 100rel affect this?

line 2700 and 2731 (nit) The text indicates the minimum value of Timer C is
181 seconds. Should it be 180?

lines 2880-2881. The text should point out that the proxy should send a
CANCEL if and when it receives a provisional response on a branch whose
client transaction is in the "calling" state.

sec 16.7: lines 2889-2890: A little bit more is needed here. Does the proxy
generate a 408 upstream? or just silently discard all state? CANCEL can only
be sent on branches that received a 1xx.

sec 17.1.2.2: lines 3275-3279. What should timer E be set to when entering
the "Proceeding" state? T2?

sec 19: line 3576. This is the only mention of T3 I could find in the spec.
What is it?

sec 20.4.0.1 (line 3880) should be 20.4.1.

sec 25: line 5440 (really minor nit) in the 4xx class, values in the 42x
range have been defined so its not just x80 upwards.

line 5610: The startline of the example is not formatted properly
change "485 Ambiguous SIP/2.0" to "SIP/2.0 485 Ambiguous"

line 5990: response code 409 is listed in Client-Error, but not described in
section 25.

line 5990: response code 421 is missing from Client-Error.

line 5991: response code 513 is missing from Server-Error.

sec 28: lines 6047-6050. Does there need to be a provision for the case of
an I-D expiring and never becoming an RFC?

cheers,
(-:bob

Robert F. Penfield
Chief Software Architect
Acme Packet, Inc.
130 New Boston Street
Woburn, MA 01801
[email-masked]

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

---

From: Robert Sparks <[email-masked]>
Date: Sun, 17 Feb 2002 21:00:26 -0600

These are handled.
(except for one point with an inline question below)

RjS

> client transaction is in the "calling" state.

I'm not sure I know what you're suggesting. Maybe your talking about the
edge where a client transaction is in calling when a proxy decides to cancel
outstanding transactions (so it doesn't send an immediate cancel), but a
provisional arrives before the transaction is torn down?

> be sent on branches that received a 1xx.

More text added. If the branch gets torn down without sending a CANCEL, the
proxy would act like the branch received a 408 (but not add it to the response
context). If it is able to send a CANCEL, the final response for the INVITE
(hopefully a 487) would go into the context).

> the "Proceeding" state? T2?

Let it run from whatever it was set to while in Trying.
Remember that this is a non-invite Client transaction, you're not really
supposed to be getting provisional responses anyhow. Non-invites should
complete quickly. If you _did_ receive a provisional, reset the timer,
and the final response got lost, you'ld be adding T2-(however much time
was left in E before you reset it) to your recovery time.

> sec 19: line 3576. This is the only mention of T3 I could find in the spec.

A vestigal feature from previous versions of the spec. It's gone now.

> an I-D expiring and never becoming an RFC?

If I understand the way this works this would be asking the folks who let the
draft lapse to clean up their garbage. I suspect it would be wasted effort.