Hello experts,

Our application is running on individually on all workstations, so creating DMCC session from each workstation, for some reason sometimes session remain alive even if our application is closed and we reach to limits of number of DMCC licenses.
FYI, while creating application session we setup we set

sessionCleanupDelay=5
sessionDuration=180
startAutoKeepAlive=true

which means I guess, if server is not receiving heartbeat till 180, disconnect the session.

But session remains there, until we manually release the session from Avaya’s interface.

Please suggest what is wrong here

ADDY

Are you sure the application has actually stopped running? Have you checked the Windows Task Manager to make sure?
Has the application closed the session before it ends?

Martin

Agreed, the app is still running even though you think it isn't.
iI you enable AES DMCC logging you should see keep alives coming from that workstation's IP address.
or do a packet capture from the workstation... there will be traffic to/from the AES.

okay we will check thanks for replay,

meanwhile can you please tell if there is any way to know how many licenses are available and how many available to be used pragmatically? or at least if we could know if we are unable to login via our application so its about license?

I do not think it is possible to get the number of free licenses via software. You would need to query the WebLM for that information and I do not think is supports an API or even an SNMP interface.

DMCC licenses are only consumed when an application attempts to register a terminal using RegisterTerminalRequest. If there are no licenses available, AE Services will respond with a RegisterTerminalResponse containing an error of "resourceUnavailable". For example:

<?xml version="1.0" encoding="UTF-8"?>
<RegisterTerminalResponse xmlns="http://www.avaya.com/csta">
<device>
<deviceIdentifier xmlns:ns1="http://www.ecma-international.org/standards/ecma-323/csta/ed3" typeOfNumber="other" mediaClass="voice" bitRate="constant">3403:AESSERVER:10.151.109.112:0</deviceIdentifier>
</device>
<code>3014</code>
<reason>Registration Reject reason: resourceUnavailable
The number of registered stations exceeded the capacity specified on the license file.</reason>
</RegisterTerminalResponse>

For TSAPI licenses, AE Services checks that there is a free license whenever an application tries to start a Call Control monitor or perform a Call Control request (e.g. MakeCall). I can't remember what the exact error cause given is in this case.

Martin

we are not doing RegisterTerminalRequest… so why DMCC is being consumed?

but this error msg "reason" is serving the purpose.

Thanks.

A DMCC license will only be consumed if an application makes a RegisterTerminalRequest. Perhaps you are having some other problem and mistaking it for a licensing issue.

Martin

Honestly I can not really follow your question. I understand the first part (partially), but not the second.

"meanwhile can you please tell if there is any way to know how many licenses are available and how many available to be used pragmatically? or at least if we could know if we are unable to login via our application so its about license?"

the following entities are licensed on AES:
DMCC
TSAPI (including DMCC Call Control and JTAPI)
TSAPI Advanced
CVLAN
DLG
AEP
There are other licenses on Communication Manager that come in to play as well (VALUE_STA, VALUE_IP_STA, IP_API_A, ASAI, ASAI_PLUS, etc)

Yet near the end of your statement you say "unable to login"
Logging in is typically a statement made relative to registering a DMCC device.


However in your response you indicate you are not Registering a Terminal (DMCC device). This would imply your application is perhaps just setting up call control monitors (possible via DMCC). This would consume a TSAPI Basic User license (however using the phrase 'unable to login' is confusing with TSAPI). Thus I remain confused about what you are asking about.

As Martin says there isn't a way to query for licenses available/in-use for any of the AES licensed objects nor when applicable Communication Manager objects. Since multiple applications use the AES simultaneously, the information in a query/response is immediately out of date information. The best way to find out is to make a request and observe the response to see if a failure occurred to to the lack of a license. The common TSAPI failure response due to licensing would be SUBSCRIBED_RESOURCE_UNAVAILABILITY

let me try to clear things.

here is extract from code... all the methods in use


ServiceProvider.StartApplicationSession
ServiceProvider.SetSessionCharacteristics
ServiceProvider.GetNewDevice

ServiceProvider.getThirdPartyCallController.GetThirdPartyDeviceId
ServiceProvider.getThirdPartyCallController.ChangeMonitor

ServiceProvider.getThirdPartyCallController.SetAgentState
ServiceProvider.getThirdPartyCallController.GetAgentState
ServiceProvider.getThirdPartyCallController.SetAgentState
ServiceProvider.getThirdPartyCallController.GetAgentState

ServiceProvider.ShutDown

ServiceProvider.getThirdPartyCallController.AnswerCall
ServiceProvider.getThirdPartyCallController.ClearCall


OwnerDevice.GetDeviceId
OwnerDevice.getPhone.getDevice.getDeviceIdAsString
OwnerDevice.getPhone.getMedia.StartMonitor
OwnerDevice.getPhone
OwnerDevice.getPhone.getMedia
OwnerDevice.getPhone.getMedia.StartMonitor


OwnerDevice.getPhone.UnregisterTerminal
OwnerDevice.ReleaseDeviceId


in my case user starts session with logging in to OneX communicator, after that user runs our application make him logged in as an agent.

our application actually keeps the check on agents state and collects the information from user when needed to store.

our application also answer to cater "Auto Answer" and rejects the calls when call not needed.

sometimes we saw stuck DMCC sessions, which causes DMCC licenses limit, we manually releasing the sessions and users continues.

DMCC applications can use just DMCC user license, or it can use just a TSAPI Basic User license or it can use a TSAPI Advanced User license or it can use a combination of those licenses.

From the methods you list it appears that your application only uses DMCC call control services which uses a TSAPI Basic User license
there are two ways to consume them.
dynamically
or more statically

If you create a call control monitor the app will consume a TSAPI Basic user license and hold onto it till you release that monitor (I perceive your application does this)
Any dynamic operations (SetAgentState) would see that there is already a license in use, and leverage it for the operation.

If you are not establishing a call control monitor, then operations like SetAgentState or AnswerCall or ClearCall would only use the TSAPI Basic User license while the operation was 'in progress.'

Because you are doing answer and clear call, you must have a call ID value to do it with. To get that you would need to use snapshotDevice() (not shown) or you would need a call control monitor on the device. Thus I assume you are establishing call control monitors which consumes TSAPI Basic user licenses and holds onto them till the application explicitly releases them or the service provider shuts down.

HOWEVER, you do not show a registerTerminalRequest BUT you state "which causes DMCC licenses limit," so you one assumption would be that somewhere be doing registerTerminalRequests.... you just didn't capture it in your trace. OR you are confused about what license limit you hit (more likely)... that your call control monitor request is rejected because you exhaust the total number of TSAPI Basic User licenses.