Subject: [sipcore] Draft new version: draft-ietf-sipcore-keep-02

From: Christer Holmberg <[email-masked]>
Date: Thu, 15 Apr 2010 07:38:34 +0200

Hi,

I've submitted a new version of the keep-alive draft.

Based on the "lessons learned" during the work on the info-events draft, I've done some editorial changes.

The TECHNICAL change, however, is that there is no longer a "=yes" value added to a "keep" parameter inserted by another entity, because it did not work in all cases.

The new solution is much more simple. An entity simply adds a "keep" parameter if it supports keep-alive, and once the route set/path is established entities will then see whether the adjacent node supports keep-alives or not.

An open issue is whether, in the proxy-to-proxy heartbeat/ping case, whether it should be possible to negotiate a keep-alive lifetime that extends the dialog for which the keep-alives were negotiated. I guess the outcome of that depends on what/if we are going to do with the options-ping draft.

The draft can also be found at:

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

Regards,

Christer

---

From: "Elwell, John" <[email-masked]>
Date: Thu, 15 Apr 2010 10:19:08 +0200

Christer,

Why is this draft-ietf? I don't recall adopting anything of this nature as a WG item. I have a major concern that the draft assumes a very specific topology. I remember discussing similar concerns on earlier iterations, but this new draft makes things worse, if anything. Details below:

1. For UAs that don't perform registration (e.g., gateways, media servers, B2BUAs typically don't do registration), the provisions of section 4 seem a bit restrictive. For example, between a proxy and a gateway, the gateway must do the keep-alives, not the proxy. I don't necessarily have a problem with this, but I wondered why there is this constraint. What I do have a problem with is the UA-to-UA case (in particular, B2BUA-to-B2BUA), where, if this mechanism is to be used, clearly one of the UAs has to receive keep-alives.

2. Also section 4.1 starts off by saying that this is all about keep-alive between a UA and its edge proxy, which tends to rule out the cases above, and also cases where a registering UA registers directly with its registrar, not via an edge proxy. Also it seems to rule out cases where the proxy does not record-route, so that for dialog keep-alive the UA would need to send keep-alives to some other entity.

3. In 4.2.2:
"When the UAC receives the response(s) to the initial request for the
   dialog, if the top-most Record-Route header field (edge proxy) of
   response(s) contains a "keep" parameter, the UAC MUST start to send
   keep-alives towards the edge proxy for the remaining duration of the
   dialog."
This doesn't make sense. The response containing the "keep" parameter will be received on the path of the  request, but depending which entities have record-routed, the dialog path may be different. A transport connection to the first entity on the dialog path is not established until the next outbound or inbound request on that dialog, so "MUST start to send keep-alives towards the edge proxy" is unachievable in such cases.

4. In 4.3.1:
"When a UAS receives an initial request for a dialog, if the top-most
   Record-Route header filed contains a "keep" parameter, and if the UAS
   is willing to send keep-alives associated with the dialog, it MUST
   insert a "keep" parameter in its Contact header field in the
   response(s) to the request.  After that the UAS MUST start to send
   keep-alives towards the edge proxy, and it MUST send keep-alives for
   the remaining duration of the registration."
I have a similar problem with this.

5. In 5.3.1:
"When a proxy receives a dialog initiation request from its previous-
   hop proxy, and the top-most Record-Route header field of the request
   contains a "keep" parameter, if the proxy is willing to send and
   receive keep-alives from the previous-hop proxy for the associated
   dialog, the proxy MUST insert a "keep" parameter in its Record-Route
   header field of the associated response(s) sent towards the previous-
   hop proxy.  After that the proxy MUST send keep-alives, and accept
   keep-alives sent from the previous-hop proxy, for the duration of the
   dialog."
I have a similar problem with this. If the top-most Record-Route header field does not represent the previous hop proxy, there is no transport connection established to allow you to start sending keep-alives at this time.

6. "When a proxy forwards a dialog initiation request towards its next-
   hop proxy, and it wants to negotiate the usage of keep-alives with
   that next-hop proxy, it MUST include a "keep" parameter in its
   Record-Record header field of the request."
How does the proxy know that the next hop is a proxy, as opposed to a UA? Assuming it does know that the next hop is a proxy, how does it know that the next hop proxy will record-route?

John

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Christer Holmberg
> Sent: 15 April 2010 06:39
> To: [email-masked]
> Subject: [sipcore] Draft new version: draft-ietf-sipcore-keep-02
> 
>  
> Hi,
>  
> Based on the "lessons learned" during the work on the 
> info-events draft, I've done some editorial changes.
>  
> The TECHNICAL change, however, is that there is no longer a 
> "=yes" value added to a "keep" parameter inserted by another 
> entity, because it did not work in all cases.
>  
> The new solution is much more simple. An entity simply adds a 
> "keep" parameter if it supports keep-alive, and once the 
> route set/path is established entities will then see whether 
> the adjacent node supports keep-alives or not.
>  
> An open issue is whether, in the proxy-to-proxy 
> heartbeat/ping case, whether it should be possible to 
> negotiate a keep-alive lifetime that extends the dialog for 
> which the keep-alives were negotiated. I guess the outcome of 
> that depends on what/if we are going to do with the 
> options-ping draft.
>  
> <http://users.piuha.net/cholmber/drafts/draft-ietf-sipcore-kee
> p-02.txt> 
>  
> Regards,
>  
> Christer
>

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 15 Apr 2010 11:43:30 +0200

Hi John,

>Why is this draft-ietf? I don't recall adopting anything of this nature as a WG item. 

The draft has been adopted a long time ago. It has just been on hold for a while, partly because of the INFO work. 

Before answering to your specific comments, I want to clarify one thing:

When I talk about "next hop" and "previous hop", I refer to the adjacent node in the established registration/dialog path - not a hop which will not be part of that path. That needs to be clarfied.

And, this is the reason, based on a comment from yourself, that we decided to NOT define the "keep" parameter for the Via header field, since not all entities that insert Via will be part of the path.

--------

>I have a major concern that the draft assumes a very specific topology. I remember discussing similar concerns on earlier iterations, but this new draft 
>makes things worse, if anything. Details below:
> 
>1. For UAs that don't perform registration (e.g., gateways, 
>media servers, B2BUAs typically don't do registration), the 
>provisions of section 4 seem a bit restrictive. For example, 
>between a proxy and a gateway, the gateway must do the 
>keep-alives, not the proxy. I don't necessarily have a 
>problem with this, but I wondered why there is this 
>constraint.

The idea is that keep-alives would not be sent towards UAs. It is the UAs that need to send keep-alives in order to keep the NAT binding open.

--------

>What I do have a problem with is the UA-to-UA case (in particular, B2BUA-to-B2BUA), where, if this mechanism is to be used, clearly one of the UAs has to 
>receive keep-alives.

The initial scope of the draft was to use the Outbound topology, and assume there is an edge proxy. After that people asked to also cover the proxy-to-proxy case.

However, if we want to cover the direct UA-to-UA case I guess we could say that the UAs check for a Record-Route with "keep", and if there is none then check for a Contact with "keep".

--------

>2. Also section 4.1 starts off by saying that this is all 
>about keep-alive between a UA and its edge proxy, which tends 
>to rule out the cases above, and also cases where a 
>registering UA registers directly with its registrar, not via 
>an edge proxy. Also it seems to rule out cases where the 
>proxy does not record-route, so that for dialog keep-alive 
>the UA would need to send keep-alives to some other entity.

See my comment about the scope of the draft above.

However, as for the UA-to-UA case, I don't have a problem if we want to also cover the direct UA-to-Registrar case. I guess the question then is how the registrar will indicate its support of keep-alives, since it normally doesn't insert a Path header field.

--------

>keep-alives towards the edge proxy for the remaining 
>duration of the dialog."
>This doesn't make sense. The response containing the "keep" 
>parameter will be received on the path of the  request, but 
>depending which entities have record-routed, the dialog path 
>may be different. A transport connection to the first entity 
>on the dialog path is not established until the next outbound 
>or inbound request on that dialog, so "MUST start to send 
>keep-alives towards the edge proxy" is unachievable in such cases.

The UAC will send the keep-alives towards the address indicated in the Record-Route - NOT to where it sent the INVITE request.

--------

>Record-Route header filed contains a "keep" parameter, and 
>if the UAS is willing to send keep-alives associated with the dialog, it MUST

Again, the UAS will send the keep-alives towards the address indicated in the Record-Route.

--------

>dialog, the proxy MUST insert a "keep" parameter in its 
>Record-Route header field of the associated response(s) sent towards 
>the previous-hop proxy.  After that the proxy MUST send keep-alives, and accept
>I have a similar problem with this. If the top-most 
>Record-Route header field does not represent the previous hop 
>proxy, there is no transport connection established to allow 
>you to start sending keep-alives at this time.

As I said in the beginning of the reply, "next hop" and "previous hop" are probably confusing terminology - at least without proper explanation.

--------

>6. "When a proxy forwards a dialog initiation request towards 
>its next- hop proxy, and it wants to negotiate the usage of keep-alives with
>How does the proxy know that the next hop is a proxy, as 
>opposed to a UA? 

I guess that would be a edge-to-UA case. But, I guess that could be clarified.

--------

>Assuming it does know that the next hop is a proxy, how does it know that the next hop proxy will record-route?

See previous comments on "next hop" and "previous hop" terminology.

Regards,

Christer

---

From: "Elwell, John" <[email-masked]>
Date: Thu, 15 Apr 2010 12:26:16 +0200

> From: Christer Holmberg [mailto:[email-masked]] 
> Sent: 15 April 2010 10:44
> To: Elwell, John; [email-masked]
> Subject: RE: Draft new version: draft-ietf-sipcore-keep-02
> 
> 
> Hi John,
> 
> The draft has been adopted a long time ago. It has just been 
> on hold for a while, partly because of the INFO work. 
[JRE] I know, but this draft looks very different from the one adopted as WG item, but never mind, the important thing is to address the comments.

> When I talk about "next hop" and "previous hop", I refer to 
> the adjacent node in the established registration/dialog path 
> - not a hop which will not be part of that path. That needs 
> to be clarfied.
> 
> And, this is the reason, based on a comment from yourself, 
> that we decided to NOT define the "keep" parameter for the 
> Via header field, since not all entities that insert Via will 
> be part of the path.
[JRE] Yes, I understand the problems with the old Via-based proposal, but on reading the present draft it didn't seem to help much.

> 
> --------
> 
> >I have a major concern that the draft assumes a very 
> specific topology. I remember discussing similar concerns on 
> earlier iterations, but this new draft 
> The idea is that keep-alives would not be sent towards UAs. 
> It is the UAs that need to send keep-alives in order to keep 
> the NAT binding open.
> 
> --------
> 
> >What I do have a problem with is the UA-to-UA case (in 
> particular, B2BUA-to-B2BUA), where, if this mechanism is to 
> be used, clearly one of the UAs has to 
> >receive keep-alives.
> 
> The initial scope of the draft was to use the Outbound 
> topology, and assume there is an edge proxy. After that 
> people asked to also cover the proxy-to-proxy case.
> 
> However, if we want to cover the direct UA-to-UA case I guess 
> we could say that the UAs check for a Record-Route with 
> "keep", and if there is none then check for a Contact with "keep".
[JRE] Many people use B2BUAs rather than proxies, and I would expect the draft to be equally applicable between B2BUAs. Also I would have expected the draft to be applicable between a proxy/B2BUA and a non-registering UA, or between a proxy/B2BUA and a directly registering UA (without an edge proxy). In other words, filling all the gaps that aren't covered by sip-outbound.

> However, as for the UA-to-UA case, I don't have a problem if 
> we want to also cover the direct UA-to-Registrar case. I 
> guess the question then is how the registrar will indicate 
> its support of keep-alives, since it normally doesn't insert 
> a Path header field.
[JRE] Well, the previous proposal used the Via header field, so in moving away from Via we seem to have lost a capability. Perhaps a UA wanting to use this mechanism must insert a Path header field - I haven't thought through the consequences, however.

> The UAC will send the keep-alives towards the address 
> indicated in the Record-Route - NOT to where it sent the 
> INVITE request.
[JRE] How can it sent keep-alives when it hasn't established a transport connection yet? It must wait for the transport connection to be established, which means waiting for an inbound or outbound mid-dialog request. If it's an inbound request, however, which entity should be responsible for keep-alives?

> indicated in the Record-Route.
[JRE] Same problem.

> As I said in the beginning of the reply, "next hop" and 
> "previous hop" are probably confusing terminology - at least 
> without proper explanation.
[JRE] OK, but this still doesn't address my concern about the absence of a transport connection.

> I guess that would be a edge-to-UA case. But, I guess that 
[JRE] As a proxy, how do I know I am the "edge", i.e., how do I know the next entity is a UA? Even in the IMS P-CSCF case, I don't know - there could be a PBX behind it.

> 
> --------
> 
> >Assuming it does know that the next hop is a proxy, how does 
> it know that the next hop proxy will record-route?
> 
[JRE] The words "When a proxy forwards a dialog initiation request towards its next-hop proxy" do not make sense - a proxy simply forwards a request to the next hop entity. Until it receives a response, it has no idea whether the entity it forwarded the request to is a UA, a non-record-routing proxy or a record-routing proxy, i.e., it has no idea whether it has sent it to something that complies with your definition of "next-hop proxy".

John

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 15 Apr 2010 12:57:13 +0200

Hi John, 

>>The draft has been adopted a long time ago. It has just been on hold 
>>for a while, partly because of the INFO work.
>[JRE] I know, but this draft looks very different from the one adopted as WG item,

Please compare the first and last version of the Info-events draft :)

Seriously, I agree there were editorial changes, but the only technical change was to not use the "=yes" parameter. And, some of the editorial changes are also based on that change.
 
>[JRE] Yes, I understand the problems with the old Via-based 
>proposal, but on reading the present draft it didn't seem to 
>help much.

Keep in mind that in Stockholm we decided to use Contact/Path/Record-Route instead of Via, so that is an existing agreement.

The change in this version is to not use the "=yes" value.

But, as I said earlier, the "next/previous hop" terminology is confusing, but I *AM* referring to adjacent nodes in the established path :)

--------

>[JRE] Many people use B2BUAs rather than proxies, and I would 
>expect the draft to be equally applicable between B2BUAs. 
>Also I would have expected the draft to be applicable between 
>a proxy/B2BUA and a non-registering UA, or between a 
>proxy/B2BUA and a directly registering UA (without an edge 
>proxy). In other words, filling all the gaps that aren't 
>covered by sip-outbound.

Since a B2BUA acts as a UA, I don't we need to separate them. If we solve UA-to-UA we also solve UA-to-B2BUA.

----------

>[JRE] Well, the previous proposal used the Via header field, 
>so in moving away from Via we seem to have lost a capability. 
>Perhaps a UA wanting to use this mechanism must insert a Path 
>header field - I haven't thought through the consequences, however.

The UA inserts Contact so that is not a problem. The question is how the registrar would indicate support.

---------

>>>3. In 4.2.2:
>>>"When the UAC receives the response(s) to the initial 
>>>request for the dialog, if the top-most Record-Route header field (edge proxy) of
>[JRE] How can it sent keep-alives when it hasn't established 
>a transport connection yet? It must wait for the transport 
>connection to be established, which means waiting for an 
>inbound or outbound mid-dialog request. If it's an inbound 
>request, however, which entity should be responsible for keep-alives?

What prevents the UAC from establishing the transport connection without waiting for any mid-dialog request to be sent?

And, unless the UAC establishes the connnection, it won't even be able to receive inbound requests in case there is a NAT.

---------

>>>4. In 4.3.1:
>>>"When a UAS receives an initial request for a dialog, if 
>>>the top-most Record-Route header filed contains a "keep" parameter, and 
>>>if the UAS is willing to send keep-alives associated with 
>>>the dialog, it MUST insert a "keep" parameter in its Contact header field in the

Same answer :)

---------

>>>5. In 5.3.1:
>>>"When a proxy receives a dialog initiation request from 
>>>its previous-hop proxy, and the top-most Record-Route header field of 
>>>the request contains a "keep" parameter, if the proxy is willing to send and

See above.

--------

>[JRE] As a proxy, how do I know I am the "edge", i.e., how do 
>I know the next entity is a UA? Even in the IMS P-CSCF case, 
>I don't know - there could be a PBX behind it.

When the proxy get the response, if there are no Record-Routes between the proxy and the UA, the proxy is adjacent to the UA.

---------

>[JRE] The words "When a proxy forwards a dialog initiation 
>request towards its next-hop proxy" do not make sense - a 
>proxy simply forwards a request to the next hop entity. Until 
>it receives a response, it has no idea whether the entity it 
>forwarded the request to is a UA, a non-record-routing proxy 
>or a record-routing proxy, i.e., it has no idea whether it 
>has sent it to something that complies with your definition 
>of "next-hop proxy".

I agree. So, the text could probably be more generic, and the actions then depend on what comes in the answer (Record-Route or Contact).

Regards,

Christer

---

From: "Elwell, John" <[email-masked]>
Date: Thu, 15 Apr 2010 15:27:41 +0200

> Sent: 15 April 2010 11:57
> Seriously, I agree there were editorial changes, but the only 
> technical change was to not use the "=yes" parameter. And, 
> some of the editorial changes are also based on that change.
[JRE] This is not true. -00 and -01 both used Via, now we use Path, Record-Route and Contact. That is a completely different solution. I agree that -02 might be moving in the right direction.

> Keep in mind that in Stockholm we decided to use 
> Contact/Path/Record-Route instead of Via, so that is an 
> existing agreement.
[JRE] Well, I could not find any mailing list endorsement of this following Stockholm, and that is nearly one year ago, so my memory failed me. The minutes just state: "Option 2 from slides: "Nodes which are adjacent in a route set/registration path"", and don't say anything about the header fields. Unfortunately the link to the slides is broken. Anyway, we should focus on fixing the present draft.

> But, as I said earlier, the "next/previous hop" terminology 
> is confusing, but I *AM* referring to adjacent nodes in the 
> established path :)
> 
> --------
> 
> Since a B2BUA acts as a UA, I don't we need to separate them. 
> If we solve UA-to-UA we also solve UA-to-B2BUA.
[JRE] Fine, but the present draft doesn't seem to work for UA-to-UA.

> The UA inserts Contact so that is not a problem. The question 
> is how the registrar would indicate support.
[JRE] If the registrar receives Path in the request, it could send Path in the response.

> What prevents the UAC from establishing the transport 
> connection without waiting for any mid-dialog request to be sent?
[JRE] Well, nothing I guess, except that isn't SIP. What would the next hop do if it receives a TCP connection without any SIP message for a while, or receives an empty UDP packet?

> 
> And, unless the UAC establishes the connnection, it won't 
> even be able to receive inbound requests in case there is a NAT.
[JRE] True, and in such cases I would expect the first proxy to record-route, so no issue. The point is, there are situations that the present draft doesn't deal with. I am happy to be convinced that you don't need keep-alive in cases that aren't covered by the draft, but we haven't had that discussion.

> When the proxy get the response, if there are no 
> Record-Routes between the proxy and the UA, the proxy is 
> adjacent to the UA.
[JRE] This still doesn't make sense. The text talks about "When a proxy forwards a dialog initiation request" - at the time of forwarding you just don't know what the next entity is - not until the response arrives.

John

> I agree. So, the text could probably be more generic, and the 
> actions then depend on what comes in the answer (Record-Route 
> or Contact).
> 
> 
> Regards,
> 
> Christer
>

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 15 Apr 2010 18:03:01 +0200

Hi,

>[JRE] This is not true. -00 and -01 both used Via, now we use Path, Record-Route and Contact. 

True. What I meant was that we in Stockholm agreed to use P/RR/C instead of Via, with the "=yes" parameter value, but it was never documented in a draft. In addition, at one point I indicated that there are problems with "=yes", and that something else is needed. That else is now presented in -02.

----------

>That is a completely different solution. I agree that -02 might be moving in the right direction.

Good.

>[JRE] Well, I could not find any mailing list endorsement of this following Stockholm, and that is nearly one year ago, so my memory failed me. 
>The minutes just state: "Option 2 from slides: "Nodes which are adjacent in a route set/registration path"", and don't say anything about the header 
>fields. Unfortunately the link to the slides is broken.

I can look for them, if you want.

----------

>Anyway, we should focus on fixing the present draft.

Yes.

----------

>[JRE] Fine, but the present draft doesn't seem to work for UA-to-UA.

I agree, and the reason for that is I assumed it was not within the scope of the solution.

But, as I said earlier, there should be no problem to make it work for UA-to-UA. Currently an UA only checks if the adjacent node supports keep-alive by looking at Record-Route, but we can add text saying that, if there is no Record-Route, the UA checks whether the Contact contains "keep".

However, the use-cases described in the beginning of the draft are the ones I used to justfiy the work, and UA-to-UA is not covered in any of those. So, I just want to be sure people are ok with adding it.

----------

>[JRE] If the registrar receives Path in the request, it could send Path in the response.

Yes. It would insert a Path pointing to itself, and add a "keep" parameter.

----------

>[JRE] Well, nothing I guess, except that isn't SIP. What would the next hop do if it receives a TCP connection without any SIP message for a while, or receives an empty UDP packet?

The UA establishes the connection when the first keep-alive is sent, and since the next hop has indicated support of keep-alive it needs to be ready to handle it.

I guess we could add a Note indicating that.

----------

>[JRE] True, and in such cases I would expect the first proxy to record-route, so no issue. The point is, there are situations that the present draft doesn't deal with. 
>I am happy to be convinced that you don't need keep-alive in cases that aren't covered by the draft, but we haven't had that discussion.

I am NOT trying to convince you about that :)  

I wrote the draft based on the use-cases we had agreed upon (at least according to my understanding), but I would be happy to cover additional use-cases, if people are ok with it.

----------

>[JRE] This still doesn't make sense. The text talks about "When a proxy forwards a dialog initiation request" - at the time of forwarding you just don't know what the next entity is - not until the…

That is what I tried to say :) 

The text about the request being forward would NOT make assumption about what type of node the next hope is - it would be detected when the response arrives.

Regards,

Christer

---

From: "Elwell, John" <[email-masked]>
Date: Thu, 15 Apr 2010 18:53:36 +0200

Christer,

The use cases in 1.1 to 1.4 seem to cover most of what I mentioned in my comments. For example, they make no assumption about the presence of an edge proxy between a UA and its registrar/proxy, and they make no assumption about which entities, if any, between two UAs, perform record-route. Therefore I would expect such situations to be covered by the solution.

What is missing from the use cases is the B2BUA case, I guess. I think if we include the proxy-to-proxy case (1.4), we should also include the B2BUA-B2BUA case, since B2BUAs are commonly used instead of proxies.

(Rest of thread stripped).

John

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 15 Apr 2010 19:04:42 +0200

Hi,

>The use cases in 1.1 to 1.4 seem to cover most of what I mentioned in my comments. For example, they 
>make no assumption about the presence of an edge proxy between a UA and its registrar/proxy, and they 
>make no assumption about which entities, if any, between two UAs, perform record-route.

Well, there is text talking about the fact why Outbound can't be used in those cases, so the assumption is that the Outbound topology is used.

But, we don't need to argue about it. I am ok to make it more general :)

>What is missing from the use cases is the B2BUA case, I guess. I think if we include the proxy-to-proxy case 
>(1.4), we should also include the B2BUA-B2BUA case, since B2BUAs are commonly used instead of 
>proxies.

Won't UA-UA case also cover B2BUA-B2BUA?

Regards,

Christer

---

From: "Elwell, John" <[email-masked]>
Date: Thu, 15 Apr 2010 21:37:10 +0200

> Sent: 15 April 2010 18:05
> >The use cases in 1.1 to 1.4 seem to cover most of what I 
> mentioned in my comments. For example, they 
> >make no assumption about the presence of an edge proxy 
> between a UA and its registrar/proxy, and they 
> Well, there is text talking about the fact why Outbound can't 
> be used in those cases, so the assumption is that the 
> Outbound topology is used.
[JRE] Outbound does not mandate an edge proxy.

> >What is missing from the use cases is the B2BUA case, I 
> guess. I think if we include the proxy-to-proxy case 
[JRE] But where is the UA-UA case in 1.1 to 1.4? If it's there, it's not obvious.

John

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 15 Apr 2010 22:30:07 +0200

Hi,

>[JRE] But where is the UA-UA case in 1.1 to 1.4? If it's there, it's not obvious.

It's not there. My point was that if we add the UA-UA case, we'll also cover the B2BUA-B2BUA case.

Regards,

Christer

---

From: Hadriel Kaplan <[email-masked]>
Date: Thu, 15 Apr 2010 23:39:19 -0400

> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Elwell, John
> Sent: Thursday, April 15, 2010 6:26 AM
>
> [JRE] Yes, I understand the problems with the old Via-based proposal, but
> on reading the present draft it didn't seem to help much.

Can someone explain the problems with the Via approach again?  I'm sorry, I must just be thick.  It seemed like such a clean/simple approach.

-hadriel

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 16 Apr 2010 07:37:41 +0200

Hi, 

>>proposal, 
>>but on reading the present draft it didn't seem to help much.
> 
>Can someone explain the problems with the Via approach again? 
>I'm sorry, I must just be thick.  It seemed like such a 
>clean/simple approach.

The main problem is that all entities, including those that will not be path of the registration/dialog path, insert Via, so when an entity receives a request it does not know which Via header represents the entity that will be its "neighbour" in the path, and can't therefor check whether that neighbour supports keep-alives or not.

Example:

P1                      P2                        P3                       P4

--- INVITE ------------->
    Via: P1;keep
    Record-Route: P1
                         --- INVITE ------------->
				     Via: P1;keep
                             Via: P2
                             Record-Route: P1
                                                  --- INVITE ------------->          
                                                      Via: P1;keep
                                                      Via: P2
                                                      Via: P3
                                                      Record-Route: P1

Now, when P4 receives the INVITE, how does it know that P1 will be its dialog path neighbour (since P2 and P3 do not record-route)? We cannot assume that P4 would be able to figure that out by starting to compare the Vias with the Record-Routes etc...

Regards,

Christer

---

From: Hadriel Kaplan <[email-masked]>
Date: Fri, 16 Apr 2010 02:23:25 -0400

> Sent: Friday, April 16, 2010 1:38 AM
> 
> The main problem is that all entities, including those that will not be
> path of the registration/dialog path, insert Via, so when an entity
> receives a request it does not know which Via header represents the entity
> that will be its "neighbour" in the path, and can't therefor check whether
> that neighbour supports keep-alives or not.

So??  What does it matter?  P4 received a request with a top-most Via that does not have the keep param, and it thereby knows the previous hop of that Via's address:port (P3) does not do keep-alive.  Likewise, P1 will get back a response with the top-most Via (its own) without the keep param's value being "yes", and knows that next-hop address:port (P2) cannot do keepalive.  

That's all that's important at that point.  

At some later time P1 will send an ACK, and P4 will get it and see the top-most Via (now P1) has the keep param, and know that previous hop addr:port of P1 can do keep-alive.  P1 won't get a response for the ACK of course (unless there's a PRACK) so it won't learn about P4's ability, but P4 can send a stun/crlf keep-alive if it wants to.  And if P1 really cares it can send an Update or re-Invite and find out for itself.

That may sound annoying to have to send a re-invite/update, but it's not the common use-case for this thing anyway, right?

The common use-case would be for a UA registering to its proxy/registrar, where the Via's will be fine.  And the other use-case might be between proxies/b2bua's, where the Via's will be fine too.

I mean basically this whole thing is an optimization at the end of the day to avoid doing OPTIONS or REGISTER refreshes, for specific common use-cases, so why make it complicated for the common use-cases just to be less annoying for the not-common use-cases?

-hadriel

---

From: "Elwell, John" <[email-masked]>
Date: Fri, 16 Apr 2010 08:28:13 +0200

One of the consequences of the changes in the current version of keep is as follows. Taking the example in the diagram Christer drew below, we have P1 and P4 on the dialog path, but not P3 and P4. The dialog-forming INVITE transaction follows the path through P1, P2, P3 and P4, so none of the transport connections used for that transaction need to be kept. The only transport connection that needs to be kept is the one from P1 to P4. However, this does not exist yet. So what the draft seems to imply is that, when a transport connection directly between P1 and P4 is established, it needs to be kept alive.

In an earlier mail, Christer suggested we establish it straight away, just to send the keep-alive, and then, when the first mid-dialog transaction takes place, the connection will be there ready and waiting. This seems wasteful to me. In particular, for some calls the only mid-dialog transaction might be the BYE, so establishing a transport connection early and keeping it alive, just to send the BYE, seems particularly pointless. Of course, other INVITE-initiated dialogs might have more traffic, e.g., UPDATE, INFO, re-INVITE, REFER, PRACK.

The alternative would be to wait for the first mid-dialog request, and then establish the connection in the normal manner and keep it alive (assuming the transaction is not a BYE).

But then, we could equally well use Via in the first mid-dialog transaction to signal keep-alive, and in fact that would probably be simpler.

We seem to have confusion between the dialog-forming transaction and the transaction that establishes connections for the dialog path (the first mid-dialog transaction).

Finally, we need to say something about dialog termination - there is no point in keeping the path open permanently, except in the context of connection reuse.

John

> Sent: 16 April 2010 06:38
> To: Hadriel Kaplan; Elwell, John; [email-masked]
> The main problem is that all entities, including those that 
> will not be path of the registration/dialog path, insert Via, 
> so when an entity receives a request it does not know which 
> Via header represents the entity that will be its "neighbour" 
> in the path, and can't therefor check whether that neighbour 
> supports keep-alives or not.
> 
> Example:
> 
> P1                      P2                        P3          
>              P4
> 
>                                                   --- INVITE -------->          
> Now, when P4 receives the INVITE, how does it know that P1 
> will be its dialog path neighbour (since P2 and P3 do not 
> record-route)? We cannot assume that P4 would be able to 
> figure that out by starting to compare the Vias with the 
> Record-Routes etc...
> 
> 
> Regards,
> 
> Christer
>

---

From: "Elwell, John" <[email-masked]>
Date: Fri, 16 Apr 2010 08:31:36 +0200

Sorry, I forgot to mention ACK in the list of mid-dialog requests below. That has specific considerations, as Hadriel has just pointed out on the old thread.

John 

> [mailto:[email-masked]] On Behalf Of Elwell, John
> Sent: 16 April 2010 07:28
> To: Christer Holmberg; Hadriel Kaplan; [email-masked]
> Subject: [sipcore] Keeping alive connections on a dialog path 
> (was RE: Draft new version: draft-ietf-sipcore-keep-02)
> 
> One of the consequences of the changes in the current version 
> of keep is as follows. Taking the example in the diagram 
> Christer drew below, we have P1 and P4 on the dialog path, 
> but not P3 and P4. The dialog-forming INVITE transaction 
> follows the path through P1, P2, P3 and P4, so none of the 
> transport connections used for that transaction need to be 
> kept. The only transport connection that needs to be kept is 
> the one from P1 to P4. However, this does not exist yet. So 
> what the draft seems to imply is that, when a transport 
> connection directly between P1 and P4 is established, it 
> needs to be kept alive.
> 
> In an earlier mail, Christer suggested we establish it 
> straight away, just to send the keep-alive, and then, when 
> the first mid-dialog transaction takes place, the connection 
> will be there ready and waiting. This seems wasteful to me. 
> In particular, for some calls the only mid-dialog transaction 
> might be the BYE, so establishing a transport connection 
> early and keeping it alive, just to send the BYE, seems 
> particularly pointless. Of course, other INVITE-initiated 
> dialogs might have more traffic, e.g., UPDATE, INFO, 
> re-INVITE, REFER, PRACK.
> 
> The alternative would be to wait for the first mid-dialog 
> request, and then establish the connection in the normal 
> manner and keep it alive (assuming the transaction is not a BYE).
> 
> But then, we could equally well use Via in the first 
> mid-dialog transaction to signal keep-alive, and in fact that 
> would probably be simpler.
> 
> We seem to have confusion between the dialog-forming 
> transaction and the transaction that establishes connections 
> for the dialog path (the first mid-dialog transaction).
> 
> Finally, we need to say something about dialog termination - 
> there is no point in keeping the path open permanently, 
> except in the context of connection reuse.
> 
> John
> 
> >                                                   --- 
> INVITE -------->          
> _______________________________________________
> sipcore mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sipcore
>

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 16 Apr 2010 09:02:50 +0200

Hi,

Just for my understanding, how would Via be simpler, since it requires the insertion of "=yes" by the adjacent entity in order to work?

Regards,

Christer

> From: Elwell, John [mailto:[email-masked]] 
> Sent: 16. huhtikuuta 2010 9:32
> Subject: RE: [sipcore] Keeping alive connections on a dialog 
> path (was RE: Draft new version: draft-ietf-sipcore-keep-02)
> 
> Sorry, I forgot to mention ACK in the list of mid-dialog 
> requests below. That has specific considerations, as Hadriel 
> has just pointed out on the old thread.
> 
> John 
> 
> > Subject: [sipcore] Keeping alive connections on a dialog 
> path (was RE: 
> > Draft new version: draft-ietf-sipcore-keep-02)
> > 
> > One of the consequences of the changes in the current 
> version of keep 
> > is as follows. Taking the example in the diagram Christer 
> drew below, 
> > we have P1 and P4 on the dialog path, but not P3 and P4. The 
> > dialog-forming INVITE transaction follows the path through 
> P1, P2, P3 
> > and P4, so none of the transport connections used for that 
> transaction 
> > need to be kept. The only transport connection that needs 
> to be kept 
> > is the one from P1 to P4. However, this does not exist yet. So what 
> > the draft seems to imply is that, when a transport 
> connection directly 
> > between P1 and P4 is established, it needs to be kept alive.
> > 
> straight away, 
> > just to send the keep-alive, and then, when the first mid-dialog 
> > transaction takes place, the connection will be there ready and 
> > waiting. This seems wasteful to me.
> > In particular, for some calls the only mid-dialog 
> transaction might be 
> > the BYE, so establishing a transport connection early and 
> keeping it 
> > alive, just to send the BYE, seems particularly pointless. 
> Of course, 
> > other INVITE-initiated dialogs might have more traffic, 
> e.g., UPDATE, 
> > INFO, re-INVITE, REFER, PRACK.
> > 
> request, and 
> > then establish the connection in the normal manner and keep 
> it alive 
> > (assuming the transaction is not a BYE).
> > 
> > But then, we could equally well use Via in the first mid-dialog 
> > transaction to signal keep-alive, and in fact that would 
> probably be 
> > simpler.
> > 
> transaction and 
> > the transaction that establishes connections for the dialog 
> path (the 
> > first mid-dialog transaction).
> > 
> > Finally, we need to say something about dialog termination 
> - there is 
> > no point in keeping the path open permanently, except in 
> the context 
> > of connection reuse.
> > 
> > John
> > 
> > > >>proposal, but on reading the present draft it didn't 
> seem to help 
> > > >>much.
> > > > 
> > > The main problem is that all entities, including those 
> that will not 
> > > be path of the registration/dialog path, insert Via, so when an 
> > > entity receives a request it does not know which Via header 
> > > represents the entity that will be its "neighbour"
> > > Now, when P4 receives the INVITE, how does it know that 
> P1 will be 
> > > its dialog path neighbour (since P2 and P3 do not 
> record-route)? We 
> > > cannot assume that P4 would be able to figure that out by 
> starting 
> > > to compare the Vias with the Record-Routes etc...
> > > 
> > > 
> > > Regards,
> > > 
> > > Christer
> > >

---

From: Hadriel Kaplan <[email-masked]>
Date: Fri, 16 Apr 2010 03:15:46 -0400

> Sent: Friday, April 16, 2010 3:03 AM
> To: Elwell, John; Hadriel Kaplan; [email-masked]
> 
> Hi,
> 
> Just for my understanding, how would Via be simpler, since it requires the
> insertion of "=yes" by the adjacent entity in order to work?

Compared to using several different header types, each used in different cases, and having a bunch of if/else checks and such?  How *isn't* it simpler? 

Setting a received top-most Via param isn't hard is it?  Like the Via "received" param.  

In fact, instead of doing the new Flow-Timer header, just make the "keep" param's value the timer.  So instead of setting it to "yes", it sets it to the number of seconds.

-hadriel

---

From: "Elwell, John" <[email-masked]>
Date: Fri, 16 Apr 2010 09:28:50 +0200

In addition to Hadriel's point, mid-dialog requests do not necessarily contain Record-Route and Contact, but always contain Via. So if we rely on Record-Route and Contact, the decision on keeping connections alive for following the first mid-dialog request would have to be based on retained state from the initial request. Does a record-routing proxy necessarily store Record-route and Contact header fields from the dialog-forming transaction?

John

> From: Hadriel Kaplan [mailto:[email-masked]] 
> Sent: 16 April 2010 08:16
> To: Christer Holmberg; Elwell, John; [email-masked]
> Compared to using several different header types, each used 
> in different cases, and having a bunch of if/else checks and 
> such?  How *isn't* it simpler? 
> 
> In fact, instead of doing the new Flow-Timer header, just 
> make the "keep" param's value the timer.  So instead of 
> setting it to "yes", it sets it to the number of seconds.
> 
> -hadriel
>

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 16 Apr 2010 09:32:57 +0200

Hi,

So, let's look at an example, to make sure I understand you.

An route set has been established, and ACK is sent:

UAC ----------- P1 ----------- UAS

---ACK --------->
---Via: UAC;keep
                ---ACK --------->
                ---Via:P1;keep
                ---Via:UAC;keep=yes

Since there is no reply to ACK, how does the UAS tell P1 that it supports keep-alives?

To make it work, wouldn't we need to require UPDATE or PRACK, so that UAS can send back a response with "Via:P1;keep=yes"?

Regards,

Christer

> Sent: 16. huhtikuuta 2010 10:16
> > Just for my understanding, how would Via be simpler, since 
> it requires 
> > the insertion of "=yes" by the adjacent entity in order to work?
>

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 16 Apr 2010 09:35:46 +0200

Hi, 

>In addition to Hadriel's point, mid-dialog requests do not 
>necessarily contain Record-Route and Contact, but always 
>contain Via. So if we rely on Record-Route and Contact, the 
>decision on keeping connections alive for following the first 
>mid-dialog request would have to be based on retained state 
>from the initial request. Does a record-routing proxy 
>necessarily store Record-route and Contact header fields from 
>the dialog-forming transaction?

I agree that it might not be possible to rely on R-R and Contact in a mid-dialog request. But, the current draft does not require a mid-dialog request.

Regards,

Christer

> > Subject: RE: [sipcore] Keeping alive connections on a 
> dialog path (was 
> > RE: Draft new version: draft-ietf-sipcore-keep-02)
> > 
> > 
> > 
> > it requires the
> > Compared to using several different header types, each used in 
> > different cases, and having a bunch of if/else checks and 
> such?  How 
> > *isn't* it simpler?
> > 
> > Setting a received top-most Via param isn't hard is it?  
> Like the Via 
> > "received" param.
> > 
> > In fact, instead of doing the new Flow-Timer header, just make the 
> > "keep" param's value the timer.  So instead of setting it 
> to "yes", it 
> > sets it to the number of seconds.
> > 
> > -hadriel
> >

---

From: "Elwell, John" <[email-masked]>
Date: Fri, 16 Apr 2010 10:03:16 +0200

Christer,

But the current draft requires retention of state from the dialog initiation request to be used when the first mid-dialog request occurs or, as I think you are suggesting, we establish the connection for the mid-dialog path immediately, in anticipation of the first mid-dialog request.

Example 1: INVITE.
The first mid-dialog request is normally ACK, so following the dialog-forming response to INVITE (e.g., 180), a record-routing proxy establishes a connection to the next record-routing proxy and keeps it alive. When the ACK arrives, the first record-routing proxy knows it can send it over that transport connection. I think this is what you are suggesting.

But what if the first mid-dialog request is UPDATE, sent in the backwards direction (legal without having used PRACK, as long as UPDATE doesn't contain an SDP offer)?

Example 2: SUBSCRIBE or REFER.
The first mid-dialog request is NOTIFY. If the first record-routing proxy establishes a connection to the second record-routing proxy at the time of the SUBSCRIBE response, how does the second record-routing proxy know that this can be used for the NOTIFY request?

Also what if the NOTIFY request reaches the first record-routing proxy before the SUBSCRIBE response?

John

> Sent: 16 April 2010 08:36
> Subject: RE: [sipcore] Keeping alive connections on a dialog path
> 
> 
> Hi, 
> 
> I agree that it might not be possible to rely on R-R and 
> Contact in a mid-dialog request. But, the current draft does 
> not require a mid-dialog request.
> 
> Regards,
> 
> Christer
> 
> 
> 
> make the

---

From: Hadriel Kaplan <[email-masked]>
Date: Fri, 16 Apr 2010 11:42:21 -0400

> Sent: Friday, April 16, 2010 3:33 AM

As I said in my email: it doesn't.  But that's ok.  SIP isn't broken.

> To make it work, wouldn't we need to require UPDATE or PRACK, so that UAS
> can send back a response with "Via:P1;keep=yes"?

No, we don't need to require anything.  The UAS learned P1 supports keep.  If it wants to, it can now send keepalives to P1.  P1 has learned that the UAC supports keep.  If it wants to, it can send keepalives to it.

If the UAC really wants to send keepalive for some reason, it can send a UPDATE, re-INVITE, or OPTIONS at its leisure, to find out about P1.  If P1 really wants to send keepalive for some reason, it can act as a UA of its own and send an out-of-dialog OPTIONS.

That's it.  It's not *broken* - SIP still works, the dialog still exists, etc.  It's just not "optimal" for this specific call-flow scenario, but who cares?!?  Why double the complexity for the common use-cases, just to make it less complex for the rare use-cases??

-hadriel

---

From: Christer Holmberg <[email-masked]>
Date: Sat, 17 Apr 2010 00:30:17 +0200

Hi Hadriel,

>If the UAC really wants to send keepalive for some reason, it can send a UPDATE, re-INVITE, or OPTIONS at its leisure, to find out about P1.  If P1 really wants to send keepalive for some reason, it…

One of the most important use-cases, also documented in the draft, is when the non-registered UAC wants to send keep-alives for a dialog, e.g. for an emergency call. It then needs to know that P1 supports keep-alives.

>That's it.  It's not *broken* - SIP still works, the dialog still exists, etc.  It's just not "optimal" for this specific call-flow scenario, but who cares?!?  Why double the complexity for the comm…

I can agree that it is rare that the UAS would want to negotiate keep-alives for a dialog - because unless the UAS already sends keep-alives (e.g. associated with its registration) the INVITE won't even reach it (assuming the UAS is behind a NAT). So, IF the UAS really wants to negotiate keep-alives for the dialog, IT can send an UPDATE and negotiate the keep-alives with P1. Because, eventhough the UAS may know that P1 supports keep-alives, P1 might want to be informed that the UAS also support them.

BUT, in the example above, replace the UAS with P2. How does P1 know that P2 supports keep-alives? YOU are one of those who wanted to support proxy-to-proxy, so I assume you regard that as an important use-case :)

Regards,

Christer

---

From: Hadriel Kaplan <[email-masked]>
Date: Fri, 16 Apr 2010 18:48:02 -0400

> Sent: Friday, April 16, 2010 6:30 PM
> 
> One of the most important use-cases, also documented in the draft, is when
> the non-registered UAC wants to send keep-alives for a dialog, e.g. for an
> emergency call. It then needs to know that P1 supports keep-alives.

And the UAC is free to send an UPDATE or re-INVITE at anytime of its choosing (well, constrained by when it can send such legally).

And really, if it's a UA making an Emergency call, it's not gonna be using a non-session-stateful proxy as its next-hop, and besides it can and should use SIP session-timers anyway.

Because as long as the next-hop proxy continues to be the one you sent the INVITE to, there's no "issue" with using the Via.  The only case it's not optimal in is when the next-hop is a stateless or transaction-stateful proxy.  If you've got one of those, NAT traversal is going to be tough anyway.

> BUT, in the example above, replace the UAS with P2. How does P1 know that
> P2 supports keep-alives? YOU are one of those who wanted to support proxy-
> to-proxy, so I assume you regard that as an important use-case :)

My personal use case isn't for some random next-hop proxy being used only for the ACK and later messages of one dialog - it would be for either the same proxy that the INVITE went to, or for a longer-lived relationship, or even provisioned.

But anyway, the P1 proxy can send an OPTIONS-ping to find out.

-hadriel

---

From: Christer Holmberg <[email-masked]>
Date: Sat, 17 Apr 2010 01:23:34 +0200

Hi,

>And the UAC is free to send an UPDATE or re-INVITE at anytime of its choosing (well, constrained by when it can send such legally).

I think people would have problems to require the usage of UPDATE and re-INVITE for emergency calls. 

Also, you cannot assume SIP session-timers will be required for emergency calls. However, that is a separate issue.

>And really, if it's a UA making an Emergency call, it's not gonna be using a non-session-stateful proxy as its next-hop, and besides it can and should use SIP session-timers anyway.

The current assumption is that the next hop is an edge proxy, which IS stateful. So, in that case it will be possible to do the keep-alive negotiation as part of the initial INVITE.

(John indicated that the next hop could also be the registrar, so that would also have to be stateful)

>Because as long as the next-hop proxy continues to be the one you sent the INVITE to, there's no "issue" with using the Via.  The only case it's not optimal in is when the 
>next-hop is a stateless or transaction-stateful proxy.  If you've got one of those, NAT traversal is going to be tough anyway.

I agree. 

So, I am happy to keep the assumption that the next hop is stateful.

>My personal use case isn't for some random next-hop proxy being used only for the ACK and later messages of one dialog - it would be for either the same proxy that the INVITE went to, or for a longe…

For proxy-to-proxy I don't think we can make the assumption that the all the proxies that the INVITE traverse will record-route. And, if that is provisioned, you can as well provision the usage of keep-alives - there is no need for a protocol level negotiation...

>But anyway, the P1 proxy can send an OPTIONS-ping to find out.

But, in that case, why not *only* use OPTIONS-ping, then, and leave proxy-to-proxy out of the scope of the keep-draft? I don't think a solution which requires a proxy to send OPTIONS is simple...

Regards,

Christer

---

From: Hadriel Kaplan <[email-masked]>
Date: Sat, 17 Apr 2010 09:08:15 -0400

> Sent: Friday, April 16, 2010 7:24 PM
> 
> >My personal use case isn't for some random next-hop proxy being used only
> >for the ACK and later messages of one dialog - it would be for either the
> >same proxy that the INVITE went to, or for a longer-lived relationship,
> >or even provisioned.
> 
> For proxy-to-proxy I don't think we can make the assumption that the all
> the proxies that the INVITE traverse will record-route. 

Just to be clear, we're not making "assumptions" which affect anything critically.  All we're doing is making assumptions for what the common use-cases of this mechanism are, so we can have a simple mechanism for those cases, while for other cases the devices might need to do more, or else they may not be able to leverage the benefits of this mechanism.  But that's ok.  This mechanism is not fixing something that doesn't work already today.  All it's doing is providing an optimization.  It's a valuable/worth-while optimization, but an optimization nonetheless, and thus we don't need to address every possible scenario under the sun.
Do you agree with that characterization?

> But, in that case, why not *only* use OPTIONS-ping, then, and leave proxy-
> to-proxy out of the scope of the keep-draft? I don't think a solution
> which requires a proxy to send OPTIONS is simple...

The solution does NOT "require" sending an OPTIONS, in the sense that there should be no "MUST" statement to that affect.  It's just something the proxy can do if it wants to learn about the keepalive ability of another proxy.  The reason why a proxy might not want to only use an OPTIONS-ping is performance, that's all.

If you prefer, I'm fine with making the proxy-to-proxy case just a side note of this draft, by saying something like "A Proxy MAY use the keepalive indication of its previous-hop or next-hop to detect that hop supports [outbound] keepalives, and MAY send keepalives to that hop."  Or something like that.  And just keep the focus of the draft the UA case.

-hadriel

---

From: Hadriel Kaplan <[email-masked]>
Date: Sat, 17 Apr 2010 09:22:16 -0400

> >And the UAC is free to send an UPDATE or re-INVITE at anytime of its
> choosing (well, constrained by when it can send such legally).
> 

I think people would have problems with requiring all UAs and all Proxies to support draft-keep.  I'd be fine if that could be done, I just don't see how it reasonably can.  It's a very useful optimization, nothing more.

> Also, you cannot assume SIP session-timers will be required for emergency
> calls. However, that is a separate issue.

And you cannot assume draft-keep will be required or supported for emergency calls either.  There is no easy answer for emergency calls, if the starting premise is any UA in existence making an emergency call through any Proxy in existence, without Registering and without any requirements for what they all must support. :)

If there were some global standard and authority to enforce what every UA must support to make an Emergency call, I would think the ability to send a re-INVITE or UPDATE at periodic intervals during the call should be pretty high on the list.  It's the most likely thing to work. (note that sending re-INVITES or UPDATEs does not actually require support for session-timers in anything)

-hadriel

---

From: Christer Holmberg <[email-masked]>
Date: Sun, 18 Apr 2010 18:51:04 +0200

Hi,

>And you cannot assume draft-keep will be required or supported for emergency calls either.  There is no easy answer for emergency calls, if the starting premise is any UA in existence making an emergency call through any Proxy in existence, without Registering and 
>without any requirements for what they all must support. :)

That's not what I was saying. I was saying that IF a UA supports and uses draft-keep, I don't think they should have to send UPDATE/re-INVITEs for the negotiation of keep-alives. Then, if they send periodic UPDATEs/re-INVITEs in order to keep the session alive is a separate issue. The puropse of keep-alives from UAs is to maintain NAT bindings.

And, for whatever it's worth, at least IMS UEs are required to support draft-keep :)

Regards,

Christer

---

From: Christer Holmberg <[email-masked]>
Date: Sun, 18 Apr 2010 19:11:21 +0200

Hi,

>Just to be clear, we're not making "assumptions" which affect anything critically.  All we're doing is making assumptions for what the common use-cases of this mechanism are, so we can have a simple mechanism for those cases, while for other cases the devices might need 
>o do more, or else they may not be able to leverage the benefits of this mechanism.  But that's ok.  This mechanism is not fixing something that doesn't work already today.  All it's doing is providing an optimization.  It's a valuable/worth-while optimization, but an 
>optimization nonetheless, and thus we don't need to address every possible scenario under the sun.

Are we assuming that there will be no proxy between the UA and edge proxy? I believe Outbound makes that assumption.

IF we make that assumption, the UA and edge proxy will be able to negotiate the keep-alive as part of the initial INVITE. No need for UPDATEs/re-INVITE.

IF we do NOT make that assumption, the UA will have to send UPDATE/re-INVITEs, because there MAY be another proxy between the UA and edge proxy.

I think we both agree that the most common use-case will be when there is no other proxy between the UA and edge proxy. But, we don't optimize the solution for that use-case if the UA needs to send UPDATE/re-INVITE in order to support the proxy-in-between use-case...

>The solution does NOT "require" sending an OPTIONS, in the sense that there should be no "MUST" statement to that affect.  It's just something the proxy can do if it wants to learn about the keepalive ability of another proxy.  The reason why a proxy might not want to 
>only use an OPTIONS-ping is performance, that's all.
>
>If you prefer, I'm fine with making the proxy-to-proxy case just a side note of this draft, by saying something like "A Proxy MAY use the keepalive indication of its previous-hop or next-hop to detect that hop supports [outbound] keepalives, and MAY send keepalives to 
>that hop."

Yes. But, then we need to describe that the proxies will not be able to negotiate the keep-alives during the initial INVITE, and that they need to wait for a UA to send UPDATE/re-INVITE before they can negotiate keep-alives.

>Or something like that.  And just keep the focus of the draft the UA case.

Also keep in mind that keep-alives negotiated for a dialog will only be sent within that dialog. So, the question is whether people are interested in such proxy-to-proxy functionality in the first place? From what I've heard people are looking for a more "static" ping, not associated with a dialog - something which option-ping provides.

Regards,

Christer