I don't like this proposal. I'm still with the camp that says: if
configured, then it must be true.
My main objection is that in this proposal, you are required to send SIP
messages before STUN messages. That's a mandate that I'm not comfortable
with since I might want to send STUN first to discover my public IP/port
to populate the contact header before I send the first REGISTER.
Hisham
On Aug 8, 2006, at 4:38 PM, Rohan Mahy wrote:
We had a very long discussion in Montreal about discovery and validation
of a SIP outbound proxy server's ability to receive STUN requests. While
the vast majority of the room was comfortable that "keepalive=stun" in a
URI was a sufficient indicator that an outbound proxy supports SIP and
STUN over the same port, a small but extremely vocal minority had
significant problems with this assumption. After a discussion with Dean,
I am willing to try a validation proposal which adds no extra round trips
if the SIP UA was indeed correctly configured.
The specific proposal works like this. A UAC which has an outbound URI
indicating with ;keepalive=stun that the next hop can support STUN
messages on the SIP port, needs to verify the first hop supports STUN
before sending any STUN messages. The UAC sends its first SIP message to
the next hop with a Proxy-Require: sip-stun. If the URI was correct
(STUN was supported), and the first-hop is an intermediary, the first-hop
removes the Proxy-Require and forwards the SIP request (probably a
REGISTER request) along adding no additional delay. A positive response
to a REGISTER or OPTIONS with Supported: outbound and no error counts as
positive confirmation that either the registrar supports STUN or expects
to never receive a request without getting it from an outbound proxy
which did not complain about the Proxy-Require [1]. If the UAC was
misconfigured (the first-hop intermediary does not support STUN
keepalives), either the first hop will reject the SIP request (if it is
an intermediary), or the registrar will not include an indicator that it
supports outbound (if the first hop was the registrar).
Note that this proposal is not a full *discovery* mechanism, just a
verification mechanism. For example, if the registrar doesn't support
outbound, but the first-hop does, there is no way described here to
discover that the first-hop can accept STUN keepalives. Do not confuse
support of STUN with support of outbound. Supported: outbound implies
that the registrar supports STUN or is configured to use an outbound
proxy that does. The sip-stun option tag only means that you can send
and receive STUN requests on your SIP port. While outbound requires STUN,
STUN does not require outbound.
[1] Also Note that there is a caveat that you can still shoot yourself in
the foot if you allow messages to come straight to your registrar that
does not support STUN. I think we agreed that we are not going to
enumerate all the ways you can subtly break things in SIP though.
thanks,
-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