[Sip] RE: draft-fwmiller-ping-00 comments

fwmiller@cornfed.com Tue, 21 February 2006 13:44 UTC

Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FBXoM-0006bh-1W; Tue, 21 Feb 2006 08:44:14 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FBXoL-0006bb-1G for sip@ietf.org; Tue, 21 Feb 2006 08:44:13 -0500
Received: from [66.113.136.12] (helo=smapp01.siteprotect.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FBXoJ-0002zE-Q3 for sip@ietf.org; Tue, 21 Feb 2006 08:44:13 -0500
Received: from smapp01.siteprotect.com (localhost [127.0.0.1]) by smapp01.siteprotect.com (8.11.6/8.11.6) with ESMTP id k1LDhZn18587; Tue, 21 Feb 2006 07:43:36 -0600
Date: Tue, 21 Feb 2006 07:43:36 -0600
Message-Id: <200602211343.k1LDhZn18587@smapp01.siteprotect.com>
From: fwmiller@cornfed.com
To: Rayees Khan <rayees.khan@flextronicssoftware.com>, fwmiller@cornfed.com
X-Spam-Score: 0.2 (/)
X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906
Cc: sip@ietf.org
Subject: [Sip] RE: draft-fwmiller-ping-00 comments
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>, <mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>, <mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org


Thanks for the comments.  Discussion inline...

------------------------------------------------
On Tue, 21 Feb 2006 14:48:04 +0530, Rayees Khan <rayees.khan@flextronicssoftware.com> wrote:

> 
>Section 2 of the draft mentions that signaling path of the PING >method is established as a result of a call setup. Now what I >understand is that main purpose the method is to keep the >signaling path alive or to check the validity of the signaling >path. This means that it would mostly be sent outside the >context of a session. In such context I guess it has to follow >path of a dialog establishing request.

The wording here should probably be changed.  The intent is to have PINGs travel through the normal proxy sequence that any other request would take, thereby refreshing the entire path.  I know we're talking mainly about the NAT traversal problem but if we're coming up with a general method, it should address keepalive all the way along whether there a forseen problems or not.  When I changed it from in-session only to being able to send anytime, I didn't do any rewording here.  I will do that now.


>Section 2.1 lists the headers that are expected in the PING >method. Well, I have come across devices using Require and >Proxy-Require header in PING messages.

Hmm.  I'd be interested in any other discussion on this point.  It would be nice to keep these out if possible to keep the message simple.


>Section 2.2 mentions the responses that are expected for a PING >request. I was wondering that it is very well possible that if >a server receives a PING request which is addressed to >something that Server does not know about it is most likely to >send a 404 response.

I'm wondering if it shouldnt just be any response except for a 1xx and 3xx class response.

FM

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip