1. RFC 3489bis Jonathan Rosenberg Cisco Systems

2. Technical Changes Needed Allow STUN over TCP –Driver: draft-ietf-sip-outbound Allow response to omit CHANGED- ADDRESS –Driver: draft-ietf-sip-outbound, ICE Soften usage of shared secret request and message integrity –Driver: draft-ietf-sip-outbound

3. Meta-Issue What exactly IS STUN???

4. STUN Meanings A vertical solution for NAT traversal, including –Detecting type of NAT –Obtaining and using a binding if your NAT allows it A request/response protocol that can be used in many ways A mechanism for obtaining a binding for some reason A connectivity check and binding keepalive tool

5. Does it matter? No sensible context for the changes we need without delineating STUNs roles No sensible path for future work without providing a framework

6. Proposed Solution STUN Framework –Defines a protocol toolkit –Used to build STUN Usages Tools in the Toolkit –Transaction model –Connection management for UDP and TCP –AVP structure –Extensibility framework –DNS procedures –OTP request –Binding request MAPPED-ADDRESS only required response attribute Usages Define –Any new requests –Any new responses –Any new attributes –Constraints on usage of attributes in requests/responses –Use cases

7. Usages NAT Type Determination (out of scope) Binding Discovery –Uses shared secret mechanism, binding request, DNS discovery Connectivity Check –ICE Usage –Binding request, message integrity, external OTP mechanism Binding Keepalive –SIP-outbound Usage –Binding request, no message integrity or OTP

8. Comments? Should we proceed down this path? Combine connectivity check and keepalive usages?