[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Sip] Outbound - a new STUN keealive proposal
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:
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
_______________________________________________
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