STUN Server
The Oracle® Enterprise Session Border Controller supports RFC 3489, which defines Simple Traversal User Datagram Protocol (UDP) through Network Address Translators (NATs). Known as STUN, this lightweight protocol that allows applications to:
- Discover the presence and types of both NATs and firewalls between themselves and the public Internet
- Determine the public IP addresses allocated to them by the NAT
SIP endpoints use the STUN protocol to find out the public IP addresses and ports for SIP signaling and RTP media transport. Then they can use the address and port information to create multimedia sessions with other endpoints on the public network.
You can define STUN servers functionality on a per-realm basis, allowing you set up multiple STUN servers.
About STUN Messaging
STUN messages uses six messages, three of which are used for Binding and three of which are uses for the Shared Secret. While it supports all three Binding messages (request, response, and error), the Oracle® Enterprise Session Border Controller does not support the Shared Secret Request or the message integrity mechanism that relies on the shared secret. When acting as a STUN server, the Oracle® Enterprise Session Border Controller responds to STUN binding requests in accordance with RFC 3489 and the rfc3489bis draft.
STUN messages can contain the following attributes:
| Message Type | Attribute Description |
|---|---|
| MAPPED-ADDRESS | Appears in the Binding Response; contains the source IP address and port from which the Binding Request was sent to the STUN server. |
| XOR-MAPPED-ADDRESS | Appears in the Binding Response; contains the MAPPED-ADDRESS information encoded in a way the prevents intelligent NAT devices from modifying it as the response goes through the NAT. |
| SOURCE-ADDRESS | Appears in the Binding Response; contains the IP address and port from which the STUN server sent its response. |
| CHANGED-ADDRESS | Appears in the Binding Response; contains an alternate STUN server IP address and port, different from the primary STUN server port. The STUN client might use this attribute to perform the NAT tests described in RFC 3489. |
| CHANGE-REQUEST | Appears in the Binding Request; instructs the STUN server to send its response from a different IP address and/or port. The STUN client might use this attribute to perform the NAT tests described in RFC 3489. |
| RESPONSE-ADDRESS | Appears in the Binding Request; defines an IP address and port to which the STUN server should send its responses. Appears in the Binding Request; |
| REFLECTED-FROM | Appears in the Binding Response; reflects the IP address and port from which a Binding Request came. Only included when the Binding Request has used the RESPONSE-ADDRESS attribute. |
| UNKNOWN-ATTRIBUTES | Appears in the Binding Error; reflects the mandatory attributes in a Binding Request message that the server does not support. |
| ERROR-CODE | Appears in the Binding Error; indicates an error was detected in the Binding Request, and contains an error code and reason phrase. |
To perform NAT discovery, the endpoint (STUN client) sends a Binding Request to the STUN server port (IP address and port) with which it is configured. The STUN server then returns either a;
- Binding Response—Allows the transaction to proceed
- Binding Error—Halts the transaction, and prompts the client to take the action appropriate to the response given in the ERROR-CODE attribute
When the transaction proceeds and the STUN server sends the Binding Response, that response contains the MAPPED-ADDRESS attribute, which contains the IP address and port from which the server received the request. The STUN client then uses the MAPPED-ADDRESS when sending signaling messages.
For example, a SIP endpoint sends Binding Requests from its SIP port to determine the public address it should place in SIP headers, like the Via and Contact, of the SIP requests it sends. When this SIP endpoint prepares to make or answer a call, it sends Binding Requests from its RTP port to find out the public address it should place in SDP included in an INVITE request or response.
STUN Server Functions on the Oracle® Enterprise Session Border Controller
When the Oracle® Enterprise Session Border Controller receives a STUN message, it first determines its message type. Only STUN Binding Requests are processed, and all other message types are dropped without response.
Then the Oracle® Enterprise Session Border Controller examines the Binding Request’s STUN attributes. It returns error responses if it finds any unsupported mandatory attributes. This takes the form of a Binding Error Response, containing the ERROR-CODE attribute with reason 420 (Unknown Attribute) and an UNKNOWN-ATTRIBUTES attribute with a list of the unsupported attributes. If the Oracle® Enterprise Session Border Controller receives a Binding Request with attributes that do not belong in STUN Binding Requests, it returns the Binding Error Response with the ERROR-CODE attribute with reason 400 (Bad Request).
Next the Oracle® Enterprise Session Border Controller determines whether to follow RFC 3489 procedures or rfc3489bis procedures. If the Transaction ID contains the STUN cookie, then the Oracle® Enterprise Session Border Controller follows rfc3489bis procedures; if not, the it follows RFC 3489 procedures. Because it defines the procedures for testing the NAT to see what type of NAT it is, RFC 3489 procedures are most complex. Issues with reliability of those results have caused testing procedures and attributes to be deprecated in fc3489bis.
RFC 3489 Procedures
The Oracle® Enterprise Session Border Controller (the STUN server) constructs the Binding Response and populates it with these attributes:
- MAPPED-ADDRESS and (optionally) XOR-MAPPED-ADDRESS—Containing the source IP address and port from which the server saw the request come
- SOURCE-ADDRESS—Containing the IP address and port from which the server will send the Binding Response
- CHANGED-ADDRESS—Containing the STUN server port that has a different address and different port from the ones on which the server request was received
If the Binding Request contains a RESPONSE-ADDRESS attribute, the server adds the REFLECTED-FROM attribute with the IP address and port from which the server saw the request come. Then the server sends the Binding Response to the IP address and port in the RESPONSE-ADDRESS attribute. If the RESPONSE-ADDRESS attribute’s IP address and port are invalid, the server sends a Binding Error Response with an ERROR-CODE attribute reason 400 (Bad Request) to the client.
If the Binding Request contains a CHANGE-REQUEST attribute, the server sends Binding Response from the IP address and port matching the information in the CHANGE-REQUEST. The following variations can occur:
- If the IP address and port flags are set, the server selects the server port with a different IP address and different port.
- If only the IP address flag is set, the server selects the server port with a different IP address but with the same port.
- If only the port flag is set, the server selects the server port with the same IP address but with a different port.
The selected server port appears in the Binding Responses’s SOURCE-ADDRESS attribute. When there is no CHANGE-REQUEST attribute, the server uses the server port on which the Binding Request was received.
Finally, the server encodes the outgoing message and sends it to the client at either:
- The destination IP address and port in the REPONSE-ADDRESS attribute, if it was present in the Binding Request.
- The MAPPED-ADDRESS.
rfc3489bis Procedures
If the Binding Request contains the appropriate cookie in its Transaction ID, the server constructs a Binding Response populated with the XOR-MAPPED-ADDRESS attribute. That attribute will contain the source IP address and port from which the server saw the request come. Then the server encodes and sends the message to the client from the IP address and port on which the request was received. The message is sent to the IP address and port from which the request came.
Monitoring
- STUN Server Statistics—You can display statistics for the STUN server using the ACLI show mbcd stun command when the STUN server has been enabled. However, if the STUN server has not been enabled since the last system reboot, the command does not appear and no statistics will be displayed.
- STUN Protocol Tracing—You can enable STUN protocol tracing two ways: by configuration or on demand.
- By configuration—The Oracle® Enterprise Session Border Controller’s STUN protocol trace file is called stun.log, which is classified as a call trace. This means that when the system configuration’s call-trace parameter is set to enabled, you will obtain STUN protocol information for the system. As with other call protocol traces, tracing data is controlled by the log-filter in the system configuration.
- On demand—Using the ACLI notify mbcd log or notify mbcd debug commands, you enable protocol tracing for STUN. Using notify mbcd debug sets the STUN log level to TRACE. You can turn off tracing using the notify mbcd onlog or notify mbcd nodebug commands. Using notify mbcd nodebug returns the STUN log level back to its configured setting.
STUN Server Configuration
You configured STUN servers on a per-realm basis, one server per realm. To support that various NAT tests it describes, RFC 3489 requires that two different IP addresses and two different UDP port numbers be used for each server. So your STUN server will listen on a total of four STUN server ports. Although newer work does away with this requirement, the Oracle® Enterprise Session Border ControllerC supports it for the purpose of backwards compatibility.
For each realm configuration with an enabled STUN server, untrusted ACL entries will be added to forward all packets received on the four STUN Server Port.
To enable STUN server support for a realm:
