From: Adam Roach <[EMAIL PROTECTED]>
Date: Thu, 19 Jul 2007 19:05:04 -0500
Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted
mechanism)
X-Scan-Signature: 00e94c813bef7832af255170dca19e36
Cc: [email protected], Cullen Jennings <[EMAIL PROTECTED]>
At the risk of further bloodying the corpse of this poor horse, I still
think the usage of feature tags in outbound is way, way off in terms of
the semantics described in 3261.
Reviewing the way this is defined to work in SIP:
3261:8.1.1.9:
> If the UAC supports extensions to SIP that can be applied by the
> server to the response, the UAC SHOULD include a Supported header
> field in the request listing the option tags (Section 19.2) for those
> extensions.
3261:8.2.4:
> A UAS that wishes to apply some extension when generating the
> response MUST NOT do so unless support for that extension is
> indicated in the Supported header field in the request. If the
> desired extension is not supported, the server SHOULD rely only on
> baseline SIP and any other extensions supported by the client.
> ...
> Any extensions applied to a non-421 response MUST be listed in a
> Require header field included in the response. Of course, the server
> MUST NOT apply extensions not listed in the Supported header field in
> the request. As a result of this, the Require header field in a
> response will only ever contain option tags defined in standards-
> track RFCs.
There are five normative statements in the text I quote above. The
mechanism described in the outbound draft actually manages to violate
_all_ _five_ of them.
The registrar infers *both* support for outbound *and* a request to
apply the outbound extension by the presence of the "reg-id" Contact
header field parameter. In particular, the client is apparently NOT
supposed to send a "Supported: outbound" header field. This appears to
contravene the normative statement in 8.1.1.9 cited above.
The registrar indicates that outbound procedures are being applied by
including a "Supported" header field in the REGISTER response. (In 3261,
"Supported" in a _response_ indicates that an extension _can_ _be_
supported in a future request, NOT that it is being applied to the
current one -- sections 11 and 13.3.1.4 both talk about Supported usage
in responses.)
In other words, the registrar (acting as a UAS) is applying an extension
when generating a response without that extension being indicated in the
"Supported" header field in the request. Again, this directly
contravenes two normative statements from section 8.2.4 (cited above).
The registrar is further applying an extension to a non-421 response
that is not listed in a "Require" header field, in violation of the
remaining normative statement in the portion of section 8.2.4 cited above.
Why are we doing this so very, very wrong? It's almost as if we've gone
out of our way to violate both the spirit AND the law of feature tag
handling in as many ways as possible. Most annoyingly, we get exactly
the desired behavior if we just do things the way they're described in
3261. To wit:
* If a client supports outbound, it includes "Supported: outbound"
in all REGISTER requests, regardless of whether the specific
request makes use of that extension.
* The client adds a "reg-id" header field parameter to any Contacts
to which outbound processing is to apply.
* The registrar includes "Require: outbound" in any REGISTER
requests to which outbound behavior is being applied.
* The registrar is free to include "Supported: outbound" in any
responses it generates -- and it means exactly what 3261 intends
it to mean: that outbound is *supported*, but is not being applied
to the response in question.
/a
_______________________________________________
Sip mailing list https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [EMAIL PROTECTED] for questions on current sip
Use [EMAIL PROTECTED] for new developments on the application of sip
_______________________________________________
Sip mailing list https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [EMAIL PROTECTED] for questions on current sip
Use [EMAIL PROTECTED] for new developments on the application of sip
