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

[Paul Kyzivat <[e-mail]>]

On 11/7/11 3:25 AM, Christer Holmberg wrote:
> 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.

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 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.

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.)

	Thanks,
	Paul


> 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
>