[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