Hi,
Does anybody know if it possible, using API, to figure out what CM an AES is "registered with"?

I'm trying to make some sort of mechanism, that would allow me to detects if a AES moves its "registration" to another CM

any insights would be greatly appreciated.

AES can connect to many Communication Managers (up to 16)

For TSAPI, JTAPI the "switch connection name" usually provides that insight as to what Communication Manager a connection relates to. The swtich connection name is part of the information that is provided when establishing a TSAPI 'stream' (think of that as communication pathway to a particular Communication Manager). The application 'knows/must manage' what objects are related to a stream at some level, so the applicaiton is in position to know or discover the binding between an object and a particular Communication Manager.

A DMCC device registration can also occur to up to 16 Communication Managers. When the request to create a device identifier, you can provide a switch connection name, or a IP address. If there is a binding between the switch connection name and the IP provided provisioned into AES, the created device identifier will contain the switch connection name. Again using meaningful names for Communication Manager will assist with knowing which Communication Manager a particular device Identfier is associated with.

AES will not switch a 'registration' (what ever you meant by that), automatically to a different Communication Manager.

If that didn't answer your question, please provide additional details about the API you are using, and clarify 'registration'.

Thank you so much for your reply.

If I understand you correctly, I should be able to NOT pass the "call server" parameter in the request to create a DeviceID, which is probably what I want.. I just was not aware that it was optional.. I will test this out!

for historical reasons you can pass an IP address for Communication Manager when creating a device ID. If AES finds that IP in the list of H.323 Gatekeeper addresses associated with a switch connection, the deviceID will work fine. I believe the resulting deviceID will contain the switch connection name - I forget the exact detail here. Test it out with the DMCC Dashboard contained in the .NET version of the SDK.

I have done some tests, and it does not look as if I'm able to leave out the switchName parameter in the GetDeviceId request Object, I have tried with both null and an empty string. I get "ch.ecma.csta.errors.InvalidParameterValueException: null" in both cases.

Would there be any special way to not pass the switchName? .. I'm using the java-sdk 10.1.0.0.0.12

I could try reading the "manual" sorry, the way to do it is by sending "0.0.0.0", I'm able to get a DeviceID back .. just putting it in the post for future reference

Well I have made progress,

I am now able to create a DeviceId without knowing the IP of the CM, but that leaves me with having to know the switchName to be able to register the device. And I guess based on the fact that one AES is able to be connected to multiple CMs, I would not be able to register the device without knowing the name of the switch on which I would like to register my Device.

That leaves me with a new question ... :)

How would I know the switchName, I'm guessing that it would be application configuration?

As I understand it that would leave me with potentially a list of "switchNames" in my application, and I would try them one after the other if registration fails? What I win is not having to configure specific IPs, but I still need the "switchName"

I currently have a situation, where I have an AES that can be connected to two different CMs (but only one at any given time) .. What I was looking for was a way to figure out what CM the AES was using as gatekeeper at the time of device registration and use that, that what way I would not need to store any configuration. :)
But based on my findings an new knowledge that might not be possible?

a letter without an address is unlikely to get to the recipient. Usually, the sender knows who they want to receive the letter.

You have a very odd environment if the AES can interact with two separate Communication Managers, BUT only one at a time, using the same swtich name.
Usually, leading digits of extensions are enough of a indicator you can generally know what extensions are associated with what switch names.
Usually, the application has some configuration information (both the AES IP/DNS and CM switch name)

I don’t know if this would work out, but TSAPI/JTAPI have a discovery protocol where they collect a set of T-links that are provisioned on AES. The application can then connect to a T-Link to set up a communication path to Communication Manager. The T-Link names contain the switch connection name as one of the fields.

Once the application has an operational connection to AES, it can query to see if a T-Link is operational or not (active or inactive).

Knowing which T-Link is operational would then allow you to move forward without additional switch name configuration in the application.

These same capabilities may be exposed in DMCC call control services. The SME for DMCC is on holiday this week so I cannot find out for you.

I'm not sure why the Avaya setup is structure the way it is :)

However, I really appreciate you responses to my questions. Based on what you have told me, and my own findings, I pretty much end up with having to have a "list of something" in my application-configuration. So I think I will do either IPs or Switch Names (The latter might be the best).

but again thank you for taking time to answer my, perhaps somewhat misguided questions.. :)