Subject: [Sip] keep-alive backwards compatibility in draft-ietf-sip-outbound-12.txt

From: Jiri Kuthan <[email-masked]>
Date: Mon, 03 Mar 2008 19:52:43 +0100

I'm just wondering if folks have been worried about the UACs that implement
the aforementioned I-D and talk to a proxy/UAS that doesn't do so?

It appears to me that mandating a reconnect on lacking PONG would lead
to quite heavy traffic.

(which is why without deeper knowledge of the history of this I-D, I would
be inclined to rely on TCP's keep-alive, which is in there)

-jiri

--
Jiri Kuthan            http://iptel.org/~jiri/

_______________________________________________
Sip mailing list  https://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: "Francois Audet" <[email-masked]>
Date: Wed, 5 Mar 2008 19:00:33 -0600

Jiri,

On p.15 it is explained that the UAC looks at the presence of
the Require: outbound field falue in a response to registration.

This is to ensure that both the registrar and the edge proxy are
compliant with this spec. The keep-alive would only be sent if
present.

Please suggest improved wording if you feel it is not clear enough. 

On the TCP keep-alive issue: this has been investigated in previous versions
of the draft. It was dropped because of the fact that changing the TCP keep-alive
is often a system-wide setting on most Operating Systems.

Rohan, we use to have some words about this in the spec, but I think it's all
gone from this version. Maybe the note should have been left here...

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Jiri Kuthan
> Sent: Monday, March 03, 2008 10:53
> To: [email-masked]
> Subject: [Sip] keep-alive backwards compatibility in 
> draft-ietf-sip-outbound-12.txt
> 
> I'm just wondering if folks have been worried about the UACs 
> that implement the aforementioned I-D and talk to a proxy/UAS 
> that doesn't do so?
> 
> It appears to me that mandating a reconnect on lacking PONG 
> would lead to quite heavy traffic.
> 
> (which is why without deeper knowledge of the history of this 
> I-D, I would be inclined to rely on TCP's keep-alive, which 
> is in there)
> 
> -jiri
> 
> 
> 
> --
> This list is for NEW development of the core SIP Protocol Use 
> [email-masked] for questions on current sip

---

From: "Christer Holmberg" <[email-masked]>
Date: Thu, 6 Mar 2008 09:25:06 +0100

Hi,

I have big issues with the keep-alive change in the -12 version.

Because, now the STUN keep-alives usage can't be applied between the UA
and outbound proxy, unless the registrar supports outbound.

I strongly think it should be possible to use STUN keep-alives for
"pure" signalling NAT traversal, even if the "rest" of outbound is not
used.

So, while I DO agree with the Vancouver(?) decission to not include any
"URI" keep parameter in the R-URI of the register request, I think we
shall we keep the URI "keep" parameter definition, and e.g. allow it to
be inserted into the Path header (I don't remember any discussions
regarding removing that possibility) by the outbound proxy, in order to
inform the UA that the outbound proxy supports STUN keep-alive.

(OR, there should be another mechanism for the outbound proxy to inform
the UA it supports STUN keep-alive)

That would allow people to start using outbound for NAT traversal, even
if the registrars haven't yet been updated to support outbound etc.

At one point we decided that we will keep the STUN keep-alive usage and
outbound in the same spec, but that we will describe the STUN keep-alive
usage as a "stand alone" function (chapter 8 of the draft). But, now you
have more or less "merged" the STUN keep-alive usage with the outbound
function, and that is bad.

Also, this change is not mentioned in the
changes-since-the-previous-version part (if it is mentioned, I
appologize for having missed it)

Regards,

Christer

---

From: "Xavier Marjou" <[email-masked]>
Date: Thu, 6 Mar 2008 17:24:12 +0100

Hi,

I support Christer's point of view.

Cheers,
Xavier

---

From: Rohan Mahy <[email-masked]>
Date: Thu, 6 Mar 2008 08:42:55 -0800

Hi Jiri,

There are two issues here.  negotiation of the outbound registration  
mechanism, and keepalive usage.

OUTBOUND NEGOTIATION - This normative text on this is currently split  
across each role, so here is a summary:
A UAC registers and indicates support for the outbound extension by  
advertising the outbound option-tag in its Supported header, and it  
requests an outbound-style registration by including a reg-id and  
instance-id.

The first-hop sees the reg-id and instance-id in a registration  
request and adds a Path header with a flow token and an 'ob' URI  
parameter.

It might go through other proxies, but we don't care.

The registrar (which is a UA) gets the request, checks that there is  
a reg-id and instance-id in the Contact, an 'ob' parameter in the  
first Path header field value, and 'outbound' in the Supported  
header.  It uses outbound-style bindings instead of RFC3261-style  
bindings for this UA instance. It returns a registration response  
with 'outbound' in its Require header.

Any intervening proxies forward the response on its merry way back to  
the UAC.  The first-hop proxy MAY add a Flow-Timer header if, and  
only if, the response has Require: outbound in it.

The UAC receives the successful registration response.  It can tell  
that outbound registration was successful since there is an outbound  
option-tag in the Require header.

<note>No bullets for the fish here, Dean.</note>

KEEPALIVE USAGE

When using keepalives for outbound, you start sending keepalives  
after a successful outbound registration.  This is safe since the  
first hop proxy already demonstrated outbound support by inserted on  
'ob' parameter, and proxies which do this are required to support  
both keepalive methods

from Section 4.2.1
>  If outbound registration succeeded, as indicated by the presence  
> of the outbound option-tag in the Require header field of a  
> successful registration response, the UA begins sending keepalives  
> as described in Section 4.4 (Keep-alives and Detecting Flow Failure).

Also, in case you think the text isn't strong enough we have these do  
no harm admonitions in the standalone STUN keepalive section.

from Section 8
> Because sending and receiving binary STUN data on the same ports  
> used for SIP is a significant and non-backwards compatible change  
> to RFC 3261, this section requires a number of checks before  
> sending STUN messages to a SIP node. If a SIP node sends STUN  
> requests (for example due to incorrect configuration) despite these  
> warnings, the node could be blacklisted for UDP traffic.
>
> A SIP node MUST NOT send STUN requests over a flow unless it has an  
> explicit indication that the target next hop SIP server claims to  
> support this specification. Note that UACs MUST NOT use an  
> ambiguous configuration option such as "Work through NATs?" or "Do  
> Keep alives?" to imply next hop STUN support.
>
>     Typically, a SIP node first sends a SIP request and waits to  
> receive a 200-class response over a flow to a new target  
> destination, before sending any STUN messages. When scheduled for  
> the next NAT refresh, the SIP node sends a STUN request to the target.

As for "native-transport" keepalives, this was explanatory text and  
was cluttering the flow so we trimmed it down, but it is still there:

Section 3.5
> UAs are also free to use native transport keep alives, however the  
> UA application may not be able to set these timers on a per- 
> connection basis, and the server certainly cannot make any  
> assumption about what values are used. Use of native transport keep  
> alives is therefore outside the scope of this document.

So, if either the first-hop or the registrar didn't support outbound,  
the UAC won't send keepalives unless it has some out-of-band  
configuration that its next hop supports them.

Hope this helps.

thanks,
-rohan

---

From: "Christer Holmberg" <[email-masked]>
Date: Thu, 6 Mar 2008 18:46:48 +0100

Hi Rohan, 

>>>Because, now the STUN keep-alives usage can't be applied between the 
>>>UA  and outbound proxy, unless the registrar supports outbound.
> 
>What gave you that impression Christer?  By my read that is 
>still allowed if the UA has explicit configuration that its 
>next-hop support keepalives:

Of course, but previously we had a mechanism for the outbound proxy to
actually indicate support.

Also, chapter 8 of the draft does say:

"A SIP node MUST NOT send STUN requests over a flow unless it has an
explicit indication that the target next hop SIP server claims to
support this specification.  Note that UACs MUST NOT use an ambiguous
configuration option such as "Work through NATs?" or "Do Keep
alives?" to imply next hop STUN support."

>>Because sending and receiving binary STUN data on the same ports used 
>>for SIP is a significant and non-backwards compatible change to RFC 
>>3261, this section requires a number of checks before sending STUN 
>>messages to a SIP node. If a SIP node sends STUN requests 
>>(for example due to incorrect configuration) despite these warnings,
the 
>>node could be blacklisted for UDP traffic.
>>
>>support this specification. Note that UACs MUST NOT use an ambiguous 
>>configuration option such as "Work through NATs?" or "Do Keep alives?"

>>to imply next hop STUN support.
>>
>>receive a 200-class response over a flow to a new target destination, 
>>before sending any STUN messages. When scheduled for the next NAT 
>>refresh, the SIP node sends a STUN request to the target.
> 
> 
>>>"pure" signalling NAT traversal, even if the "rest" of outbound is 
>>>not  used.
>>>
>>>So, while I DO agree with the Vancouver(?) decission to not include 
>>>any  "URI" keep parameter in the R-URI of the register request, I 
>>>think we  shall we keep the URI "keep" parameter definition, and e.g.

>>>allow it to  be inserted into the Path header (I don't remember any 
>>>discussions  regarding removing that possibility) by the outbound 
>>>proxy, in order to  inform the UA that the outbound proxy supports 
>>>STUN keep-alive.
>>>
>>>(OR, there should be another mechanism for the outbound proxy to 
>>>inform  the UA it supports STUN keep-alive)
> 
>Currently, that other mechanism is out-of-band configuration. 
>We could also add another way to indicate this in the 
>future, but for know the WG seems happy with what we have.

I don't understand "add in future". We already had a mechanism. 

This is what you, me and Cullen were discussing a long time ago, and we
all agreed to :)

One thing we in Vancouver DID agree to was that a mechanism to also
indicate the keep-alive refresh timer value WOULD be a future extension.

Regards,

Christer

> >>  That would allow people to start using outbound for NAT 
> traversal, 
> >> even  if the registrars haven't yet been updated to 
> support outbound 
> >> etc.
> >>
> >>  At one point we decided that we will keep the STUN 
> keep-alive usage 
> >> and  outbound in the same spec, but that we will describe the STUN 
> >> keep-alive  usage as a "stand alone" function (chapter 8 of the 
> >> draft). But, now you  have more or less "merged" the STUN 
> keep-alive 
> >> usage with the outbound  function, and that is bad.
> >>
> >> [email-masked] for questions on current sip  Use 
> >> [email-masked] for new developments on the application of sip
> >>
> 
>

---

From: Rohan Mahy <[email-masked]>
Date: Thu, 6 Mar 2008 10:28:12 -0800

> alives?" to imply next hop STUN support."

That text has been there for ages.  That is not new.

>>> used
>>> alives?"
>>> destination,

I'm pretty sure we had rough consensus to remove the parameter  
completely. I'll go dig up my notes and the minutes.  Maybe Francois  
can jump in here.

thanks,
-rohan

---

From: "Christer Holmberg" <[email-masked]>
Date: Thu, 6 Mar 2008 19:38:05 +0100

Hi, 

>>>>>Because, now the STUN keep-alives usage can't be applied between 
>>>>>the UA  and outbound proxy, unless the registrar supports outbound.
>>>
>>>What gave you that impression Christer?  By my read that is still 
>>>allowed if the UA has explicit configuration that its next-hop 
>>>support keepalives:
>>

>>configuration option such as "Work through NATs?" or "Do 
>>Keep alives?" to imply next hop STUN support."
> 

Exactly - so therfor I don't think the explicit configuration you
propose is appropriate :)

>completely. I'll go dig up my notes and the minutes.  Maybe Francois  

Maybe the problem is that we only discussed the usage of the parameter
in the R-URI, and when we agreed not to use it there we forgot that it
could actually be used in the Path header.

Regards,

Christer

---

From: Jiri Kuthan <[email-masked]>
Date: Thu, 06 Mar 2008 22:58:38 +0100

I have to admit this was too complicated for me too understand. So basically
UAC advertises downstream its semi-transport-level keep-alive capability (CRLF/STUN)
by the way of app-level negotitation (reg-id), the downstream entity (say
a proxy-based load-balancer) signals its support for it by adding PATH/ob,
and the registrar UAS signals load-balancer's support by Require:outbound?

So specifically if the registrar doesn't turn PATH/ob into 200/Require/outbound,
client shall not do ping-pong keep-alive to its load-balancer?

If that's what it is, I understood the point now. 

Can someone explain to me what is the benefit of mixing transport-level natping
functionality with application-level capabilty negotiation? My appologies if this
has been discussed in past years of outbound, but it is really hard to understand
for me. 

Thanks!

-jiri

At 19:04 06/03/2008, Dean Willis wrote:

>I think we had a stale address for Jiri on this thread.
>
>He's been using [email-masked] recently, and I'm getting no DNS hit on
>fokus.
>
>
>
>Dean Willis wrote:
>> 
>> On Mar 5, 2008, at 7:00 PM, Francois Audet wrote:
>> 
>>> Jiri,
>>>
>> I'm going to have to go study this, because ordinarily Require has
>> nothing to do with the edge proxy (which would have been only looking at
>> Proxy-Require), and it's pretty much meaningless in responses anyhow --
>> it's only processed in requests AFAIK.
>> 
>> I think we're trying to catch fish with a bullet again.
>> 
>> -- 
>> Dean
>>

---

From: "Francois Audet" <[email-masked]>
Date: Thu, 6 Mar 2008 16:45:00 -0600

Yes, we had agreed to remove keep altogether.

Using parameters for the job of something that logically belongs to
configuration is futile and harmful as it would result in infinite-length 
URIs or other field.

I can also garantee that everybody that presents a concept will somehow
believe that this particular concept is worthy of being a parameter
while the other guy's concept is inferior and doesn't warrant it.

I think the point of the text was that it shouldn't be an AMBIGUOUS
parameter, but instead a EXPLICIT parameter.

So, this paragraph is completely accurate:
	A SIP node MUST NOT send STUN requests over a flow unless 
      it has an explicit indication that the target next hop SIP server 
      claims to support this specification. Note that UACs MUST NOT use 
      an ambiguous configuration option such as "Work through NATs?" or "Do 
      Keep alives?" to imply next hop STUN support.

But it would be clearer if we added the following sentence at the end:
	Rather than an ambiguous configuration option, it MUST be an explicit
      configuration such as "Server supports RFC XXX CRLF keep-alives? 
      without RFC XXX registration procedures?".

I really do believe that a parameter "on the wire" for such a corner case 
(i.e., "I want to do outbound, but just the keep-alive") is absolutely 
not warranted.

> From: Christer Holmberg [mailto:[email-masked]] 
> Sent: Thursday, March 06, 2008 10:38
> To: Rohan Mahy
> Cc: Xavier Marjou; Audet, Francois (SC100:3055); 
> [email-masked]; Cullen Jennings
> Subject: RE: [Sip] Outbound-12: STUN keep-alives without outbound
> 
> 
> Hi, 
> 
> ambiguous 
> Exactly - so therfor I don't think the explicit configuration 
> you propose is appropriate :)
> 
> Maybe the problem is that we only discussed the usage of the 
> parameter in the R-URI, and when we agreed not to use it 
> there we forgot that it could actually be used in the Path header.
> 
> Regards,
> 
> Christer
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> future, but 
> > >> for know the WG seems happy with what we have.
> > >
> > > This is what you, me and Cullen were discussing a long 
> time ago, and 
> > > we all agreed to :)
> > >

---

From: "Francois Audet" <[email-masked]>
Date: Thu, 6 Mar 2008 16:54:16 -0600

Yeah, this is quite obscure (but I think Jiri's description is
overly complex).

I *think* that what we should say somewhere is the following:

- If this specification is supported by the registrar (as per presence of
  the Require: outbound in the 200 response to the Registration, then
  the UAC MUST do keep-alives as per section X.Y.

- In the keep-alive section, we could explain that while the keep alive
  described in this section were defined to be used by environments that
  supports this specification (Dhuh), using keep-alives in environments 
  registration as per this specification are not supported (explain how
  this is detected), is allowed if there is EXPLICIT knowledge that it is
  supported (as per the current text).

> From: Jiri Kuthan [mailto:[email-masked]] 
> Sent: Thursday, March 06, 2008 13:59
> To: Dean Willis; Dean Willis
> Cc: Audet, Francois (SC100:3055); Rohan Mahy; [email-masked]
> Subject: Re: [Sip] keep-alive backwards compatibility in 
> I have to admit this was too complicated for me too 
> understand. So basically UAC advertises downstream its 
> semi-transport-level keep-alive capability (CRLF/STUN) by the 
> way of app-level negotitation (reg-id), the downstream entity 
> (say a proxy-based load-balancer) signals its support for it 
> by adding PATH/ob, and the registrar UAS signals 
> load-balancer's support by Require:outbound?
> 
> So specifically if the registrar doesn't turn PATH/ob into 
> 200/Require/outbound, client shall not do ping-pong 
> keep-alive to its load-balancer?
> 
> Can someone explain to me what is the benefit of mixing 
> transport-level natping functionality with application-level 
> capabilty negotiation? My appologies if this has been 
> discussed in past years of outbound, but it is really hard to 
> understand for me. 
> 
> Thanks!
> 
> -jiri
> 
> 
> >>> On p.15 it is explained that the UAC looks at the presence of the 
> >>> Require: outbound field falue in a response to registration.
> >> 
> >> nothing to do with the edge proxy (which would have been 
> only looking 
> >> at Proxy-Require), and it's pretty much meaningless in responses 
> >> anyhow -- it's only processed in requests AFAIK.
> >>

---

From: Dean Willis <[email-masked]>
Date: Thu, 6 Mar 2008 21:24:14 -0600

>  the UAC MUST do keep-alives as per section X.Y.

That can't be quite right. The registrar might support keepalive, but  
the edge proxy might not.

I believe Rohan's explanation indicated that the Require: outbound  
would only be in the 200 OK response to REGISTER if both the edge  
proxy and the registrar support it.

So using your terminology:

  If this specification is supported by the UAC, the edge proxy (if  
present) and the registrar, then there will be a Require: outbound in  
the 200 response to the Registration indicating that
  the UAC MUST do keep-alives as per section X.Y.

--
Dean

---

From: "Francois Audet" <[email-masked]>
Date: Thu, 6 Mar 2008 22:13:08 -0600

That works for me. 

> From: Dean Willis [mailto:[email-masked]] 
> Sent: Thursday, March 06, 2008 19:24
> To: Audet, Francois (SC100:3055)
> Cc: Jiri Kuthan; Rohan Mahy; [email-masked]
> > Yeah, this is quite obscure (but I think Jiri's description 
> is overly 
> > complex).
> >
> > - If this specification is supported by the registrar (as 
> per presence 
> > of  the Require: outbound in the 200 response to the Registration, 
> > then  the UAC MUST do keep-alives as per section X.Y.
> 
> That can't be quite right. The registrar might support 
> keepalive, but the edge proxy might not.
> 
> I believe Rohan's explanation indicated that the Require: 
> outbound would only be in the 200 OK response to REGISTER if 
> both the edge proxy and the registrar support it.
> >
> 
> present) and the registrar, then there will be a Require: 
> outbound in the 200 response to the Registration indicating that

---

From: "Christer Holmberg" <[email-masked]>
Date: Fri, 7 Mar 2008 08:46:55 +0100

Francois,

I am not following you...

Why do we then need the "ob" parameter? Why should the outbound proxy
"on the wire" be able to say "I want to do outbound"?

Why not simply use configuration?

And, the parameter would NOT say "I want to do outbound, but just the
keep-alive". It would say "I want to do keep-alive", which we along time
ago agreed is a stand-alone function, and not part of outbound itself. I
don't remember any change of that decission.

Also, I don't agree this is a "corner case". STUN keep-alive is pretty
much the only signalling keep-alive mechanism we have specified for SIP,
and there are people who want to use it for that.

Regards,

Christer

> From: Francois Audet [mailto:[email-masked]] 
> Sent: 7. maaliskuuta 2008 0:45
> To: Christer Holmberg; Rohan Mahy
> Cc: Xavier Marjou; [email-masked]; Cullen Jennings
> Using parameters for the job of something that logically 
> belongs to configuration is futile and harmful as it would 
> result in infinite-length URIs or other field.
> 
> I can also garantee that everybody that presents a concept 
> will somehow believe that this particular concept is worthy 
> of being a parameter while the other guy's concept is 
> inferior and doesn't warrant it.
> 
> I think the point of the text was that it shouldn't be an 
> AMBIGUOUS parameter, but instead a EXPLICIT parameter.
> 
>       an ambiguous configuration option such as "Work through 
> NATs?" or "Do >       Keep alives?" to imply next hop STUN support.
> 
> I really do believe that a parameter "on the wire" for such a 
> corner case (i.e., "I want to do outbound, but just the 
> keep-alive") is absolutely not warranted.
> 
>  
> 
> > >>>>>think we  shall we keep the URI "keep" parameter 
> definition, and 
> > >>>>>e.g.
> > >

---

From: "Christer Holmberg" <[email-masked]>
Date: Fri, 7 Mar 2008 09:52:04 +0100

Hi,

An alternative solution, based on "ob", and which does not require
"keep", would be to add something like the following:

"When the UA receives a 200 OK response to a REGISTER message, it can
deduce that outbound keepalives and flows can be used if there either is
an "outbound" options-tag in a Supported or Requires header, or in lack
of this, if the URI in the path header contains the "ob" URI parameter."

Now, if there is no Supported/Require with "outbound" the UA knows that
the registrar does not support outbound, but since the Path header
contains "ob" the UA knows that the outbound proxy supports it, and that
it supports keep-alives.

This would of course require an outbuond proxy who only wants to do
keep-alive to implement "full" outbound, but it would at least be
possible to use keep-alives between the UA and the outbound proxy even
if the registrar does not support outbound.

Does that sound feasible?

Regards,

Christer

> Behalf Of Christer Holmberg
> Sent: 7. maaliskuuta 2008 9:47
> To: Francois Audet; Rohan Mahy
> Cc: [email-masked]; Cullen Jennings; Xavier Marjou
> Subject: Re: [Sip] Outbound-12: STUN keep-alives without outbound
> 
> 
> Francois,
> 
> Why do we then need the "ob" parameter? Why should the 
> outbound proxy "on the wire" be able to say "I want to do outbound"?
> 
> And, the parameter would NOT say "I want to do outbound, but 
> just the keep-alive". It would say "I want to do keep-alive", 
> which we along time ago agreed is a stand-alone function, and 
> not part of outbound itself. I don't remember any change of 
> that decission.
> 
> Also, I don't agree this is a "corner case". STUN keep-alive 
> is pretty much the only signalling keep-alive mechanism we 
> have specified for SIP, and there are people who want to use 
> it for that.
> 
> Regards,
> 
> Christer
> 
> 
> > configuration is futile and harmful as it would result in 
> > infinite-length URIs or other field.
> > 
> > I can also garantee that everybody that presents a concept will 
> > somehow believe that this particular concept is worthy of being a 
> > parameter while the other guy's concept is inferior and doesn't 
> > warrant it.
> > 
> > I really do believe that a parameter "on the wire" for such 
> a corner 
> > case (i.e., "I want to do outbound, but just the
> > > Cc: Xavier Marjou; Audet, Francois (SC100:3055); [email-masked]; 
> > > Cullen Jennings
> > > parameter in the R-URI, and when we agreed not to use it there we 
> > > forgot that it could actually be used in the Path header.
> > > 
> > > Regards,
> > > 
> > > Christer
> > > 
> > > 
> > > 
> > > 
> > > 
> > > 
> > > 
> > > 
> > > 
> > > 
> > > > >>>>  Sip mailing list  
> https://www.ietf.org/mailman/listinfo/sip

---

From: Rohan Mahy <[email-masked]>
Date: Fri, 7 Mar 2008 07:15:19 -0800

Hi Christer,

The edge proxy is only supposed to add the ob parameter to the Path  
if the edge proxy included a flow token in the path URI.  This should  
only happen when the UA included a reg-id and instance-id parameter  
in its Contact header.

thanks,
-rohan

---

From: "Christer Holmberg" <[email-masked]>
Date: Fri, 7 Mar 2008 19:59:13 +0100

Hi Rohan, 

>The edge proxy is only supposed to add the ob parameter to 
>the Path if the edge proxy included a flow token in the path 
>URI.  This should only happen when the UA included a reg-id 
>and instance-id parameter in its Contact header.

Correct. But, the point is that the UA would then still be "allowed" to
use STUN keep-alive between itself and the outbound proxy, even if the
registrar doesn't support outbound.

Regards,

Christer

> > deduce that outbound keepalives and flows can be used if 
> there either 
> > is an "outbound" options-tag in a Supported or Requires 
> header, or in 
> > lack of this, if the URI in the path header contains the "ob" URI 
> > parameter."
> >
> > Now, if there is no Supported/Require with "outbound" the UA knows 
> > that the registrar does not support outbound, but since the Path 
> > header contains "ob" the UA knows that the outbound proxy 
> supports it, 
> > and that it supports keep-alives.
> >
> >> From: [email-masked] [mailto:[email-masked]] 
> On Behalf Of 
> >> Christer Holmberg
> outbound proxy 
> >> keep-alive". It would say "I want to do keep-alive", which 
> we along 
> >> time ago agreed is a stand-alone function, and not part of 
> outbound 
> >> itself. I don't remember any change of that decission.
> >>
> >> Also, I don't agree this is a "corner case". STUN keep-alive is 
> >> pretty much the only signalling keep-alive mechanism we have 
> >> specified for SIP, and there are people who want to use it 
> for that.
> >>
> >> Regards,
> >>
> >> Christer
> >>
> >>
> belongs to 
> AMBIGUOUS 
> >>>       claims to support this specification. Note that 
> UACs MUST NOT 
> >>> use
> there we

---

From: "Christer Holmberg" <[email-masked]>
Date: Sat, 8 Mar 2008 04:22:09 +0100

Hi Dean,
 
>> Correct. But, the point is that the UA would then still be "allowed" 
>> to use STUN keep-alive between itself and the outbound proxy, even if the
>So I think you're saying that we've gotten the decision as to whether 
>to use keepalive between the UA and the edge proxy tangled up with 
>whether or not we use the outbound-style persistent binding at the 
>registrar?

Yes.

>Perhaps if the keepalive negotiation were independent of outbound, it 
>would work better for you.

Well, that is what I initially said in this thread, and what I believe we already did have before Outbound-12: the outbound proxy was able to insert the "keep" parameter in the Path header to indicate support of keep-alive...

I think that the UA relying on configuration whether the outbound proxy supports keep-alive or not is never going to work - especially not in mobile environments...

Regards,

Christer

---

From: Dean Willis <[email-masked]>
Date: Fri, 7 Mar 2008 15:33:40 -0600

On Mar 7, 2008, at 12:59 PM, Christer Holmberg wrote:

> to

--
Dean

---

From: Hadriel Kaplan <[email-masked]>
Date: Sat, 8 Mar 2008 11:04:15 -0500

I agree with Christer: I thought the keep-alive indication was staying too, and that it was the timer part that was out.  The keep-alive mechanism is really independent of the rest of outbound.  It could have been a separate draft even.  While I like the overall outbound extension, there are plenty of people supporting endpoints behind NATs today, for whom the new keep-alive mechanism would be very useful by itself while the rest of outbound is not.

I do agree with a point someone made about going down a slippery-slope of separating individual behaviors of extensions being a bad idea in general.  But there's always a judgment call that has to be made based on what we think people will want and what it useful, and personally I think keep-alive fits that bill.

Otherwise I am fairly confident we will see the "proxies" lying about outbound support to the endpoints, simply to get the keep-alive behavior from them.

-hadriel

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Christer Holmberg
> Sent: Friday, March 07, 2008 10:22 PM
> To: Dean Willis
> Cc: [email-masked]; Rohan Mahy; Francois Audet; Xavier Marjou; Cullen
> Jennings
> Well, that is what I initially said in this thread, and what I believe we
> already did have before Outbound-12: the outbound proxy was able to insert
> the "keep" parameter in the Path header to indicate support of keep-
> alive...
>
> I think that the UA relying on configuration whether the outbound proxy
> supports keep-alive or not is never going to work - especially not in
> mobile environments...
>
> Regards,
>
> Christer
>
>
>

---

From: "Francois Audet" <[email-masked]>
Date: Sat, 8 Mar 2008 12:51:56 -0600

We voted on the "issue". This is a done deal. 

> Sent: Thursday, March 06, 2008 23:47
> To: Audet, Francois (SC100:3055); Rohan Mahy

---

From: "Francois Audet" <[email-masked]>
Date: Sat, 8 Mar 2008 13:14:51 -0600

Can someone explain to me just how you can make Keep-Alives work without
the rest of outbound????

> Sent: Friday, March 07, 2008 13:34
> To: Christer Holmberg
> Cc: Rohan Mahy; [email-masked]; Cullen Jennings; Audet, 
> Francois (SC100:3055); Xavier Marjou
> the Path 
> So I think you're saying that we've gotten the decision as to 
> whether to use keepalive between the UA and the edge proxy 
> tangled up with whether or not we use the outbound-style 
> persistent binding at the registrar?
> 
> Perhaps if the keepalive negotiation were independent of 
> outbound, it would work better for you.
> 
> --
> Dean
> 
>

---

From: "Francois Audet" <[email-masked]>
Date: Sat, 8 Mar 2008 13:20:27 -0600

> Well, that is what I initially said in this thread, and what 
> I believe we already did have before Outbound-12: the 
> outbound proxy was able to insert the "keep" parameter in the 
> Path header to indicate support of keep-alive...

I checked the meeting notes from IETF 70, and we had "a strong
concensus to remove the keep parameter".

I don't see why we are still discussing this topic.

---

From: Hadriel Kaplan <[email-masked]>
Date: Sat, 8 Mar 2008 14:44:55 -0500

Surely you don't think SIP deployments today don't support NAT traversal for clients, or that they need outbound to do so?

But anyway, here's one way (for UDP): client sends Register or Options to proxy, including the rport Via param (rfc3581).  Servers sets the received/rport params in response. Client sees received and rport params in response, and uses the address/port for its Contact for a new Register.  Client also sets keep param, and server responds, so that client can use STUN to keep the NAT binding open.

-hadriel

> Francois Audet
> Sent: Saturday, March 08, 2008 2:15 PM
> To: Dean Willis; Christer Holmberg
> Cc: [email-masked]; Rohan Mahy; Xavier Marjou; Cullen Jennings

---

From: "Christer Holmberg" <[email-masked]>
Date: Sun, 9 Mar 2008 12:25:02 +0100

Francois,

What about my proposal of allowing STUN keep-alive between the UA and
outbound proxy, even if the registrar does not support it?

That does NOT require the usage of "keep". The UA only checks whether
the outbound proxy has inserted "ob" in the Path header.

Regards,

Christer 

> Sent: 8. maaliskuuta 2008 21:20
> To: Christer Holmberg; Dean Willis
> > Well, that is what I initially said in this thread, and 
> what I believe 
> > we already did have before Outbound-12: the outbound proxy 
> was able to 
> > insert the "keep" parameter in the Path header to indicate 
> support of 
> > keep-alive...
> 
> I checked the meeting notes from IETF 70, and we had "a 
> strong concensus to remove the keep parameter".
>

---

From: Aki Niemi <[email-masked]>
Date: Sun, 09 Mar 2008 13:30:59 +0200

On la, 2008-03-08 at 04:22 +0100, ext Christer Holmberg wrote:
> Well, that is what I initially said in this thread, and what I believe
> we already did have before Outbound-12: the outbound proxy was able to
> insert the "keep" parameter in the Path header to indicate support of
> keep-alive...

The 'keep' was removed because it's *completely* useless. The client
discovers outbound support via 'ob' in the Path. If it's using UDP
flows, it uses STUN; if it has TCP flows, it uses CRLF.

Apparently 'ob' doesn't work for you, because you want to use the
keepalive parts and not full outbound. But I object to holding up
progress on this draft just because you need to piggyback a parameter on
a standards track document for some other purpose. 

Please write a draft and let's move on.

Cheers,
Aki

---

From: "Christer Holmberg" <[email-masked]>
Date: Sun, 9 Mar 2008 12:38:19 +0100

Hi, 

>The 'keep' was removed because it's *completely* useless. The 
>client discovers outbound support via 'ob' in the Path. If 
>it's using UDP flows, it uses STUN; if it has TCP flows, it uses CRLF.

Again, that is what I have proposed as an alternative. I have said that
the UA should be allowed, when it sees the "ob" parameter in the Path,
to use keep-alive even if the registrar does not support outbound.

>Apparently 'ob' doesn't work for you, because you want to use the
keepalive parts and not full outbound.

See above.

Regards,

Christer

---

From: Aki Niemi <[email-masked]>
Date: Sun, 09 Mar 2008 14:16:03 +0200

> to use keep-alive even if the registrar does not support outbound.

What's there to stop it from doing just that?

Cheers,
Aki

---

From: "Christer Holmberg" <[email-masked]>
Date: Sun, 9 Mar 2008 14:29:02 +0100

Hi, 

>>Again, that is what I have proposed as an alternative. I have said 
>>that the UA should be allowed, when it sees the "ob" 
>>parameter in the Path, to use keep-alive even if the registrar does
not 
>>support outbound.

Nothing, as far as I know.

I am only asking for some clarification text.

The draft currently says:

"The UAC examines successful registration responses for the presence
of an 'outbound' option-tag in a Require header field value.
Presence of this option-tag indicates that the registrar is compliant
with this specification, and that any edge proxies which needed to
participate are also compliant."

So, I think it would be good to add something like:

"If the registrar did not support outbound, but there was a path header
with the edge proxy URI
present in the 200 OK response to the REGISTER message, the UAC may
check 
whether the URI-parametyer "ob" is included in the URI. If so, then the
UAC knows that
outbound keepalives can be used even though the registrar does not
support outbound."

So, it's just a clarification...

Regards,

Christer

---

From: "Xavier Marjou" <[email-masked]>
Date: Sun, 9 Mar 2008 16:49:41 +0100

It would be great if the only thing to do could be to add such a
precision. This would encourage the incremental deployment of some
outbound draft features even if the registrar does not support
outbound.

Xavier

---

From: Cullen Jennings <[email-masked]>
Date: Sun, 9 Mar 2008 16:01:59 -0400

I'm not saying the draft is right or wrong with regards to keep alive.  
We have not had any new information about requirements for keep alive  
than what we have 2 or more years ago. But, every single meeting we  
seem to change the keep alive mechanism. In many meetings we achieved  
strong consensus on how it should work, then a very few people on the  
list have argued for something different and we have changed it. We  
will never finish if we keep doing this.

Cullen <with my individual contributor hat on>

---

From: "Christer Holmberg" <[email-masked]>
Date: Sun, 9 Mar 2008 22:06:10 +0100

Hi Cullen,

Believe me, I want to finish this draft as fast as you (and many
others).

So, all I am asking for is for a few lines of clarification text. It
doesn't change anything, or reintroduce any parameters. I think even Aki
said that what I now propose is already allowed, so it would just be a
clarification.

I also think it's unfair of blaming me for coming with new requirements.
Already 2 years ago you, me and Rohan agreed to allow to outbound proxy
to indicate support of keep-alive, and it was in the draft until version
-12. But, again, I don't mind having it in a separate draft, in order to
progress the outbound draft. Again, as far as the outbound draft is
concerned, all I ask for is a few words of to clarify something which
people say IS already allowed.

Regards,

Christer

> From: Cullen Jennings [mailto:[email-masked]] 
> Sent: 9. maaliskuuta 2008 22:02
> To: Dean Willis
> Cc: Christer Holmberg; Aki Niemi; Rohan Mahy; SIP; Francois Audet
> We have not had any new information about requirements for 
> keep alive than what we have 2 or more years ago. But, every 
> single meeting we seem to change the keep alive mechanism. In 
> many meetings we achieved strong consensus on how it should 
> work, then a very few people on the list have argued for 
> something different and we have changed it. We will never 
> finish if we keep doing this.
> 
> > > check  whether the URI-parametyer "ob" is included in the URI. If 
> > > so,
> > then the
> > >  UAC knows that

---

From: Cullen Jennings <[email-masked]>
Date: Sun, 9 Mar 2008 17:14:22 -0400

I have no objections to some clarifying text and I certainly did not  
mean to imply that you were responsible for the slowness of this  
draft. There is plenty of blame to go around but I think folks can  
start with Rohan and I at the top of the blame list :-)

On Mar 9, 2008, at 5:06 PM, Christer Holmberg wrote:

> > > >  >>parameter in the Path, to use keep-alive even if the  
> registrar
> > > does
> > > >  not
> > > >  >>support outbound.
> > > >  >
> > > >  "If the registrar did not support outbound, but there was a  
> path
> > > header
> > > >  with the edge proxy URI

---

From: Dean Willis <[email-masked]>
Date: Sun, 9 Mar 2008 23:58:43 -0400

On Mar 9, 2008, at 8:16 AM, Aki Niemi wrote:

>> that

As I read it,. by the current spec it can't STUN the proxy unless the  
registrar also supports outbound. This seems to be a non-required  
interaction.

---

From: Jiri Kuthan <[email-masked]>
Date: Mon, 10 Mar 2008 16:17:15 +0100

Here is something which is incredibly simple to do (which I consider a feature):
send TCP keep-alives (sorry about OSs that can't configure those) and STUN-UDP.
That's it and it works for many apps and it does not take the multi-hop 
multi-layer interaction. Remove it from outbound and get outbound finished.
Keep stuff simple and separated (i.e. do keep-alive with the entity terminating
TCP connection or UDP flow, which is what is in question; don't interact with
outbound proxies, registrars, or even worse all of them).

-jiri