Exploring the DMCC Dashboard
One of the best things about DMCC Dashboard is the freedom it gives you to explore the DMCC API without having to write test code or poke around in the debugger. Let's walk through how you might use the dashboard to access a few device control features through DMCC. We'll place a call from the Softphone by using the DMCC Dashboard to effectively press buttons on the device.

The first requirement is to start a session with DMCC (Figure 2). Since we don't have a session yet, there's not much we can do, so many of the controls on the dashboard are disabled. As we step through the process, different fields will become enabled to show that those functions have become available. You can change this behavior (it's on by default), but it's a helpful feature and is one way that the DMCC Dashboard helps to guide you through the proper sequence of operations.

Figure 2. Starting up a session in the DMCC Dashboard. Fields related to the API call are automatically highlighted.

As you move the cursor over the "Start Appl. Session" button, a tool tip appears that tells you about the API. At the same time, the fields that represent parameters for that call are highlighted, letting you know what you need to supply. To start a session, we need the DMCC socket, login information, and a few other parameters, all of which we've supplied (some, such as Session Name and Session Duration, are defaulted by DMCC Dashboard). Tool tips and field highlighting are available for every operation in the dashboard, both making it easier to find your way through a task and making the DMCC Dashboard a valuable source of API documentation in its own right.

Clicking the button calls the StartApplicationSession method of the .NET API. Figure 3 shows the XML tracking pane, which displays the messages exchanged between the dashboard and the DMCC service when the API is called. At the bottom of Figure 3 you can also see the Events pane, which shows the events fired by the SDK when the start application session response was received.

Now that we've got a session established, we can continue with the additional steps we need to take to complete the setup sequence. There's a sequence you'll often encounter when starting up a task in the DMCC Dashboard:

1. Start the application session.
2. Get one or more device IDs.
3. Start monitors.Register a terminal for each device ID.

The DMCC Dashboard emphasizes this common sequence by laying out the four buttons required for these steps from left to right in a row, starting with "Start Appl. Session." (And the buttons to unwind these operations at shutdown are on the next row, in the opposite order).

Figure 3. Monitoring XML traffic and events in the DMCC Dashboard.

To control the IP Softphone, we enter its extension and then call GetDeviceID, which returns a string that we can use to refer to the device in subsequent calls. We then start up a set of monitors on the server that register our interest in receiving certain monitor events (for example, when the display on the phone changes).

Finally, we register the terminal with the server. Since we are working with an actual device that's already registered with Communication Manager (the Softphone), we register the terminal in Dependent mode. The dependency mode and media control settings are API parameters that must be set at registration time and that determine the kinds of access granted to the application. These can be set in the dashboard through a pair of combo boxes.

With the terminal registered, we can proceed to pressing buttons on the device to complete the call. Clicking a key on the key pad calls the PressButton API and results in a ButtonPress XML message sent to the AE Services server. This is just like clicking buttons on the Softphone itself, so when we click 4-0-1-0-0 in sequence on the DMCC Dashboard keypad the Softphone goes off hook and calls the simulated phone at extension 40100.

Let's expand on this simple example a little bit and see how you might use DMCC dashboard for call recording. As before, we need to go through the setup sequence to register terminals. For call recording, we'll register two devices: first, we'll register the IP Softphone in Dependent mode, as before. Then we'll register a second terminal in Independent mode, and for that registration we'll set the media control to "Server Mode." This will allow us access to server media for that second device.

To keep things simple, we'll just make a call from the second terminal (using it as the recording device) to the Softphone, and record the message spoken at the Softphone for later playback. To do this we use the Make Call button on the dashboard's Call Control tab to place a third-party call between the two stations.

Once the call is established, we can start recording. All we need to do is supply a filename (this will be a .wav file on the server) and click Start on the Server Media tab. This calls the StartRecording API. To complete recording, we click Stop. At that point, the .wav file we specified is stored on the server for later playback.

At some later time our hypothetical application would call a number and play back the recorded message. We can simulate that by using MakeCall again, specifying the server file to play and then clicking Play, which calls the StartPlaying API.

In a more sophisticated call recording application, you might instead monitor the first device for inbound or outbound calls. When a call is initiated, you could set up to receive a forked media stream for recording, or conference in an additional recording device as in a three-party call (there is a sample application in the SDK that does just this).

There is much more to DMCC dashboard than is covered in these simple examples, including using DMCC call control APIs for conferencing and call transfers, and dialing directly using the DMCC Dashboard itself as a softphone. And there are, of course, dozens of controls that we haven't mentioned on the DMCC Dashboard's seven tabs that allow you to exercise nearly all of the capabilities of the DMCC service.

Monitor, Prototype, and Test
As we've seen, the DMCC Dashboard can track XML messages exchanged between clients and the AE Services server. There are two points about XML monitoring in the dashboard that make it an especially valuable diagnostic and debugging tool. First, the traffic you see is not limited to the DMCC Dashboard client; monitors are installed server-side. This means that you can monitor events at remote stations connected to the same Avaya Communication Manager and AE Services servers (subject to security restrictions). Second, the DMCC Dashboard allows you to send arbitrary XML to the DMCC service, so you can modify messages from the trace to see what effect these changes have.

The DMCC Dashboard can be used to prototype simple applications. You can step through a series of API calls in the dashboard, and then use XML and events from the log as a guide as you build the feature into your application. If you are programming to the XML API directly (rather than through a SDK), you can also use the XML from DMCC Dashboard as a template for building your own messages.

DMCC Dashboard includes an automated testing facility. Each button click is recorded in the dashboard, along with the full context of the API call (including the contents of fields in the dashboard). You can save these recorded operations in an XML script, and later edit or reload and replay the script. Dashboard scripts could be used as part of a network test, for example, or as regression tests for your application.

Whether you're using the .NET SDK or not, if you're developing for Avaya AE Services using DMCC, get a copy of DMCC Dashboard. The benefits for .NET and XML developers are clear. Java developers, too, can use dashboard to get a handle on the DMCC Java API, which is similar to the DMCC API for .NET.