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

"Paul E. Jones" <paulej@packetizer.com> Mon, 16 August 2010 16:46 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 ABCB73A69FF; Mon, 16 Aug 2010 09:46:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.019
X-Spam-Level:
X-Spam-Status: No, score=0.019 tagged_above=-999 required=5 tests=[AWL=-0.982, 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 mskALhJK5foI; Mon, 16 Aug 2010 09:46:19 -0700 (PDT)
Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by core3.amsl.com (Postfix) with ESMTP id 4C51F3A6881; Mon, 16 Aug 2010 09:46:19 -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 o7GGkeZv021331 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 16 Aug 2010 12:46:45 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1281977206; bh=dNihPNbCFDt7yt2oAriEUHRYofxgpuvfKOiXR5gK9CA=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=af+MLW3kUzXW7YjHnDXc27LmEfg+fq2VZKnyy9TGHCYlB9uHQnt7+awV2P4ZQWP08 m8RysRPrRtdvSRyQCn+Gu0fop6pXUtx+e7hy22AtpOdg6DEKZ8l9yOdSA0ov1YRuZV 9bp1m9H1tcLe5DwYBHyhS7yWB8mnYdpaKqkpb1gg=
From: "Paul E. Jones" <paulej@packetizer.com>
To: "'marius zbihlei'" <marius.zbihlei@1and1.ro>
References: <053401cb39dd$44070ee0$cc152ca0$@packetizer.com> <4C690C38.6010804@1and1.ro> <012901cb3d45$5544c880$ffce5980$@packetizer.com> <4C694532.4020109@1and1.ro>
In-Reply-To: <4C694532.4020109@1and1.ro>
Date: Mon, 16 Aug 2010 12:45:44 -0400
Message-ID: <017e01cb3d62$7c171d10$74455730$@packetizer.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQJ7YPXf2shkdXst8Oeg2uiqnTvIBAJGarLcAUcUVigCKte1dZFWP3xg
Content-language: en-us
Cc: sip-ops@ietf.org, dispatch@ietf.org, 'Hadriel Kaplan' <HKaplan@acmepacket.com>, sip-implementors@lists.cs.columbia.edu
Subject: Re: [sip-ops] [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 16:46:21 -0000

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