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

From: Christer Holmberg <[email-masked]>
Date: Thu, 3 Nov 2011 14:08:07 +0100

Hi,

The Feature-Caps draft currently allows sending of feature indications in reliable 18x and 200 responses.

I've received an off-line question, asking whether the indicated features must be identical, if included both in 18x and 200 for the same request.

My suggestion would be that we take the same approach that we did for Info Packages.

Section 5.2.3 of RFC 6086 says:

                "As with SDP answers, the receiver can include the same Recv-Info
                header field value in multiple responses (18x/2xx) for the same
                INVITE/re-INVITE transaction, but the receiver MUST use the same
                Recv-Info header field value (if included) in all responses for the
                same transaction."

...so, for Feature-Caps it could say something like:

                "An entity can include the same Feature-Caps
                header field value in multiple responses (18x/2xx) for the same
                INVITE/re-INVITE transaction, but the entity MUST use the same
                Feature-Caps header field value (if included) in all responses for the
                same transaction."

Regards,

Christer

---

From: Andrew Allen <[email-masked]>
Date: Thu, 3 Nov 2011 18:20:50 +0000

Agree

From: [email-masked] [mailto:[email-masked]] On Behalf Of Christer Holmberg
Sent: Thursday, November 03, 2011 8:08 AM
To: <[email-masked]>
Subject: [sipcore] Feature-Caps: Feature indications in 18x and 200

Hi,

Regards,

Christer

---------------------------------------------------------------------
This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.

---

From: Christer Holmberg <[email-masked]>
Date: Sun, 6 Nov 2011 00:49:51 +0100

Hi,
 
I received a comment that it would be good to clarify that the header field value must be identical in 18x/2xx responses belonging to the same dialog.
 
In addition, I received a request to say that, if the header field is sent in a 18x, it shall also be sent in all subsequent 18x responses, and the 2xx responses, for the same dialog.
 
So, the updated text could say something like:

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

Regards,

Christer

________________________________

From: Andrew Allen [mailto:[email-masked]] 
Sent: 3. marraskuuta 2011 20:21
To: Christer Holmberg; <[email-masked]>
Subject: RE: Feature-Caps: Feature indications in 18x and 200

Agree

 

Hi,

                 same transaction."

                 same transaction."

Regards,

Christer

---

From: Hadriel Kaplan <[email-masked]>
Date: Sun, 6 Nov 2011 13:17:20 +0000

The tricky thing is a UAC can't rely on getting the same list in all responses, even if we mandate devices send the same back, due to forking cases, right?

So what do we say about the UAC receiving the responses if it gets a 200 with a different Caps list than the 18x?

-hadriel

On Nov 5, 2011, at 7:49 PM, Christer Holmberg wrote:

> _______________________________________________
> sipcore mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sipcore

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Sun, 6 Nov 2011 18:07:01 +0100

Christer is identifying the sending requirements.

For the receiving side, I'd suggest that the contents of the 2xx have to be taken as definitive (assuming you have received it).

Regards

Keith 

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Hadriel Kaplan
> Sent: 06 November 2011 13:17
> To: Christer Holmberg
> Cc: [email-masked] Core) WG
> Subject: Re: [sipcore] Feature-Caps: Feature indications in 
> 18x and 200
> 
> 
> The tricky thing is a UAC can't rely on getting the same list 
> in all responses, even if we mandate devices send the same 
> back, due to forking cases, right?
> 
> So what do we say about the UAC receiving the responses if it 
> gets a 200 with a different Caps list than the 18x?
> 
> -hadriel
> 
> 
> > I received a comment that it would be good to clarify that 
> the header field value must be identical in 18x/2xx responses 
> belonging to the same dialog.
> > 
> > In addition, I received a request to say that, if the 
> header field is sent in a 18x, it shall also be sent in all 
> subsequent 18x responses, and the 2xx responses, for the same dialog.
> > 
> > The Feature-Caps draft currently allows sending of feature 
> indications in reliable 18x and 200 responses.
> > 
> > 
> > 
> > I've received an off-line question, asking whether the 
> indicated features must be identical, if included both in 18x 
> and 200 for the same request.
> > 
> > 
> > 
> >               "As with SDP answers, the receiver can 
> include the same 
> > Recv-Info
> > 
> >                header field value in multiple responses 
> (18x/2xx) for 
> > the same
> > 
> >                INVITE/re-INVITE transaction, but the 
> receiver MUST use 
> > the same
> > 
> >                header field value in multiple responses 
> (18x/2xx) for 
> > the same
> > 
> >                INVITE/re-INVITE transaction, but the entity 
> MUST use 
> > the same
> > 
> > This transmission (including any attachments) may contain 
> confidential information, privileged material (including 
> material protected by the solicitor-client or other 
> applicable privileges), or constitute non-public information. 
> Any use of this information by anyone other than the intended 
> recipient is prohibited. If you have received this 
> transmission in error, please immediately reply to the sender 
> and delete this information from your system. Use, 
> dissemination, distribution, or reproduction of this 
> transmission by unintended recipients is not authorized and 
> may be unlawful.

---

From: Christer Holmberg <[email-masked]>
Date: Sun, 6 Nov 2011 22:05:57 +0100

Hi Hadriel,

> So what do we say about the UAC receiving the responses if it gets a 200 with a different Caps list than the 18x?

Please note that the text talks about using the same value in 18x and 200 - per dialog.

So, in forking case, you can of course receive different values in 18x/2xx responses associated with different early dialogs.

Regards,

Christer

---

From: Christer Holmberg <[email-masked]>
Date: Sun, 6 Nov 2011 22:08:40 +0100

Hi,

> For the receiving side, I'd suggest that the contents of the 2xx have to be taken as definitive (assuming you have received it).

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.

Regards,

Christer

> (18x/2xx) for the same

---

From: Hadriel Kaplan <[email-masked]>
Date: Mon, 7 Nov 2011 03:34:27 +0000

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

Right, so I agree with Keith that the 2xx should win.

-hadriel

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 7 Nov 2011 09:25:14 +0100

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

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

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 07 Nov 2011 13:39:31 -0500

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

> 	same transaction.<addition>  If an entity, for a given dialog,

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 7 Nov 2011 20:00:10 +0100

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