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

From: "Francois Audet" <[email-masked]>
Date: Wed, 15 Feb 2006 16:48:08 -0600

Well, not really.

It only works with protocols that magically can be demultiplexed
from running on the same port as STUN...

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Hisham Khartabil
> Sent: Monday, February 13, 2006 09:02
> To: Cullen Jennings
> Cc: [email-masked]
> Subject: Re: [Sip] Outbound and STUN Keep Alive
> 
> 
> The advantages of using STUN for this is that it works for all 
> application layer protocols that need a keepalive mechanism for NAT 
> bindings (thats why I suggested privately to Cullen to move this part 
> of the I-D into a separate draft and submit it in BEHAVE).
> 
> If we want a SIP specific solution, then I would suggest (well, not 
> entirely my idea. It has been suggested before) a new SIP method that 
> achieves what STUN achieves for those NATs that reboot. Something like
> 
> NATKEEPALIVE
> 
> The contact in the 200 OK returns the new external port (and IP 
> address) assigned. The only advantage to this is that we do 
> not use the 
> same port for both SIP and STUN and we avoid having to extend parsers 
> to support that and create a link between SIP parsers and 
> STUN parsers.
> 
> Regards,
> Hisham
> 
> On Feb 13, 2006, at 12:34 AM, Cullen Jennings wrote:
> 
> > There has been a few threads about keep alives in 
> outbound.... I will
> > start
> > a thread here.
> >
> > For UDP, I think STUN is clearly the best choice. It's the 
> only thing
> > that
> > is quick and works when the NAT reboots.
> >
> > For TCP, there is the the option to use STUN the same as UDP.
> >
> > There might be another solution for TCP. I'll call it the 
> Double CRLF. 
> > Basically the UA sends a CRLF, when the proxy receives 
> this, it must 
> > sends a CRLF within 1 second.  If the UA does not get back the CRLF 
> > within 6 seconds
> > of sending the first one, it considers the connection dead.
> >
> > First questions is, does Double CRLF work?
> >
> > Second questions is, given we have to do STUN for UDP, would we want
> > to do
> > something different for TCP?
> >
> > _______________________________________________
> > 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
> 
> 

_______________________________________________
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: Jonathan Rosenberg <[email-masked]>
Date: Wed, 15 Feb 2006 18:11:56 -0500

Given the presence of the magic cookie in each stun request, can you 
give an example of a protocol where such demuxing could not be done?

-Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Cisco Fellow                                   Parsippany, NJ 07054-2711
Cisco Systems
[email-masked]                              FAX:   (973) 952-5050
http://www.jdrosen.net                         PHONE: (973) 952-5000
http://www.cisco.com

---

From: Dean Willis <[email-masked]>
Date: Wed, 15 Feb 2006 17:51:41 -0600

On Feb 15, 2006, at 5:11 PM, Jonathan Rosenberg wrote:

> Given the presence of the magic cookie in each stun request, can  
> you give an example of a protocol where such demuxing could not be  
> done?

Any protocol where the magic cookie could be valid application data.

Somewhere down in here is a requirement for a "NAT Traversing  
Protocol" that provides arbitrary demux over a shared channel.

Oh wait, that's called a TLS VPN.

--
Dean

---

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 15 Feb 2006 23:58:19 -0500

It comes down to probabilities. You can make the probability of 
collision arbitrarily low by increasing the number of bits. Assuming 
random data in an application protocol, 16 bits is already 1.5e-5 
probability of collision. Not good enough? Throw a few more bits in.

-Jonathan R.

Dean Willis wrote:

> Somewhere down in here is a requirement for a "NAT Traversing  Protocol" 
> that provides arbitrary demux over a shared channel.
>