Re: [sipcore] Required normative revisions to support 199 response

Christer Holmberg <christer.holmberg@ericsson.com> Tue, 07 December 2010 20:16 UTC

Return-Path: <christer.holmberg@ericsson.com>
X-Original-To: sipcore@core3.amsl.com
Delivered-To: sipcore@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 78D0728C0EE for <sipcore@core3.amsl.com>; Tue, 7 Dec 2010 12:16:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.447
X-Spam-Level:
X-Spam-Status: No, score=-6.447 tagged_above=-999 required=5 tests=[AWL=0.152, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Cxev2IwughiZ for <sipcore@core3.amsl.com>; Tue, 7 Dec 2010 12:16:46 -0800 (PST)
Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id DF07828C0ED for <sipcore@ietf.org>; Tue, 7 Dec 2010 12:16:45 -0800 (PST)
X-AuditID: c1b4fb39-b7bd2ae000001d22-da-4cfe96826ceb
Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id A4.41.07458.2869EFC4; Tue, 7 Dec 2010 21:18:10 +0100 (CET)
Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.175]) by esessmw0237.eemea.ericsson.se ([153.88.115.90]) with mapi; Tue, 7 Dec 2010 21:18:10 +0100
From: Christer Holmberg <christer.holmberg@ericsson.com>
To: Paul Kyzivat <pkyzivat@cisco.com>, SIPCORE <sipcore@ietf.org>
Date: Tue, 7 Dec 2010 21:18:09 +0100
Thread-Topic: [sipcore] Required normative revisions to support 199 response
Thread-Index: AcuVsFP3DYAm/1VWSUaLuAtw0x4AbQAlpvDV
Message-ID: <7F2072F1E0DE894DA4B517B93C6A058502C7190C@ESESSCMS0356.eemea.ericsson.se>
References: <4CFD9187.3090207@cisco.com>
In-Reply-To: <4CFD9187.3090207@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: AAAAAA==
Subject: Re: [sipcore] Required normative revisions to support 199 response
X-BeenThere: sipcore@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: SIP Core Working Group <sipcore.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/sipcore>, <mailto:sipcore-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sipcore>
List-Post: <mailto:sipcore@ietf.org>
List-Help: <mailto:sipcore-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sipcore>, <mailto:sipcore-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 07 Dec 2010 20:16:47 -0000

Hi,

>In offline discussions, Robert, Cullen (and maybe others?) have
>questioned whether draft-ietf-sipcore-199-02.txt requires a normative
>change to RFC 3262 (100rel). We've gotten deep enough into this that it
>seemed proper to bring it back to the list for further discussion.
>
>The issue is that this draft, as currently written, requires that the
>199 response be sent *un*reliably even if Require:100rel was specified
>by the UAC. It is (partially) mitigated by the introduction of a new
>'199' option tag. If Supported:199 is not present in the request, the
>199 response can't be sent. So the draft makes the argument that there
>is no backward compatibility issue, making this an extension rather than
>a change.
>
>BUT, there is still a potential backward compatibility issue for other
>proxies that don't know about the 199 option. A dialog-stateful proxy
>upstream of the 199-sender might observe the unreliable 199 and not it
>to be inconsistent with the Require:100rel.
>
>In addition, I realized that this draft also extends RFC 3261, in that
>it for the first time introduces a case where a *proxy* may *originate*
>(not just forward) a response in the context of an existing (early)
>dialog. According to 3261 a proxy that initiates a response is actually
>doing so in the role of a UAS, and so must add its own to-tag, thus
>creating a new dialog.
>
>So, I have proposed that the specification for what goes on when sending
>199 be tweaked, in a way that is trivially different from an
>implementation perspective but that is conceptually significant. Namely:
>
>- There should be no exception from Require:100rel. When a UAS sends
>   a 199, if Require:100rel is in effect it MUST send the 199 reliably.

I know that people (including me) wanted to allow a UAS to always send 199 unreliably.

However, I can live with Paul's suggestion (partly because I don't think Require:100rel is very often used in real deployments).,

>- When a *proxy* *originates*a 199, it is considered to be operating
>   as a *proxy*, not as a UAS. Hence it is not bound by Require:100rel.
>   Rather it is bound by Proxy-Require:100rel. The proposal is to
>   make a revision to 3262 that says 100rel MUST NOT be used in
>   Proxy-Require. And as now the proxy MUST NOT send the 199 reliably.
>   That ensures there won't be a PRACK that would then possibly be
>   forwarded on to the UAS that doesn't expect it.
>
>   But the proxy is *originating* the 199 response in the context of the
>   existing (early) dialog. It must make a response that is valid in that
>   context. (E.g. the to-tag.)
>
>This does not eliminate the impact on upstream proxies. They will still
>see an unreliable provisional response that might be surprising. So this
>still requires a revision to 3262. I really hated the idea of making a
>special case for the single 199 response code. So my proposal is:
>
>- in any case where a proxy is permitted to originate a provisional
>   response within an existing dialog (early or not) it must do so
>   unreliably. (For now the only case this applies to is 199.)

I had a look at 3262, and the follwoing statement could be added to section 4 (UAC behavior) of RFC 3262:

"The UAC MUST, even if it has required provisional responses to be sent reliably, be prepared to receive unreliably
sent provisional response, as such responses might have been sent by SIP proxies."


>- the 100rel option MUST NOT be sent (ever) in Proxy-Require.

I had a look at 3262, and one could argue that the usage of Proxy-Require isn't defined in the first place.

But, if we want to be explicit, the following statement could be added to section 4 (UAC behavior) of RFC 3262:

"A UAC MUST NOT insert a Proxy-Require header field with the option tag 100rel into the request."


>The effect of this is that UACs and proxies may see unreliable
>provisionals even when Require:100rel is in effect. This is a (hopefully
>insignificant) backward incompatibility from 3262.
>
>*** I'm requesting feedback on the above approach.
>*** Are you happy with it?
>*** Do you have a better idea?

I am ok with the approach.

-----

>While writing this I thought of another issue that needs discussion.
>When the proxy is constructing the 199, to be in the context of the
>dialog, how should it be constructed? The following are questionable:
>
>- Contact address
>- Record-Route
>- History-Info
>- (did I forget any that matter?)
>
>The straightforward answer is that these should all be copied from the
>final response that triggered the sending of the 199. An alternative
>might be to copy from the response that the proxy considers to have
>established the early dialog. These *might* not be the same.
>
>Alternatively, perhaps the proxy should generate the 199 response
>without the Contact since the contact does not reflect the sender of the
>response. But that would be contrary to some discussions that occurred a
>couple of years ago (aug 2008) on the sip-implementors list, which
>concluded (IMO) that 3261 implies Contact is required in all provisional
>responses.

I think this has been discussed before, and as far as I remember none of the header fields above are required to be present in a provisional response - unless the response is used to create a dialog, which is not the case with 199.

So, unless I'm wrong, I would not like to re-open that discussion, because it is not part of what was supposed to be be brought to the list for discussion.

(From a debugging perspective, I actually think it could be good if the response from the proxy does not contain the header fields, which gives a hint that the response might have been generated by a proxy).

Regards,

Christer