Enable checkpoint logging events

Many companies use statistics from the access log to bill customers. If your programming includes live events or 24/7 programming, the events you use to calculate billing might not occur within a billing cycle. To solve this problem, you can enable checkpoint events. Checkpoint events log bytes periodically during an event. The following are available as checkpoint events: connect-continue, play-continue, and publish-continue.

You must enable checkpoint events at the server level in the Server.xml file. You can disable checkpoints at the vhost and application level in the Vhost.xml and Application.xml files. You can also override the logging interval at the vhost and application levels. For more information, see the comments in the XML files located in the rootinstall/conf folder.

  1. Open the rootinstall/conf/Server.xml file in a text editor.

  2. Locate the Root/Server/Logging/Checkpoints element:

    <Checkpoints enable="false"> <CheckInterval>60</CheckInterval> <LogInterval>3600</LogInterval> </Checkpoints>
  3. Set the Checkpoints enable attribute to true, like this: <Checkpoints enable="true">.

  4. You can optionally set values for the CheckInterval and LogInterval elements to indicate how often the server should check for and log events.

  5. Save and validate the file.

  6. Restart the server.

Allow Administration API methods to be called over HTTP

You must specify each Administration API method that may be called over HTTP.

  1. Open the rootinstall/conf/ams.ini file.

  2. Set the USERS.HTTPCOMMAND_ALLOW parameter to a comma-delimited list of APIs, and restart the server. The default value is ping. For more information, see Allow (HTTPCommands).

Allow application debugging connections

To play back streams and obtain data from shared objects, the Administration Console must make a special debugging connection to the server. By default, the server does not allow this connection.

  1. Open the Application.xml file.


    You can set these values in an Application.xml file at the VHost level or at the application level. To set the value at the application level, copy an Application.xml file to the application’s folder.

  2. Locate the following XML:

  3. Set the AllowDebugDefault element to true.


    Debug connections count against license limits.

  4. Save and validate the file.

  5. Restart the server.

Configuring IPv6

IPv6 (Internet Protocol version 6) is a new version of Internet Protocol that supports 128-bit addresses. The current version of Internet Protocol, IPv4, supports 32-bit addresses. IPv6 alleviates the address shortage problem on the Internet. A system that only runs IPv6 can't communicate with a system that only runs IPv4.

By default, Adobe Media Server runs in IPv4 mode, even if the operating system is configured for IPv6. When Adobe Media Server runs in IPv6 mode, hostnames specified in Adaptor.xml are resolved to IPv4 and IPv6 addresses.


In Red Hat® Linux systems, you must update the NETWORKING_IPV6 value in /etc/sysconfig/network when installing or uninstalling IPv6.

Activate IPv6 on the network interface card.

IPv6 is embedded in all operating systems that the server supports. You may need to activate IPv6 on the interfaces. For more information, see the operating system’s Help.

Allow the server to listen on IPv6 sockets.

  1. Open the rootinstall/conf/Server.xml file in a text editor.

  2. Locate the NetworkingIPv6 tag and set enable to "true":

    <NetworkingIPv6 enable="true" />
  3. Save the file and restart the server.

Enclose numeric IPv6 addresses in URLs in brackets.

Wherever a numeric IPv6 address is used in a client-side script, server-side script, or in the server configuration files, enclose it in brackets:


You must specify the interface zone index for a link-local address:



It’s a good idea to register the RTMP, RTMPS, and RTMPE protocols with a network services database and use a service name (or decimal port number, if necessary) in the server configuration files.

Check the logs

When the server starts, it logs available stack configuration, host name, and all available IP addresses for the host in the master.xx.log, edge.xx.log, and admin.xx.log files (located in the rootinstall/logs/ directory). The following x-comment fields from a sample edge log file indicate that the IPv6 stack and the IPv4 stack are available, and that the server host has dual addresses and is listening on both interfaces:

 AMS detected IPv6 protocol stack! 
 AMS config <NetworkingIPv6 enable=true> 
 AMS running in IPv6 protocol stack mode! 
 Host: amsqewin2k3-02 IPv4: IPv6: fe80::204:23ff:fe14:da1c%4 
 Listener started ( _defaultRoot__? ) : 19350/v6 
 Listener started ( _defaultRoot__? ) : 19350/v4 
 Listener started ( _defaultRoot__? ) : 1935/v6 
 Listener started ( _defaultRoot__? ) : 1935/v4

On Red Hat Linux, the edge logs display only the highest IP version the socket listeners are using, even if the socket listeners accept connections over both IPv4 and IPv6. In the previous example, only the v6 entries would be displayed.

On IPv6-enabled Linux, if you are using an host name that resolves to IPv4 host name with an RTMPT or RTMPTE connection, configure the Adaptor.xml appropriately to resolve connections quickly. See HTTPIdent2.

Defining Application object properties

You can define properties for the server-side Application object in the server’s Application.xml configuration files. If you define properties in the default Application.xml file, the properties are available for all applications on a virtual host. If you define properties in an Application.xml file in an application folder, the properties are available only for that application.

To define a property, create an XML tag in the ScriptEngine section of the Application.xml file. The property name corresponds to the tag’s name, and the property value corresponds to the tag’s contents.

For example, the following XML fragment defines the properties user_name and dept_name, with the values jdoe and engineering, respectively:


To access the property in server-side code, use the syntax in either of these examples:



The properties you define are accessible from application.config.property, not from application.property.

For example, given the previous XML fragment, the following trace() statements are valid:

 trace("I am " + application.config.user_name + " and I work in the " + application.config.dept_name + " department."); 
 trace("I am " + application.config["user_name"] + " and I work in the " + application.config["dept_name"] + " department.");

The output from either statement would be as follows:

 I am jdoe and I work in the engineering department.

You can also use environment variables and symbols you define in the substitution.xml file. For example, assume that the environment variable COMPUTERNAME is equal to jsmith01, and you have defined a symbol named DEPT in the substitution.xml file:


In addition, the following XML appears in the Application.xml file:


In a server-side script, the following trace statements are valid:

 trace("My computer's name is: " + application.config.compName); 
 trace("My department is: " + application.config.dept);

The output is as follows:

 My computer's name is: jsmith01 
 My department is: Engineering


Server-side ActionScript trace()statements display in the Live Log panel of the Administration Console.

Configure or disable native bandwidth detection

The server can detect a client’s bandwidth in the core server code (called native bandwidth detection), or in a server-side script (called script-based bandwidth detection). Native bandwidth detection is faster than script-based because the core server code is written in C and C++. Also, with native bandwidth detection, if a client connects through edge servers, the outermost edge server detects the bandwidth, which results in more accurate data. Native bandwidth detection is enabled and configured by default.

The server detects bandwidth by sending a series of data chunks to the client, each larger than the last. If desired, you can configure the size of the data chunks, the rate at which they’re sent, and the amount of time the server sends data to the client. For more information about detecting bandwidth in an application, see the Developer Guide.

  1. Open the Application.xml file.


    You can set these values in an Application.xml file at the VHost level or at the application level. To set the value at the application level, copy an Application.xml file to the application’s folder.

  2. Locate the following code:

             <BandwidthDetection enabled="true"> 


    To disable native bandwidth detection, set the enabled attribute to false and restart the server.

  3. Edit the following elements.




    Set the enabled attribute to "true" or "false" to turn this feature on or off.


    The maximum rate in Kbps that the server sends data to the client. The default value is -1, which sends the data at whatever rate is necessary to measure bandwidth.


    The amount of data in bytes that the server sends to the client. To detect the client’s bandwidth, the server attempts to send a series of random blocks of data to the client, each time sending this much more data. For example, x bytes are sent, followed by 2x bytes, followed by 3x bytes, and so on until MaxWait time has elapsed.


    The number of seconds the server sends data to the client. Increasing this number provides a more accurate bandwidth figure, but it also forces the client to wait longer.

  4. Save and validate the Application.xml file.

  5. Restart the server.

This work is licensed under a Creative Commons Attribution-Noncommercial-Share Alike 3.0 Unported License  Twitter™ and Facebook posts are not covered under the terms of Creative Commons.

Legal Notices   |   Online Privacy Policy