RE: [Sip] PING/PONG

"Steve Langstaff" <steve.langstaff@citel.com> Wed, 10 November 2004 10:01 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 FAA17311 for <sip-web-archive@ietf.org>; Wed, 10 Nov 2004 05:01:24 -0500 (EST)
Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRpJ2-0005ug-Qk for sip-web-archive@ietf.org; Wed, 10 Nov 2004 05:02:25 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRp4j-0005UG-09; Wed, 10 Nov 2004 04:47:37 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRoxS-0004kW-QW for sip@megatron.ietf.org; Wed, 10 Nov 2004 04:40:07 -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 EAA15270 for <sip@ietf.org>; Wed, 10 Nov 2004 04:40:02 -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 1CRoyM-0005Lh-0k for sip@ietf.org; Wed, 10 Nov 2004 04:41:02 -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: Wed, 10 Nov 2004 09:39:07 -0000
Message-ID: <CD9775120D600F43B9C50329395E9DB6172502@ivor.citel.com>
Thread-Topic: [Sip] PING/PONG
Thread-Index: AcTGVeD72vlivuzXRNmVFA8//spI5wABZoOgAAGeqgAAAsmPsAAmuEDw
From: Steve Langstaff <steve.langstaff@citel.com>
To: Christian Stredicke <Christian.Stredicke@snom.de>, Chris Boulton <cboulton@ubiquity.net>, "Christer Holmberg (JO/LMF)" <christer.holmberg@ericsson.com>, fluffy@cisco.com
X-Spam-Score: 0.3 (/)
X-Scan-Signature: 1a1bf7677bfe77d8af1ebe0e91045c5b
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="===============1075131135=="
Sender: sip-bounces@ietf.org
Errors-To: sip-bounces@ietf.org
X-Spam-Score: 0.9 (/)
X-Scan-Signature: 2086112c730e13d5955355df27e3074b

(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.
 
...but if you want your keep alive message to be routed over the same path and transports as your original INVITE (and hence keep them alive), don't you need most of the "expensive" content of (say) the OPTIONS message - e.g. the vias.

-- 
Steve Langstaff. 

_______________________________________________
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