[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Sip] Outbound - a new STUN keealive proposal
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:
>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 aFrom sip-bounces at ietf.org Mon Aug 14 05:39:54 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
by megatron.ietf.org with esmtp (Exim 4.43)
id 1GCYtb-0002tA-1o; Mon, 14 Aug 2006 05:38:07 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
by megatron.ietf.org with esmtp (Exim 4.43) id 1GCYtY-0002t0-S9
for sip at ietf.org; Mon, 14 Aug 2006 05:38:04 -0400
Received: from rat.iptel.org ([213.192.59.67] helo=mail.iptel.org)
by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GCYtY-0004g6-BJ
for sip at ietf.org; Mon, 14 Aug 2006 05:38:04 -0400
Received: from uk1lt10071.iptel.org (shell.iptel.org [213.192.59.74])
by mail.iptel.org (Postfix) with ESMTP id B9E2D20A309;
Mon, 14 Aug 2006 09:37:31 +0000 (UTC)
Message-Id: <7.0.1.0.0.20060814112004.029275e0 at iptel.org>
X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0
Date: Mon, 14 Aug 2006 11:23:07 +0200
To: Cullen Jennings <fluffy at cisco.com>, SIP <sip at ietf.org>
From: Jiri Kuthan <jiri at iptel.org>
Subject: Re: [Sip] Outbound - a new STUN keealive proposal
In-Reply-To: <9AE47FFD-4ADC-4B1A-A561-FADBD8B4ABED at cisco.com>
References: <9AE47FFD-4ADC-4B1A-A561-FADBD8B4ABED at cisco.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Spam-Score: 0.0 (/)
X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1
Cc: Rohan Mahy <rohan at ekabal.com>
X-BeenThere: sip at ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
<mailto:sip-request at ietf.org?subject=unsubscribe>
List-Post: <mailto:sip at ietf.org>
List-Help: <mailto:sip-request at ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
<mailto:sip-request at ietf.org?subject=subscribe>
Errors-To: sip-bounces at ietf.org
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:
>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
--
Jiri Kuthan http://iptel.org/~jiri/
_______________________________________________
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