[Sip] Re: Outbound: Feature Tag (Ab)Use

[Rohan Mahy <[e-mail]>]

Hi Adam,

I believe outbound-11 now correctly uses option-tags.

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 [e-mail] for questions on current sip
Use [e-mail] for new developments on the application of sip