[Sip] PING/PONG

"Christian Stredicke" <Christian.Stredicke@snom.de> Mon, 08 November 2004 21:55 UTC

Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07148 for <sip-web-archive@ietf.org>; Mon, 8 Nov 2004 16:55:18 -0500 (EST)
Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRHUU-0007DT-57 for sip-web-archive@ietf.org; Mon, 08 Nov 2004 16:55:59 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRHNc-0007Qt-2b; Mon, 08 Nov 2004 16:48:52 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRH8D-0002mU-Mc for sip@megatron.ietf.org; Mon, 08 Nov 2004 16:32:57 -0500
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04220 for <sip@ietf.org>; Mon, 8 Nov 2004 16:32:54 -0500 (EST)
Received: from natsmtp00.rzone.de ([81.169.145.165]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRH8p-0006RU-Ag for sip@ietf.org; Mon, 08 Nov 2004 16:33:36 -0500
Received: from snom.de (pD9568738.dip.t-dialin.net [217.86.135.56]) by post.webmailer.de (8.13.1/8.13.1) with ESMTP id iA8LVHVn016439; Mon, 8 Nov 2004 22:31:18 +0100 (MET)
Content-class: urn:content-classes:message
MIME-Version: 1.0
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Date: Mon, 08 Nov 2004 22:31:15 +0100
Message-ID: <B52FDDEC7CBE9D40B36FE900C9AD78B417695F@merenge.intern.snom.de>
Thread-Topic: PING/PONG
thread-index: AcTF2kbloPYnFtW7Qjah6sX+t0mDhg==
From: Christian Stredicke <Christian.Stredicke@snom.de>
To: fluffy@cisco.com
X-Spam-Score: 1.0 (+)
X-Scan-Signature: 73734d43604d52d23b3eba644a169745
Cc: sip@ietf.org
Subject: [Sip] PING/PONG
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>
Content-Type: multipart/mixed; boundary="===============0308069664=="
Sender: sip-bounces@ietf.org
Errors-To: sip-bounces@ietf.org
X-Spam-Score: 0.7 (/)
X-Scan-Signature: 6d95a152022472c7d6cdf886a0424dc6

Hello Cullen,
 
I think it is no harm if there is a PING message defined in SIP. I
personally think it is overdue anyway. Implementors can then decide if
they are using it or not. Lets leave that decision to the implementors!
 
But we have to consider who is sending keep-alive traffic. "IMHO" is it
definitely better if the UA does this, because then e.g. usually it is
ok to send CRLF keep alive or STUN.
 
We register with a header that incates (a) that the UA is able to do the
refreshing and (b) what the proposed refresh time is. The UA can do all
these tricky NAT measurement tricks and then propose the refresh time.
Stupid UA may just propose a predefined value, e.g. 20 seconds. The
registrar (or whatever is in the path) then can acknowlege the refresh
role and leave the refreshing to the UA. Otherwise, it will send the
refresh messages. In that case, it will probably use PING, cause it
needs a response to keep the NAT alive in all cases - even if it is a
"503 Not Implemented".
 
Christian
 
_______________________________________________
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