Subject: Re: STUN keep-alive: Where to document it? (was [Sip] Re: A coment todraft-ietf-sip-outbound-04)

From: "Christer Holmberg" <[email-masked]>
Date: Sun, 9 Jul 2006 01:52:05 +0300

Hi,

I guess we would need an option tag for the UAC/UAS to indicate the support.

When it comes to the edge proxy sending the STUN requests, that is probably the same thing as the "network initiated keepalive" mechanism I proposed while we were still discussing whether we are going to use STUN in the first place. I did not propose STUN at that point, but anything that triggers a message (a response in the STUN case) to be sent back from the client towards the edge proxy (some NATs require keepalive traffic in that direction in order to keep the bindings open).

One issue with that proposal was that the client doesn't know if e.g. a NAT is rebooting. It would require some timer, so that the client can assume a reboot has occured if it doesn't receive a STUN request before the timer expires.

Regards,

Christer

_______________________________________________
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: "Jeroen van Bemmel" <[email-masked]>
Date: Sun, 9 Jul 2006 01:11:42 +0200

Hi Christer,

>One issue with that proposal was that the client doesn't know if e.g. a NAT 
>is rebooting. It would require some timer, so that the client can assume a 
>reboot has >occured if it doesn't receive a STUN request before the timer 
>expires.

Also client-initiated STUN requires such a periodic timer. Furthermore, 
sending a STUN request and then waiting for a response also implicitly uses 
a timer (typical implementation is the sending thread blocking on some event 
with a timeout, reception of the response setting this event)

I just scanned briefly through RFC3489bis section 7.1. It appears that much 
more needs to be said on exactly how STUN is to be done. For example,
RFC3489bis suggests a retransmission scheme with timeout after 9500ms for 
UDP; for TCP it says "SHOULD NOT retransmit", but what should be used for 
timeout? Surely not 9.5 seconds? And compared to SIP standard timings, a 
retransmission after 100ms (UDP) seems rather quick...

Regards,

Jeroen

---

From: "Christer Holmberg \(JO/LMF\)" <[email-masked]>
Date: Sun, 9 Jul 2006 10:25:54 +0200

Moved from the "RE: STUN keep-alive: Where to document it? (was [Sip] Re: A coment  todraft-ietf-sip-outbound-04)" thread:

>retransmission after 100ms (UDP) seems rather quick... 

I agree that we probably need to document that. I found the same issue with RTSP at one point - there were no transaction/re-transmission/timeout timers etc defined (I haven't been working with RTSP for a while now, so I don't know what the situation is at the moment).

The question is whether we want "SIP specific" behavior, in which case it should be in the SIP STUN keep-alive document (or dedicated chapter in the outbound spec), or if we want generic behavior in which case it should be in 3489bis.

(...OR, if we want outbound specific behavior, in which case it should be in the outbound spec).

Regards,
 
Christer

---

From: "Christer Holmberg \(JO/LMF\)" <[email-masked]>
Date: Sun, 9 Jul 2006 10:25:51 +0200

Moved from the "STUN keep-alive: Where to document it? (was [Sip] Re: A coment  todraft-ietf-sip-outbound-04)" thread:

>with a timeout, reception of the response setting this event)

Correct. But, these timers a "local" client timers aren't they, i.e. how often it sends STUN requests and for how long it should wait for a reply? 

In case the server generates the STUN request the client must know which timers the server uses. That can of course be a standardized value, OR it can be provided in some header, but the client needs to know about it.

Regards,

Christer

---

From: "Hadriel Kaplan" <[email-masked]>
Date: Sun, 9 Jul 2006 17:55:35 -0400

I would strongly suggest you keep with the client-side initiating STUN
requests.  It's been our experience that the device behind the NAT (on the
private/internal side) is always at a distinct advantage over the one on the
outside of it for keepalives.  If you want the reasons I can list them, but
it's probably not worth the time and I think this has been said before by
others on this mailing list in the past.

It would be nice though if the server could give the client a stun-interval
value to use.  Like many solutions do with Registers and expires/min-expires
today.  Some regions of the world seem to have insanely short NAT cache
timers, and others have very long ones, and there's a penalty to be paid for
the former.

-hadriel

> -----Original Message-----
> From: Christer Holmberg (JO/LMF) [mailto:[email-masked]]
> Sent: Sunday, July 09, 2006 4:26 AM
> To: Jeroen van Bemmel; Rohan Mahy; [email-masked]
> Cc: Miguel Garcia; Cullen Jennings
> Subject: [Sip] STUN keep-alive: Client vs server generating requests
> 
> Moved from the "STUN keep-alive: Where to document it? (was [Sip] Re: A
> coment  todraft-ietf-sip-outbound-04)" thread:
> 
> Jeroen wrote:
> 
> 
> Correct. But, these timers a "local" client timers aren't they, i.e. how
> often it sends STUN requests and for how long it should wait for a reply?
> 
> In case the server generates the STUN request the client must know which
> timers the server uses. That can of course be a standardized value, OR it
> can be provided in some header, but the client needs to know about it.
> 
> Regards,
> 
> Christer
> 
> 
> 
>

---

From: "Jeroen van Bemmel" <[email-masked]>
Date: Mon, 10 Jul 2006 00:03:14 +0200

Hadriel,

OK, I'll take your word for it. If we then interpret such a 
'stun-interval=xxx' as an indication of support for STUN (and say 'no STUN 
unless interval is provided'), I'm happy

Only trouble is: in many cases, the proxy would not know which type of NAT 
there is in between, let alone how long it caches...

Regards,

Jeroen

----- Original Message ----- 
From: "Hadriel Kaplan" <[email-masked]>
To: "'Jeroen van Bemmel'" <[email-masked]>; <[email-masked]>
Sent: Sunday, July 09, 2006 11:55 PM
Subject: RE: [Sip] STUN keep-alive: Client vs server generating requests

>> >>is rebooting. It would require some timer, so that the client can 
>> >>assume
>> a

---

From: "Hadriel Kaplan" <[email-masked]>
Date: Mon, 10 Jul 2006 10:31:34 -0400

> From: Jeroen van Bemmel [mailto:[email-masked]]
> 

If it doesn't know, then it sets the value recommended in the draft.
However, there are ways for the proxy to find out, and there are also
operators who know what the timeout is. (e.g., if the NAT is provided by
them)

-hadriel