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

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: sipcore-bounces@ietf.org 
> [mailto:sipcore-bounces@ietf.org] On Behalf Of Hadriel Kaplan
> Sent: 06 November 2011 13:17
> To: Christer Holmberg
> Cc: sipcore@ietf.org 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
> 
> 
> On Nov 5, 2011, at 7:49 PM, Christer Holmberg wrote:
> 
> > 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:aallen@rim.com]
> > Sent: 3. marraskuuta 2011 20:21
> > To: Christer Holmberg; <sipcore@ietf.org>
> > Subject: RE: Feature-Caps: Feature indications in 18x and 200
> > 
> > 
> > 
> > Agree
> > 
> > 
> > 
> > From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On 
> > Behalf Of Christer Holmberg
> > Sent: Thursday, November 03, 2011 8:08 AM
> > To: <sipcore@ietf.org>
> > Subject: [sipcore] Feature-Caps: Feature indications in 18x and 200
> > 
> > 
> > 
> > 
> > 
> > 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
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> ---------------------------------------------------------------------
> > 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. 
> > _______________________________________________
> > sipcore mailing list
> > sipcore@ietf.org
> > https://www.ietf.org/mailman/listinfo/sipcore
> 
> _______________________________________________
> sipcore mailing list
> sipcore@ietf.org
> https://www.ietf.org/mailman/listinfo/sipcore
> 