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

Paul Kyzivat <pkyzivat@cisco.com> Tue, 07 December 2010 23:18 UTC

Return-Path: <pkyzivat@cisco.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 C69FA3A69B1 for <sipcore@core3.amsl.com>; Tue, 7 Dec 2010 15:18:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.506
X-Spam-Level:
X-Spam-Status: No, score=-110.506 tagged_above=-999 required=5 tests=[AWL=0.093, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
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 tmwC8rPaiRPm for <sipcore@core3.amsl.com>; Tue, 7 Dec 2010 15:18:18 -0800 (PST)
Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 446783A67FF for <sipcore@ietf.org>; Tue, 7 Dec 2010 15:18:18 -0800 (PST)
Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AvsEAHdP/kxAZnwM/2dsb2JhbACjSnGmWJtPhUkEhGKGD4MT
X-IronPort-AV: E=Sophos;i="4.59,313,1288569600"; d="scan'208";a="190146314"
Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 07 Dec 2010 23:19:44 +0000
Received: from [161.44.174.115] (dhcp-161-44-174-115.cisco.com [161.44.174.115]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id oB7NJilv001996; Tue, 7 Dec 2010 23:19:44 GMT
Message-ID: <4CFEC10F.5000700@cisco.com>
Date: Tue, 07 Dec 2010 18:19:43 -0500
From: Paul Kyzivat <pkyzivat@cisco.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.12) Gecko/20101027 Thunderbird/3.1.6
MIME-Version: 1.0
To: Christer Holmberg <christer.holmberg@ericsson.com>
References: <4CFD9187.3090207@cisco.com> <7F2072F1E0DE894DA4B517B93C6A058502C7190C@ESESSCMS0356.eemea.ericsson.se>
In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A058502C7190C@ESESSCMS0356.eemea.ericsson.se>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: SIPCORE <sipcore@ietf.org>
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 23:18:20 -0000

inline

On 12/7/2010 3:18 PM, Christer Holmberg wrote:
> 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).,

I raise this because I am not happy with carving out response-code 
specific exceptions to 100rel.

And I don't find the efficiency argument compelling in this case.

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

I think I am ok with that, though currently only 199 gives proxies 
dispensation to send a provisional response that wasn't originated by a UAS.

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

You are right that 3262 doesn't assign any special behavior to a proxy 
if Proxy-Require:100rel is present. There is nothing in 3261 or 3262 
that would prevent the insertion of Proxy-Require:100rel. It would 
require all proxies to understand it, but that understanding doesn't 
call for any behavior. So I guess no added language is required.

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

The requirement, or not, to include the Contact is my major concern.
You say that the response is not establishing a dialog, but that is not 
certain. The proxy believes the dialog to have been established, based 
on a previously received response. But unless that response was reliable 
and the PRACK returned, there is no certainty that the UAC knows the 
dialog to have been established. Its possible that the earlier 
provisional was lost, and the 199 is the first time the UAC knows there 
is a dialog.

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

Well, I think the above makes you theoretically wrong in rare cases.
But also, the question of whether non-100 1xx messages must have a 
Contact has not, afaik, been settled.

So we at least need to consider what behavior is required regarding 
Contact, and whether that is a normative change. Right now the 199 draft 
doesn't say one way or the other.

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

Yes, it probably would be better for the Contact to be missing, since it 
definitely should not be used. Same for Record-Route.

	Thanks,
	Paul