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

Hi Hadriel,

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

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

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