Hello,

I am developing a NT service that needs to call a user, play a wave file to them, acccept a DTMF response, and then transfer the call to another number/device based on the DTMF response. It looks like TSAPI is the only API designed for 3rd party control, but it doesn''t appear to support audio/DTMF (that I could see). Therefore, can anyone tell me what API I should be using to accomplish the functionality described above, and point me to some documentation?

Thanks,
Chris

The .NET DMCC API can do all of that. You will need to have the station who is playing the wave file, listening for tones, and doing the transfer in "Server Media" mode.

The .NET DMCC API is not ''generally available'' so use it with caution. 

You can also do all of this using the XML interface to DMCC.

you can also use the java version of the DMCC SDK

You can either choose to serve up the audio from your client application machine, and do your own tone detection if you use client media mode since your application machine (or a machine of your choosing) will be the source and sync for the RTP media,

OR

you can utilize services provided by the AE Server to play a wave file and do DTMF tone detection for your application. Of course this puts load on the AES and you can not scale as large nor run as many applications against the AES as you could if your application hosted the RTP functionality.

You can find the documentation on the devconnect web portal. There is also sample code (the simple IVR sample is probably a good starting point if you want to code in java), that demonstrates much of the capabilities you want to implement (the missing piece is transfer although it does do a conference as I recall).  

Log into the portal and follow the links for Avaya Product Information / Information / Documentation /SDKs,
 then 
Premium Content sort by Avaya Platform
then
Avaya Communication Manager 
 AES, DMCC (formerly CMAPI), TSAPI, ASAI, DEM, and SIP 

then locate the SDK version you want to work with under the
Software 3.1 
SDKs for Clients 

heading

I forgot to mention that the .NET API, the Java API and straight XML from the language of your choice can all be used to accomplish your task the choice is yours. We were not trying to indicate that one API had advantages over the others (with the exception that .NET is beta at the moment).

The programmers guides for XML and Java are good starting places to learn more about the API and are available via the portal at the location I pointed to for the SDKs. There is also a training course available for the DMCC API available through the web portal as well. The relevent section is about one hour long and contains information similar to that which is contained in the programmers guide. look for the devconnect Training link on your home page when you login to the portal. and follow the link for "Avaya Application Enablement Services - In-Depth Technical Training" Take the module on DMCC (formally CMAPI)

Thanks for the information. I''ll start looking through the DMCC documentation. We do all of our development in C#, so I''m definitely interested in the .Net API. Any idea when it will be released for production use? Also, I need to manage multiple calls, answer incoming calls, and detect when calls are disconnected. Can you think of any issues I might face trying to do this with DMCC?

Thanks,
Chris

Chris:

I will try to find out a projected date on when the .NET API will be available for production use.

I don''t see any reason why it would not work for what you have described. A few months ago we wrote a sample load generator application (in C# *using the .NET API) which managed a couple hundred simultaneous calls.

I''ve been reading through the DMCC documentation and looking at the examples. It has lead me to a couple of questions about what we are trying to accomplish. We have a custom audio switch that we are going to interface to the PBX using a T1. This is audio only, so there is no smart device at this extension, which means when I transfer calls from the incoming extension, I need to (via DMCC) answer the call at the transfer extension. However, the audio still needs to flow down the T1. It looks like this may be possible, but the documentation has me a little worried when it says that calls are made/answered using the devices physical elements. Does this really mean that its using the physical device, or the softphone instance? If the latter, I assume I can represent our T1 connection as a softphone instance? I also need to insert myself in the middle of outbound calls on the extension(s) to which our audio switch is connected. I need to make the call using DMCC, but have the audio still flow through the T1. I think the answer to the question above will answer this one as well, but wanted to mention it just incase.

Finally, if I make the call for the device and decide I want to manipulate the media stream, does the physical device (T1) still recieve the stream as well, or would I have to somehow "transfer" the stream to the device when I was done with it?

I''m new to phone interfaces, so I hope this makes sense.

Thanks,
Chris

Chris:

I will try to answer your questions. I can appreciate the frustrations you are going through.

When you register a device (device is an extension) one of the things you specify is the media mode.

The media mode simply dictates where the media (RTP data stream) is going to be delivered.

If you specify no media, then shared control is assumed and the media will go to the physical phone that is on someone''s desk. This mode allows you to control the phone but you have no physical access to the media. This is the only mode where the person''s physical phone does not get deactivated.

If you specify "Server Media" then the DMCC will register to CM as a softphone and ALL media will go to DMCC. This will allow you to do things like record a call, play a wave file, listen for digits, etc. In this mode, if there is a phone on a person''s desk it will get deactivated.

If you specify "Client Media" then your DMCC will register with CM as a softphone, HOWEVER, all media will be directed to your application. Therefore, YOU can manipulate the media in any way you want to. You can record it, you can inject media, etc. Your application must provide the logic for doing all this. The ServiceProvider component does not currently provide any capability for manipulating the data. The only thing it does is tell DMCC to pass the media to the destination that you specify.

Finally, there is "Telecommute" media mode. This mode allows you to direct the media to any device that has a phone number. For example, a cell phone.

Chris,
    The insertion of this audio server behind a T1 interface (is that a T1 in packet data mode where RTP is still a possibility, or is it configured as a trunk or perhaps as off premises extensions?) is a new twist to the requirements that we were unaware of previously. I presume it is unable to collect DTMF based on the nature of your questions.  Our previous answers were driven by an impression that you had complete flexibility on the media source, and could use more of the capabilities provided by the DMCC API. While I still think there are a number of ways to approach your development using AES APIs (I am now thinking that TSAPI/JTAPI is best), I think you would be best served by taking advantage of the ability for registered developers to pay for an hour''s worth of support. For those dollars we can make sure we understand the application?s required operating environment, discuss the pros and cons of various approaches (APIs) and make sure you get started on the right "foot" so to speak.

To take advantage of this support option, please send an email to support@developerconnectprogram.com, and in it state you need as described in the forum, say you were on the DMCC form and ask to be escalated to Tier 3 (provide a phone number you are available during USA East Coast business hours).  They will provide you with further instructions. For your knowledge the first hour of this support is $250, subsequent hours are $200. I think we can do a reasonably good job of getting you started with an hours worth of investment.

John/Dave,

Thanks for the information. We have a conference call setup with Avaya and our client for today, though I don''t know if the Avaya participants are technical in nature. I?m just trying to get up to speed so I can talk about this with some level of competency. If we don?t get what we need from this call, I will be sure to setup something with your support group.

Our hardware engineer is developing the T1 interface to our audio switch, so I?ll have to get with him about how exactly that is going work (VIC comes to mind for some reason). The incoming calls will made with Spectralink wireless phones as I understand it. These should support the DMCC API (I would think) However, since the interface to our audio switch is dumb, I am trying to figure out the best way to ?help? it get connected after I transfer the incoming call to its extension.

Thanks,
Chris

Chris,  
   The information I have indicates a VIC (Cisco term for Voice Interface Circuit) is a FXS (Foreign Exchange Station) T1 interface. If that is correct, from CM''s perspective it will ''see'' 24 analog stations. The issue there is going to be you can not drive an analog station off hook programmatically. The individual implementing the voice server is going to have to implement a method of being told to go on/off hook and signal that across the T1 interface. A true FXS can do this, and properly motivated the individual implementing the analog server can as well. On/Off hook is signaled by a change in particular bits being sent in the T1?s signaling stream.

   If I can assume that the voice server can minimally go off hook by itself based on some message sent by your application, then TSAPI or JTAPI will do the rest of your requirements (monitor the delivery of calls to the voice server, initiate calls from the voice server, and collect digits on these calls (either inbound or outbound), and initiate transfers to other extensions.

  It seems strange to us that you would want to design in another server (the voice server) in this day and age (unless it is a pre-existing product). In products being implemented today, the hardware costs (T1 interfaces) can be avoided by bundling these capabilities in a system that provides the voice via an RTP stream. A single server can terminate/originate many (50 or more) such streams simultaneously without the hardware costs of the T1 interface and the voice server. Most IT departments want solutions involving as few servers and as little hardware as possible. It is possible that your application also runs on this voice server making the number of servers a non-issue, but the cost of the T1 interface remains (maintenance spares, for both your server and CM, etc). It also precludes easily moving the server since CM and the voice server must be connected by the T1 wiring, and can not take advantage of the IP network.

I hope you got the information you need from today?s meeting, but if not, please know that we are here to help you be successful in your application development, and take advantage of the support services we have to offer.

John/Dave