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

Michael Miller <mlm.michael.miller@gmail.com> Mon, 16 August 2010 23:36 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 7FE8A3A6827; Mon, 16 Aug 2010 16:36:56 -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 TSwh6dVXOrcm; Mon, 16 Aug 2010 16:36:55 -0700 (PDT)
Received: from mail-gw0-f44.google.com (mail-gw0-f44.google.com [74.125.83.44]) by core3.amsl.com (Postfix) with ESMTP id C8FB23A67F0; Mon, 16 Aug 2010 16:36:54 -0700 (PDT)
Received: by gwaa18 with SMTP id a18so2562730gwa.31 for <multiple recipients>; Mon, 16 Aug 2010 16:37:22 -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=1ISZGdeQDIMKVkSO29svAsKiGU20+BAYTYVEYAv++4o=; b=Oits9tyQ0F6Wv13Bxs+nmPDCVCAtJcNWNgz0i0lN134bVRHs5Ugd6DFvsZ+9/DQLhN REdbdQZqG8OZyUB2xTQnmh3YHjdKx+BEF6Q3CXudmIx9MHoKLelAt97K2nDlqbSBW0bc ANOYZVGFZHqU+BX1uqWTa+IvDkqi9Eb1AFq1Q=
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=YUsaH7PW4r9hKz1HotcRzoUVBKvnN8qb+s260Ot2xMPemjAjgNtl35SetPD85dMJ01 ioziLbXYD+q0RYJxeK/8A+/3GGdb3zhP6ovW3LaAreE9IfVjPk0Ddwd3yBMNKWBSpdKf cszsZAhr3F+Oq0fhbwzkpI7m2EpI3j0HmsXH0=
Received: by 10.101.138.8 with SMTP id q8mr6622814ann.164.1282001842173; Mon, 16 Aug 2010 16:37:22 -0700 (PDT)
Received: from [192.168.1.162] (c-71-205-254-94.hsd1.mi.comcast.net [71.205.254.94]) by mx.google.com with ESMTPS id p12sm11128358ane.34.2010.08.16.16.37.20 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 16 Aug 2010 16:37:21 -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> <A0F5A450-114E-4574-93E3-CEBD07DA9F4F@gmail.com> <ca173b25-5050-4846-a19d-cdf5d3997d6d@email.android.com>
In-Reply-To: <ca173b25-5050-4846-a19d-cdf5d3997d6d@email.android.com>
Mime-Version: 1.0 (iPhone Mail 8A306)
Content-Type: text/plain; charset=us-ascii
Message-Id: <67CEA0ED-6F29-4D89-9177-6355B8EC8458@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 19:37:28 -0400
To: "Paul E. Jones" <paulej@packetizer.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:36:56 -0000

Ok. Sounds good. I like to help where I can. 

Michael L. Miller
Sent from my Mobile Device

On Aug 16, 2010, at 6:54 PM, "Paul E. Jones" <paulej@packetizer.com>; wrote:

> 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
>