[Sip] Outbound Issues: slides 3 and 4

Rohan Mahy <rohan@ekabal.com> Tue, 08 August 2006 14:38 UTC

Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GASj5-0007mj-NG; Tue, 08 Aug 2006 10:38:35 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GASj3-0007md-Ph for sip@ietf.org; Tue, 08 Aug 2006 10:38:33 -0400
Received: from figas.ekabal.com ([204.61.215.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GASj2-0008NZ-DB for sip@ietf.org; Tue, 08 Aug 2006 10:38:33 -0400
Received: from [131.161.248.92] (open-131-161-248-92.cliq.com [131.161.248.92]) (authenticated) by figas.ekabal.com (8.11.6/8.11.6) with ESMTP id k78EcRF18606; Tue, 8 Aug 2006 07:38:27 -0700
Mime-Version: 1.0 (Apple Message framework v624)
Content-Type: text/plain; charset="US-ASCII"; format="flowed"
Message-Id: <f42475fcd7ff6c4129ce895e0c2bd451@ekabal.com>
Content-Transfer-Encoding: 7bit
From: Rohan Mahy <rohan@ekabal.com>
Date: Tue, 08 Aug 2006 07:38:52 -0700
To: IETF SIP List <sip@ietf.org>
X-Mailer: Apple Mail (2.624)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: c1c65599517f9ac32519d043c37c5336
Cc: Rohan Mahy <rohan@ekabal.com>
Subject: [Sip] Outbound Issues: slides 3 and 4
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>, <mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>, <mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org

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@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip