[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Sip] Outbound Issues: slides 3 and 4
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