I'm new to the Dashboard (v4.2.2.60) and I'm trying to make a call between two extensions. I'm using 32129 & 32130 although I don't care which ones because I ultimately just want to monitor the call events.

I start a session, get both deviceIds, register both terminals, go to the Call Control tab, populate the source & destination deviceIds (as highlighted in blue when I hover the mouse over the 'Make Call' button) and press 'Make Call' but I get the failure below. I've tried changing the Dependency Mode but it makes no difference.

Please can someone help me out as to what the problem might be?

---------------------
Outgoing XML 6
<?xml version="1.0" encoding="utf-8"?>
<MakeCall xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns="http://www.ecma-international.org/standards/ecma-323/csta/ed3">
<callingDevice typeOfNumber="other" mediaClass="notKnown">32129::192.168.17.129:0</callingDevice>
<calledDirectoryNumber typeOfNumber="other" mediaClass="notKnown">32130::192.168.17.129:0</calledDirectoryNumber>
</MakeCall>
-----------------------
Incoming XML 6
<?xml version="1.0" encoding="UTF-8"?><CSTAErrorCode xmlns="http://www.ecma-international.org/standards/ecma-323/csta/ed3"><operation>generic</operation></CSTAErrorCode>

In order to do most third party call control commands (like MakeCall) the Device Id must have the name of the Communication Manager in it.

When you created the Device ID you put in the IP address instead of the name of the Communication Manager. This is OK for first party call control type commands (e.g., pushButton, onhook, etc.) but not for third party call control commands.

Dave

Dave is referring to a 'switch connection name' .. and it is not the name of Communication Manager, but rather the symbolic name of a link from AE Services to Communication Manager as provisioned on AE Services. Further for this to work well, you need to provision a list of IP addresses under the H.323 Gatekeeper button of the switch connection on AE Services. Please refer to the AE Services Administration and Maintenance guide (section DMCC with Call Control Services) for details on how to provision a switch connection for DMCC Call Control use along with the corresponding H.323 Gatekeeper list. For it all to work, you will need a CTI link (ADJ_IP) on Communication Manager, and provisioned CLANs in the switch connection as well. Again details are in the AE Services Administration and Maintenance guide.

Thanks. I'll try what Dave suggested but do I also need to do what John suggested if I'm just running everything (IPCode, Dashboard & all VMs) on my development workstation?

My only aim at the moment is to see the XML generated by a call and I was just using two of the pre-setup softphones. (We don't have any Avaya hardware installed yet although I should be getting a couple of 1616 IP phones soon.)

IPCoDE has this pre-configured... the switch connection name is 'cmsim'

You need to do what Dave said in regard to how you get the deviceID you are using... but unless you changed the IP of Communication Manager (which you didnt) and did not update the H.323Gatekeepers list, you should not be having a problem. however there is no switch connection name (second field ) in the deviceID you posted below (32129::192.168.17.129:0 --- should be 32129:cmsim:192.168.17.129:0) ... Please double check the H.323 gatekeepers list associated with the switch connection via the AES OA*M web page (http://192.168.17.128 login CTI OAM Administration -> Administration -> Switch Connections -> cmsim -> [H323 Gatekepers]

Dashboard now shows a 135.* address when I get a deviceId.

On H323 Gatekeepers the IP address is 135.8.117.122. (When I was setting up IPCode I had some connectivity issues and was given instructions on here to change the CM IP address to a 192.* address and told that we may have been given an incorrectly burned disk.)

I've tried removing the 135 address from the H323 Gatekeepers list and adding 192.168.17.129 but after restarting the VMs then Dashboard won't even start a session due to the connection being refused. Prior to the VM restart I had to enter the cmsim password (devconnect123456) again because it was indicating an invalid password rather than indicating 'Talking'.

Can you give me instructions as to what I need to change?

If you can not get a SESSION, then it would appear that the AE Services' server IP address is wrong in the dashboard (or AE Services, but I have never seen that change... just the password seems to get corrupted).

removing the 135 address and inserting 192 is the correct thing to do. I dont understand why you have a
135.8.117.122 address in the gatekeeper though. That makes little to no sense to me.

I managed to get it working. I reverted to a backup of the environment (taken before I made any changes today), adding the correct H323 GK address, set the cmsim password and restarting the VMs. Originally what I did was change the H323 GK address, restart the VMs, set the password because I was getting errors and then restart the VMs.

I must have managed to mess up the environment somehow. The main difference was originally that I only changed the cmsim password AFTER restarting the VM.

Since I've restarted my workstation and VMs then even Dashboard gets a 'connection refused' when I try and start a session.

After the VMs have been started then the status of the cmsim connection via the AES web page displays 'Invalid password' which I've reset and it shows 'Talking'. However Dashboard is still unable to connect afterwards. The status in AES shows that the CVLAN, TASPI & DMCC services are 'ONLINE'.

For the cmsim connection I've entered 'devconnect123456' in both boxes and clicked Apply but it loses the change after I restart the VM. I did subsequently shut the VMs down from the Linux prompt as recommended.

My questions:
1) How do I make the password change permanent?
2) What can I do to find out why even Dashboard won't connect? I can ping 192.168.17.128 OK.

it seems IPCoDE is changing more in the LDAP database than the switch connection passwords. We found that the DMCC unsecure port was disabled which was preventing access with StartApplicationSession.

While I have no solution to these DB corruption problems we see, having a backup copy of the AE Services virtual machine can not hurt.