Re: [Sip] Outbound Issues: slides 3 and 4

[Hisham Khartabil <hisham.khartabil at telio.no>]

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