Re: [sipcore] draft-roach-sipcore-rfc3265bis-00
"Dale Worley" <dworley@nortel.com> Fri, 02 October 2009 21:43 UTC
Return-Path: <dworley@nortel.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 95A9E3A69E5 for <sipcore@core3.amsl.com>; Fri, 2 Oct 2009 14:43:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.58
X-Spam-Level:
X-Spam-Status: No, score=-6.58 tagged_above=-999 required=5 tests=[AWL=0.019, 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 D53ChRLqbrJN for <sipcore@core3.amsl.com>; Fri, 2 Oct 2009 14:43:47 -0700 (PDT)
Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id 685BC3A68BE for <sipcore@ietf.org>; Fri, 2 Oct 2009 14:43:47 -0700 (PDT)
Received: from zrtphxs1.corp.nortel.com (casmtp.ca.nortel.com [47.140.202.46]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id n92LigJ21727; Fri, 2 Oct 2009 21:44:42 GMT
Received: from [47.16.90.165] ([47.16.90.165]) by zrtphxs1.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 2 Oct 2009 17:44:41 -0400
From: Dale Worley <dworley@nortel.com>
To: "DRAGE, Keith (Keith)" <drage@alcatel-lucent.com>
In-Reply-To: <EDC0A1AE77C57744B664A310A0B23AE20874FD06@FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com>
References: <C0E80510684FE94DBDE3A4AF6B968D2D06311DBD@esealmw118.eemea.ericsson.se> <4A85C195.4060903@nostrum.com> <CA9998CD4A020D418654FCDEF4E707DF0E3D8462@esealmw113.eemea.ericsson.se> <EDC0A1AE77C57744B664A310A0B23AE20874FD06@FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com>
Content-Type: text/plain
Organization: Nortel Networks
Date: Fri, 02 Oct 2009 17:44:40 -0400
Message-Id: <1254519880.3767.33.camel@khone.us.nortel.com>
Mime-Version: 1.0
X-Mailer: Evolution 2.12.3 (2.12.3-5.fc8)
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 02 Oct 2009 21:44:41.0722 (UTC) FILETIME=[8C6195A0:01CA43A9]
Cc: Ian Elz <ian.elz@ericsson.com>, "sipcore@ietf.org" <sipcore@ietf.org>
Subject: Re: [sipcore] draft-roach-sipcore-rfc3265bis-00
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: Fri, 02 Oct 2009 21:43:48 -0000
In regard to the fact that a proxy (that wishes to remain in the signaling path) must Record-Route all SUBSCRIBEs without to-tags, and all NOTIFYs: On Tue, 2009-08-18 at 15:24 +0200, DRAGE, Keith (Keith) wrote: > Christer wrote > > > Again, a 3261 compliant proxy may Record-Route the SUBSCRIBE, > > but that doesn't mean it will Record-Route the NOTIFY. It may > > simply be configured to Record-Route all dialog initiation requests. > > > > It can only do this if it understands that SUBSCRIBE is a dialog > initiation request, and it can only do this if it implements either > RFC 3265 or 3265bis. > > As I understood it, the behaviour described by Adam is already in RFC > 3265, and therefore it is a non-conformant implementation of RFC 3265 > if it does something difference. Some years ago, I was in a long discussion about how SUBSCRIBE/NOTIFY need to be record-routed, especially in the context of non-dialog-stateful proxies. Unfortunately, nobody in the conversation recalled section 3.1.5 of RFC 3265, but we came to the conclusion that in order for subscriptions to work *in practice*, a non-dialog-stateful proxy must record-route SUBSCRIBEs without to-tags and all NOTIFYs, or record-route none of them. So practical demands require that any proxy in an environment that uses SUB/NOT would satisfy 3.1.5 (in almost all cases), that is *be* RFC 3265-compliant, even if it didn't *intend* to be RFC 3265-compliant. In that context, 3265bis doesn't demand any behavior from proxies that they don't (in practice) have to have already. So I think we can safely depend on them having the proper behavior. Dale
- [sipcore] draft-roach-sipcore-rfc3265bis-00 Ian Elz
- Re: [sipcore] draft-roach-sipcore-rfc3265bis-00 Adam Roach
- Re: [sipcore] draft-roach-sipcore-rfc3265bis-00 -… Ian Elz
- Re: [sipcore] draft-roach-sipcore-rfc3265bis-00 Christer Holmberg
- Re: [sipcore] draft-roach-sipcore-rfc3265bis-00 -… Ian Elz
- Re: [sipcore] draft-roach-sipcore-rfc3265bis-00 -… Adam Roach
- Re: [sipcore] draft-roach-sipcore-rfc3265bis-00 Adam Roach
- Re: [sipcore] draft-roach-sipcore-rfc3265bis-00 Christer Holmberg
- Re: [sipcore] draft-roach-sipcore-rfc3265bis-00 -… Paul Kyzivat
- Re: [sipcore] draft-roach-sipcore-rfc3265bis-00 DRAGE, Keith (Keith)
- Re: [sipcore] draft-roach-sipcore-rfc3265bis-00 Christer Holmberg
- Re: [sipcore] draft-roach-sipcore-rfc3265bis-00 -… Christer Holmberg
- Re: [sipcore] draft-roach-sipcore-rfc3265bis-00 -… Ian Elz
- Re: [sipcore] draft-roach-sipcore-rfc3265bis-00 -… Ian Elz
- Re: [sipcore] draft-roach-sipcore-rfc3265bis-00 -… Paul Kyzivat
- Re: [sipcore] draft-roach-sipcore-rfc3265bis-00 -… Ian Elz
- Re: [sipcore] draft-roach-sipcore-rfc3265bis-00 -… Paul Kyzivat
- Re: [sipcore] draft-roach-sipcore-rfc3265bis-00 -… Christer Holmberg
- Re: [sipcore] draft-roach-sipcore-rfc3265bis-00 -… Paul Kyzivat
- Re: [sipcore] draft-roach-sipcore-rfc3265bis-00 -… Christer Holmberg
- Re: [sipcore] draft-roach-sipcore-rfc3265bis-00 Dale Worley