Please login or register to access secure site features.

Note: By continuing to use DevConnect Program Services you agree to our latest Registered Member Terms.

Sign in using DevConnect ID

Forgot password?

Trouble logging in?

Submit a ticket for Registration Support.

I have an SSO ID

?
sign in

Don't have a DevConnect or SSO ID ?

Create a DevConnect account or join the program.

register now
^
Messages posted by: JohnBiggs
Forum Index » Profile for JohnBiggs » Messages posted by JohnBiggs
Message
1) yes
2) all of them (SIP, IP), (96XX and 46XX and softphones)

You will need to do some re-configuring of the simulator so you can connect the IP hard phones to it. By default it uses VMware host only mode. There are instructions bundled with the Simulator named "networking instructions.pdf" that guide you through changing the configuration from host only to one of two networked solution (either private lan, or corporate lan).

One other note is that the simulator limits you to 10 IP phones, being connected at any moment in time.
Are you asking about IP phone registrations or call center Agent Login?

The answers to date have been around IP phone registration. However there is some functionality that may interest you in an API. There is a Special Application (SA8420) -- SA's require a license to be enabled which is a for fee item -- that supports 'ip-hoteling'. ip-hoteling allows an administrator to change the extension associated with one IP phone into another at the SAT. 

IP-hoteling leverages features such as Personal Station Association (PSA) and Terminal Translation Installation (PSA) which also need licensed on in the system and provisioned.

There is an AES API called System Management Service (SMS). It supports a subset of the commands allowed at the System Access Terminal. In release 4.0 of AES working with 3.X and 4.0 of CM, this API supports one of the required commands associated with the SA8420 service (enable ip-registration). The other commands allow an even more flexible solution to be created.

If you accept the constraint that the terminal must be registered in the first place (say to a dummy extension), the ip-hoteling service can switch the registration to another extension via the SMS API.

If you can not accept that constraint, then you could utilize a telnet session and ?screen scrape? to invoke the more robust command set so you could utilize the enable/disable ip-reg-tti and list tti-ip-station which allows associations to be made from unnamed registered IP stations.  Screen scraping a problematic way to implement a service due to the changes that regularly get made to the information presented, and layout of various screens from one release to the next and is not a recommended methodology for application development.

SMS is a web service and the application uses SOAP to send the requests to the AES where they are reformatted and sent on to CM. CM sends the response to AES which sends a SOAP reply to the application.


Alternatively if you are asking about call center Agent login and logout, both JTAPI/TSAPI and DMCC APIs can use feature access codes to log agents in and out. DMCC can also push buttons on the station it is monitoring which allows a more static configuration behavior (note you need to use abbreviated dialing buttons for agent login and logout). An application can use SMS to discover the feature access codes provisioned on CM, or they can be provisioned into the application directly as it is installed.
Jigar,
    The extenstion 48001 is a VDN (vector directory number), you need to send the request with the extenstion of a hunt group. On the simulator use 49001. That is what we have been testing with. ACD is auto matic call distribution which is another term for a hunt group (so is split by the way). I do not know why there are so many terms for the same concept, probably different industry groups each putting their personal stamp on something.
Jigar,
     We reproduced the fault you are seeing when we utilized the JTAPI exerciser. We tried deleting and adding the aessim login back without success. We did however create a new login and used it to issue the request successfully.

To add a new login, start the AES OA&M Web page and login with the avaya login.  Then select 
User Management --> User Management --> Add User.
Set the User Id, Common Name, Surname, User Password and Confirm Password fields. Set ST User to "yes", and retry your query.

I will look deeper into this fault in the simulator SDB and try to have it resolved in the June release.
Jigar,
     using the TSAPI exerciser I can query the ACD status (using ATT_QUERY_ACD_SPLIT) of  split x49000 from the AES-CM-SES Simulator and see the number of calls in queue successfully. Admittedly this is not a JTAPI request, but in my mind that absolves the simulator and moves the question into the differences between JTAPI and TSAPI capabilities and  invocation.  

    I assume you are enamored with the use of JTAPI over TSAPI for one reason or the other.  Like I said earlier I can look deaper into this on Monday.
Jigar
   I can dig into what may be occuring with the SDB on Monday when I am in the office and see what may be preventing the method from working for you on the simulator. To the best of my knowledge the SDB was already enabled when you installed the simulator. What credentials (login) are you using with the TSAPI session ?
which version of the AES are you working with (type swversion at the Linux command prompt)?

What do you mean that the AES is configured with two services? Typically a serice just does a get service provider request, the AES is unaware of that service prior to the request.  Does the problem happen when one is not connected and the other is trying to connect? Does it matter which of the two apps is offline? Is everything ok when one app has a service link and the second is trying to connect (or more likely you can not get to that state)

When you say AES is configured are you talking about provisioned users? Switch Connections (they are AES to CM links though)? Something else?
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
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.
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)
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
Scott, 
    You may be able to retrieve the abbreviated dial information you are looking for by using the System Management Service API. SMS is a web based SOA service which will allow you to retrieve information related to how a station is configured. from an application. Specifically the response to a display station XXX command via the SAT.  True abbreviated dial information are actually kept on a different form which is not available via SMS in AES release 3.1. These unsupported forms are the "change abbreviated-dialing xxx yyy" forms.

The SMS SDK is available via the devconnect web portal (look for System Management Service on this page:
https://devconnect.avaya.com/public/dyn/d_dyn.jsp?fn=125

The Avaya IP softphone gets the information it gets via a protocol called PASTE which I am fairly certain is Avaya propritary.
try looking on the page I referenced (just cut and paste into the browser window you are in right now), and then look for

The TelephonyServiceWebPortal sample application is designed to demonstrate the use of each of the Application Enablement Services Telephony Web Service requests in the context of a web application. Using this application users can lookup phone numbers from an LDAP database and then call, transfer, or conference any of the matching database entries from their phone set 
 
 Application Notes for the Telephony Service Web Portal Sample Application (1.47Mb .pdf) 
The Device Media and Call Control (DMCC) API on the Applications Enablement Server (AES) can allow an application to access most button push requsts. Avaya''s TSAPI /JTAPI implementation is mostly limited to third party behviors on calls at devices (i.e. the ButtonPressEv, SpeakerVolumeEv) are not implemented in Avaya''s TSAPI/JTAPI implementation

See the thread labled "How do you call other buttons" for a longer discussion on what buttons an application can and can not "see" pushed through the DMCC API (i.e. you won''t see speakerphone volumn up/down as it is implemented locally in the phone), you can see feature function buttons.
There is also sample code for System Management Service and Telephony Service contained in the respective SDKs.
 
Forum Index » Profile for JohnBiggs » Messages posted by JohnBiggs
Go to: