On Jul 20, 2007, at 9:06 AM, Rohan Mahy wrote:
Hi Adam,
What can I say but "You're right". Unless there is some
fundamental objection, I will make this change pronto to my working
copy.
I believe this also means I can remove the 'ob' parameter from the
UAC's Contact header.
On further thought, I realized that the 'ob' parameter is still
needed, since it reflects whether the UAC is sending over a flow for
which out bound processing is being applied, as opposed to merely
indicating the UAC is capable of requesting outbound.
thanks,
-rohan
thanks,
-rohan
On Jul 19, 2007, at 5:05 PM, 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.
* 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
