Subject: [Sip] Outbound - a new STUN keealive proposal

From: Cullen Jennings <[email-masked]>
Date: Sun, 13 Aug 2006 15:57:56 -0700

Hi,

Rohan and I spent some time this afternoon trying to find a proposal  
that makes more people happy than the other proposals mentioned about  
STUN keepalive handling. We did this because some people expressed  
concern or displeasure about one proposal or another, but keep in  
mind that both of us are fine with the draft as is, in regards to  
this topic.

What we are proposing is the following:

1) We already agreed to move the STUN keepalive definition to a  
separate section.  This makes it clear how to use STUN keepalives  
even for implementations that do not use the rest of outbound. This  
is agreed - we are doing it, just listing it here for completeness.

2) Following the basic principle of "do no harm", we propose adding  
text to tell UAs that if an initial STUN request and its  
retransmissions fail, the UA MUST stop sending STUN requests to this  
destination.  The details of how to specify this will be difficult to  
articulate succinctly, but we'd like to get agreement to this idea in  
principle.  The difficulty is that if a flow fails completely, this  
is not necessarily indicative that the server has forgotten how to do  
STUN.

3) In the same vein, we propose adding text to make it clearer that a  
UA MUST NOT send STUN requests unless it has an explicit indication  
that the target SIP server supports STUN. We can further clarify that  
UA implementations should not have an ambiguous manual configuration  
option such as a "Work with NATs?" checkbox that would cause STUN  
keepalives to be used blindly. Manual configuration of an outbound  
URI that includes the ";keealive=stun" parameter is considered an  
explicit indication.

Now on to the new part of the proposal...

4) In the STUN keepalive section of the document, define a "sip-stun"  
option-tag and describe its semantics (this server can receive STUN  
messages and SIP messages on the same port). Describe that an OPTIONS  
message MAY be used to probe or verify if a specific server supports  
sip-stun. Future specifications can define other uses of this option- 
tag. This leaves our options open as a WG.

5) In the outbound portion of the draft, make it clear that the first- 
hop proxy MUST support the "sip-stun" option-tag. (If the UA probes  
the first-hop, the probe needs to succeed).

6) Also in the outbound section of the draft, explain that that it is  
NOT RECOMMENDED for a UAC to include a Proxy-Require header field  
with the sip-stun option-tag.  This is because the request would fail  
in some topologies where the first proxy supports sip-stun but  
subsequent proxies do not. Remind implementors that RFC 3261 does not  
allow proxies to remove option-tags from a Proxy-Require header field.

To summarize this proposal:
- It does no harm:  It insures STUN is only used when explicitly  
configured and provides supportive implementation guidance, and it  
stops sending STUN if the server does not respond to initial STUN  
traffic.
- It leaves our options open, while allowing outbound to progress:   
It keeps the door open for future explicit discovery mechanisms, and  
allows other potential uses of STUN keepalives.
- It works.

Please reply to the list or to (the chairs and authors) with one of  
the following choices:
a) This is fine/good/OK
b) I can live with this proposal, but prefer omitting the "sip-stun"  
option-tag
c) I object (please provide reasons)
d) I don't care, just please finish the document

Thanks, Cullen & Rohan

_______________________________________________
Sip mailing list  https://www1.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: Fredrik Thulin <[email-masked]>
Date: Mon, 14 Aug 2006 09:12:40 +0200

On Monday 14 August 2006 00:57, Cullen Jennings wrote:
> STUN keepalive handling.
... 

This is fine, please finish the document.

/Fredrik

---

From: "Christer Holmberg \(JO/LMF\)" <[email-masked]>
Date: Mon, 14 Aug 2006 09:51:59 +0200

Hi,

One more thing:

In another thread I proposed to, instead of using keepalive=stun, we
would use the same value as we use for the option-tag (e.g.
sip-stun-keepalive).

In the "[Sip] Outbound issues: slides 9 and 10" thread Rohan proposes an
"ob" parameter to indicate support of Outbound, so why not simply use
"sip-stun-keepalive" (or something similar) for STUN keepalive?

The reason that the outbound proxy inserts "ob" is so that the registrar
can verify that the outbound proxy supports Outbound. 

Example:

Path: sip:[email-masked];ob;sip-stun-keepalive

Regards,

Christer

-----Original Message-----
From: Christer Holmberg (JO/LMF) 
Sent: 14. elokuuta 2006 9:50
To: 'Cullen Jennings'; SIP
Cc: Rohan Mahy
Subject: RE: [Sip] Outbound - a new STUN keealive proposal

Hi Cullen and Rohan,

Unfortunately I can't reply with any of the options (a,b,c or d). I do
NOT object to your proposal. In fact, I think it looks very good, but I
have a few questions:

1. Editorial: Shouldn't the
stop-sending-STUN-requests-if-retransmissions-fail text (point 2) be in
3849bis? To me it sounds like generic STUN transaction procedures, which
should be defined in the STUN spec. Or, do we consider it specific to
the STUN keepalive usage for SIP???

2. Functional: The proposal does not say anything about the outbound
proxy being able to indicate STUN keepalive support, i.e. by inserting a
keepalive=stun (or something similar) in a Path/Service-Route header,
and/or the option tag in the Supported header (if the outbound proxy
happens to also be the registrar), or the REGISTER, as has been
discussed in a separate thread (I think we also agreed to keep it within
the scope). I think it would be very useful, especially in cases where
the UA does not have any "explicit indication" beforehand, and where the
UA does not want to send OPTIONS before sending REGISTER (e.g. due to
the fact that the UA would continue the registration no matter if the
outbound proxy supports STUN keepalive or not).

3. Editorial: Would it be possible to name the option tag
"sip-stun-keepalive", instead of just "sip-stun"? Or, are we sure we
will never have to be able to indicate any other type of STUN usage
support for SIP?

Regards,

Christer

-----Original Message-----
From: Cullen Jennings [mailto:[email-masked]]
Sent: 14. elokuuta 2006 1:58
To: SIP
Cc: Rohan Mahy
Subject: [Sip] Outbound - a new STUN keealive proposal

Hi,

Rohan and I spent some time this afternoon trying to find a proposal
that makes more people happy than the other proposals mentioned about
STUN keepalive handling. We did this because some people expressed
concern or displeasure about one proposal or another, but keep in mind
that both of us are fine with the draft as is, in regards to this topic.

1) We already agreed to move the STUN keepalive definition to a separate
section.  This makes it clear how to use STUN keepalives even for
implementations that do not use the rest of outbound. This is agreed -
we are doing it, just listing it here for completeness.

2) Following the basic principle of "do no harm", we propose adding text
to tell UAs that if an initial STUN request and its retransmissions
fail, the UA MUST stop sending STUN requests to this destination.  The
details of how to specify this will be difficult to articulate
succinctly, but we'd like to get agreement to this idea in principle.
The difficulty is that if a flow fails completely, this is not
necessarily indicative that the server has forgotten how to do STUN.

3) In the same vein, we propose adding text to make it clearer that a UA
MUST NOT send STUN requests unless it has an explicit indication that
the target SIP server supports STUN. We can further clarify that UA
implementations should not have an ambiguous manual configuration option
such as a "Work with NATs?" checkbox that would cause STUN keepalives to
be used blindly. Manual configuration of an outbound URI that includes
the ";keealive=stun" parameter is considered an explicit indication.

5) In the outbound portion of the draft, make it clear that the first-
hop proxy MUST support the "sip-stun" option-tag. (If the UA probes the
first-hop, the probe needs to succeed).

6) Also in the outbound section of the draft, explain that that it is
NOT RECOMMENDED for a UAC to include a Proxy-Require header field with
the sip-stun option-tag.  This is because the request would fail in some
topologies where the first proxy supports sip-stun but subsequent
proxies do not. Remind implementors that RFC 3261 does not allow proxies
to remove option-tags from a Proxy-Require header field.

To summarize this proposal:
- It does no harm:  It insures STUN is only used when explicitly
configured and provides supportive implementation guidance, and it stops
sending STUN if the server does not respond to initial STUN traffic.
- It leaves our options open, while allowing outbound to progress:   
It keeps the door open for future explicit discovery mechanisms, and
allows other potential uses of STUN keepalives.
- It works.

Please reply to the list or to (the chairs and authors) with one of the
following choices:
a) This is fine/good/OK
b) I can live with this proposal, but prefer omitting the "sip-stun"  
option-tag
c) I object (please provide reasons)
d) I don't care, just please finish the document

Thanks, Cullen & Rohan

_______________________________________________
Sip mailing list  https://www1.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: <[email-masked]>
Date: Mon, 14 Aug 2006 11:24:07 +0300

Hi,

I was very happy to see this proposal from Cullen and agree 

>allow proxies to remove option-tags from a Proxy-Require header field.

The reasons for my disagreement are expressed in this email from
Jonathan, from a thread related to RFC 3329:

http://www1.ietf.org/mail-archive/web/sip/current/msg07871.html

Jonathan says:
> Interestingly, RFC3329 is not the first RFC to have a proxy 
> remove a proxy-require header. RFC 3323 (Privacy extensions) 
> does the same thing for much the same reason. As such, I agree 
> that this is probably a bug in RFC3261.
>
> I've logged the bug into bugzilla:
> http://bugs.sipit.net/sipwg/show_bug.cgi?id=707

Further on the submitted proposal is incomplete in the sense that
it does not specify how the compliant proxy must react to a request
which would contain sip-stun option tag in Proxy-Require header.
The proposed text is just a recommendation so that a compliant
UA implementation might still use that tag in Proxy-Require header.
The results for doing that must be deterministic even if the UA
would be preferred to send OPTIONS instead.

I propose this item 6 to be removed from the proposal and 
the text I proposed earlier to be added to the draft:

> The UA MAY add a Proxy-Require header field with the
> value "sip-stun" to its REGISTER request. When the UA
> thereafter receives 200 OK with Supported: Outbound it 
> can be sure that the next hop will support STUN keepalives.
>
> The proxy MUST remove the "sip-stun" value from the
> Proxy-Require header field and then remove the header
> if no values remain before forwarding the request to
> the next hop.

Regards,

Erkki 

>From: ext Cullen Jennings [mailto:[email-masked]] 
>Sent: 14.August.2006 01:58
>To: SIP
>Cc: Rohan Mahy

---

From: "Christer Holmberg \(JO/LMF\)" <[email-masked]>
Date: Mon, 14 Aug 2006 08:49:56 +0200

Hi Cullen and Rohan,

Regards,

Christer

-----Original Message-----
From: Cullen Jennings [mailto:[email-masked]] 
Sent: 14. elokuuta 2006 1:58
To: SIP
Cc: Rohan Mahy
Subject: [Sip] Outbound - a new STUN keealive proposal

Hi,

Thanks, Cullen & Rohan

---

From: Jiri Kuthan <[email-masked]>
Date: Mon, 14 Aug 2006 11:23:07 +0200

Hi Cullen,

I think we should actually step back and seek what level of applicability
are we seeking. Is STUN/keepalives a SIP thing for sip-wg or is it perhaps
a general application guideline for behave?

also regarding 3 -- I think if we consider saying MUST NOT, we should include
WHY.

-jiri

At 00:57 14/08/2006, Cullen Jennings wrote:
>sip-stun. Future specifications can define other uses of this option- tag. This leaves our options open as a WG.
>
>5) In the outbound portion of the draft, make it clear that the first- hop proxy MUST support the "sip-stun" option-tag. (If the UA probes  

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

---

From: Jiri Kuthan <[email-masked]>
Date: Mon, 14 Aug 2006 11:23:07 +0200

Hi Cullen,

-jiri

---

From: Hisham Khartabil <[email-masked]>
Date: Mon, 14 Aug 2006 12:12:20 +0200

I think we should say the following:

A UA MAY do *either or both* of the following, *in any order*, in order 
to verify that an outbound proxy supports stun keepalive, IF the UA is 
configured to say that outbound proxy supports stun

- send stun requests including retransmissions
- send SIP OPTIONS request

Implementers can choose the order they want. It can even be 
configurable where the service provider can configure the order.

I also want to point out that the UA needs to try again after some 
units of time if stun fails, if the UA is configured to say that 
outbound proxy supports stun. The reason is that I might have upgraded 
my server to a bad version where the stun part was buggy. I don't want 
to ask my customers to reboot their UA in order to get stun to work 
again from the UA.

Hisham

On Aug 14, 2006, at 12:57 AM, Cullen Jennings wrote:

> separate section.  This makes it clear how to use STUN keepalives even 
> for implementations that do not use the rest of outbound. This is 
> agreed - we are doing it, just listing it here for completeness.
>
> principle.  The difficulty is that if a flow fails completely, this is 
> not necessarily indicative that the server has forgotten how to do 
> STUN.
>
> keepalives to be used blindly. Manual configuration of an outbound URI 
> that includes the ";keealive=stun" parameter is considered an explicit 
> indication.
>
> sip-stun. Future specifications can define other uses of this 
> option-tag. This leaves our options open as a WG.
>
> 5) In the outbound portion of the draft, make it clear that the 
> first-hop proxy MUST support the "sip-stun" option-tag. (If the UA 
> probes the first-hop, the probe needs to succeed).
>
> the sip-stun option-tag.  This is because the request would fail in 
> some topologies where the first proxy supports sip-stun but subsequent 
> proxies do not. Remind implementors that RFC 3261 does not allow 
> proxies to remove option-tags from a Proxy-Require header field.
>
> - It leaves our options open, while allowing outbound to progress:  It 
> keeps the door open for future explicit discovery mechanisms, and

---

From: Rohan Mahy <[email-masked]>
Date: Mon, 14 Aug 2006 08:11:38 -0700

Hi Christer,

> the STUN keepalive usage for SIP???

I don't think this is generic STUN procedures.  There are reasons why 
you need to have different transmission policies.  For example ICE 
would not work if we SIP STUN keepalive style restrictions on it.

> outbound proxy supports STUN keepalive or not).

Since it is unlikely that we are going to agree on this within a year, 
we had extremely strong support in the meeting and on the mailing list 
to do this work _*LATER*_.

> will never have to be able to indicate any other type of STUN usage

Unless someone can provide an existence proof, I think the longer 
option-tag name is cumbersome and probably unnecessary.

thanks,
-rohan

> separate
> text
> UA
> some
> proxies
> stops

---

From: "Christer Holmberg \(JO/LMF\)" <[email-masked]>
Date: Mon, 14 Aug 2006 17:54:16 +0200

Hi Rohan, 

>>NOT object to your proposal. In fact, I think it looks very good, but 
>>I have a few questions:
>>
>>stop-sending-STUN-requests-if-retransmissions-fail text (point 2) be 
>>in 3849bis? To me it sounds like generic STUN transaction procedures, 
>>which should be defined in the STUN spec. Or, do we consider it 
>>specific to the STUN keepalive usage for SIP???
>>
you need to have different transmission policies.  
>For example ICE would not work if we SIP STUN keepalive style
restrictions on it.

Ok. If everybody agree I will accept it.

>>proxy being able to indicate STUN keepalive support, i.e. by inserting

>>a keepalive=stun (or something similar) in a Path/Service-Route 
>>header, and/or the option tag in the Supported header (if the outbound

>>proxy happens to also be the registrar), or the REGISTER, as has been 
>>discussed in a separate thread (I think we also agreed to keep it 
>>within the scope). I think it would be very useful, especially in 
>>cases where the UA does not have any "explicit indication" beforehand,

>>and where the UA does not want to send OPTIONS before sending REGISTER

>>(e.g. due to the fact that the UA would continue the registration no 
>>matter if the outbound proxy supports STUN keepalive or not).
>
we had extremely strong support in the meeting and 
>on the mailing list to do this work _*LATER*_.

I haven't seen much objection to it, and both Jonathan and Cullen
indicated (I appologize if I missunderstood them) that it would be
useful to include it already NOW.

And, we are going to define the option-tag (for OPTIONS and/or
Proxy-Require) and the URI paramter (for Path and/or Service-Route)
anyway, so I don't think it would add much work.

And, what about the proxy inserting the "ob" parameter (see slide 9 and
10 issue)??? Isn't that needed already NOW? How is that different from
the proxy inserting a STUN support indication?

I agree that we should aim at short option-tag names, but unfortunately
it's difficult to proof STUN usages which may be defined in future... :)

Regards,

Christer

> principle.

---

From: Hisham Khartabil <[email-masked]>
Date: Mon, 14 Aug 2006 18:01:17 +0200

Rohan,

Specify whatever you want, as long as its optional to implement. I will 
not require it from my vendors. I believe this settles it :)

Thanks,
Hisham

On Aug 14, 2006, at 5:26 PM, Rohan Mahy wrote:

> Hisham,
>
> We are trying to converge here.  It seems pretty clear to me that 
> fewer people will be OK with your proposal.  I'll point out that you 
> can ALREADY send STUN before SIP by configuring your STUN server 
> address to the address of your SIP server. In large part, we are 
> talking about the UA deciding to send STUN based on its *SIP* server 
> configuration.
>
> thanks,
> -rohan
>
> On Aug 14, 2006, at 3:12, Hisham Khartabil wrote:
>> A UA MAY do *either or both* of the following, *in any order*, in 
>> order to verify that an outbound proxy supports stun keepalive, IF 
>> the UA is configured to say that outbound proxy supports stun
>>
>> outbound proxy supports stun. The reason is that I might have 
>> upgraded my server to a bad version where the stun part was buggy. I 
>> don't want to ask my customers to reboot their UA in order to get 
>> stun to work again from the UA.
>>
>> Hisham
>>
>>> that makes more people happy than the other proposals mentioned 
>>> about STUN keepalive handling. We did this because some people 
>>> expressed concern or displeasure about one proposal or another, but 
>>> keep in mind that both of us are fine with the draft as is, in 
>>> regards to this topic.
>>>
>>> destination.  The details of how to specify this will be difficult 
>>> to articulate succinctly, but we'd like to get agreement to this 
>>> idea in principle.  The difficulty is that if a flow fails 
>>> completely, this is not necessarily indicative that the server has 
>>> forgotten how to do STUN.
>>>
>>> 3) In the same vein, we propose adding text to make it clearer that 
>>> a UA MUST NOT send STUN requests unless it has an explicit 
>>> indication that the target SIP server supports STUN. We can further 
>>> clarify that UA implementations should not have an ambiguous manual 
>>> configuration option such as a "Work with NATs?" checkbox that would 
>>> cause STUN keepalives to be used blindly. Manual configuration of an 
>>> outbound URI that includes the ";keealive=stun" parameter is 
>>> considered an explicit indication.
>>>
>>> 4) In the STUN keepalive section of the document, define a 
>>> "sip-stun" option-tag and describe its semantics (this server can 
>>> receive STUN messages and SIP messages on the same port). Describe 
>>> that an OPTIONS message MAY be used to probe or verify if a specific 
>>> server supports sip-stun. Future specifications can define other 
>>> uses of this option-tag. This leaves our options open as a WG.
>>>
>>> 6) Also in the outbound section of the draft, explain that that it 
>>> is NOT RECOMMENDED for a UAC to include a Proxy-Require header field 
>>> with the sip-stun option-tag.  This is because the request would 
>>> fail in some topologies where the first proxy supports sip-stun but 
>>> subsequent proxies do not. Remind implementors that RFC 3261 does 
>>> not allow proxies to remove option-tags from a Proxy-Require header 
>>> field.
>>>

---

From: Rohan Mahy <[email-masked]>
Date: Mon, 14 Aug 2006 08:26:55 -0700

Hisham,

We are trying to converge here.  It seems pretty clear to me that fewer 
people will be OK with your proposal.  I'll point out that you can 
ALREADY send STUN before SIP by configuring your STUN server address to 
the address of your SIP server. In large part, we are talking about the 
UA deciding to send STUN based on its *SIP* server configuration.

thanks,
-rohan

On Aug 14, 2006, at 3:12, Hisham Khartabil wrote:
> order to verify that an outbound proxy supports stun keepalive, IF the 
> UA is configured to say that outbound proxy supports stun
>

---

From: "Hadriel Kaplan" <[email-masked]>
Date: Mon, 14 Aug 2006 21:03:46 -0400

> From: Christer Holmberg (JO/LMF) [mailto:[email-masked]]
> 

Not necessarily I think - we define "sip-stun" now.  If we need to use stun
for something other than keepalive in the future, it would be "sip-stun-xyz"
or "sip-xyz-stun", or a second option tag only used if "sip-stun" option tag
is also used, or whatever.  The two strings don't match, ergo are unique and
differentiating.
-hadriel

---

From: Cullen Jennings <[email-masked]>
Date: Mon, 14 Aug 2006 21:49:59 -0700

> NOT object to your proposal. In fact, I think it looks very good,  

I think some of these questions are actually some good improvements -  
thanks

> the STUN keepalive usage for SIP???

Propose some text - as much as the advice can be made generic, I  
would want it to be in 3849bis. I suspect it hard to say too much  
more than what is in 3849.

> keepalive=stun (or something similar) in a Path/Service-Route header,

Rohan and I meant this proposal to allow something like - if the UA  
found out about a URI to use in a Path/S-R header or something  
similar and it had the keep-alive=stun, then the UA would do stun  
when connecting to that URI

> happens to also be the registrar), or the REGISTER, as has been

Again, we meant this proposal to allow something like this. We said  
the proxy needed to put this in the supported (if it supported it). I  
guess we should have said this about the Registrar too. We can update  
the proposal with that.

> within

Sounds like a good suggestion - I did see you made this before -  
Rohan and I just did not get to this level of detail in the proposal.

> a UA
> the

---

From: Cullen Jennings <[email-masked]>
Date: Mon, 14 Aug 2006 21:55:57 -0700

> would use the same value as we use for the option-tag (e.g.

My individual feeling on this is I would be fine with this - I'm not  
sure if others would or not. The selection of which keep alive  
mechanism to use was very controversial and people seemed to feel  
like keep-alive=foo might make it easier to have different keep alive  
mechanisms. I'm not sure I follow this logic as one could always have  
a foo-keepalive uri parameter if a new keep alive method was defined  
and the alternative seemed harder given many SIP stacks handling of  
multiple parameters with the same name. Anyways, I'm happy either  
way. I'm not sure everyone would be OK with this or not.

---

From: "Christer Holmberg \(JO/LMF\)" <[email-masked]>
Date: Tue, 15 Aug 2006 23:26:47 +0200

Hi, 

thanks
>> 1. Editorial: Shouldn't the
stop-sending-STUN-requests-if-retransmissions-fail text (point 2)  
>> be in 3849bis? To me it sounds like generic STUN transaction
procedures,  
>> which should be defined in the STUN spec. Or, do we consider it
specific to
>Propose some text - as much as the advice can be made generic, I would
want it to be in 3849bis. I suspect it hard to say 
>too much more than what is in 3849.

I need to think a little more about this a little bit more.

Chapter 7.1 of 3849bis does talk about STUN re-transimission timers, and
when a transaction shall be considered to have failed. But, there is no
text about what happens after that. THAT may be STUN usage dependent,
though, and in some cases it could even be "an implementation issue"...

But, I don't see anything SIP specific in saying that STUN keep-alive
re-transmissions shall stop if there is no reply, so shouldn't that text
be in 3849bis - either in the generic transaction chapter (chapter 7),
or in the keep-alive usage chapter (12.4)? The part of the outbound spec
defining the SIP usage of STUN keep-alive can then of course refer to
that text in 3849bis.

My main concern is that we dont specify things which people will later
find out belongs to another spec, and another WG.

>>proxy being able to indicate STUN keepalive support, i.e. by  
>>inserting a keepalive=stun (or something similar) in a
Path/Service-Route header,
>when connecting to that URI

Ok. Point 3 did not make that very clear, though, because it only talked
about a configured URI indicating keep-alive=stun. 

But, if the URI can also come from the proxy itself (in the
Path/S-R/whatever header) in the registration response I am ok with the
proposal. Could you perhaps clarify that in Cthe proposal?

>the proxy needed to put this in the supported (if it supported it).
>I guess we should have said this about the Registrar too. We can update

>the proposal with that.

I guess you can say that the indication is put in the Supported header
if the outbound proxy and the registrar happen to be the same entity.
Otherwise the proxy would insert the indication in Path, S-R or whatever
we decided upon.

I think the outbound proxy should insert the STUN keep-alive indication
in the SAME header where it inserts the outbound ("ob") indication.
Currently that is the Path header (see slide 9 and 10 proposal), but I
know Jonathan had some ideas of using S-R.

Regards,

Christer

---

From: "Dan Wing" <[email-masked]>
Date: Tue, 15 Aug 2006 17:16:20 -0700

> >>    stop-sending-STUN-requests-if-retransmissions-fail text (point
> >>    2) be in 3849bis?  To me it sounds like generic STUN
> >>    transaction procedures, which should be defined in the STUN
> >>    spec.  Or, do we consider it specific to the STUN keepalive
> >>    usage for SIP???
> >
> Chapter 7.1 of 3849bis does talk about STUN re-transimission timers,
> and when a transaction shall be considered to have failed.  But,
> there is no text about what happens after that.  THAT may be STUN
> usage dependent, though, and in some cases it could even be "an
> implementation issue"...
>
> But, I don't see anything SIP specific in saying that STUN
> keep-alive re-transmissions shall stop if there is no reply, so
> shouldn't that text be in 3849bis - either in the generic
> transaction chapter (chapter 7), or in the keep-alive usage chapter
> (12.4)? The part of the outbound spec defining the SIP usage of STUN
> keep-alive can then of course refer to that text in 3849bis.

It would be more appropriate in the keepalive usage section.

> My main concern is that we dont specify things which people will
> later find out belongs to another spec, and another WG.

My concern is that if you stop doing STUN keepalives because you 
haven't received a response in NNNN retransmissions, your NAT 
binding will time out soon thereafter.  So here is some proposed text 
for the RFC3489bis keepalive section:

  If, after retransmitting the STUN Binding Request NNNN times,
  the STUN client does not receive a STUN Binding Response, the
  STUN client should assume the STUN server is no longer 
  available.  The STUN client SHOULD cease retransmitting the
  STUN keepalives and inform other applications that the NAT
  binding is no longer valid (e.g., attempt to re-register if
  using SIP).

-d

---

From: "Dan Wing" <[email-masked]>
Date: Tue, 15 Aug 2006 17:18:49 -0700

> > 3849bis? To me it sounds like generic STUN transaction procedures, 

ICE uses the Connectivity Check usage (*), whereas sip-outbound is using
the Keepalive usage.  So as long as Christer's suggested text is only
associated with RFC3489bis's Keepalive usage I think we're safe.

(*) The only time ICE uses the Keepalive usage is where ICE 
    suggests that something is needed to keep NAT bindings alive 
    if media isn't being actively transmitted, and ICE suggests 
    using the keepalive usage, a 'silence packet', an RTP NoOp 
    packet, etc.

-d

---

From: Rohan Mahy <[email-masked]>
Date: Tue, 15 Aug 2006 17:20:36 -0700 (PDT)

Hi,

I think this is a slippery slope for 3489bis.  I can think of about 3 use
cases that would break, or at least would be confusing, with this wording.
 I would like some time to propose language specific to SIP and STUN on
the same port that is appropriate.

thanks,
-rohan

---

From: "Christer Holmberg \(JO/LMF\)" <[email-masked]>
Date: Wed, 16 Aug 2006 08:55:18 +0200

Dan is correct - I am only talking about the STUN keep-alive usage.

Regards,

Christer 

-----Original Message-----
From: Dan Wing [mailto:[email-masked]] 
Sent: 16. elokuuta 2006 3:19
To: 'Rohan Mahy'; Christer Holmberg (JO/LMF)
Cc: 'SIP'; 'Cullen Jennings'
Subject: RE: [Sip] Outbound - a new STUN keealive proposal

> > in 3849bis? To me it sounds like generic STUN transaction 
> > procedures, which should be defined in the STUN spec. Or, do we 
> > consider it specific to the STUN keepalive usage for SIP???
> 

-d

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on curFrom [email-masked] Wed Aug 16 02:58:59 2006
Content-class: urn:content-classes:message
Subject: RE: [Sip] Outbound - a new STUN keealive proposal
Date: Wed, 16 Aug 2006 08:55:18 +0200
To: "Dan Wing" <[email-masked]>,
	"Rohan Mahy" <[email-masked]>
Cc: SIP <[email-masked]>, Cullen Jennings <[email-masked]>

Dan is correct - I am only talking about the STUN keep-alive usage.

Regards,

Christer 

-----Original Message-----
From: Dan Wing [mailto:[email-masked]] 
Sent: 16. elokuuta 2006 3:19
To: 'Rohan Mahy'; Christer Holmberg (JO/LMF)
Cc: 'SIP'; 'Cullen Jennings'
Subject: RE: [Sip] Outbound - a new STUN keealive proposal

> > in 3849bis? To me it sounds like generic STUN transaction 
> > procedures, which should be defined in the STUN spec. Or, do we 
> > consider it specific to the STUN keepalive usage for SIP???
> 

-d

---

From: "Christer Holmberg \(JO/LMF\)" <[email-masked]>
Date: Wed, 16 Aug 2006 08:55:07 +0200

Hi Rohan,

We could write something like:

"If the STUN binding transaction fails, as described in 3489, the SIP UA
must/may/could/must not do this-and-that-SIP-procedure".

I have nothing against putting SIP specific actions into the outbound
draft, but anything that can be considered to be generic to STUN
keepalive usage should be in 3489bis.

Regards,

Christer 

-----Original Message-----
From: Rohan Mahy [mailto:[email-masked]] 
Sent: 16. elokuuta 2006 3:21
To: Dan Wing
Cc: Christer Holmberg (JO/LMF); 'Cullen Jennings'; 'SIP'; 'Rohan Mahy';
[email-masked]
Subject: RE: [Sip] Outbound - a new STUN keealive proposal

Hi,

I think this is a slippery slope for 3489bis.  I can think of about 3
use cases that would break, or at least would be confusing, with this
wording.
 I would like some time to propose language specific to SIP and STUN on
the same port that is appropriate.

thanks,
-rohan

>> I need to trent sip

---

From: "Christer Holmberg \(JO/LMF\)" <[email-masked]>
Date: Wed, 16 Aug 2006 08:55:07 +0200

Hi Rohan,

Regards,

Christer 

-----Original Message-----
From: Rohan Mahy [mailto:[email-masked]] 
Sent: 16. elokuuta 2006 3:21
To: Dan Wing
Cc: Christer Holmberg (JO/LMF); 'Cullen Jennings'; 'SIP'; 'Rohan Mahy';

Hi,

thanks,
-rohan

>> re-transmissions shall stop if there is no reply, so shouldn't that 
>> text be in 3849bis - either in the generic transaction chapter 
>> (chapter 7), or in the keep-alive usage chapter (12.4)? The part of 
>> the outbound spec defining the SIP usage of STUN keep-alive can then 
>> of course refer to that text in 3849bis.
>
> haven't received a response in NNNN retransmissions, your NAT binding 
> will time out soon thereafter.  So here is some proposed text for the 
> RFC3489bis keepalive section:
>

hink a little more about this a little bit more.

>> re-transmissions shall stop if there is no reply, so shouldn't that 
>> text be in 3849bis - either in the generic transaction chapter 
>> (chapter 7), or in the keep-alive usage chapter (12.4)? The part of 
>> the outbound spec defining the SIP usage of STUN keep-alive can then 
>> of course refer to that text in 3849bis.
>
> haven't received a response in NNNN retransmissions, your NAT binding 
> will time out soon thereafter.  So here is some proposed text for the 
> RFC3489bis keepalive section:
>

---

From: "Christer Holmberg \(JO/LMF\)" <[email-masked]>
Date: Wed, 16 Aug 2006 08:55:27 +0200

Hi, 

>>and when a transaction shall be considered to have failed.  But, there

>>is no text about what happens after that.  THAT may be STUN usage 
>>dependent, though, and in some cases it could even be "an 
>>implementation issue"...
>>

>My concern is that if you stop doing STUN keepalives because you
haven't received a response in NNNN retransmissions, 
>your NAT binding will time out soon thereafter.  So here is some
>  binding is no longer valid (e.g., attempt to re-register if

I don't think we need to talk about NNNN times. Can't we simply say "If
the STUN client does not receive a response, and the STUN transaction
fails, the STUN client should assume....".

Then, IF we want to talk about SIP actions taken due to the failure
(re-registers etc), THAT belongs to a SIP specific spec I think.

Regards,

Christer

---

From: Rohan Mahy <[email-masked]>
Date: Wed, 16 Aug 2006 08:42:53 -0700

Christer, it is not that simple.  Does the STUN client send 
retransmissions?  What if the STUN transaction failed but other traffic 
to the same port succeeded before-hand?  afterwards?  What happens if 
the STUN transaction fails over an still open TCP connection?  What if 
your TCP connection stalls?

thanks,
-rohan

On Aug 15, 2006, at 23:55, Christer Holmberg ((JO/LMF)) wrote:
>>> there
>>> later

---

From: "Christer Holmberg \(JO/LMF\)" <[email-masked]>
Date: Thu, 17 Aug 2006 14:15:10 +0200

>Christer, it is not that simple.  Does the STUN client send
retransmissions? 

According to 3849bis, it does.

>What if the STUN transaction failed but other traffic to the same port
succeeded before-hand?  afterwards?

That is an interesting question. But, I don't tink it's SIP specific,
because that "other traffic" could be non-SIP.

But, I am not sure we want to specify behavior, saying that one protocol
behavior is dependent on another...

>What happens if the STUN transaction fails over an still open TCP
connection?  What if your TCP connection stalls?

That is also an interesting question. But, I don't think that is SIP
specific either.

So, there may be more issues we need to consider. But, if we can agree
they belong to 3849bis we can move the discussion to BEHAVE, and it
won't affect the work on the outbound spec.

But, again, if we want the STUN failure to trigger SIP specific actions
(e.g. trigger the sending of a new REGISTER), that should of course be
described in the outbound draft.

Regards,

Christer

>>  If, after retransmitting the STUN Binding Request NNNN times,  the 
>> STUN client does not receive a STUN Binding Response, the  STUN 
>> client should assume the STUN server is no longer  available.  The 
>> STUN client SHOULD cease retransmitting the  STUN keepalives and 
>> inform other applications that the NAT  binding is no longer valid 
>> (e.g., attempt to re-register if  using SIP).
>
> I don't think we need to talk about NNNN times. Can't we simply say 
> "If the STUN client does not receive a response, and the STUN 
> transaction fails, the STUN client should assume....".
>