[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [Sip] Outbound - a new STUN keealive proposal
Hi,
I was very happy to see this proposal from Cullen and agree
with it - apart from one single item, which I still disagree:
>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.
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
>-----Original Message-----
>From: ext Cullen Jennings [mailto:fluffy at cisco.com]
>Sent: 14.August.2006 01: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