<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE configuration SYSTEM "configuration.dtd">

<!-- Sample configuration file, version 1.0.3 and above. -->
<!-- Configuration table starts always starts with "configuration"
     element as root -->

<configuration>

   <!-- General configuration has a fixed list of elements. Note
        that information in the general section includes to info 
        announced by this nodes to it's peers during capabilities
        exchange. -->
   <general>

      <!-- Product, version and vendor ID information specified
           here will be embedded in the CER message -->
      <product>Open Diameter</product>

      <!-- Software revision number. For Open Diameter
           this is equivalent to the Firmware-Revision AVP
           in the CER -->
      <version>1</version>

      <!-- Vendor id of diameter entity broadcast to 
           peers in the CER -->
      <vendor_id>0</vendor_id>

      <!-- List of locally supported vendor id's. Note
           that advertisement of supported vendor id's
           is needed when routing messages with vendor
           specific application id's -->
      <supported_vendor_id>0</supported_vendor_id>
      <supported_vendor_id>1</supported_vendor_id>

      <!-- List of locally supported auth application 
           id's. This contains one or more auth application
           id's that will be broadcasted to peers. -->
      <auth_application_id>1</auth_application_id>
      <auth_application_id>2</auth_application_id>

      <!-- List of locally supported acct application
           id's. This contains one or more auth application
           id's that will be broadcasted to peers. -->
      <acct_application_id>3</acct_application_id>
      <acct_application_id>4</acct_application_id>

      <!-- List of locally supported vendor specific application
           id's. This contains one or more vendor specific application
           id's that will be broadcasted to peers.  Each vendor
           specifc application id will contain one or more vendor
           id's (RFC 3588) and exactly one auth or acct application
           id -->
      <vendor_specific_application_id>

          <!-- List of vendor id's advertized by this diameter
               entity -->
          <vendor_id>31</vendor_id>
          <vendor_id>32</vendor_id>
          <vendor_id>33</vendor_id>

          <!-- Exactly one instance of the
               vendor's auth application id -->  
          <auth_application_id>1</auth_application_id>

          <!-- Or Exactly one instance of the
               vendor's acct application id -->  
          <acct_application_id>4</acct_application_id>
      </vendor_specific_application_id>
      <vendor_specific_application_id>
          <vendor_id>41</vendor_id>
          <vendor_id>42</vendor_id>
          <vendor_id>43</vendor_id>
          <auth_application_id>5</auth_application_id>
          <acct_application_id>6</acct_application_id>
      </vendor_specific_application_id>
   </general>

   <parser> 
      <!-- Path and filename of dictionary file. The path MUST be
           a full path or relative to the location of this configuration
           file -->
      <dictionary>config\dictionary.xml</dictionary>
   </parser>

   <!-- Transport management section. This section contains 
        to local diameter transport information, peer table
        and route table -->
   <transport_mngt>

      <!-- Diameter entity identity. Note that a running open
           diameter application will use the identity string 
           instead of calling OS dependent gethostname functions
           to determine it's identity. Hence, users MUST enter
           a valid resovable entry for this string -->
      <identity>nas_server</identity>

      <!-- Diameter realm. As with identity, a running open
           diameter application uses the realm string to
           identify its domain of reponsibility. This allows
           virtual domains to exists within a single host
           where multiple open diameter entities are running
           with different realm configuration --> 
      <realm>research.org</realm>

      <!-- Diameter TCP listening port. Port number to listen
           to for peer connection request. When using virtual
           domains, make sure each entity listens to different
           port numbers -->
      <tcp_listen_port>1812</tcp_listen_port>

      <!-- Diameter SCTP listening port. Port number to listen
           to for peer connection request. When using virtual
           domains, make sure each entity listens to different
           port numbers -->
      <sctp_listen_port>1813</sctp_listen_port>

      <!-- Enables or disables IPv6 support for this stack -->
      <use_ipv6>0</use_ipv6>

      <!-- Watchdog timeout. Interval between watchdog messages 
           -->
      <watchdog_timeout>0</watchdog_timeout>

      <!-- Retry connection interval. Amount of time in between
           attempts to reconnect to a disconnected peer. If the
           value is 0, then no retry attempt will be made.
           -->
      <reconnect_interval>30</reconnect_interval>

      <!-- Max re-connection attempt. Number of times a reconnection
           attempt will be made until it gives up. If the
           value is 0, then no retry attempt will be made.
           -->
      <reconnect_max>30</reconnect_max>

      <!-- Request retransmission interval. Retransmission of
           pending request will be done until max_request_retransmission
           is exceeded. Care should be taken in defining this
           value. A high value (>60) will slow down retransmission,
           a low value (<5) will cause performance issues. If the
           value is 0, then no retransmission attempt will be made.
           -->
      <request_retransmission_interval>10</request_retransmission_interval>

      <!-- Max request retransmission. Maximum number of pending
           request retransmission. Care should be taken in defining this
           value. A high value (>10) will cause too much traffic.
           If the value is 0, then no retransmission attempt will be made.
           -->
      <max_request_retransmission_count>3</max_request_retransmission_count>

      <!-- This is the initial amount of buffer that is pre-allocated for
           message reception. Each time a message is received that does
           not fit this value, the buffer will be enlarged by this value
           multiplied by increments of 1 until the message fits or up to
           a maximum of 10 increments. A default vaule of 2048 is recommended.
           -->
      <receive_buffer_size>2048</receive_buffer_size>

      <!-- Provides a customized list of local host IP 
           addresses that will be advertised to other
           peers during CER/CEA exchange. For SCTP, 
	   the IP addresses MUST be valid addresses
	   for all interface address present in the
	   system. For TCP, only the first IP address
	   will be used.
           -->
      <advertised_host_ip>192.168.1.100</advertised_host_ip>
      <advertised_host_ip>192.168.1.101</advertised_host_ip>
      <advertised_host_ip>192.168.1.102</advertised_host_ip>
      
      <!-- Peer table lists peers that this open diameter 
           application will attempt to connect to on startup.
           Each peer entry contains host, port and tls
           enabled information.  Internally, the peer table 
           are currently configure statically using this section. 
           No dynamic learning is currently available -->
      <peer_table>
          <!-- This defines the expiration time for dynamically
                learned peers -->
          <expiration_time>1</expiration_time>
          <peer>
              <hostname>tari-dhcp163.research.telcordia.com</hostname>
              <port>1812</port>
              <use_sctp>0</use_sctp>
              <tls_enabled>0</tls_enabled>
          </peer>
      </peer_table>

      <!-- Route table list the realm entries that this peer
           will use to resolve message paths. Each entry
           contains the realm name, the peer to send the
           messaage to, the application id of the peer and
           it role (whether a proxy, local .. etc). Note that
           peer_reference element MUST point to an existing
           peer in the peer_table else this route will be
           in-active. Also, a default_route flag can be added
           to a route entry to set the default route. If more
           than one route has a default_route flag set then
           the last entry with this flag set becomes the
           default route -->
      <route_table>
          <!-- Defines the expiration time for dynamically
               learned routes. A value of 0 means no expiration -->
          <expire_time>0</expire_time>

          <!-- A route entry defines a lookup information
               for a diameter message containing destination
               realm AVP's. For more information on diameter
               routing, pls see "Open Diameter Routing Architecture" -->
          <route>
             <!-- Realm that this route serves. MUST be unique to
                   this table --> 
             <realm>other.research.org</realm>

             <!-- The role that this diameter entity will play in
                  resolving messages matching this realm. Valid 
                  values for this elements are:
                   0 (local)    - application acting as local servers
                   1 (relay)    - application acting as relay agent                  
                   2 (proxy)    - application acting as proxy server
                   3 (redirect) - application acting as redirect agent -->
             <role>0</role> 

             <!-- Re-direct host usage. This provides a hint to
                  the receiver of the redirect indication on what
                  to do with the request. If this route is acting
                  as a redirect agent, the Redirect-Host-Usage AVP
                  sent in the redirect indication will have this value.
                  Note that this is valid only if <role> is set to
                  redirect(3). Valid values are:
                    0  DONT_CACHE  - redirect host should not be cached.
                    1  ALL_SESSION - All messages within the same session id
                                     MAY be sent to the redirect host
                    2  ALL_REALM   - All messages destined for the realm
                                     MAY be sent to the redirect host
                    3  REALM_AND_APPLICATION - All messages for the application
                                     requested to the realm specified MAY be
                                     sent to the redirect host
                    4  ALL_APPLICATION - All messages for the application
                                     requested MAY be sent to the redirect host
                    5  ALL_HOST    - All messages that would be sent to the
                                     host that generated the Redirect-Host 
                                     MAY be sent to the redirect host
                    6  ALL_USER    - All messages for the user requested MAY 
                                     be sent to the redirect host -->
             <redirect_usage>0</redirect_usage>

             <!-- For each route, there is a set of applications
                  that are supported. This is used by the base
                  protocol library as the second index to resolving
                  a route for a message --> 
             <application>

                  <!-- Application Id is used as a second key for 
                       routing queries. See details above -->
                  <application_id>1</application_id>

                  <!-- For vendor specific application id's. As
                       per RFC this should be 0 for standard
                       track applications. Otherwise, this
                       value is used in conjunction with
                       application_id as a second search key -->
                  <vendor_id>0</vendor_id>

                  <!-- For each application, there can be a set
                       of servers support it. Each server has
                       a metric associated with it and the 
                       routing engine chooses the server in
                       metric order (0 being highest) -->
                  <peer_entry>

                      <!-- Diameter peer serving this realm and
                           application id. This server name
                           MUST exits in the peer table for
                           this route to be active.
                      <server>server1.research.org</server>
 
                      <!-- Metric value for this server entry.
                           The higher the value, the lower the
                           preference. 0 is the highest value
                           and entries with equal value will 
                           be resolve in the order they are
                           defined in this configuration file -->
                      <metric>1</metric>  
                  </peer_entry>
                  <peer_entry>
                      <server>server2.research.org</server>
                      <metric>5</metric>  
                  </peer_entry>
             </application>
             <application>
                  <application_id>
                       <id>1</id>
                       <type>1</type>
                  </application_id> 
                  <peer_entry>
                      <server>server1.research.org</server>
                      <metric>1</metric>  
                  </peer_entry>
                  <peer_entry>
                      <server>server6.research.org</server>
                      <metric>5</metric>  
                  </peer_entry>
             </application>
          </route>

          <!-- The definition of a default route is the same
                as for any other route. The existance of a
                default route means that all no-match queries
                will result in a default route return -->
          <default_route>
             <realm>research.telcordia.com</realm>
             <role>full</role> 
             <application>
                  <application_id>
                       <id>1</id>
                       <type>1</type>
                  </application_id> 
                  <peer_entry>
                      <server>server1.research.org</server>
                      <metric>1</metric>  
                  </peer_entry>
                  <peer_entry>
                      <server>server2.research.org</server>
                      <metric>5</metric>  
                  </peer_entry>
             </application>
             <application>
                  <application_id>
                       <id>5</id>
                       <type>1</type>
                  </application_id> 
                  <peer_entry>
                      <server>server1.research.org</server>
                      <metric>1</metric>  
                  </peer_entry>
                  <peer_entry>
                      <server>server6.research.org</server>
                      <metric>5</metric>  
                  </peer_entry>
             </application>
          </route>
      </route_table>
   </transport_mngt>

   <!-- Session manager configuration table. This section
        consist of fixed elements that MUST exists -->
   <session_mngt>

      <!-- Dictates the maximum number of concurrent
           sessions that will be maintained by open
           diameter. These include both auth and acct
           sessions -->
      <max_sessions>10000</max_sessions>

      <!-- The following dictates default values for
           auth sessions -->
      <auth_sessions>

         <!-- Stateful session flag. If set to 1, then
              server will enforce stateful sessions and
              clients will hint for stateful sessions. If
              set to 0 or if missing then stateless sessions.

              The value of auth-session state can actually 
              negotiated between client and server. So for 
              the server, auth-session-state is used as follows:

              1. If the request message sent by the client 
                 contains an auth-session-state, the server 
                 check's it's own configuration. If the values 
                 are equal then the server uses that value to 
                 determine statefulness. If the values are not 
                 equal and the server's configuration is set to 
                 AAA_SESSION_STATE_MAINTAINED, then the client's 
                 value determines the statefulness of the session. 
                 If the values are not equal and the server's 
                 configuration is NOT AAA_SESSION_STATE_MAINTAINED 
                 then the server's configuration determines the 
                 statefulness.
              2. If the request message sent by the client does 
                 not contain an auth-session-state, the server 
                 check's the settings of SetAuthSessionState() 
                 function. If SetAuthSessionState() returns a 
                 value, it is used to determine the statefulness 
                 of the session otherwise the configuration value 
                 is used.

              Based on the above policy, the server will return 
              an auth-session-state avp in answer message.

              For the client:

              1. The initial request sent by the client can contain 
                 an auth-session-state value as a hint to the server. 
                 This value is taken from the settings of SetAuthSessionState() 
                 function. If SetAuthSessionState() returns a value, 
                 it is used to as a hint value otherwise the configuration 
                 value is used.
              2. If the answer message sent by the server contains 
                 an auth-session-state, then that value will be used 
                 by the client. If no auth-session-state avp is sent, 
                 then the hint sent in (1) is used.
           -->
         <stateful>1</stateful>

         <!-- Timeout in seconds before a session requires 
              re-authentication. For stateless sessions, a value
              of zero(0) will cause the client session to be maintained
              indefinitely. For stateless server sessions, the library
              will ask you periodically if you want to reclaim the session
              in ReClaimSession() method -->
         <session_timeout>30</session_timeout>

         <!-- Timeout in seconds before a session is 
              terminated regardless of wether it has
              been re-authenticated -->
         <lifetime_timeout>360</lifetime_timeout>

         <!-- Grace period after lifetime timeout before
              full termination -->
         <grace_period_timeout>30</grace_period_timeout>

         <!-- Timeout before subsequent ASR messages
              are sent if the inital attempt fails -->
         <abort_retry_timeout>20</abort_retry_timeout>

      </auth_sessions>

      <!-- The following dictates default values for
           acct sessions -->
      <acct_sessions>

         <!-- Timeout in seconds before a session requires 
              re-authentication -->
         <session_timeout>30</session_timeout>

         <!-- Record interim interval dictated to the client
              if this entity is a server or hint to the server
              if this is a client -->
         <interim_interval>5</interim_interval>

         <!-- Realtime required value dictated to the client
              if this entity is a server or hint to the server
              if this is a client -->
         <realtime>1</realtime>

      </acct_sessions>

   </session_mngt>

   <!-- Log section dictates the verbose levels that
        the library generates as well as target outputs -->
   <log>

      <!-- The following are the available log levels
           that can be "enabled" or "disabled" -->
      <flags>
         <debug>disabled</debug>
         <trace>disabled</trace>
         <info>disabled</info>
      </flags>

      <!-- The following are the target outputs of
           the logs. It can be a combination of
           each entry -->
      <target>
         <!-- enables or disables terminal output -->
         <console>enabled</console>
         <!-- enables or disables syslog output -->
         <syslog>disabled</syslog>
      </target>
   </log>
</configuration>