[Sip] Outbound - a new STUN keealive proposal

[Cullen Jennings <fluffy at cisco.com>]

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 sip-implementors at cs.columbia.edu for questions on current sip
Use sipping at ietf.org for new developments on the application of sip