Re: [sip-ops] SIP OPTIONS "ping"
"Paul E. Jones" <paulej@packetizer.com> Fri, 13 August 2010 04:19 UTC
Return-Path: <paulej@packetizer.com>
X-Original-To: sip-ops@core3.amsl.com
Delivered-To: sip-ops@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2F5D33A6814 for <sip-ops@core3.amsl.com>; Thu, 12 Aug 2010 21:19:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.41
X-Spam-Level:
X-Spam-Status: No, score=-1.41 tagged_above=-999 required=5 tests=[AWL=1.188, BAYES_00=-2.599, HTML_MESSAGE=0.001]
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 sOCPPGzRsDhC for <sip-ops@core3.amsl.com>; Thu, 12 Aug 2010 21:18:56 -0700 (PDT)
Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by core3.amsl.com (Postfix) with ESMTP id 072F33A6892 for <sip-ops@ietf.org>; Thu, 12 Aug 2010 21:18:55 -0700 (PDT)
Received: from sydney (rrcs-98-101-146-183.midsouth.biz.rr.com [98.101.146.183]) (authenticated bits=0) by dublin.packetizer.com (8.14.2/8.14.2) with ESMTP id o7D4JNcW016677 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 13 Aug 2010 00:19:29 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1281673169; bh=2zXETL6GEJeMPfG32qbQx+7IbuRzIMrU6lx2Zk2yVaU=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type; b=kPQHD40HjSqJqdsKPHkcvqz/uXEMOdasdF8dobQPR17tKwn8KHcA6vG4HGDiW1R7X /ytmAqiwFoO+l06n6zwbR8r89QLYr7EyiyHn1GkC2oAZ9lDEZa5dOZScfoJ0bQNo73 psPxgXkB41sOPBrQOkEQBBnA85xp/7hAdmOE/rgI=
From: "Paul E. Jones" <paulej@packetizer.com>
To: 'Brian Rosen' <br@brianrosen.net>
References: <053401cb39dd$44070ee0$cc152ca0$@packetizer.com> <736CC4E3-7489-42F6-9E68-1C6EA51C0503@brianrosen.net>
In-Reply-To: <736CC4E3-7489-42F6-9E68-1C6EA51C0503@brianrosen.net>
Date: Fri, 13 Aug 2010 00:18:34 -0400
Message-ID: <006b01cb3a9e$9bbc3e00$d334ba00$@packetizer.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_006C_01CB3A7D.14AC4BB0"
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQJ7YPXf2shkdXst8Oeg2uiqnTvIBAH8ZVRzkW6XLaA=
Content-language: en-us
Cc: sip-ops@ietf.org, 'Hadriel Kaplan' <HKaplan@acmepacket.com>, sip-implementors@lists.cs.columbia.edu
Subject: Re: [sip-ops] SIP OPTIONS "ping"
X-BeenThere: sip-ops@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: SIP Operations <sip-ops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/sip-ops>, <mailto:sip-ops-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sip-ops>
List-Post: <mailto:sip-ops@ietf.org>
List-Help: <mailto:sip-ops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sip-ops>, <mailto:sip-ops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 13 Aug 2010 04:19:00 -0000
Brian, If I could, I'd revise RFC 3261. It's that document that introduces the use of OPTIONS as a "ping" mechanism, but gives little guidance to implementers and, as such, implementations are all over the map. I've seen at least 6 different variants implemented. But, I think trying to revise RFC 3261 would open a can of worms. So, I was suggesting we progress this as standard track to update RFC 3261, but that didn't happen. I'm not trying to introduce anything new, though: just clarify what should have been elaborated upon more fully in 3261. Even so, there are certainly points of contention, I'm sure, since folks do have it implemented differently. Paul From: Brian Rosen [mailto:br@brianrosen.net] Sent: Thursday, August 12, 2010 8:45 AM To: Paul E. Jones Cc: sip-ops@ietf.org; sip-implementors@lists.cs.columbia.edu; Hadriel Kaplan Subject: Re: [sip-ops] SIP OPTIONS "ping" I think this is needed, and I would go for informational. While I sort of understand that you are "pushing" the definition of OPTIONS, if it was PS, you wouldn't update any RFCs, right? Brian On Aug 12, 2010, at 1:14 AM, Paul E. Jones wrote: Folks, Gonzalo and I produced an Internet Draft aiming at trying to bring some consistency to the way in which SIP user agents implement an OPTIONS "ping" procedure. It seems that a very large number of vendors do this, but unfortunately, there seems to be little consistency. Initially, we positioned the document as a standards track RFC, since this essentially builds on RFC 3261. However, there was some pushback from folks in the IETF for a variety of reasons, not the least of which is the fact that there is no working group chartered to do the work. We don't feel this one draft warrants the creation of a working group. So, we've got three options we can consider: 1) Forge ahead outside of a working group 2) Change the status of the draft to Informational 3) Forget about the draft and let every SIP device do it the way they want, throwing hope of consistency out the window (Yeah, you can tell I prefer not to go for the third option.) In any case, I'd like to get feedback from the on the SIP operators and SIP implementers lists. Do you think it's worth trying to address this issue? If so, which option do you think we should pursue? Note that we're certainly open to feedback on the draft. I'd prefer it to have a few more "MUST" statements in the text, rather than "SHOULD". But, we need to find that right balance: http://tools.ietf.org/html/draft-jones-sip-options-ping Paul _______________________________________________ sip-ops mailing list sip-ops@ietf.org https://www.ietf.org/mailman/listinfo/sip-ops
- [sip-ops] SIP OPTIONS "ping" Paul E. Jones
- Re: [sip-ops] SIP OPTIONS "ping" Brian Rosen
- Re: [sip-ops] SIP OPTIONS "ping" Cullen Jennings
- Re: [sip-ops] [Sip-implementors] SIP OPTIONS "pin… Paul E. Jones
- Re: [sip-ops] SIP OPTIONS "ping" Paul E. Jones
- Re: [sip-ops] SIP OPTIONS "ping" Paul E. Jones
- Re: [sip-ops] [Sip-implementors] SIP OPTIONS "pin… Paul E. Jones
- Re: [sip-ops] [Sip-implementors] SIP OPTIONS "pin… Paul E. Jones
- Re: [sip-ops] [dispatch] [Sip-implementors] SIP O… Michael Miller
- Re: [sip-ops] [dispatch] [Sip-implementors] SIP O… Paul E. Jones
- Re: [sip-ops] [dispatch] [Sip-implementors] SIP O… Michael Miller
- Re: [sip-ops] SIP OPTIONS "ping" Paul E. Jones
- Re: [sip-ops] [dispatch] SIP OPTIONS "ping" Marius Zbihlei