rfc3489.txt

this is simple sip stack.

   no response is received, it performs test I again, but this time,
   does so to the address and port from the CHANGED-ADDRESS attribute
   from the response to test I.  If the IP address and port returned in
   the MAPPED-ADDRESS attribute are not the same as the ones from the
   first test I, the client knows its behind a symmetric NAT.  If the
   address and port are the same, the client is either behind a
   restricted or port restricted NAT.  To make a determination about
   which one it is behind, the client initiates test III.  If a response
   is received, its behind a restricted NAT, and if no response is
   received, its behind a port restricted NAT.

   This procedure yields substantial information about the operating
   condition of the client application.  In the event of multiple NATs
   between the client and the Internet, the type that is discovered will
   be the type of the most restrictive NAT between the client and the
   Internet.  The types of NAT, in order of restrictiveness, from most
   to least, are symmetric, port restricted cone, restricted cone, and
   full cone.

   Typically, a client will re-do this discovery process periodically to
   detect changes, or look for inconsistent results.  It is important to
   note that when the discovery process is redone, it should not



Rosenberg, et al.           Standards Track                    [Page 20]

RFC 3489                          STUN                        March 2003


   generally be done from the same local address and port used in the
   previous discovery process.  If the same local address and port are
   reused, bindings from the previous test may still be in existence,
   and these will invalidate the results of the test.  Using a different
   local address and port for subsequent tests resolves this problem.
   An alternative is to wait sufficiently long to be confident that the
   old bindings have expired (half an hour should more than suffice).

10.2 Binding Lifetime Discovery

   STUN can also be used to discover the lifetimes of the bindings
   created by the NAT.  In many cases, the client will need to refresh
   the binding, either through a new STUN request, or an application
   packet, in order for the application to continue to use the binding.
   By discovering the binding lifetime, the client can determine how
   frequently it needs to refresh.



































Rosenberg, et al.           Standards Track                    [Page 21]

RFC 3489                          STUN                        March 2003


                        +--------+
                        |  Test  |
                        |   I    |
                        +--------+
                             |
                             |
                             V
                            /\              /\
                         N /  \ Y          /  \ Y             +--------+
          UDP     <-------/Resp\--------->/ IP \------------->|  Test  |
          Blocked         \ ?  /          \Same/              |   II   |
                           \  /            \? /               +--------+
                            \/              \/                    |
                                             | N                  |
                                             |                    V
                                             V                    /\
                                         +--------+  Sym.      N /  \
                                         |  Test  |  UDP    <---/Resp\
                                         |   II   |  Firewall   \ ?  /
                                         +--------+              \  /
                                             |                    \/
                                             V                     |Y
                  /\                         /\                    |
   Symmetric  N  /  \       +--------+   N  /  \                   V
      NAT  <--- / IP \<-----|  Test  |<--- /Resp\               Open
                \Same/      |   I    |     \ ?  /               Internet
                 \? /       +--------+      \  /
                  \/                         \/
                  |                           |Y
                  |                           |
                  |                           V
                  |                           Full
                  |                           Cone
                  V              /\
              +--------+        /  \ Y
              |  Test  |------>/Resp\---->Restricted
              |   III  |       \ ?  /
              +--------+        \  /
                                 \/
                                  |N
                                  |       Port
                                  +------>Restricted

                 Figure 2: Flow for type discovery process







Rosenberg, et al.           Standards Track                    [Page 22]

RFC 3489                          STUN                        March 2003


   To determine the binding lifetime, the client first sends a Binding
   Request to the server from a particular socket, X.  This creates a
   binding in the NAT.  The response from the server contains a MAPPED-
   ADDRESS attribute, providing the public address and port on the NAT.
   Call this Pa and Pp, respectively.  The client then starts a timer
   with a value of T seconds.  When this timer fires, the client sends
   another Binding Request to the server, using the same destination
   address and port, but from a different socket, Y.  This request
   contains a RESPONSE-ADDRESS address attribute, set to (Pa,Pp).  This
   will create a new binding on the NAT, and cause the STUN server to
   send a Binding Response that would match the old binding, if it still
   exists.  If the client receives the Binding Response on socket X, it
   knows that the binding has not expired.  If the client receives the
   Binding Response on socket Y (which is possible if the old binding
   expired, and the NAT allocated the same public address and port to
   the new binding), or receives no response at all, it knows that the
   binding has expired.

   The client can find the value of the binding lifetime by doing a
   binary search through T, arriving eventually at the value where the
   response is not received for any timer greater than T, but is
   received for any timer less than T.

   This discovery process takes quite a bit of time, and is something
   that will typically be run in the background on a device once it
   boots.

   It is possible that the client can get inconsistent results each time
   this process is run.  For example, if the NAT should reboot, or be
   reset for some reason, the process may discover a lifetime than is
   shorter than the actual one.  For this reason, implementations are
   encouraged to run the test numerous times, and be prepared to get
   inconsistent results.

10.3  Binding Acquisition

   Consider once more the case of a VoIP phone.  It used the discovery
   process above when it started up, to discover its environment.  Now,
   it wants to make a call.  As part of the discovery process, it
   determined that it was behind a full-cone NAT.

   Consider further that this phone consists of two logically separated
   components - a control component that handles signaling, and a media
   component that handles the audio, video, and RTP [12].  Both are
   behind the same NAT.  Because of this separation of control and
   media, we wish to minimize the communication required between them.
   In fact, they may not even run on the same host.




Rosenberg, et al.           Standards Track                    [Page 23]

RFC 3489                          STUN                        March 2003


   In order to make a voice call, the phone needs to obtain an IP
   address and port that it can place in the call setup message as the
   destination for receiving audio.

   To obtain an address, the control component sends a Shared Secret
   Request to the server, obtains a shared secret, and then sends a
   Binding Request to the server.  No CHANGE-REQUEST attribute is
   present in the Binding Request, and neither is the RESPONSE-ADDRESS
   attribute.  The Binding Response contains a mapped address.  The
   control component then formulates a second Binding Request.  This
   request contains a RESPONSE-ADDRESS, which is set to the mapped
   address learned from the previous Binding Response.  This Binding
   Request is passed to the media component, along with the IP address
   and port of the STUN server.  The media component sends the Binding
   Request.  The request goes to the STUN server, which sends the
   Binding Response back to the control component.  The control
   component receives this, and now has learned an IP address and port
   that will be routed back to the media component that sent the
   request.

   The client will be able to receive media from anywhere on this mapped
   address.

   In the case of silence suppression, there may be periods where the
   client receives no media.  In this case, the UDP bindings could
   timeout (UDP bindings in NATs are typically short; 30 seconds is
   common).  To deal with this, the application can periodically
   retransmit the query in order to keep the binding fresh.

   It is possible that both participants in the multimedia session are
   behind the same NAT.  In that case, both will repeat this procedure
   above, and both will obtain public address bindings.  When one sends
   media to the other, the media is routed to the NAT, and then turns
   right back around to come back into the enterprise, where it is
   translated to the private address of the recipient.  This is not
   particularly efficient, and unfortunately, does not work in many
   commercial NATs.  In such cases, the clients may need to retry using
   private addresses.

11. Protocol Details

   This section presents the detailed encoding of a STUN message.

   STUN is a request-response protocol.  Clients send a request, and the
   server sends a response.  There are two requests, Binding Request,
   and Shared Secret Request.  The response to a Binding Request can





Rosenberg, et al.           Standards Track                    [Page 24]

RFC 3489                          STUN                        March 2003


   either be the Binding Response or Binding Error Response.  The
   response to a Shared Secret Request can either be a Shared Secret
   Response or a Shared Secret Error Response.

   STUN messages are encoded using binary fields.  All integer fields
   are carried in network byte order, that is, most significant byte
   (octet) first.  This byte order is commonly known as big-endian.  The
   transmission order is described in detail in Appendix B of RFC 791
   [6].  Unless otherwise noted, numeric constants are in decimal (base
   10).

11.1  Message Header

   All STUN messages consist of a 20 byte header:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      STUN Message Type        |         Message Length        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+