Subject: [MEDIACTRL] Keep-Alive Header!!!!

From: Chris Boulton <[email-masked]>
Date: Mon, 29 Jun 2009 15:38:49 +0100

All,

We have one final issue that needs some input from the group.  I would 
be grateful if you could respond to this mail ASAP.  A comment received 
from our AD reads:

Did the group consider an absolute upperbound on the
        Keep-Alive header field value? The syntax right now allows
        the number to be without-bound large.

So - my first question is - does the group feel we need an upper bound 
for this header?

If one is needed I would propose the following change to section 6.3.4.1

If the Client initiating the SDP Offer has a COMEDIA setup
      attribute equal to active, the Keep-Alive header MUST be included
      in the SYNC message generated by the offerer.  The value of the
      Keep-Alive header SHOULD be in the range of 95 to 120 seconds
      (this is consistent with SIP Outbound[I-D.ietf-sip-outbound]).  The value
	MUST NOT exceed XXX seconds.

So please respond stating firstly if you think we need this upper bound 
AND if you do, state what it should be in seconds.

Thanks.

Chris.

---

From: Lorenzo Miniero <[email-masked]>
Date: Mon, 29 Jun 2009 16:48:01 +0200

Hi Chris,

I'm not sure we need an upper bound for that, considering its main purpose is to negotiate the frequency for keep-alive messages in case NATs and firewalls are involved in the path between an AS and a MS. Without such a need, Keep-Alives could be sent at a much lower pace. Nevertheless, having a value might be useful anyway, if not to put some constraints and provide guidance. That said, I'd choose a reasonably large value like 10 minutes or the like (larger values would probably be meaningless).

L.

On Mon, 29 Jun 2009 15:38:49 +0100
Chris Boulton <[email-masked]> wrote:

> _______________________________________________
> MEDIACTRL mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mediactrl
> Supplemental Web Site:
> http://www.standardstrack.com/ietf/mediactrl
> 

-- 
Lorenzo Miniero <[email-masked]>

---

From: "Steve Buko" <[email-masked]>
Date: Mon, 29 Jun 2009 14:06:13 -0400

Chris,

I wouldn't find an upper bound to be extremely useful, however for
completeness I can understand the request.
As Lorenzo stated, I would make it a fairly large number ( > 600
seconds) so we don't limit implementations ability to reduce message
flow.

Steve

|-----Original Message-----
|From: [email-masked] [mailto:[email-masked]] On
|Behalf Of Lorenzo Miniero
|Sent: Monday, June 29, 2009 10:48 AM
|To: Chris Boulton
|Cc: [email-masked]
|Subject: Re: [MEDIACTRL] Keep-Alive Header!!!!
|
|Hi Chris,
|
|I'm not sure we need an upper bound for that, considering its main
|purpose is to negotiate the frequency for keep-alive messages in case
|NATs and firewalls are involved in the path between an AS and a MS.
|Without such a need, Keep-Alives could be sent at a much lower pace.
|Nevertheless, having a value might be useful anyway, if not to put some
|constraints and provide guidance. That said, I'd choose a reasonably
|large value like 10 minutes or the like (larger values would probably
be
|meaningless).
|
|L.
|
|
|On Mon, 29 Jun 2009 15:38:49 +0100
|Chris Boulton <[email-masked]> wrote:
|
|> All,
|>
|> We have one final issue that needs some input from the group.  I
would
|> be grateful if you could respond to this mail ASAP.  A comment
|received
|> from our AD reads:
|>
|> Did the group consider an absolute upperbound on the
|>         Keep-Alive header field value? The syntax right now allows
|>         the number to be without-bound large.
|>
|> So - my first question is - does the group feel we need an upper
bound
|> for this header?
|>
|> If one is needed I would propose the following change to section
|6.3.4.1
|>
|> If the Client initiating the SDP Offer has a COMEDIA setup
|>       attribute equal to active, the Keep-Alive header MUST be
|included
|>       in the SYNC message generated by the offerer.  The value of the
|>       Keep-Alive header SHOULD be in the range of 95 to 120 seconds
|>       (this is consistent with SIP Outbound[I-D.ietf-sip-outbound]).
|The value
|> 	MUST NOT exceed XXX seconds.
|>
|>
|> So please respond stating firstly if you think we need this upper
|bound
|> AND if you do, state what it should be in seconds.
|>
|> Thanks.
|>
|> Chris.
|>
|>
|> _______________________________________________
|> MEDIACTRL mailing list
|> [email-masked]
|> https://www.ietf.org/mailman/listinfo/mediactrl
|> Supplemental Web Site:
|> http://www.standardstrack.com/ietf/mediactrl
|>
|
|
|--
|Lorenzo Miniero <[email-masked]>
|_______________________________________________
|MEDIACTRL mailing list
[email-masked]
|https://www.ietf.org/mailman/listinfo/mediactrl
|Supplemental Web Site:
|http://www.standardstrack.com/ietf/mediactrl

---

From: Jean-Francois Bertrand <[email-masked]>
Date: Mon, 29 Jun 2009 11:42:19 -0700

I agree with Lorenzo and Steve on this.  When dealing with NATs and firewalls, this keep-alive timeout needs to fairly short.  Using a longer timeout dont add much value as other signaling timeouts would allow an application to detect that a remote CFW endpoint has died (or has stopped processing events).  Specifying 10min as an upper bound sounds reasonable. 

/JF
________________________________________
From: [email-masked] [[email-masked]] On Behalf Of Steve Buko [[email-masked]]
Sent: Monday, June 29, 2009 2:06 PM
To: Lorenzo Miniero; Chris Boulton
Cc: [email-masked]
Subject: Re: [MEDIACTRL] Keep-Alive Header!!!!

Chris,

Steve

---

From: "McGlashan, Scott" <[email-masked]>
Date: Tue, 30 Jun 2009 12:40:52 +0000

Yepp, 10 minutes would be fine.

Scott

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Jean-Francois Bertrand
Sent: Monday, June 29, 2009 20:42
To: Steve Buko; Lorenzo Miniero; Chris Boulton; [email-masked]
Subject: Re: [MEDIACTRL] Keep-Alive Header!!!!

/JF

Chris,

I wouldn't find an upper bound to be extremely useful, however for completeness I can understand the request.
As Lorenzo stated, I would make it a fairly large number ( > 600
seconds) so we don't limit implementations ability to reduce message flow.

Steve

---

From: Eric Burger <[email-masked]>
Date: Tue, 30 Jun 2009 11:10:55 -0400

10 minutes is consistent with RFC5321 (SMTP email), so let us go with  
it.

On Jun 30, 2009, at 8:40 AM, McGlashan, Scott wrote:

> I agree with Lorenzo and Steve on this.  When dealing with NATs and  
> firewalls, this keep-alive timeout needs to fairly short.  Using a  
> longer timeout dont add much value as other signaling timeouts would  
> allow an application to detect that a remote CFW endpoint has died  
> (or has stopped processing events).  Specifying 10min as an upper  
> bound sounds reasonable.
>
> /JF
> From: [email-masked] [[email-masked]] On  
> Behalf Of Steve Buko [[email-masked]]