Chad,

This is a TSAPI/JTAPI-related question, and unfortunately, the AES forums are not monitored by experts in these topics.
You can however request "to-pay-for" support on such issues via clicking on the "Request Technical Support" link in the left panel on this website.

Best regards,

Tim

Brian,

Thanks for re-posting in this forum!

I have checked internal sources, and it appears as though this information is not available via the functionality exposed through the SMS web service.

You would need to use our JTAPI / TSAPI SDK to come by this information for any given call to an agent.

[Please note that there are licensing costs involved with using TSAPI connections to AES / CM.]

Sorry for the "bad news", but hoping this helps at all,

Tim

Brian,

Would you mind using the AES Web Services Forum for questions regarding SMS (and other web services offered by AES)?
That forum is monitored by different subject matter experts and you are more likely to get a qualified response.

Also, when you post there, would you please give some more detail about the exact type of information you are trying to receive, and in what context (e.g., are you trying to see the CLI info that a station sends out? Are you more interested in the switches routing tables, etc.)?

Thanks in advance,

Tim

Kevin,

Our web services require that you provide user credentials (login / password) before you can submit requests. For our SMS web service, you need to use a valid Communication Manager account's details. For our Telephony Web Service, you need to use a valid account as administered in AES' LDAP database for User Management.

Here comes some sample code for our SMS service:
SystemManagementService smsService = new SystemManagementService();





smsService.Credentials = new System.Net.NetworkCredential("user1@127.0.0.171", "user1pw");

smsService.PreAuthenticate = true;



smsService.sessionID = new AESTestWS.sms.@string();

smsService.sessionID.Text = new string[1];

smsService.sessionID.Text[0] = this.sessionID;



String objectname = "";

Result result;

try

{

submitRequestType req = new submitRequestType();

req.fields = fields.Text;

req.model = model.Text;

req.objectname = objectname;

req.operation = operation.Text;

req.qualifier = qualifier.Text;

result = smsService.submitRequest(req).@return;

smsService.release(null);



}

catch (Exception ex)

{

results.Text = ex.ToString();

return;

}




Hoping this helps,

Tim

PS: Make sure that you set the PreAuthenticate flag on the web service instance, as is required for all .NET WS clients.

Jigar,

There certainly are transferred events that get generated when you monitor a station / call.
If you use our JTAPI or TSAPI APIs, the transfer events are generated today. For our DMCC API, this is currently in beta status and will very soon be available (with AES release 4.1).

Hoping this helps,

Tim

Mike,

Please check out
http://www.avaya.com/master-usa/en-us/resource/assets/whitepapers/microsoft%20white%20paper%200702.pdf
for general information on Avaya's Unified Communications solutions with Microsoft Office apps.

For more technical details, you could try searching for "TR/87" on support.avaya.com. TR/87 is the protocol that is used to communicate between MOC/LCS and AES.
More details on this can also be found in the TR/87 implementation guide:
http://support.avaya.com/elmodocs2/AES/4.0/02_601893_1_1.pdf


Hoping this helps,

Tim

Russel,

Would you mind opening a trouble ticket with technical support for this problem? There is a "Request Technical Support" link for this in the left-hand frame of this page.

I apologize for having to redirect you, but the above issue will take some more attention to resolve, and this forum is generally not attended by JTAPI / TSAPI experts.


Best regards, and again my regrets for not being able to help out here,

Tim

Robert,

You can retrieve a list of agents through our System Management Service (SMS) web service. Unfortunately, to date there is no way of retrieving data from SMS as an XML doc, but rather as a string that lists items (i.e., agents in your case) delimited by a "|" character. You would have to write your own logic to parse this data and create an XML DOM from it.

BTW: you are not the first one to request XML docs as a result format for SMS. Our product management team is aware of similar enhancement requests, and I will let them know that you have interest this feature.

Hoping this helps at all,

Tim

you are very welcome

Xhui Yao,

Unfortunately, there is currently no support for TAPI on AES, and I am unaware of any plans to support this in the future.
I will relay your request to our Product Management.

Tim

Michael,

Sorry for the delay, took some time to find the response (which I am only relaying ... I learned just this myself):
The AES/TSAPI versions to use for to-digit reason codes are 3.1+.   You should want to use the library call attV6SetAgentState() for setting the state for the agent, or you  you will probably get UniversalFailures.
There is some CM admin work involved, as well (change in sys-params customer options, sys-params features, and chnages for the cti-link). I only have a link to an Avaya Intranet site for the details. 
As you seem to be Avaya personnel, you can try this link:
http://nacd5.usae.avaya.com/mynotes/reason_codes.htm


Hoping this helps,

     Tim

You are welcome, I am glad John figured out your set-up issue.

      Tim
 

Jigar,

I just consulted our team's JTAPI expert about this issue, and here is his response:
- CallCenterProvider.getACDAddresses() will give you the list of devices administered in the SDB that are ACD extensions.  You can go that route, but it will require this piece of administration.  
- Similar things apply to getACDManagerAddresses(). If you administer extensions in the SDB that are VDN extensions, then getACDManagerAddresses() will return the list of those SDB extensions that are VDNs.
- There is an alternative way to get the queue size: you need to call Provider.getAddress(s) where s is a string with the extension of the ACD.  This will give you an  javax.telephony.Address object.  If you correctly cited the extension of an ACD, then the object returned will be an instance of the more specific ACDAddress object.
[Our JTAPI implementation returns an Address object that also implements the appropriate other interfaces - another example: if the Address names the extension of a VDN, then the returned Address object will also implement the ACDManagerAddress interface, and can support those methods]
- So, to summarize the alternative: simply call Provider.getAddress(String) and then if the returned Address also is an instance of ACDAddress, conclude that that extension is also an ACD. Similarly, you can do Provider.getAddress(s) and, if s names the extension of a VDN, the returned Address object will also implement ACDManagerAddress. On these objects, you should be able to then call the getNumberQueued() method .


Hoping this helps,

    Tim

Jigar,

You are very welcome! 
I hope that involving John RE: AES-CM-SES simulator will help clear up your issue.

     Tim

Hi Jigar,

SMS is for system management and administration, so that would be the wrong web service. You would want to use the Telephony Web service for call control purposes. 
Unfortunately,  I don''t think that the Telephony web service supports what you are looking for either. Your best shot is a JTAPI application, as suggested in the AES Server platform forum.

  Tim