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

Michael Miller <mlm.michael.miller@gmail.com> Mon, 16 August 2010 21:17 UTC

Return-Path: <mlm.michael.miller@gmail.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 0D7783A6AC3; Mon, 16 Aug 2010 14:17:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 2.397
X-Spam-Level: **
X-Spam-Status: No, score=2.397 tagged_above=-999 required=5 tests=[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, MIME_QP_LONG_LINE=1.396]
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 17HH-wbfciW4; Mon, 16 Aug 2010 14:17:29 -0700 (PDT)
Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by core3.amsl.com (Postfix) with ESMTP id 605483A6ABD; Mon, 16 Aug 2010 14:17:29 -0700 (PDT)
Received: by vws10 with SMTP id 10so4217175vws.31 for <multiple recipients>; Mon, 16 Aug 2010 14:18:05 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:references:in-reply-to :mime-version:content-type:message-id:content-transfer-encoding:cc :x-mailer:from:subject:date:to; bh=A1WWeN+jA66ljfKs/cX2V56cvQ1cRglw2VCJjmvT5fk=; b=LMNqNvCMxbbyGKHengAlWNE2nPnydUMf4gaZuxnIcH+irvZBdGM2gHejkFSmcnm8WM LnhS7yC8dq2iF6lpXQyKd25U7h7NA8aqu3l7Zmu5sW/eRT4knbho6SeAO89yEMlxpqFn cHWh1V3BNp98zvTBrdUbCw7oBy4zTds89gqO8=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=references:in-reply-to:mime-version:content-type:message-id :content-transfer-encoding:cc:x-mailer:from:subject:date:to; b=rPMrs4kEOUwe1Rpmyf514rVmGnGwZjj08pL8KE48X/mzH4QMxkZnhIGwopDCbpDps5 GigylktONdgo5SGyfi9B8S73Vwg51dl7qSAVw/602wjlKLZurms/7Ldp+6KxoGn0SsZB k+J+9KrBaKt0LwF+h0XuRDCBUrwaO8WKJaiYU=
Received: by 10.220.122.151 with SMTP id l23mr3365024vcr.162.1281993482887; Mon, 16 Aug 2010 14:18:02 -0700 (PDT)
Received: from [10.70.112.39] (mobile-166-137-136-078.mycingular.net [166.137.136.78]) by mx.google.com with ESMTPS id a16sm432583vcm.42.2010.08.16.14.18.01 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 16 Aug 2010 14:18:02 -0700 (PDT)
References: <053401cb39dd$44070ee0$cc152ca0$@packetizer.com> <4C690C38.6010804@1and1.ro> <012901cb3d45$5544c880$ffce5980$@packetizer.com> <4C694532.4020109@1and1.ro> <017e01cb3d62$7c171d10$74455730$@packetizer.com>
In-Reply-To: <017e01cb3d62$7c171d10$74455730$@packetizer.com>
Mime-Version: 1.0 (iPhone Mail 8A306)
Content-Type: text/plain; charset=us-ascii
Message-Id: <A0F5A450-114E-4574-93E3-CEBD07DA9F4F@gmail.com>
Content-Transfer-Encoding: quoted-printable
X-Mailer: iPhone Mail (8A306)
From: Michael Miller <mlm.michael.miller@gmail.com>
Date: Mon, 16 Aug 2010 17:18:06 -0400
To: "Paul E. Jones" <paulej@packetizer.com>
X-Mailman-Approved-At: Mon, 16 Aug 2010 14:54:33 -0700
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 21:17:32 -0000

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