Good afternoon!

I''ve noticed that the Avaya IP Softphone seems to get information about the number that''s programmed for a fixed abbreviated dial and displays it... however, I don''t seem to get that information through GetButtonInformation.

How is Avaya IP Softphone getting that information?  Similarly, is there a method for determining *which* reason code is associated to an aux-work button, or for that matter any extended information about any kind of buttons?

Are you sure the button is adminstered as an abbreviated dial button and not a Busy Indication button?

If it is a Busy Indication button then the associated number will be returned in the AssociatedNumber field of the GetButtonInfoResponseArgs argument.

Note, that the beta version of the .NET API does not support the AssociateNumber attribute.

This bug has been fixed in the version we are currently working on.

Here is what the XML looks like for a GetButtonInformationResponse on a Busy Indication button.


<?xml version="1.0" encoding="UTF-8"?><GetButtonInformationResponse xmlns="http://www.ecma-international.org/standards/ecma-323/csta/ed3"><buttonList><buttonItem><button>270</button><buttonLabel></buttonLabel><buttonLabelSettable>false</buttonLabelSettable><buttonFunction>39</buttonFunction><buttonAssociatedNumber typeOfNumber="dialingNumber" bitRate="constant">5386000</buttonAssociatedNumber><buttonAssociatedNumberSettable>false</buttonAssociatedNumberSettable><lampList><lampID>270</lampID></lampList></buttonItem></buttonList></GetButtonInformationResponse>

The "5386000" is the number that is dialed when the user presses the button.

Regarding getting the aux-work information. I don''t think there is a way to currently get that. I just checked the incoming XML information that is sent for an aux-work button and the reason code information is not there.

Unfortunately it is an abbr-dial.  So the problem is specifically with the .NET version?

When do you expect to release the "new/fixed" version?

I just verified with the latest version that we are testing in house and it does work for abbreviated dial buttons.

I will try to find out when this version is going to be made available.

Please remember that the .NET SDK/API is in pre-release form. We released it early so our partners could try it out and give us their feedback.

The more feedback we get from our DevConnect partners the better we will be able to make it.

If you have any requests for added capability or features, now is the time to ask for it.

In the meantime, you could always look at the raw xml that is coming in to get the associated number.

Since you''re asking... it would be nice to have the full details of any button (eg. Aux Work reason codes and groups, group page number, hunt group night service number, q-calls group number, q-time group number, vu-display ID, etc.).

Unfortunately, that information is not supplied in the XML data that the API gets. Therefore, it has no way of providing that information.

It was worth asking... maybe you''re redoing the XML too!  :)

Thanks for your help -- I look forward to hearing when the fix is available.

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.

I think for now I'm going to administer a btn-view button on the phone and, upon startup of the app, do a quick run through of the buttons to see what they are.

That should work.

FYI, I hope to post the latest version of the .NET API sometime in the next few weeks. This version has the original bug that you reported fixed.