Subject: [sipcore] Draft new version: keep

From: "Christer Holmberg" <[email-masked]>
Date: Tue, 1 Dec 2009 12:18:20 +0100

Hi,

I've submitted a new version of the keep draft. There are no changes
from the previous version, but it had expired.

I will produce a new version, with new content, once we get the info
issues resolved - it has really taken more time than expected... 

A new version of the info draft will be submitted tomorrow.

Regards,

Christer

---

From: "Rifaat Shekh-Yusef" <[email-masked]>
Date: Sat, 12 Dec 2009 13:53:59 -0500

Hi Christer,
 
I read your document (sipcore-keep-01) and I have the following
questions (I am sorry if these questions were asked before):
 
RFC 5626 recommends the STUN Keep-Alive technique with connection-less
transports and CRLF Keep-Alive technique with connection-oriented
transports.
Is this document recommending the client should use STUN Keep-Alive
technique for both connection-oriented and connection-less transports?
Why did you choose STUN over CRLF?
 
The header of Section 8 implies that there is an overlap between this
document and the connect-reuse draft, but when you read the section you
realize that this is not the case.
Why do you think that this section is needed? Does it matter if the
connection between the UA and the proxy uses one TCP connection or two
TCP connections?
 
Thanks,
 Rifaat

________________________________

From: [email-masked] [mailto:[email-masked]] On
Behalf Of Christer Holmberg
Sent: Tuesday, December 01, 2009 6:18 AM
To: [email-masked]
Subject: [sipcore] Draft new version: keep

Hi, 

Regards, 

Christer

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 14 Dec 2009 08:18:15 +0100

Hi,
  
>I read your document (sipcore-keep-01) and I have the following questions (I am sorry if these questions were asked before):
> 
>RFC 5626 recommends the STUN Keep-Alive technique with connection-less transports and CRLF Keep-Alive technique with connection-oriented transports.
>Is this document recommending the client should use STUN Keep-Alive technique for both connection-oriented and connection-less transports?

No.

The idea is to use the keep-alive mechanism defined in RFC 5626.

The purpose of the draft is only to allow entities to negotiate the usage of keep-alive, if they don't support outbound.

>The header of Section 8 implies that there is an overlap between this document and the connect-reuse draft, but when you read the section you realize 
>that this is not the case.
>Why do you think that this section is needed? Does it matter if the connection between the UA and the proxy uses one TCP connection or two TCP 
>connections?

At one point I was asked to add that section, just to point out the differences between keep-alive and connect-reuse.

Regards,

Christer

From: [email-masked] [mailto:[email-masked]] On Behalf Of Christer Holmberg
Sent: Tuesday, December 01, 2009 6:18 AM
To: [email-masked]
Subject: [sipcore] Draft new version: keep

Hi, 

I've submitted a new version of the keep draft. There are no changes from the previous version, but it had expired. 

I will produce a new version, with new content, once we get the info issues resolved - it has really taken more time than expected... 

Regards, 

Christer

---

From: "Rifaat Shekh-Yusef" <[email-masked]>
Date: Mon, 14 Dec 2009 10:47:51 -0500

>The purpose of the draft is only to allow entities to negotiate the
usage of keep-alive, if they don't support outbound.

Then section 5 should be clarified to reflect this, as this is not clear
from the current text.

>>document and the connect-reuse draft, but when you read the section
you realize that this is not the case.
TCP connections?
>
>At one point I was asked to add that section, just to point out the
differences between keep-alive and connect-reuse.

This section does not seem to add any value to this document.

Regards,
 Rifaat

Hi, 

Regards, 

Christer

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 15 Dec 2009 08:05:02 +0100

Hi, 

>>>transports and CRLF Keep-Alive technique with connection-oriented transports.
>Then section 5 should be clarified to reflect this, as this is not clear from the current text.

Section 1 says:

"This specification defines a new SIP Via header parameter, "keep",which can be used by a UA to indicate support of the keep-alive
techniques defined in [I-D.ietf-sip-outbound]."

Section 5 also mentions, in a number of places, "keep-alive techniques defined in outbound", but I will take a look whether it can be more clear.

>>>connection between the UA and the proxy uses one TCP connection or two TCP connections?
>>

I would have to check the archieves for the discussions about it, but in general I would not like to remove chapters which we have agreed to add.

I guess the people who wanted to chapter (Vijay?) could comment.

Regards,

Christer

---

From: "Rifaat Shekh-Yusef" <[email-masked]>
Date: Tue, 15 Dec 2009 09:21:22 -0500

Hi Christer,

>>>>RFC 5626 recommends the STUN Keep-Alive technique with 
>>>>connection-less transports and CRLF Keep-Alive technique with
connection-oriented transports.
>"This specification defines a new SIP Via header parameter,
"keep",which can be used by a UA to indicate support of the keep-alive
techniques defined in >[I-D.ietf-sip-outbound]."
>
>Section 5 also mentions, in a number of places, "keep-alive techniques
defined in outbound", but I will take a look whether it can be more
clear.

The very first paragraph in section 5 says the following:

   "A SIP entity aciting as a UAC which supports the method defined in
   this specification MUST act as a STUN client
   [I-D.ietf-behave-rfc3489bis], and MUST support the amount of STUN
   which is required to apply the STUN keep-alive technique
   [I-D.ietf-sip-outbound]."

The way I understand this paragraph and the use of "MUST" is that you
are mandating STUN, period.

Regards,
 Rifaat