a call recorder needs RTP and thus it needs to register as a DMCC device. A high availability solution will take two.
the soft phone needs another DMCC device registration.
Thus, as you point out, normally you will have consumed the three that Communication Manager provides.
A fourth _registered_ DMCC application cannot be accommodated.
DMCC allows for third party call control services (makeCall(), answer(), etc) those can be accessed without _registering_ the DMCC device. Unfortunately the service you mention (listing the buttons and pushing one) is a first party service, thus requires a DMCC registration to execute.
What you mention about the instance IDs, I presume is occurring on a single AES server. The second getDeviceID must specify a difference instance ID than has already been allocated (the app should first try zero, and if that fails, try one, and then try two). As DMCC has become more popular, we are seeing conflicts between multiple applications trying to provide services to the same device.
Using multiple AESs does not solve your problem as the limit of three registered devices is in Communication Manager.
Unfortunately one-X Softphone does not have an API to the soft phone itself, so there is no help there.
|