Subject: [Sip] Draft -08 comments, part 3: "major" issues

From: Jonathan Lennox <[email-masked]>
Date: Tue, 26 Feb 2002 18:42:16 -0500

Here's part three of my comments on draft -08: "major" issues that would
either change normative behavior, whose resolution isn't obvious, or that
would require a significant amount of additional text to be added.  None of
them are really *that* major, though.  (The line between this section and
the previous one is sort of fuzzy, of course.)

Again, my comments use the line numbers from the PS/PDF versions of the
spec, but all text quotes come from the text version.

In general:
Do you have permission from the owners of atlanta.com, biloxi.com, and
chicago.com for the use of their domains in the examples?  All three are
registered...

Section 8.1.1.7:
It'd be nice to have some explanation of what the magic cookie string
"z9hG4bK" in the Via branch means and where it came from.  Is it purely
random?

Section 8.3:
The text on redirect servers seems a bit troubling.
   However, redirect servers MUST NOT redirect a request to a URI equal
   to the one in the Request-URI; instead, provided that the URI does
   not point to itself, the redirect server SHOULD proxy the request to
   the destination URI.

I have no problem with the MUST NOT, but the SHOULD troubles me -- it means
that there's no such thing as an unconditionally compliant pure redirect
server, since every redirect server has to have some proxy functionality.
I think it'd be better to leave handling of this scenario up to implementor
discretion.  (The whole concept of using a redirect server as an outbound
proxy seems a bit bizarre.)

Section 14.2, line 2314, says:
   A UAS that receives a second INVITE before it sends the final
   response to a first INVITE with a lower CSeq sequence number on the
   same dialog MUST return a 500 (Server Internal Error) response to the
   second INVITE

I understand the concept and motivation, but isn't there a better error code
than a plain 500 for this?  Especially since this is really a client error.
I don't see why this can't use 491 (Request Pending), just like the glare
situation in the next paragraph does.

Also in 14.2, at line 2344:
   If, however, it [the session description in an re-INVITE] is
   unacceptable to the UAC, the UAC SHOULD generate an answer with a
   valid session description, and then send a BYE to terminate the
   session.

This is the only case where a re-INVITE failure can lead to a session being
torn down, as far as I can see.  Would it be a good idea, therefore, to say
that UACs SHOULD NOT do late offer-answer for re-INVITEs, i.e. SHOULD always
include the existing session description in the re-INVITE?

Section 16.7:
The discussion of proxy response handling doesn't discuss the "final
response received after a stateful proxy goes stateless" problem.  This can
happen if a downstream server is frozen, you time out, and then it comes
back to life.  In this scenario, a proxy can end up sending a non-2xx after
a 2xx, multiple non-2xx responses, or multiple 2xx responses to a non-INVITE
request.  Is this forbidden, and if not, how is it dealt with?  (This is
mostly relevant for step 5.)

On a similar note, does the spec require that you proxy responses upstream
statelessly after you've torn down the response context, forbid it, or leave
it optional?  It's hard to tell...

Section 16.7:
Step 6 of proxy response handling says
             A proxy which receives a 503 (Service Unavailable) response
             SHOULD NOT forward it upstream unless it can determine that
             any subsequent requests it might proxy will also generate a
             503. In other words, forwarding a 503 means that the proxy
             knows it cannot service any requests, not just the one for
             the Request-URI in the request which generated the 503.

What if you only proxied to a single branch, and you got back a 503?  You
SHOULD NOT return it, and instead should make up some new response out of
the whole cloth?  That doesn't make much sense.

Section 16.11:
The discussion of stateless proxies says
        o A stateless proxy MUST choose one and only one target from the
          target set. This choice MUST only rely on fields in the
          message and time-invariant properties of the server.
and
        Since a stateless proxy must forward retransmitted requests
        to the same destination and add identical branch parameters
        to each of them, it can only use information from the
        message itself and time-invariant configuration data for
        those calculations. If the configuration state is not
        time-invariant (for example, if a routing table is updated)
        any requests that could be affected by the change may not
        be forwarded statelessly during an interval equal to the
        transaction timeout window before or after the change. The
        method of processing the affected requests in that interval
        is an implementation decision. A common solution is to
        forward them transaction statefully.

It seems from this text that it's not possible to design a stateless proxy
server which bases its routing decisions on a REGISTER-based location
service, since you can't anticipate the arrival of a REGISTER request and
start proxying statefully.  Is this true?  If so, should it be called out
more clearly?  If not, what am I missing?

Section 18.1.1:
The discussion of the transport connection probably ought
to mention something along the lines that the transport layer SHOULD NOT
close TCP connections prematurely, for backward compatibility with RFC
2543-compliant devices which will interpret this as a CANCEL (client to
server) or whatever the other-direction close meant.  This might be hard to
specify, though.

Section 18.3:
Should the section on transport framing have a note that multiple messages
in a UDP packet has been deprecated, or is the mention of this in the big
changes section enough?

Section 19.1.4:
What was the motivation for making URI comparisons non-transitive, and
special casing certain uri-parameters?  It seems like it just makes a lot of
implementation things much harder.  Wouldn't it be simpler just to say that
uri parameters must match?  This would mean that the URI comparison code
could be completely ignorant of the semantics of URI parameter names, and
old and new parameters are treated equally.

Section 20.26 (Priority):
You say that a message with no Priority field SHOULD be treated the same as
"non-urgent".  This conflicts with CPL, which treats a missing Priority as
the same as "normal."  These should probably be aligned.

Section 20.42 (Via):
This section says
   Transport protocols defined here are "UDP", "TCP", "TLS", and "SCTP".
   "TLS" means TLS over TCP.  When a request is sent to a SIPS URI, the
   protocol still indicates "SIP", and the transport protocol is TLS.

What about TLS over SCTP?  And is this abuse of the "transport" tag really a
good idea here, given that it was decided that it was a bad idea in URIs?

Section 20.42 (Via):
The discussion of the branch parameter probably ought to re-mention the
branch parameter's magic cookie.

-- 
Jonathan Lennox
[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: Jonathan Rosenberg <[email-masked]>
Date: Wed, 27 Feb 2002 05:16:28 -0500

> "z9hG4bK" in the Via branch means and where it came from.  Is it purely

Yes. That is generally the meaning of a magic cookie.

> proxy seems a bit bizarre.)

OK. I think thats a good point. I'd rather keep this tidbit about
redirecting outbound proxies, since I know someone will ask eventually.
I will change the SHOULD to MAY. The alternative is to reject with a
404.

> situation in the next paragraph does.

5xx means that the same request as is, may succeed later, and that is
true here. Anyway, this should never happen, since you are not supposed
to send a new INVITE until you got an answer to the previous. So, we
theoretically don't even need to describe this case.

> include the existing session description in the re-INVITE?

No. There are valid cases where an offer needs to be in a 2xx to
re-invite, for 3pcc.

> mostly relevant for step 5.)

It is forbidden. Its all dealt with in the UA. The existing
transaction/dialog matching rules will result in only one final response
for a non-invite being accepted (the others will look like retransmits).
For INVITE, the first 2xx destroys the transaction. A subsequent non-2xx
would be passed to the core; the spec does not discuss what to do in
this case - it ought to ignore them. I added a sentence to that effect.
Receiving a 2xx after a 4xx will result in it being ignored as a
retransmit.

> it optional?  It's hard to tell...

lines 2781-4 of bis-08 explicitly state that you MUST act as a stateless
proxy for them.

> the whole cloth?  That doesn't make much sense.

No, that is the right thing. I added a sentence saying it should do
that. Yes, its a bit ugly, but it brings a world of value to 503.
Without it, we have no overload handling capabilities, and that has been
frequently requested.

> more clearly?  If not, what am I missing?

The point is that you can never be ALWAYS stateless. In this specific
instance, to achieve causality, you would delay the instantiation of the
registration update for 32s, go stateful, make the registration change,
and then go stateless. That works just fine. I don't think there is a
need to go into detail. There is sufficient room for innovation here; we
merely need to call out the problem.

> server) or whatever the other-direction close meant.  This might be hard

THis text exists. Line 3545 of bis-08 already says that its RECOMMENDED
(same as SHOULD) to keep the connection open for at least a
transaction-intervals worth of time after the last message. That meets
the requirement.

> in a UDP packet has been deprecated, or is the mention of this in the

Yes, it is sufficient. We have tried to move all of the text there,
rather than scattered.

> old and new parameters are treated equally.

This is a general mechanism for backwards compatibility. I agree that
transitivity would be nice in theory, but it seemed a riskier
proposition.

> the same as "normal."  These should probably be aligned.

Fixed. The problem is that caller prefs actually says non-urgent; thats
where I copied it from. I changed bis to normal, and also caller prefs.

> What about TLS over SCTP? 

When we get there, it'll require a new value. We discussed using:

SIPS/2.0/TCP

instead, but deemed this too backwards incompatible.

> And is this abuse of the "transport" tag
> really a

Compromises, as always. The grammar only allows SIP here, so it would
break parsers potentially far away from this proxy.

> branch parameter's magic cookie.

Good idea, since it is easy to miss otherwise, and its really important.

Thanks,
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

---

From: Jonathan Lennox <[email-masked]>
Date: Wed, 27 Feb 2002 10:57:47 -0500

> Yes. That is generally the meaning of a magic cookie.

Okay.  I thought it might have been somebody's birthday, base64-encoded, or
something cute like that. :-)

> > I understand the concept and motivation, but isn't there a better error
> > code than a plain 500 for this?  Especially since this is really a
> > client error.  I don't see why this can't use 491 (Request Pending),
> > just like the glare situation in the next paragraph does.
>

Okay.  So if I want to send 4xx instead (on the grounds that this is the
other guy's fault, not my fault, and so a client error), it's okay?

> > response received after a stateful proxy goes stateless" problem.  This
> > can happen if a downstream server is frozen, you time out, and then it
> > comes back to life.  In this scenario, a proxy can end up sending a
> > non-2xx after a 2xx, multiple non-2xx responses, or multiple 2xx
> > responses to a non-INVITE request.  Is this forbidden, and if not, how
> > is it dealt with?  (This is mostly relevant for step 5.)
>

It seems like ignoring a 2xx after a 4xx is a good way to get blasted with
an RTP stream you don't have any way of shutting up.  But I suppose this is
an exceptional case, and so undefined by the spec, so an entity can do what
it likes.

> > special casing certain uri-parameters?  It seems like it just makes a
> > lot of implementation things much harder.  Wouldn't it be simpler just
> > to say that uri parameters must match?  This would mean that the URI
> > comparison code could be completely ignorant of the semantics of URI
> > parameter names, and old and new parameters are treated equally.
> 

I realized last night the real problem with this.  It means you can't
canonicalize a SIP URI.

Here's an example.  In our server, we use a SQL database as the back end to
our registration service.  Since SQL doesn't understand SIP URIs, only
strings, we convert all URIs into a canonical string form before inserting
them into the database.  In the previous spec this meant case-smashing all
CI elements, deleting default parameters, and lexicographically sorting all
the parameters and headers.  Then, to accomplish registration updates, we
just use the address-of-record and the contact URI as database keys, and the
database does everything correctly.

With bis-08's URI comparison rules, there's *no way* to do this.  (Trivial
proof: string equality is an equivalence relation.)  We'd have to somehow
put knowledge of these URI comparison rules into the database access code.
I *guess* this means putting both a all-nonstandard-parameters-stripped form
and a nonstandard-parameters-present form in the database, querying for
both, updating both, deleting as necessary...it's going to be a rat's nest,
and probably a lot less efficient.

I imagine a whole lot of implementations are using string or hash
comparisons of canonicalized URIs, in some form or another, for their
location services...

-- 
Jonathan Lennox
[email-masked]

---

From: Robert Sparks <[email-masked]>
Date: 27 Feb 2002 10:11:38 -0600

Look at lines 1703-1707 of bis-08.pdf

---

From: Jonathan Lennox <[email-masked]>
Date: Wed, 27 Feb 2002 12:25:25 -0500

> Look at lines 1703-1707 of bis-08.pdf

Okay -- that solves it for the address-of-record.  But line 1733 still
invokes the URI comparison rules for the contact addresses.

-- 
Jonathan Lennox
[email-masked]

---

From: Robert Sparks <[email-masked]>
Date: 27 Feb 2002 12:42:48 -0600

> invokes the URI comparison rules for the contact addresses.

And how is -08 making things harder than, say -02? (Transitivity went
away way back then - see section 2.1 of bis-02).

---

From: "Cullen Jennings" <[email-masked]>
Date: Wed, 27 Feb 2002 16:46:17 -0800

Bis 8, line 399.

Thought we had decided to not encourage people to use IP address to build
the Call-ID.