Subject: RE: [Sip] Outbound and STUN Keep Alive

From: "Chris Boulton" <[email-masked]>
Date: Fri, 17 Feb 2006 10:22:30 -0000

I don't know why the double CRLF is not enough for keep-alive.

[Chris Boulton] Equally why is STUN not enough?  It is already specified
for UDP in the Outbound draft and would provide consistency across the
board for keep-alive + the savings previously mentioned over a SIP
mechanism - so why not use it for TCP? 

Information contained in this e-mail and any attachments are intended for the use of the addressee only, and may contain confidential information of Ubiquity Software Corporation.  All unauthorized use, disclosure or distribution is strictly prohibited.  If you are not the addressee, please notify the sender immediately and destroy all copies of this email.  Unless otherwise expressly agreed in writing signed by an officer of Ubiquity Software Corporation, nothing in this communication shall be deemed to be legally binding.  Thank you.

_______________________________________________
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

---

From: Cullen Jennings <[email-masked]>
Date: Fri, 17 Feb 2006 18:08:37 -0800

> I don't know why the double CRLF is not enough for keep-alive.

There have been a few people (Sean and Gary) that posted on the list
pointing out that they use double CRLF (with TCP) and it works.

Clearly the double CRLF does not work with UDP and we will need STUN there.
Dean pointed out that with double CRLF, because there is no transaction
identifier there might be a problem. The UA sends a CRLF, then the UA waits
to get one back and if it does not receive one in a reasonable time, it
considered the connection dead. The issue is, you might not get a CRLF back
to the same thing you sent - there might have just been a CRLF lying around
for no good reason. I don't know if this would turn out to be a problem or
not but it certainly is worth thinking about.

---

From: "Gary Gan" <[email-masked]>
Date: Sat, 18 Feb 2006 00:24:33 -0500

I don't think the transaction ID is required for the purpose of the
keep-alive as it is in the full STUN protocol. Isn't it true that the
receiver UDP socket always know where the sender is by the UDP stack itself?

A multiplexing STUN and SIP server in the same port is a good idea. A single
simplified STUN binding request may be required, a normal STUN binding
request is about 70 bytes with the all the header overhead, 28 bytes are
real data, which is little bit too long. The transaction ID takes 16 bytes
in one of the implementation, for me it can be removed, but I don't know if
it is still STUN compliant with a NULL transaction ID field.

Gary Gan

---

From: "Gary Gan" <[email-masked]>
Date: Sat, 18 Feb 2006 12:03:44 -0500

There might be a problem if just simply multiplexing STUN and SIP server in
the same port.

New clients would not be backwards compatible with old servers. They will
declare server-down when they find no response.

I believe to have the keep-alive adopted in the SIP standard may be a better
approach. The client can query if the server supports the keep-alive message
first before it even tries to send it. 

Directly sending the STUN to the SIP server may not a good idea for keeping
alive the NAT binding of the SIP session. I don't know how it can handle
situations if the client is configured to use outbound proxy behind a
firewall that forwards all SIP messages to the SIP server. 

Gary Gan
Clique Communications, LLC

---

From: "Frank W. Miller" <[email-masked]>
Date: Sat, 18 Feb 2006 10:14:03 -0500

I've updated the draft to remove the restriction that it be sent only
during a session and added the ability to treat a 405 coming back from a
UAS that does not support PING as a valid response.

http://www.cornfed.com/ping.txt

FM

---

From: Cullen Jennings <[email-masked]>
Date: Sat, 18 Feb 2006 17:37:39 -0800

> declare server-down when they find no response.

The draft define a way for the client to find out if the server supports
this or not to solve this problem.

---

From: "Jeroen van Bemmel" <[email-masked]>
Date: Sun, 19 Feb 2006 18:19:45 +0100

Frank,

A UAS not recognizing PING would send back a 501 response, not a 405 (see 
RFC3261 section 21.5.2)

Regards,

Jeroen

---

From: "Frank W. Miller" <[email-masked]>
Date: Sun, 19 Feb 2006 13:33:23 -0500

You're correct.  I overlooked the 405 being used for methods that are
recognized, which would clearly not be the case for older
implementations.  I'll make this change.

FM