Re: [sipcore] Feature-Caps: Feature indications in 18x and 200

[Christer Holmberg <[e-mail]>]

Hi, 

>>>> If an entity receives different values in responses associated with 
>>>> the same dialog, an error case has occured (as the sender should not 
>>>> send different values for the same dialog).
>>>>
>>>> So, we can either say that the first response with Feature-Caps is 
>>>> taken as definitive, or we can say that the Feature-Caps in 2xx is 
>>>> taken as definitive, because for a given dialog they should always 
>>>> be the same.
>>>
>>> Right, so I agree with Keith that the 2xx should win.
>
> I generally have some discomfort with specifying the behavior of a recipient upon receiving 
> invalid input. Doing so tacitly gives the sender permission to send in this way, because the behavior is defined. 
> If we are to define how this case is handled we might as well make it valid behavior.

Correct. As you say, if this happens, the sender does something wrong, so no matter what we specify for the receiver, 
I don't think we can ensure that the sender and receiver will have a common understanding.

The same applies for Info Packages, and for that we don't specify any receiver procedures for such error case either.

> So at least I would prefer to have the behavior in this case be non-normative.
>
> The reason for sending multiple times can be to get it there asap and still ensure it gets 
> there when the provisionals are unreliable. But its worth considering what to do when the 
> value is send in a *reliable* provisional.

The text currently says that the header field has to be sent in a reliable response, but of course we can allow it also
in unreliable responses - as long as it is sent at least in one reliable response.

> The text below talks about a single transaction. But it seems the intent is to establish 
> state the lasts for the duration of a dialog (or a registration).
>
> ISTM that it should probably be ok to change the value for a dialog via a reliable request 
> or response withing the dialog. (And for a registration via a registration update.) That 
> would cover the 3pcc cases.

Correct, and based on your earlier comments I have suggested text for that in another 
thread ([sipcore] Feature-Caps: Feature indication in target refresh request).

The text we are discussing now only covers multiple responses for a single transaction.

> While obscure, IMO that would mean that after establishing a value with a reliable provisional, you should then be
> able to change it in another reliable provisional or the 2xx. (And maybe in an UPDATE.)

The text I've suggested states that the change must be done using a target refresh request.

If you want to discuss that, let's do it in the other thread :)

Regards,

Christer



> So, I have done some additions (<addition>) to the suggested text:
>
> 	"An entity can include the same Feature-Caps
> 	header field value in multiple responses (18x/2xx)
> 	for the same INVITE/re-INVITE transaction, but for a
> 	given dialog the entity MUST use the same Feature-Caps
> 	header field value (if included) in all responses for
> 	the same transaction. In addition, if an entity includes
> 	a Feature-Caps header field in a 18x response, for the
> 	given dialog it MUST include the header field in all
> 	subsequent 18x responses, and the 2xx response, for the
> 	same transaction.<addition>  If an entity, for a given dialog,
>        receives different Feature-Caps header field values in
> 	responses to the same transaction (this would not happen in
> 	normal operations), it MUST use the latest header field
> 	values as the valid one.</addition>"
>
> Regards,
>
> Christer
> _______________________________________________
> sipcore mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/sipcore
>

_______________________________________________
sipcore mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/sipcore