[sip-ops] SIP OPTIONS "ping"

"Paul E. Jones" <paulej@packetizer.com> Thu, 12 August 2010 05:15 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 []) by core3.amsl.com (Postfix) with ESMTP id CB2783A697B for <sip-ops@core3.amsl.com>; Wed, 11 Aug 2010 22:15:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.248
X-Spam-Status: No, score=0.248 tagged_above=-999 required=5 tests=[AWL=0.246, BAYES_50=0.001, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([]) by localhost (core3.amsl.com []) (amavisd-new, port 10024) with ESMTP id QjsSwuZKJtD5 for <sip-ops@core3.amsl.com>; Wed, 11 Aug 2010 22:14:56 -0700 (PDT)
Received: from dublin.packetizer.com (dublin.packetizer.com []) by core3.amsl.com (Postfix) with ESMTP id 297B53A697F for <sip-ops@ietf.org>; Wed, 11 Aug 2010 22:14:55 -0700 (PDT)
Received: from sydney (rrcs-98-101-146-183.midsouth.biz.rr.com []) (authenticated bits=0) by dublin.packetizer.com (8.14.2/8.14.2) with ESMTP id o7C5FNul010090 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 12 Aug 2010 01:15:29 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1281590129; bh=e0LMmnjjLabFWIDJ0ilLwv2NBvutJfkcGk4RKcqyttc=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version:Content-Type; b=nzKTbIH5KQfoUf92ZAiLaBqLSLyc7/Mp8lNsYHB/A/z/oDXrJg/p2vjDIVG7VTBUI LrkCukh6tfd3T3pwmVMze8NGNBAayNqY439MVRayQqx+dbGBZvCm9zrezJsBnhBpsk K7RWXUIzeZHCEeF/pU9FEqdl+GDgnXiqhPWKxnXg=
From: "Paul E. Jones" <paulej@packetizer.com>
To: <sip-ops@ietf.org>, <sip-implementors@lists.cs.columbia.edu>
Date: Thu, 12 Aug 2010 01:14:34 -0400
Message-ID: <053401cb39dd$44070ee0$cc152ca0$@packetizer.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0535_01CB39BB.BCF65940"
X-Mailer: Microsoft Outlook 14.0
thread-index: Acs53UBmkKgtMEtOSxC/dOMzX8shWQ==
Content-Language: en-us
Cc: Hadriel Kaplan <HKaplan@acmepacket.com>
Subject: [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: Thu, 12 Aug 2010 05:15:06 -0000



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: