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

"DRAGE, Keith (Keith)" <keith.drage@alcatel-lucent.com> Wed, 08 December 2010 13:31 UTC

Return-Path: <keith.drage@alcatel-lucent.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 2EDD33A6947 for <sipcore@core3.amsl.com>; Wed, 8 Dec 2010 05:31:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -105.574
X-Spam-Level:
X-Spam-Status: No, score=-105.574 tagged_above=-999 required=5 tests=[AWL=0.675, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4, 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 888c0XMyaPYD for <sipcore@core3.amsl.com>; Wed, 8 Dec 2010 05:31:46 -0800 (PST)
Received: from smail2.alcatel.fr (smail2.alcatel.fr [64.208.49.57]) by core3.amsl.com (Postfix) with ESMTP id 55A533A693E for <sipcore@ietf.org>; Wed, 8 Dec 2010 05:31:39 -0800 (PST)
Received: from FRMRSSXCHHUB02.dc-m.alcatel-lucent.com (FRMRSSXCHHUB02.dc-m.alcatel-lucent.com [135.120.45.62]) by smail2.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id oB8DWFCa025187 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 8 Dec 2010 14:33:02 +0100
Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.46]) by FRMRSSXCHHUB02.dc-m.alcatel-lucent.com ([135.120.45.62]) with mapi; Wed, 8 Dec 2010 14:32:55 +0100
From: "DRAGE, Keith (Keith)" <keith.drage@alcatel-lucent.com>
To: Christer Holmberg <christer.holmberg@ericsson.com>, Paul Kyzivat <pkyzivat@cisco.com>, SIPCORE <sipcore@ietf.org>
Date: Wed, 8 Dec 2010 14:32:54 +0100
Thread-Topic: [sipcore] Required normative revisions to support 199 response
Thread-Index: AcuVsFP3DYAm/1VWSUaLuAtw0x4AbQAlpvDVACO+SPA=
Message-ID: <EDC0A1AE77C57744B664A310A0B23AE21E3D63CC@FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com>
References: <4CFD9187.3090207@cisco.com> <7F2072F1E0DE894DA4B517B93C6A058502C7190C@ESESSCMS0356.eemea.ericsson.se>
In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A058502C7190C@ESESSCMS0356.eemea.ericsson.se>
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-Scanned-By: MIMEDefang 2.64 on 155.132.188.80
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: Wed, 08 Dec 2010 13:31:49 -0000

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

How about: 

"The UAC MUST support reception of all provisional responses, sent reliably or unreliably; use of the option tag value "100rel" in a Require header field does not change this requirement."

regards

Keith

> -----Original Message-----
> From: sipcore-bounces@ietf.org 
> [mailto:sipcore-bounces@ietf.org] On Behalf Of Christer Holmberg
> Sent: Tuesday, December 07, 2010 8:18 PM
> To: Paul Kyzivat; SIPCORE
> Subject: Re: [sipcore] Required normative revisions to 
> support 199 response
> 
> 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
> _______________________________________________
> sipcore mailing list
> sipcore@ietf.org
> https://www.ietf.org/mailman/listinfo/sipcore
>