Subject: [sipcore] Draft submission: draft-ietf-sipcore-keep-00 (was RE: Document Adoption)

From: "Christer Holmberg" <[email-masked]>
Date: Mon, 4 May 2009 10:05:36 +0200

Hi,

I've submitted the -00 version of draft-ietf-sipcore-keep.

It can also be found at:

http://users.piuha.net/cholmber/drafts/draft-ietf-sipcore-keep-00.txt

I have not done any changes based on Shaun's comments. Any changes will
be in the next revision.

Regards,

Christer

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Adam Roach
> Sent: 1. toukokuuta 2009 0:05
> To: SIPCORE; 
> [email-masked]; 
> [email-masked]
> Subject: [sipcore] Document Adoption
> 
> [as chair]
> 
> This message announces the formal adoption of two additional 
> documents as SIPCORE working group items to satisfy two of 
> our chartered milestones.
> 
> Two weeks ago, the document 
> draft-niemi-sipping-event-throttle, which was accepted by the 
> RAI community at the San Franciso SIPPING meeting, was 
> proposed by the chairs as a candidate to satisfy the 
> milestone "SIP Events throttling mechanism"[1]. There was one 
> affirmation of this decision. There was one objection, which 
> was withdrawn after the question under consideration was 
> clarified[2]. Given the "previously adopted" status of this 
> document, and the lack of any remaining objections, the 
> chairs now consider this a working group document.
> 
> We also had eight positive responses and no objections to 
> adopting draft-holmberg-sipcore-keep as a working group item 
> [3] to satisfy the milestone "Mechanism for indicating 
> support for keep-alives".
> 
> Authors: please submit a draft-ietf-sipcore version of your 
> document as soon as practical. Also, please keep in mind that 
> change control now resides with the working group -- you are 
> advised to make no substantive changes without discussion on 
> the working group mailing list.
> 
> Thanks!
> 
> /a
> 
> --
> [1] http://www.ietf.org/mail-archive/web/sipcore/current/msg00005.html
> [2] http://www.ietf.org/mail-archive/web/sipcore/current/msg00019.html
> [3] http://www.ietf.org/mail-archive/web/sipcore/current/msg00021.html
> _______________________________________________
> sipcore mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sipcore
>

---

From: "Tan, Ya Ching (NSN - DE/Munich)" <[email-masked]>
Date: Tue, 5 May 2009 13:27:25 +0200

Some comments :

1. Please update all references of [I-D.ietf-behave-rfc3489bis] to RFC
5389.

2. It is stated under Section 6 (Server behavior) that "The UAS MUST
also process double-CRLF keep-alives", but there is no mention of the
requirement to support the CRLF keep alive technic under Section 5
(Client behavior).

3. The draft repeatedly uses the term 'initial SIP request'.  What is
the definition of this as it is not a known technical term in SIP [RFC
3261].  The sentence in Section 5 "If the UAC wishes to apply keep-alive
for future calls, it MUST insert a "keep" Via parameter in the initial
SIP request of those calls".  This seems to imply that 'initial SIP
request' means the initial INVITE.  'Initial INVITE' is what RFC 3261
calls the dialog-initiating INVITE.  Should the "keep" parameter in Via
only be used in initial REGISTER and initial INVITE ?

4. What is the definition of 'initial SIP response' used throughout the
draft ?  I take it that the "keep=yes" parameter is only meaningful and
useful if the response is a 2xx.  Is that right ?

5. The Via headers in the REGISTER/INVITE sent by the Proxy P1 are in
the wrong order.  "Via:P1" should be the topmost Via header.

6. Section 5 : "... and the UAC wants to send keep-alives towards the
next hop, the entity MUST include a "keep" Via parameter in the SIP
request".  It should be "... the entity MUST include a "keep" parameter
in the Via header it inserts into the SIP request".

7. Section 5 : "If the Via header header in the initial SIP responses
contains a "keep" parameter with a "yes" value..." should read "If the
top Via header in the 2xx SIP response contains a "keep" parameter with
a "yes" value...".

8. Third paragraph of Section 5 : "If the initial SIP response contains
a Flow-Timer header...".  In the SIP outbound draft, the Flow-Timer
header is only meant to be present in 'a successful registration
response' (i.e. in a REGISTER response).

9. Typos in Section 9.1 and 9.2 : "recommented" -> "recommended".

Regards,
Ya-Ching

---

From: "Christer Holmberg" <[email-masked]>
Date: Tue, 5 May 2009 14:03:39 +0200

Hi, 

5389.

Will do.

>2. It is stated under Section 6 (Server behavior) that "The 
>UAS MUST also process double-CRLF keep-alives", but there is 
>no mention of the requirement to support the CRLF keep alive 
>technic under Section 5 (Client behavior).

I'll look into that.

>3. The draft repeatedly uses the term 'initial SIP request'.  
>What is the definition of this as it is not a known technical 
>term in SIP [RFC 3261].  The sentence in Section 5 "If the 
>UAC wishes to apply keep-alive for future calls, it MUST 
>insert a "keep" Via parameter in the initial SIP request of 
>those calls".  This seems to imply that 'initial SIP request' 
>means the initial INVITE.  'Initial INVITE' is what RFC 3261 
>calls the dialog-initiating INVITE.  Should the "keep" 
>parameter in Via only be used in initial REGISTER and initial INVITE ?

I think that is the current assumption, yes, but I am not sure whether
we need to make that restriction.

Regarding the usage of "initial SIP request", I guess it should say
"initial SIP dialog request", or something like that. I think similar
wording is used in some places of the document.

>4. What is the definition of 'initial SIP response' used 
>throughout the draft ?  I take it that the "keep=yes" 
>parameter is only meaningful and useful if the response is a 
>2xx.  Is that right ?

I guess it should be "response to the initial SIP request", or something
like that.

In addition to 2xx, the keep=yes can also be useful in provisional
responses.

>5. The Via headers in the REGISTER/INVITE sent by the Proxy 
>P1 are in the wrong order.  "Via:P1" should be the topmost Via header.

True. I noted that already earlier, but forgot to fix it.

>6. Section 5 : "... and the UAC wants to send keep-alives 
>towards the next hop, the entity MUST include a "keep" Via 
>parameter in the SIP request".  It should be "... the entity 
>MUST include a "keep" parameter in the Via header it inserts 
>into the SIP request".

Correct.

>7. Section 5 : "If the Via header header in the initial SIP 
>responses contains a "keep" parameter with a "yes" value..." 
>should read "If the top Via header in the 2xx SIP response 
>contains a "keep" parameter with a "yes" value...".

Correct.

>8. Third paragraph of Section 5 : "If the initial SIP 
>response contains a Flow-Timer header...".  In the SIP 
>outbound draft, the Flow-Timer header is only meant to be 
>present in 'a successful registration response' (i.e. in a 
>REGISTER response).

I was thinking about the same. But, does outbound actaully forbid
Flow-Timer to be used elsewhere than in REGISTER responses? I know that
the procedures only talk about registration responses, but that is not
the same thing.

I guess what is missing from outbound is the normal table which shows
for which methods and message types the header can be used.

>9. Typos in Section 9.1 and 9.2 : "recommented" -> "recommended".

I'll fix it.

Thank you very much for your comments!

Regards,

Christer

---

From: "Elwell, John" <[email-masked]>
Date: Tue, 05 May 2009 14:53:13 +0100

> [mailto:[email-masked]] On Behalf Of Christer Holmberg
> Sent: 05 May 2009 13:04
> To: Tan, Ya Ching (NSN - DE/Munich)
> Cc: SIPCORE
> Subject: Re: [sipcore] Draft submission: 
> draft-ietf-sipcore-keep-00 (wasRE:Document Adoption)
> 
> 
[JRE] So the sender of an "initial SIP dialog request" would invoke the
capability between itself and the next downstream SIP entity. Presumably
a SIP proxy that does not record-route would  never invoke this
capability. But what about the next SIP entity downstream, if that
doesn't record-route? Presumably it too should refrain from engaging in
this capability. Mid-dialog requests would by-pass any
non-record-routing proxies, so there would be no opportunity at the time
of the "initial SIP dialog request" to create, and hence keep-alive, the
connections needed for mid-dialog requests. I couldn't find any
discussion of this in the latest draft.

John

---

From: "Christer Holmberg" <[email-masked]>
Date: Tue, 5 May 2009 22:49:43 +0200

Hi John,

You raise a good point. The draft should probably say that a SIP entity
MUST record-route (unless the entity is an endpoint) if it is going to
send and/or receive keep-alives.

Regards,

Christer

-----Original Message-----
From: Elwell, John [mailto:[email-masked]] 
Sent: Tuesday, May 05, 2009 4:53 PM
To: Christer Holmberg; Tan, Ya Ching (NSN - DE/Munich)
Cc: SIPCORE
Subject: RE: [sipcore] Draft submission: draft-ietf-sipcore-keep-00
(wasRE:Document Adoption)

> >What is the definition of this as it is not a known technical term in

> >SIP [RFC 3261].  The sentence in Section 5 "If the UAC wishes to 
> >apply keep-alive for future calls, it MUST insert a "keep" Via 
> >parameter in the initial SIP request of those calls".  This seems to 
> >imply that 'initial SIP request'
> >means the initial INVITE.  'Initial INVITE' is what RFC 3261 calls 
> >the dialog-initiating INVITE.  Should the "keep"

John

---

From: "Elwell, John" <[email-masked]>
Date: Wed, 06 May 2009 07:17:58 +0100

Christer,

That seems somewhat back-to-front. You don't record route (and hence
determine the path of the dialog) just because you want to do
keep-alives. You first decide whether you are to be on the path of a
dialog, and then you should decide whether to do keep-alives with your
neighbour. I guess where non-record-routing proxies are involved, this
can be achieved only on the first mid-dialog request. However, for an
INVITE-initiated dialog this might be the ACK request, but unfortunately
that doesn't have a response, so it is not suitable. In some cases it
would be an UPDATE or PRACK request during the early dialog. For a
SUBSCRIBE- or REFER-initiated dialog it would be the first NOTIFY
request.

In extending the keep-alive principle to dialogs, we need to be very
careful how we specify it.

John

> From: Christer Holmberg [mailto:[email-masked]] 
> Sent: 05 May 2009 21:50
> To: Elwell, John; Tan, Ya Ching (NSN - DE/Munich)
> Cc: SIPCORE
> Subject: RE: [sipcore] Draft submission:

---

From: "Christer Holmberg" <[email-masked]>
Date: Wed, 6 May 2009 08:43:13 +0200

Hi John,

I think there are cases where you may record route because you want to
do keep-alives.

But, we don't need to argue about that. I guess your point is that we
should allow the keep-alive negotiation also in mid-dialog request?

Regards,

Christer

> Sent: 6. toukokuuta 2009 9:18
> That seems somewhat back-to-front. You don't record route 
> (and hence determine the path of the dialog) just because you 
> want to do keep-alives. You first decide whether you are to 
> be on the path of a dialog, and then you should decide 
> whether to do keep-alives with your neighbour. I guess where 
> non-record-routing proxies are involved, this can be achieved 
> only on the first mid-dialog request. However, for an 
> INVITE-initiated dialog this might be the ACK request, but 
> unfortunately that doesn't have a response, so it is not 
> suitable. In some cases it would be an UPDATE or PRACK 
> request during the early dialog. For a
> SUBSCRIBE- or REFER-initiated dialog it would be the first 
> NOTIFY request.
> 
> In extending the keep-alive principle to dialogs, we need to 
> be very careful how we specify it.
> 
> John
> 
> > You raise a good point. The draft should probably say that a SIP 
> > entity MUST record-route (unless the entity is an endpoint) 
> if it is 
> > going to send and/or receive keep-alives.
> > 
> > Regards,
> > 
> > Christer
> > 
> > [JRE] So the sender of an "initial SIP dialog request" would invoke 
> > the capability between itself and the next downstream SIP entity.
> > Presumably
> > doesn't record-route? Presumably it too should refrain from 
> engaging 
> > in this capability. Mid-dialog requests would by-pass any 
> > non-record-routing proxies, so there would be no opportunity at the 
> > time of the "initial SIP dialog request" to create, and hence 
> > keep-alive, the connections needed for mid-dialog requests. 
> I couldn't 
> > find any discussion of this in the latest draft.
> > 
> > John
> > 
> > 
>

---

From: "Elwell, John" <[email-masked]>
Date: Wed, 06 May 2009 08:27:41 +0100

Christer,

Using the mechanism on mid-dialog requests might be one of the
consequences. Another consequence might be that non-record-routing
proxies should not attempt to invoke keep-alive.  Perhaps we might
deliberately exclude the mechanism for use between two entities between
which there was one or more non-record-routing proxy. I don't really
know - I just know that there are some issues to do with
non-record-routing proxies that don't arise in the sip-outbound case
(because the UA and the outbound proxy always stay in on the path).

I would like to see some discussion about the applicability of
keep-alives to dialogs, before we jump in and propose a mechanism.

John 

> Sent: 06 May 2009 07:43

---

From: "Christer Holmberg" <[email-masked]>
Date: Wed, 6 May 2009 10:58:48 +0200

Hi, 

>Using the mechanism on mid-dialog requests might be one of the
consequences.

Yes.

>Another consequence might be that non-record-routing proxies should not
attempt to invoke keep-alive.

Yes.

>Perhaps we might deliberately exclude the mechanism for use between two
entities between which there was one or more non-record-routing proxy.

I am not sure I understand. The keep-alives are always between two
neighbour entities. If there are other proxies (no matter if they are
record-routing or not) between the two entities, thoe two entities will
not send keep-alives between each other. When a SIP entity receives a
request, it only checks the TOPMOST Via if it contains "keep", so if
some other proxy has added a Via header (without "keep") no keep-alives
will be sent.

Regards,

Christer

>I don't really know - I just know that there are some issues to do with

>non-record-routing proxies that don't arise in the 
>sip-outbound case (because the UA and the outbound proxy 
>always stay in on the path).
> 
> I would like to see some discussion about the applicability 
> of keep-alives to dialogs, before we jump in and propose a mechanism.
> 
> John 
> 
> (and hence 
> > > dialog, and then you should decide whether to do keep-alives with 
> > > your neighbour. I guess where non-record-routing proxies are 
> > > involved, this can be achieved only on the first 
> mid-dialog request. 
> > > However, for an INVITE-initiated dialog this might be the ACK 
> > > request, but unfortunately that doesn't have a response, so it is 
> > > not suitable. In some cases it would be an UPDATE or 
> PRACK request 
> > > during the early dialog. For a

---

From: "Elwell, John" <[email-masked]>
Date: Wed, 06 May 2009 11:05:50 +0100

> Sent: 06 May 2009 09:59
[JRE] Suppose an INVITE request is routed:
	UA1 -> Proxy1 - >Proxy2 -> Proxy3 -> UA2
Suppose also that Proxy1 and Proxy3 record-route, but Proxy2 does not.
There is no point in doing keep-alive between Proxy1 and Proxy2, or
between Proxy2 and Proxy3. When the first mid-dialog request is sent, it
will go directly from Proxy1 to Proxy3 or vice versa. My question was
whether we want to allow the invocation of keep-alive on that hop
(Proxy1 to Proxy3) or whether we want to exclude this? Bear in mind that
the first mid-dialog request (excluding ACK) could occur some
considerable time after the call is established (e.g., an UPDATE request
when session timer expires), so the benefit of keep-alive would last
only between that request and the final BYE request.

For SUBSCRIBE- and REFER-initiated dialogs it is a little simpler,
because there is always an immediate NOTIFY request to form the dialog.

John

---

From: "Christer Holmberg" <[email-masked]>
Date: Wed, 6 May 2009 14:30:43 +0200

Hi, 

>>>Perhaps we might deliberately exclude the mechanism for use
>>>between two entities between which there was one or more 
>>>non-record-routing proxy.
>> 
>>record-routing or not) between the two entities, thoe two entities 
>>will not send keep-alives between each other. When a SIP entity 
>>receives a request, it only checks the TOPMOST Via if it contains 
>>"keep", so if some other proxy has added a Via header (without "keep")
no keep-alives will be sent.
>There is no point in doing keep-alive between Proxy1 and Proxy2, or
between Proxy2 and Proxy3.

Correct. So, in that case, if Proxy2 doesn't Record-Route, it should not
insert "yes" in the Via received from Proxy1, and it should not insert
"keep" in its Via sent towards Proxy3.

>When the first mid-dialog request is sent, it will go directly from
Proxy1 to Proxy3 or vice versa. 

Correct.

>My question was whether we want to allow the invocation of keep-alive
on that hop (Proxy1 to Proxy3) or whether we want to exclude this? 

Technically I see no harm in allowing sending keep-alives TO an entity
which didn't record-route, eventhough I am not sure it is useful.

However, I don't think it shall be possible to send keep-alives FROM an
entity which didn't record-route. Because, that entity would not know
when the registration, or the session, terminates, in order to stop
sending keep-alives.

>Bear in mind that the first mid-dialog request (excluding ACK) 
>could occur some considerable time after the call is 
>established (e.g., an UPDATE request when session timer 
>expires), so the benefit of keep-alive would last only 
>between that request and the final BYE request.

Yes.

But, I think that in many (most?) cases keep-alives will be sent between
entities which are going to be in the signalling path anyway.

For example, I think one of the most common use-case will be between a
UA and an edge proxy. So, the UA inserts "keep" in the Via of the
initial request, and the edge proxy will record-route and insert "yes".

Yes.

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 06 May 2009 09:48:04 -0400

> I think there are cases where you may record route because you want to

Christer - can you explain that. I agree with John that it seems 
backwards. What would be a use case where the decision the do keep 
alives comes first and the need to r-r in order to be present for those 
keep alives is secondary?

	Thanks,
	Paul

---

From: "Christer Holmberg" <[email-masked]>
Date: Wed, 6 May 2009 20:20:28 +0200

Hi, 

do keep-alives.
>keep alives is secondary?

I am not sure I understand what is meant by "first and secondary". My
point is that an entity can choose to Record-Route because it wants to
either send or receive keep-alives (in the same way that it may choose
to record-record due to whatever other reasons). An edge proxy, if it
detects that the UA is behind a NAT, could Record-Route in order to
allow the UA to send keep-alives towards it.

But, of course, we can allow an entity to indicate that it is willing to
receive keep-alives (by inserting a "yes" value) even if it doesn't
record-route.

Regards,

Christer

>> involved, this can be achieved only on the first mid-dialog request. 
>> request, but unfortunately that doesn't have a response, so it is not

>> suitable. In some cases it would be an UPDATE or PRACK request during

>> the early dialog. For a

---

From: "Elwell, John" <[email-masked]>
Date: Wed, 06 May 2009 20:12:21 +0100

Christer, 

> Sent: 06 May 2009 13:31
[JRE] That is not the point. I am asking about keep-alives between
Proxy1 and Proxy3, both of which record-routed.

John

---

From: "Christer Holmberg" <[email-masked]>
Date: Wed, 6 May 2009 22:59:29 +0200

Hi, 

> >>>Perhaps we might deliberately exclude the mechanism for use between

> >>>two entities between which there was one or more non-record-routing

> >>>proxy.
> Correct. So, in that case, if Proxy2 doesn't Record-Route, it should 
> not insert "yes" in the Via received from Proxy1, and it should not 
> insert "keep" in its Via sent towards Proxy3.
> 
> 

>Proxy1 and Proxy3, both of which record-routed.

In that case the top Via (Proxy2) will not contain the "keep" parameter.
So, Proxy3 would need to make sure that the last entity (Proxy1) which
inserted "keep" is also the last entity which record-routed. And, I am
not sure we want to start comparing Via- and Record-Route headers in
order to figure that out.

An alternative would of course be to define "keep" as a Record-Route
(and Path) parameter. Then it doesn't matter how many proxies (read: Via
headers) there are between Proxy1 and Proxy3, as long as the top
Record-Route contains the keep parameter.

However, UAs don't insert Record-Route, so a UAC that supports sending
of keep-alives would have to insert "keep" somewhere else.

Regards,

Christer

> However, I don't think it shall be possible to send keep-alives FROM 
> an entity which didn't record-route. Because, that entity would not 
> know when the registration, or the session, terminates, in order to 
> stop sending keep-alives.
> 
> 
> >Bear in mind that the first mid-dialog request (excluding ACK) could 
> >occur some considerable time after the call is established (e.g., an 
> >UPDATE request when session timer expires), so the benefit of 
> >keep-alive would last only between that request and the final BYE 
> >request.
> 
> Yes.
> 
> But, I think that in many (most?) cases keep-alives will be sent 
> between entities which are going to be in the signalling path anyway.
>

---

From: "Elwell, John" <[email-masked]>
Date: Thu, 07 May 2009 07:15:52 +0100

> Sent: 06 May 2009 21:59
[JRE] No, I would not want to do that. My point is that at the time of
the dialog-forming request, there will be no direct transport connection
between proxy1 and proxy3, so keep-alive is not relevant. However, as a
result of the first mid-dialog request, there will be a direct transport
connection between Proxy1 and Proxy3. So the question is whether we want
to figure out a way of keeping that alive or not.

> of keep-alives would have to insert "keep" somewhere else.
[JRE] And also it would not apply to REGISTER keep-alives. This would be
a significant departure from what we are chartered to do -  I am not
sure we want to go there.

To summarise:
- The mechanism we currently have works for REGISTER-initiated
keep-alives.
- It also works for dialog-based keep-alives between entities that were
adjacent at dialog-initiation time and remain on the dialog path.
- It does not work for dialog-based keep-alives between entities that
were not adjacent at dialog-initiation time but become adjacent
subsequently (as a result of intermediate proxies not record-routing).

The last case does not arise if B2BUAs are used or all proxies
record-route. Does the WG want to address the last case or not?

John

---

From: "Christer Holmberg" <[email-masked]>
Date: Thu, 7 May 2009 10:12:09 +0200

Hi, 

>[JRE] No, I would not want to do that. My point is that at 
>the time of the dialog-forming request, there will be no 
>direct transport connection between proxy1 and proxy3, so 
>keep-alive is not relevant. However, as a result of the first 
>mid-dialog request, there will be a direct transport 
>connection between Proxy1 and Proxy3. So the question is 
>whether we want to figure out a way of keeping that alive or not.

I think there will be a direct transport connection between proxy1 and
proxy3 already at the time of the response to the dialog-forming
request. So, you can start sending keep-alives at that point. You don't
need to wait for the first mid-dialog request.

>>and Path) parameter. Then it doesn't matter how many proxies
>>(read: Via headers) there are between Proxy1 and Proxy3, as long as
the top 

>[JRE] And also it would not apply to REGISTER keep-alives. 
>This would be a significant departure from what we are 
>chartered to do -  I am not sure we want to go there.

For REGISTER you would use the Path header. Outbound also uses that.

Regards,

Christer

keep-alives.
>- It also works for dialog-based keep-alives between entities 
>that were adjacent at dialog-initiation time and remain on 
>the dialog path.
>- It does not work for dialog-based keep-alives between 
>entities that were not adjacent at dialog-initiation time but 
>become adjacent subsequently (as a result of intermediate 
>proxies not record-routing).
> 
>The last case does not arise if B2BUAs are used or all 
>proxies record-route. Does the WG want to address the last 
>case or not?
> 
> John
>

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 07 May 2009 11:55:20 -0400

Christer Holmberg wrote:
> to record-record due to whatever other reasons).

I agree that it *could* do that.
But I fail to understand *why* it would do that?
Aren't the keepalives there to assure there is a working communication 
path between them? If it has no other reason to be on a path, then why 
would it want the keepalives? They don't have value in their own right.

> An edge proxy, if it

Maybe its just semantics, but in that case the reason it is R-R'ing is 
not because it wants to do keepalives. It is R-R'ing in order to 
maintain a working path to the UA. Doing keepalives is something else 
might need to do to keep that working path up.

> receive keep-alives (by inserting a "yes" value) even if it doesn't

Does that mean that keepalives should be sent even though the target of 
the keepalives is of no use?

	Thanks,
	Paul

---

From: "Christer Holmberg" <[email-masked]>
Date: Thu, 7 May 2009 19:03:18 +0200

Hi, 

>>>>I think there are cases where you may record route because you want 
>>>>to do keep-alives.

path between them? If it has no other reason to be on a path, then why
would it want the keepalives? They don't have value in their 
>own right.

I agree, so in that case there probably wouldn't be any keep-alives
negotiated. The receiving entity would not Record-Route, and it would
not insert "keep".

But, the comments was that an entity first decides to Record-Route, and
then decides to do keep-alives. So, when the entity has decided to
Record-Route it can insert "keep" in the same request.

>>An edge proxy, if it detects that the UA is behind a NAT, could
Record-Route in order to 
not because it wants to do keepalives. It is R-R'ing in order to
maintain a working path to the UA. Doing keepalives is something 
>else might need to do to keep that working path up.

Yes.

>>But, of course, we can allow an entity to indicate that it is willing 
>>to receive keep-alives (by inserting a "yes" value) even if it doesn't

Well, if there is no use to send keep-alives, there will be no "yes"
inserted.

Assume I insert "keep", and forwards a request to you. No keep-alives
are going to be sent until you actually add a "yes" value. And, if there
is no reason for keep-alives you will not add "yes", and there won't be
any keep-alives. 

It is always the receiving entity which decides (by inserting "yes")
whether there will be keep-alives or not. The sending entity only
indicates (by inserting "keep") that he is able to send keep-alives.

Regards,

Christer

>>> not

---

From: "Elwell, John" <[email-masked]>
Date: Thu, 07 May 2009 21:01:11 +0100

> Sent: 07 May 2009 09:12
[JRE] I don't understand how that can happen, since the response will
follow the path of the Via entries, not the path or record-routes.
Please explain.

John

> So, you can start sending keep-alives at that point. 
> You don't

---

From: "Spencer Dawkins" <[email-masked]>
Date: Thu, 7 May 2009 15:21:47 -0500

> follow the path of the Via entries, not the path or record-routes.

I'm as confused as John is. For example, if the signaling path is using TCP, 
there would be a TCP connection between Proxy1 and Proxy2, and a separate 
TCP connection between Proxy2 and Proxy3, but this would not cause a 
SYN/SYN-ACK/ACK exchange between Proxy1 and Proxy3 - or am I missing 
something?

Thanks,

Spencer

---

From: "Christer Holmberg" <[email-masked]>
Date: Fri, 8 May 2009 12:43:48 +0200

Hi,

>>>>[JRE] No, I would not want to do that. My point is that at the time 
>>>>of the dialog-forming request, there will be no direct transport 
>>>>connection between proxy1 and proxy3, so keep-alive is not relevant.

>>>>However, as a result of the first mid-dialog request, there will be 
>>>>a direct transport connection between Proxy1 and Proxy3. So the 
>>>>question is whether we want to figure out a way of keeping that 
>>>>alive or not.
>>>
>I'm as confused as John is. For example, if the signaling 
>path is using TCP, there would be a TCP connection between 
>Proxy1 and Proxy2, and a separate TCP connection between 
>Proxy2 and Proxy3, but this would not cause a SYN/SYN-ACK/ACK 
>exchange between Proxy1 and Proxy3 - or am I missing something?

No, you are not :)

The TCP connection between Proxy1 and Proxy3 will be established when
something is sent from Proxy1 to Proxy3. That would normally be a
mid-dialog request, but it COULD of course also be the keep-alive
message.

But, if we don't want the keep-alive message to establish the TCP
connection we can simply decide that keep-alives can be negotiated only
between adjacent nodes, and we can keep the Via parameter based
solution. 

Then, it would not be possible to negotiate keep-alives between Proxy1
and Proxy3 during the initial request, since Proxy2 would still insert a
Via (it would then be possible to negotiate keep-alives between Proxy1
and Proxy3 during a mid-dialog request, becuase then they will be
adjacent).

Regards,

Christer

---

From: Hisham Khartabil <[email-masked]>
Date: Mon, 11 May 2009 09:25:45 +1000

> and Proxy3 during a mid-dialog request, becuase then they will be

John's query is not about the possibility of negotiating keep-alives
between Proxy1 and Proxy3 during initial message exchange. He is
asking if we have a requirement to negotiate keep-alives between
proxy1 and proxy3 using mid-dialog messages.

I think its a valid scenario and we should work on a solution.

Hisham

---

From: "Christer Holmberg" <[email-masked]>
Date: Mon, 18 May 2009 14:06:09 +0200

Hi,

The requirements talk about negotiating keep-alives towards the next hop
(UAC) and the previous hop (UAS), so in my opinion that only talks about
adjacent nodes.

We can of course argue whether we talk about nodes being adjacent during
the routing of the initial INVITE, or nodes which become adjacent once
the route set has been established :) 

However, I think the only difference which headers we use for the
negotiation.

If we talk about adjacent nodes during routing of the initial INVITE the
Via based solution works fine.

If we talk about adjacent nodes in the route set I think we need to use
e.g. Record-Route/Contact/Path.

Of course we could use a Via based solution also for the second case,
but then we need to establish the route set before we do the keep-alive
negotiation, to make sure all Vias belong to entities in the route set.
And, that also means a separate SIP transaction (UPDATE or PRACK) for
the negotiation part.

Regards,

Christer 

> From: Hisham Khartabil [mailto:[email-masked]] 
> Sent: 11. toukokuuta 2009 2:26
> To: Christer Holmberg
> Cc: Spencer Dawkins; Elwell, John; Tan, Ya Ching (NSN - 
> DE/Munich); SIPCORE
> >>I'm as confused as John is. For example, if the signaling path is 
> >>using TCP, there would be a TCP connection between
> >>Proxy2 and Proxy3, but this would not cause a 
> SYN/SYN-ACK/ACK exchange 
> >>between Proxy1 and Proxy3 - or am I missing something?
> >
> > No, you are not :)
> >
> > connection we can simply decide that keep-alives can be negotiated 
> > only between adjacent nodes, and we can keep the Via 
> parameter based 
> > solution.
> >
> > and Proxy3 during the initial request, since Proxy2 would 
> still insert 
> > a Via (it would then be possible to negotiate keep-alives between 
> > Proxy1 and Proxy3 during a mid-dialog request, becuase then 
> they will 
> > be adjacent).
> 
> John's query is not about the possibility of negotiating 
> keep-alives between Proxy1 and Proxy3 during initial message 
> exchange. He is asking if we have a requirement to negotiate 
> keep-alives between

---

From: "Christer Holmberg" <[email-masked]>
Date: Mon, 25 May 2009 07:49:06 +0200

Hi,

My proposal would be that we keep the Via based solution.

That allows negotiation as part of of keep-alives in any transaction. A
Record-Route based solution only allowes the negotiation during the
initial dialog transaction, since the route set can't be modified later
during the dialog.

Are people ok with that?

Regards,

Christer

> Sent: 18. toukokuuta 2009 15:06
> To: Hisham Khartabil
> Cc: SIPCORE
> draft-ietf-sipcore-keep-00(wasRE:Document Adoption)
> 
> 
> Hi,
> 
> (UAC) and the previous hop (UAS), so in my opinion that only 
> talks about adjacent nodes.
> 
> We can of course argue whether we talk about nodes being 
> adjacent during the routing of the initial INVITE, or nodes 
> which become adjacent once the route set has been established :) 
> 
> However, I think the only difference which headers we use for 
> the negotiation.
> 
> If we talk about adjacent nodes during routing of the initial 
> INVITE the Via based solution works fine.
> 
> If we talk about adjacent nodes in the route set I think we 
> need to use e.g. Record-Route/Contact/Path.
> 
> Of course we could use a Via based solution also for the 
> second case, but then we need to establish the route set 
> before we do the keep-alive negotiation, to make sure all 
> Vias belong to entities in the route set.
> And, that also means a separate SIP transaction (UPDATE or 
> PRACK) for the negotiation part.
> 
> Regards,
> 
> Christer 
> 
> 
> > Cc: Spencer Dawkins; Elwell, John; Tan, Ya Ching (NSN - DE/Munich); 
> > SIPCORE
> > >>>>I think there will be a direct transport connection 
> between proxy1
> > > and
> keep-alives

---

From: Dean Willis <[email-masked]>
Date: Tue, 26 May 2009 01:24:12 -0500

I don't believe it is reasonable to change the keepalive set after the  
route-set is determined, and think it's inefficient to do an  
additional-re-INVITE in order to add keepalive to a dialog. So I think  
I prefer something on the record-route operation that lets us use the  
initial dialog formation to establish keepalive.

--
Dean

---

From: Gonzalo Camarillo <[email-masked]>
Date: Wed, 27 May 2009 15:46:06 +0300

Hi,

> need to wait for the first mid-dialog request.

the response will not trigger such a connection because even though 
Proxy2 did not record routed, he inserted itself in the Via, which is 
used to route responses.

On a different note, the negotiation you are trying to perform here has 
somewhat similar requirements as the one specified in RFC 3486. You may 
want to have a look at that spec at some point.

Cheers,

Gonzalo

---

From: Gonzalo Camarillo <[email-masked]>
Date: Wed, 27 May 2009 15:50:28 +0300

Hi,

> the route set has been established :) 

well, that is actually the main point of the discussion. We need to 
understand whether or not we have that requirement. For example, in RFC 
3486, the UAC can negotiate SigComp compression with a node that will be 
adjacent to it during the dialog but that was not in the initial 
request. Do we have the same requirement here or not?

Cheers,

Gonzalo