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

From: "Elwell, John" <[email-masked]>
Date: Sun, 19 Feb 2006 22:09:27 +0000

It seems that the double CRLF solution is the most efficient and least
likely to impact scalability. It suffers from the problem Cullen points out
below. STUN has the advantage of commonality with UDP (although I am
doubtful about the value of this, because it is solving different problems),
but it is never going to be quite as scaleable as the CRLF approach. (By the
way, I agree with those who say SIP OPTIONS, SIP PING etc. are not
scalable.)

What about something between the CRLF approach and the STUN approach, just
sufficient to give a rudimentary transaction capability? It could involve as
little as 2 bytes in each direction, where one byte is used to distinguish
the message from SIP and the second byte is used as a cyclic sequence
number. When you get the same sequence number back you know that
connectivity is still in place. It is still two protocols on one port, so
doubtless those who don't like STUN and SIP on one port will not like this
proposal either. The question is, whether this would be more scalable than
STUN. To me, the scalability issue is the biggest issue we have to solve,
and I think this solution is pretty well as efficient as you can get while
still having the concept of a transaction.

John 

> -----Original Message-----
> From: Cullen Jennings [mailto:[email-masked]] 
> Sent: 18 February 2006 02:09
> To: Chris Boulton; Gary Gan; Dean Willis; Francois Audet
> Cc: [email-masked]; [email-masked]
> Subject: Re: [Sip] Outbound and STUN Keep Alive
> 
> On 2/17/06 2:22 AM, "Chris Boulton" <[email-masked]> wrote:
> 
> > 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.
> 
>  
> 
> _______________________________________________
> 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
> 

_______________________________________________
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: Sun, 19 Feb 2006 14:29:49 -0800

Agree with John. 

I've been trying to think about the details of the double CRLF. It's hard to
construct and exact case (that does not involve buggy software) that would
results in double CRLF with no transaction identifier getting messed up due
to lack of transaction identifier. I can't decide if the lack of transaction
id is a real problem or a theoretical one.

We will need STUN for UDP so also have to deal with the do we want one or
two things (but agree with your comments below.