Subject: [Sip] bis-06 comments

From: Anders Kristensen <[email-masked]>
Date: Sat, 02 Feb 2002 19:35:41 -0500

Some minor comments on bis-06.

"Note that both the transaction corresponding to the original request 
and the CANCEL transaction will 1453
complete independently. However, a UAC canceling a request cannot rely 
on receiving a 487 (Request 1454
Terminated) response for the original request, as an RFC 2543-compliant 
UAS will not generate such a 1455
response. If there is no final response for the original request in 
64*T1 seconds (T1 is defined in Section 1456
17.1.1.1), the client SHOULD then consider the original transaction 
cancelled and SHOULD destroy the client 1457
transaction handling the original request. 1458"

Not that it really matters, but shouldn't this really be 64*T1 minus 
however long the transaction has been in the Calling state?

"A dialog can also be in the "early" state, which occurs when it is 
created with a provisional response, and then transition to the 
"confirmed" state when the final response comes. 1812"

  - or to the "terminated" state, depending on the status code. 
Evidently, there's a dialog state machine hiding in there. Maybe it 
should be made explicit.

When a 1xx to an initial INVITE does contain a To tag, this 1xx and not 
a subsequent final response, establishes the dialog. Text like

"When a UAS responds to a request with a response that establishes a 
dialog (such as a 2xx to INVITE), the 1824
UAS MUST copy all Record-Route headers from the request into the 
response (including the URIs, URI 1825
parameters, and any Record-Route header parameters, whether they are 
known or unknown to the UAS) 1826
and MUST maintain the order of those headers. The UAS MUST add a Contact 
header field to the response. 1827"

then applies to the 1xx but not necessarily to the 2xx (as I read it), 
meaning that a 200 to an INVITE might legally not contain Record-Route 
and Contact. This is probably unfortunate and unintended.  BTW, 180's in 
the Examples section doesn't include R-R and Contacts.

1xx's other than 100 now MUST always be given a To tag. This puts extra 
work load on dialog-stateful proxies and I don't really see what the 
point of such a requirement would be.

"13.2.2.2 3xx responses A 3xx response may contain a Contact header 
field providing new addresses 2084
where the callee might be reachable. Depending on the status code of the 
3xx response (see Section 25.3) 2085
the UAC MAY choose to try those new addresses. 2086"

Actually, "the UAC MAY choose to try those new addresses" regardless of 
the actual 3xx.

"A 300 (Multiple Choices), 301 (Moved Permanently) or 302 (Moved 
Temporarily) response SHOULD contain 2168
a Contact header field containing URIs of new addresses to be tried. 2169"

Should be "SHOULD contain one or more...".

""the wire". In this case, the UAC will receive a 2xx to the 
INVITE.ItSHOULD then terminate the call by 2306
following the procedures described in Section 15.1.1. 2307"

I'd suggest making this a MUST or remove the upper-case requirement 
altogether.

"a proxy performing load balancing may route a BYE without a Route 
header field in a different way than the INVITE,since 2317
both requests have different CSeq sequence numbers. 2318"

That's not what section 24.2 USED to say (in bis-05):  "More 
specifically, once a request is delivered successfully to a par- ticular 
next hop, all subsequent requests with the same Call-ID MUST be 
delivered to that next hop. 4187".  Mind you, this was obviously bogus 
anyway, as the route being constructed might dictate otherwise.

I'm confused about section 24.2. There doesn't seem to be any note about 
it's disappearance in the Changes. Is it supposed to be replaced by 
draft-ietf-sip-srv-04.txt? That draft and what was 24.2 doesn't seem to 
have very much in common (in the sense of shared text), in particular 
the quote above isn't in the draft.

"If the domain of the Request-URI indicates a domain this element is not 
responsible for, it SHOULD set 2109
the next hop URI to the Request-URI, and leave the IP address, port and 
transport of the next hop empty. 2110"

Hmm, isn't it really up to the proxy itself to decide where to route 
such an incoming request? The suggested behaviour is a good default but 
it's not wrong to make different decisions, right?

"If this proxy wishes to request to remain on the path of future 
requests in this dialog, it MUST insert a Record-Route header value 
(Section refsec:record-route) into the copy before any existing Record- 2225
Route header values. 2226"

- should be "If this proxy wishes to request to remain on the path of 
future requests in this dialog *and* this is an initial request *and* 
the request potentially establishes a dialog..."?

"The Request-URI will be different each time the request passes through. 
2250"

Is this necessarily so?

"If the proxy chooses to recurse on a 3xx class response, it MUST NOT 
add the response to the response 2327
context 2328"

What if the proxy *partially* recursed, e.g. if it tried all sip URLs 
but not mailto and http URLs? In this case it makes sense to return a 
3xx with just those Contacts that haven't been tried. Maybe the best way 
to view this situation is as if such a 3xx had been received from a 
"virtual" branch.

"If a 6xx response is received, it is not immediately forwarded, but the 
stateful proxy SHOULD cancel 2334
all pending transactions as described in Section 9. 2335"

... "and no new branches can be created in this context."

Seems to me the majority of SHOULD/SHOULD NOT items in 17.1.1.2 should 
be MUST/MUST NOT.

Anders

_______________________________________________
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: Jonathan Rosenberg <[email-masked]>
Date: Mon, 11 Feb 2002 15:23:29 -0500

Anders, thanks for your comments. Responses inline.

> however long the transaction has been in the Calling state?

No, I think its right as written. Lets say I send an INVITE, and then
get a 1xx. Then, I CANCEL. The CANCEL is received a the UAS. The UAS
begins to send a final response at that point, or will never do so (for
older UAS). The tiemr needs to be large enough to cover the case where
the UAS is sending the final response, but there are network problems.
The UAS will continue to retransmit that final response for 64*T1 after
receiving the cancel, and this is how long the UAC needs to wait.

>   - or to the "terminated" state, depending on the status code.

Good point. I will clarify that it goes to confirmed only for a 2xx on
that dialog. For other response codes, or for a timeout after the last
2xx, it terminates.

> Evidently, there's a dialog state machine hiding in there. Maybe it

I think its simple enough that a textual description will suffice. I
think the spec is long enough as it is ;)

> and Contact. This is probably unfortunate and unintended. 

How do you read that? The text explicitly calls out 2xx to INVITE. The
text in section 12.1 is also very explicit on which responses create
dialogs.

> BTW, 180's in

Well, there is no RR because there is no record-routing, but there ought
to be  a contact. I've fixed that.

> point of such a requirement would be.

This is being discussed in another thread, and also amongst the editors.
We're working it.

> Actually, "the UAC MAY choose to try those new addresses" regardless of

Sure, but this section is talking about 3xx, and I think its worth
pointing it out, since it is the primary function of 3xx. Is something
wrong with the text as written?

> Should be "SHOULD contain one or more...".

Actually, no. This is another subject that has been tossed around amongs
the editors. When you see a header like:

Contact: sip:[email-masked]
Contact: sip:[email-masked]

is that two contact headers, or one contact header with two values? It
is inconsistent in the text right now, as written. We are going to be
using the consistent naming that this is one header with two values, I
think that is more correct.

> I'd suggest making this a MUST or remove the upper-case requirement

Well, MUST is wrong, I think. Its OK if the UAC decides that "oh, I got
a 2xx anyway. Alright, I'll continue with the call". However, if the
intention was to hang up, the process ought to continue, and thus the
SHOULD. My general preference (and not all of the editors agree on this)
is to err on the side of explicit strengths rather than a simple active
voice. We've gotten in trouble on this in the past many times.

> anyway, as the route being constructed might dictate otherwise.

Right. Well, that old text is now gone. I think the note is OK as
written given the current state of bis.

> draft-ietf-sip-srv-04.txt?

Yes. There is a long, painful history with this draft and the text it is
associated with.

> That draft and what was 24.2 doesn't seem to

Right. The problem is that the requirement mandates dialog-statefulness
to handle failure cases. THus, the new text has relaxed the constraint.
Now, its just within a transaction that requests need to go to the same
place. A proxy can use a hash of the call-id as a random-number
generator for the SRV selection procedures. This results in reuqests
within the same call usually going to the same server, but not if there
has been a failure between transactions. It also doesn't require call
statefulness.

> it's not wrong to make different decisions, right?

The general idea is that if you don't own a namespace, you really can't
do a location service lookup on it to change it. So, a proxy cannot
change the desintation (i.e., r-uri), although it can certainly decide a
different next hop to send it to (loose routing).

What did you have in mind that required a proxy to modify a URI for a
domain it doesn't own?

> the request potentially establishes a dialog..."?

Yeah, good point. This text might make people think that they need to
record-route mid-dialog requests. I'll clarify. It now reads:

If this proxy wishes to remain on the path of future
requests in a dialog created by this request (assuming the request
creates a dialog), it {\MUST} insert a
\header{Record-Route} header field into the copy before any existing
\header{Record-Route} header field, even if a \header{Route} header
field is
already present.

> "The Request-URI will be different each time the request passes through.

No, its not necessarily so. You can legitimately spiral even if the
r-uri is unchanged. THis text is gone, however, in the changes that led
to bis-07.

> to view this situation is as if such a 3xx had been received from a

This has already been fixed. Its fixed in bis-07, at least, maybe
earlier versions too (I didnt check).

> ... "and no new branches can be created in this context."

Good point. I added the text.

> Seems to me the majority of SHOULD/SHOULD NOT items in 17.1.1.2 should

Many of them; those related to retransmissions, primarily. I've changed
them.

Thanks for your comments,

Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.            72 Eagle Rock Avenue
Chief Scientist                         First Floor
dynamicsoft                             East Hanover, NJ 07936
[email-masked]                 FAX: (973) 952-5050
http://www.jdrosen.net                  PH:  (973) 952-5000
http://www.dynamicsoft.com