Subject: RE: [Sip] PING/PONG

From: "Christian Stredicke" <[email-masked]>
Date: Tue, 9 Nov 2004 16:06:42 +0100

________________________________

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Chris Boulton
Sent: Tuesday, November 09, 2004 9:31 AM
To: Christian Stredicke; Christer Holmberg (JO/LMF); [email-masked]
Cc: [email-masked]
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: [email-masked] [mailto:[email-masked]]
On Behalf Of Christer Holmberg (JO/LMF)
		Sent: Tuesday, November 09, 2004 7:16 AM
		To: Christian Stredicke; [email-masked]
		Cc: [email-masked]
		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: [email-masked]
[mailto:[email-masked]]On Behalf Of Christian Stredicke
			Sent: 8. marraskuuta 2004 23:31
			To: [email-masked]
			Cc: [email-masked]
			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 [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip