[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
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:fluffy at cisco.com]
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.
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