Re: [sip-ops] [dispatch] [Sip-implementors] SIP OPTIONS "ping"

"Paul E. Jones" <paulej@packetizer.com> Mon, 16 August 2010 23:16 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 7BE113A6827; Mon, 16 Aug 2010 16:16:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.128
X-Spam-Level:
X-Spam-Status: No, score=0.128 tagged_above=-999 required=5 tests=[AWL=-0.873, BAYES_00=-2.599, J_CHICKENPOX_34=0.6, J_CHICKENPOX_42=0.6, J_CHICKENPOX_51=0.6, J_CHICKENPOX_53=0.6, J_CHICKENPOX_72=0.6, J_CHICKENPOX_84=0.6]
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 TEc5N7jx-825; Mon, 16 Aug 2010 16:16:02 -0700 (PDT)
Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by core3.amsl.com (Postfix) with ESMTP id F3FF33A681D; Mon, 16 Aug 2010 16:16:01 -0700 (PDT)
Received: from dyn-129.arid.us (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 o7GNGNnB032537 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 16 Aug 2010 19:16:28 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1282000590; bh=+S5AhyXvDDleSwLoNLEfFmVwGvtmlu2wPbDZpj8GY/0=; h=References:In-Reply-To:MIME-Version:Content-Type: Content-Transfer-Encoding:Subject:From:Date:To:CC:Message-ID; b=NDmwEFgMbVnMe74tAmRWU7Jq1RHHvuuZkAJpGBaZYEy78bzelwAAmMunPEuVg7EVx MIc35BiyhohaQoRroFw0hwoqpsJH8VDekzit+Btm60nb+2Y29Hfm7u0IH2vXQk1SFP w3Ri/7/7nc9RgxzeZNiYhuEvXfL6yRX2Pe6AmvR0=
X-User-Agent: K-9 Mail for Android
References: <053401cb39dd$44070ee0$cc152ca0$@packetizer.com> <4C690C38.6010804@1and1.ro> <012901cb3d45$5544c880$ffce5980$@packetizer.com> <4C694532.4020109@1and1.ro> <017e01cb3d62$7c171d10$74455730$@packetizer.com> <A0F5A450-114E-4574-93E3-CEBD07DA9F4F@gmail.com>
In-Reply-To: <A0F5A450-114E-4574-93E3-CEBD07DA9F4F@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
From: "Paul E. Jones" <paulej@packetizer.com>
Date: Mon, 16 Aug 2010 18:54:09 -0400
To: Michael Miller <mlm.michael.miller@gmail.com>
Message-ID: <ca173b25-5050-4846-a19d-cdf5d3997d6d@email.android.com>
Cc: "dispatch@ietf.org" <dispatch@ietf.org>, "sip-ops@ietf.org" <sip-ops@ietf.org>, marius zbihlei <marius.zbihlei@1and1.ro>, Hadriel Kaplan <HKaplan@acmepacket.com>, "sip-implementors@lists.cs.columbia.edu" <sip-implementors@lists.cs.columbia.edu>
Subject: Re: [sip-ops] [dispatch] [Sip-implementors] 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: Mon, 16 Aug 2010 23:16:03 -0000

We had a side discussion and reached agreement that this end-to-end procedure really ought to be a separate document. I think the scope of each is enough to justify two documents.

So, we'll collaborate to produce two separate documents. Whether those will be informational or standards track is TBD.

Paul

"Michael Miller" <mlm.michael.miller@gmail.com>; wrote:

>The end the end OPTIONS ping sounds like a great ideal, but does this change this doc from more of a informational/best practice to some thing that would require a change to SIP (like a header or something). 
>
>I'm new to this
>
>Michael L. Miller
>Sent from my Mobile Device
>
>On Aug 16, 2010, at 12:45 PM, "Paul E. Jones" <paulej@packetizer.com>; wrote:
>
>> Marius,
>> 
>> There is another important consideration to give to this.  The OPTIONS
>> "ping" we described was intended to be between a device and its next hop.
>> What you would actually want is an OPTIONS that goes end-to-end.
>> 
>> I think both need clarification, but I'm now thinking that perhaps we ought
>> to document these separately.  Of course, I'd be happy to work with you on
>> both.
>> 
>> Paul
>> 
>>> -----Original Message-----
>>> From: marius zbihlei [mailto:marius.zbihlei@1and1.ro]
>>> Sent: Monday, August 16, 2010 10:04 AM
>>> To: Paul E. Jones
>>> Cc: sip-ops@ietf.org; sip-implementors@lists.cs.columbia.edu; 'Gonzalo
>>> Salgueiro'; 'Hadriel Kaplan'; dispatch@ietf.org
>>> Subject: Re: [Sip-implementors] SIP OPTIONS "ping"
>>> 
>>> Paul E. Jones wrote:
>>>> Marius,
>>>> 
>>>> It is certainly true that we were focused entirely on out-of-dialog
>>>> OPTIONS messages when we wrote the draft.  I'm certainly not opposed
>>>> to also including in-dialog OPTIONS exchanges if it fit smoothly within
>>> the draft.
>>>> Alternatively, we could create two drafts.
>>>> 
>>>> Would you like to draft some initial text for in-dialog and see if it
>>>> makes sense to include it in this same draft or a separate one?  If in
>>>> the same draft, then perhaps in-dialog and OOD would be two separate
>>> sections?
>>>> 
>>>> Paul
>>>> 
>>>> 
>>> Hello again,
>>> 
>>> I would gladly draft some initial text around this idea, but I am a little
>>> torn apart between what I expect from the draft(and current
>>> implementations) and what previous standards say.
>>> 
>>> Quote from RFC 3261
>>> 12.2.2 UAS Behavior "Requests that do not change in any way the state of a
>>> dialog may be received within a dialog (for example, an OPTIONS request).
>>> They are processed as if they had been received outside the dialog."
>>> 
>>> Along with other texts[1], this means that in-dialog OPTIONS requests
>>> should be treated as OOD(also the thread I have linked seems to suggest
>>> that). But I know for certain that lots of implementors do return a 481,
>>> and several services rely on that error code to check if a dialog is still
>>> running. I know about SIP Session Timers but using OPTIONS ping like
>>> this(to discover if a dialog has finished) has some benefits(like the
>>> proxy being able to terminate a call , which is not possible using SST
>>> [2]), and more and more this looks like a "de facto" behavior.
>>> 
>>> With this in mind, I have to ask the question: Should we allow (or
>>> inforce) the 481 response for a in-dialog OPTIONS request(if the dialog
>>> does not exits)(this is what I personally want and many implementors
>>> already do), or should we respond with a 200 OK regardless if the dialog
>>> exists or not?!
>>> 
>>> Thank you in advance for answering this.
>>> 
>>> [1] RFC 5057 section 5.3: "OPTIONS does not belong to any usage. Only
>>> those failures discussed in Section 5.1 and Section 5.2 that destroy
>>> entire dialogs will have any effect on the usages sharing the dialog with
>>> a failed OPTIONS request."
>>> 
>>> This in fact might prove usefull, as a failed in-dialog OPTIONS request
>>> will guaranty that the dialog will not be destroyed
>>> 
>>> [2] http://www.rfc-editor.org/rfc/rfc4028.txt
>>> 8.3. Session Expiration
>>> 
>>> When the current time equals or passes the session expiration for a
>>> session, the proxy MAY remove associated call state, and MAY free any
>>> resources associated with the call. Unlike the UA, it MUST NOT send a BYE.
>>>>> -----Original Message-----
>>>>> From: marius zbihlei [mailto:marius.zbihlei@1and1.ro]
>>>>> Sent: Monday, August 16, 2010 6:00 AM
>>>>> To: Paul E. Jones
>>>>> Cc: sip-ops@ietf.org; sip-implementors@lists.cs.columbia.edu; Gonzalo
>>>>> Salgueiro; Hadriel Kaplan
>>>>> Subject: Re: [Sip-implementors] SIP OPTIONS "ping"
>>>>> 
>>>>> 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?
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>> Hello,
>>>>> 
>>>>> I have read the draft and as far I can tell it addresses OPTIONS
>>>>> outside a dialog. I know that this has already been discussed on this
>>>>> mailing list[1], but there still are many vendors/SIP implementors
>>>>> that use a in- dialog OPTIONS to figure out if a dialog is still
>>>>> running(if not the UAS "will" respond with a 481- Call does not
>>>>> exist). By reading the comments and the RFC I know this is wrong(a
>>>>> UAS might return a 200 OK even if the dialog does not exist), but I
>>>>> think this enters into the "3) Forget about the draft and let every
>>>>> SIP device do it the way they want, throwing hope of consistency out
>>> the window " category.
>>>>> 
>>>>> My first reaction is also to address this topic in the draft. What do
>>>>> you think?
>>>>> 
>>>>> Marius
>>>>> 
>>>>> [1]https://lists.cs.columbia.edu/pipermail/sip-implementors/2008-
>>>>> May/019278.html
>>>>> 
>>>>>> 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-implementors mailing list
>>>>>> Sip-implementors@lists.cs.columbia.edu
>>>>>> https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
>>>>>> 
>>>>>> 
>>>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>> 
>> 
>> _______________________________________________
>> dispatch mailing list
>> dispatch@ietf.org
>> https://www.ietf.org/mailman/listinfo/dispatch