[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
- [Sip] draft-fwmiller-ping-00 comments Rayees Khan
- [Sip] RE: draft-fwmiller-ping-00 comments fwmiller
- [Sip] RE: draft-fwmiller-ping-00 comments Rayees Khan
- [Sip] Re: draft-fwmiller-ping-00 comments Frank W. Miller
- [Sip] Certification cources Priti