Good points, some nits inline
Regards,
Jeroen
Adam Roach wrote:
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.
[jvb] this would probably be a MUST, right?
* 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.
[jvb] you mean responses
* 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.
[jvb] is not _necessarily_ being applied, it depends on presence of Require:
outbound (only). Guess this is a MAY, right?
/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
