RE: [Sip] PING/PONG
"Christian Stredicke" <Christian.Stredicke@snom.de> Tue, 09 November 2004 15:25 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 KAA08861 for <sip-web-archive@ietf.org>; Tue, 9 Nov 2004 10:25:39 -0500 (EST)
Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRXt3-0006N0-Uz for sip-web-archive@ietf.org; Tue, 09 Nov 2004 10:26:29 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRXiE-0004x6-4v; Tue, 09 Nov 2004 10:15:14 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRXb9-0001gn-84 for sip@megatron.ietf.org; Tue, 09 Nov 2004 10:07:56 -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 KAA06019 for <sip@ietf.org>; Tue, 9 Nov 2004 10:07:52 -0500 (EST)
Received: from natnoddy.rzone.de ([81.169.145.166]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRXbu-0005w1-3U for sip@ietf.org; Tue, 09 Nov 2004 10:08:42 -0500
Received: from snom.de (pD95686F1.dip.t-dialin.net [217.86.134.241]) by post.webmailer.de (8.13.1/8.13.1) with ESMTP id iA9F6kQD002916; Tue, 9 Nov 2004 16:06:47 +0100 (MET)
Content-class: urn:content-classes:message
MIME-Version: 1.0
Subject: RE: [Sip] PING/PONG
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Date: Tue, 09 Nov 2004 16:06:42 +0100
Message-ID: <B52FDDEC7CBE9D40B36FE900C9AD78B41769C9@merenge.intern.snom.de>
Thread-Topic: [Sip] PING/PONG
thread-index: AcTGVeD72vlivuzXRNmVFA8//spI5wABZoOgAAGeqgAAAsmPsA==
From: Christian Stredicke <Christian.Stredicke@snom.de>
To: Chris Boulton <cboulton@ubiquity.net>, "Christer Holmberg (JO/LMF)" <christer.holmberg@ericsson.com>, fluffy@cisco.com
X-Spam-Score: 0.6 (/)
X-Scan-Signature: d1013c8bad83fa4e4ccb34a7376b19d5
Cc: sip@ietf.org
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="===============1083694966=="
Sender: sip-bounces@ietf.org
Errors-To: sip-bounces@ietf.org
X-Spam-Score: 0.6 (/)
X-Scan-Signature: 04ebe73024b6be81174765e91aced811
________________________________ From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of Chris Boulton Sent: Tuesday, November 09, 2004 9:31 AM To: Christian Stredicke; Christer Holmberg (JO/LMF); fluffy@cisco.com Cc: sip@ietf.org Subject: RE: [Sip] PING/PONG All I am saying is lets define the tool "PING", if and how implementors are using it is up to them. [Chris Boulton] Sorry if I am missing something BUT was does this buy you (That say OPTIONs doesn't)? IMHO wither we should use existing methods to achieve this OR go with the STUN option for both transport protocols - to keep it consistent. (CS) OPTIONS has the problem that it is relatively expensive (size and CPU) and might result in responses that exceed the UDP fragmentation limit (there are many DSL routers that treat UDP fragmentation as security problem including the one that I have at home). Therefore I think it would not hurt to have a specific message that is designed only for the keep-alive job. The other question is who sends the keep-alive. I would be good if the UA does that job, but it is not backward compatible with the specs that I know. There we need to specify something. [Chris Boulton] Whatever we decide we shouldn't restrict it to 'one-way'. In different deployments and scenarios it should be possible for either entity to keep a connection alive. (CS) Sure. But the role has to be negotiated. If possible, the UA should do that job. If it is not able to do this (e.g. because it does not support refreshing) the fall back solution will always be that the network side has to do the job. CS ________________________________ From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of Christer Holmberg (JO/LMF) Sent: Tuesday, November 09, 2004 7:16 AM To: Christian Stredicke; fluffy@cisco.com Cc: sip@ietf.org Subject: RE: [Sip] PING/PONG Hi, I don't have anything PING, but no matter how short and effective (in the number of SIP headers etc) we make it it is still pretty "heavy" on the network. I think we should, as I said yesterday, at least have a look at an option which "combines" CRLF and PING (or whatever method is used), ie a UA can send CRLF every X seconds, and PING every n*X seconds. Of course, using a combined mechanism would mean that it would take longer to detect a NAT failure, in case the NAT binding goes done while the UA sends CRLF. But, we also have to remember, that eventhough PING would have a response (which CRLC does not have), due to the transcation timeout- and re-transmission timers it would still take a while (until the transcation expires) to figure out that the NAT binding has been closed. Regards, Christer Holmberg Ericsson Finland -----Original Message----- From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org]On Behalf Of Christian Stredicke Sent: 8. marraskuuta 2004 23:31 To: fluffy@cisco.com Cc: sip@ietf.org Subject: [Sip] PING/PONG 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 This email and any attached files are confidential and copyright protected. If you are not the addressee, any dissemination, distribution or copying of this communication is strictly prohibited. Unless otherwise expressly agreed in writing, nothing stated in this communication shall be legally binding.
_______________________________________________ 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] PING/PONG Christian Stredicke
- RE: [Sip] PING/PONG Christer Holmberg (JO/LMF)
- RE: [Sip] PING/PONG Steve Langstaff
- Re: [Sip] PING/PONG Bob Penfield
- RE: [Sip] PING/PONG Christer Holmberg (JO/LMF)
- RE: [Sip] PING/PONG Christian Stredicke
- Re: [Sip] PING/PONG Bob Penfield
- RE: [Sip] PING/PONG Chris Boulton
- RE: [Sip] PING/PONG Christian Stredicke
- RE: [Sip] PING/PONG Steve Langstaff
- RE: [Sip] PING/PONG Christian Stredicke
- RE: [Sip] PING/PONG Chris Boulton
- RE: [Sip] PING/PONG Steve Langstaff
- Re: [Sip] PING/PONG Spencer Dawkins
- RE: [Sip] PING/PONG Christian Stredicke
- Re: [Sip] PING/PONG Klaus Darilion
- Re: [Sip] PING/PONG Jonathan Rosenberg
- [Sip] How to get old messages on archives!! vikram bhuskute
- RE: [Sip] PING/PONG Christian Stredicke
- Re: [Sip] PING/PONG Jonathan Rosenberg
- RE: [Sip] PING/PONG Steve Langstaff
- RE: [Sip] PING/PONG Christian Stredicke
- RE: [Sip] PING/PONG Steve Langstaff
- Re: [Sip] PING/PONG Jonathan Rosenberg
- Re: [Sip] PING/PONG Charles Eckel
- Re: [Sip] PING/PONG Jonathan Rosenberg
- Re: [Sip] PING/PONG Robert Sparks
- Re: [Sip] PING/PONG Jonathan Rosenberg
- Re: [Sip] PING/PONG Robert Sparks
- Re: [Sip] PING/PONG Jonathan Rosenberg
- Re: [Sip] PING/PONG Robert Sparks
- Re: [Sip] PING/PONG Jonathan Rosenberg
- Re: [Sip] PING/PONG Robert Sparks