RE: [Sip] PING/PONG

"Steve Langstaff" <steve.langstaff@citel.com> Tue, 09 November 2004 12: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 HAA18358 for <sip-web-archive@ietf.org>; Tue, 9 Nov 2004 07:25:33 -0500 (EST)
Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRV4m-0001Tn-OF for sip-web-archive@ietf.org; Tue, 09 Nov 2004 07:26:21 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRUwl-0001Dm-Lw; Tue, 09 Nov 2004 07:18:03 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRUwP-00015X-HJ for sip@megatron.ietf.org; Tue, 09 Nov 2004 07:17:41 -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 HAA17605 for <sip@ietf.org>; Tue, 9 Nov 2004 07:17:38 -0500 (EST)
Received: from firewall.citel.com ([62.190.107.60] helo=ivor.citel.com) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CRUwz-0001GE-4h for sip@ietf.org; Tue, 09 Nov 2004 07:18:27 -0500
Content-Class: urn:content-classes:message
MIME-Version: 1.0
X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0
Subject: RE: [Sip] PING/PONG
Date: Tue, 09 Nov 2004 12:14:44 -0000
Message-ID: <CD9775120D600F43B9C50329395E9DB64F31DA@ivor.citel.com>
Thread-Topic: [Sip] PING/PONG
Thread-Index: AcTGVK9I0LqupMtPR4ePO2+jlFpEpgAAPYGA
From: Steve Langstaff <steve.langstaff@citel.com>
To: sip@ietf.org
X-Spam-Score: 0.6 (/)
X-Scan-Signature: a1f9797ba297220533cb8c3f4bc709a8
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="===============0317071365=="
Sender: sip-bounces@ietf.org
Errors-To: sip-bounces@ietf.org
X-Spam-Score: 0.9 (/)
X-Scan-Signature: ba0d4c5f57f7c289496fce758bbf4798

Doesn't the OPTIONS message do this job (of keeping a link 'alive')?
 

-- 
Steve Langstaff. 

-----Original Message-----
From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org]On Behalf Of Christer Holmberg (JO/LMF)
Sent: 09 November 2004 11:37
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
 

_______________________________________________
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