Our agents get kicked out by the switch.
And DMCC log show that we are recieving 'TerminalUnregisteredEvent"
<TerminalUnregisteredEvent xmlns="http://www.avaya.com/csta">
<monitorCrossRefID xmlns:ns1="http://www.ecma-international.org/standards/ecma-323/csta/ed3">17411</monitorCrossRefID>
<device>
<deviceIdentifier xmlns:ns2="http://www.ecma-international.org/standards/ecma-323/csta/ed3" typeOfNumber="other" mediaClass="voice" bitRate="constant">xxxxxx:PBX:xxx.xxx.xx.xx:0</deviceIdentifier>
</device>
<reason>Received unregistration request from switch reason=2081 text=2081</reason>
<code>3012</code>
</TerminalUnregisteredEvent>

This is so hard to duplicate. We dunno why and when we receive this error.
Has any one seen this error before. if yes can you please tell us why we are getting this error and how we can resolve it.


Thanks,
Anu kotha

posting in multiple forums does not get you an answer faster, it just creates more work for the moderators. At least here you provide a complete problem statement.

the event code description is "IPSoftphone in shared control configuration with DCP (or IP) is forced unregistered because softphone switched to invalid state."

From looking briefly into the code there are numerous cases triggering this event code. Most involving some protocol issue (like unexpected socket closure) between Communication Manager and the station (s) registered against that station.

If it is really bothering you I suggest registering in Independant mode instead of Dependant, however review the programmer's reference guide for the differences in these two registration modes and understand what ramifications that may have on your application.

Thanks for your reply.

I guess I did not read the fine print under your forums as to how to use them.
If it makes you all feel better I was not trying to create more work. Did not know where something like this had to be posted.

Thanks

John,

If we register our device in "Independant" mode, then we are capable of logging in the agent and taking calls without a proper voice path established (iClarity). How can we verify that the agent is logged into iClarity from DMCC?

Thanks

Jason,
How is it that you are logging the agent in now? Are you driving the physical phone through the login sequence by going off hook and dialing the FAC?

I have no exposure to iClarity so I am not of much help there. Through DMCC you can not derive an agents state. It is planned to expose those methods from TSAPI in the 6.0 AE Services release (2H2010). Right now to determin agent's state you must use TSAPI or the SMS administration interface.

The unregistration events you are seeing are a result of Communication Manager disconnecting the device that the agent is using due to some protocol/network problem. The unregistration is done to the DMCC device because that is how Communication Manager /AE Services notifies a dependant mode application. Your reaction should be to attempt re-registration. If that fails, you should release the DeviceID, get another (this is assuming you are using multiple CLANs in a H.323 Gatekeeper List), re-request monitors, and re-register. Your application should stay in this outer loop until the registration succeeds.

An independant mode device registration would successfully log in agent in even if the physical phone it was associated with is not physically connected to the system. I do not believe you want this behavior if you are doing an agent assist type application.

Johh

Hi John,

I received an exact the same case from our cusomter as Jason's. I have just opened a QQ for T4 on CM side.

We want to figured out why CM would be unregistering the DMCC station which takes shared control of the IP Softphone (iClarity). I've checked MST trace but not see any message received from AES/DMCC prior to CM sending URQ to AES/DMCC. This is really interesting.

Regards,
Howard

MST won't tell you anything about what is going on with a DMCC unregistration. All that traffic is happening in the context of an H.323 connection between AES and a C-LAN or procr interface. From what I can tell the unregistration of the DMCC device is happening because the connection with iClarity either hit a protocol problem or connectivity problem. I would look for network issues between iClarity and Communication Manager.

Hi John,

I agree with you. Please take a look at what i have seen out of the MST trace below:
I have captured two instances and in one of them I see a GRQ message coming from the iClarity softphone then CM replies with GCF finally CM sends URQ to the DMCC application. T4 is also focusing on why would iClarity send GRQ to CM while it's just answered an incoming call.
After the agent finishes the call, the iClarity sends out URQ to CM and gets itself unregistered then re-registers back.

Considering the issue has been reported not only by the VPN connected agents but also the LAN connected agents (the VPN connected agents have much more occurrences than LAN connected agents though), i would like to ask for your help as to how to troubleshoot this should it be the network connectivity issue, and would also love to know why DMCC is unregistered prior to iClarity softphone? Many thanks to your warmhelp!

Regards,
Howard

case 1) GRQ at beginning of a call causing Communication Manager to unregister the station. Sounds like a question for the Communication Manager development/support team. I wouldnt think that a GRQ is a problem, but I don't know the AAA protocol all that well.

case 2) iClarity sending URQ at the end of the call. Sounds like a question for iClarity not Avaya.

DMCC is getting unregistered BY Communication Manager BECAUSE the primary registration (iClarity) was unregistered BECAUSE of case 1 or 2 above. Solve them and you solve the customer's problem.

Hi John,

You're right.

We've determined the cause of the DMCC unregistration is on Cisco SSL VPN client, once changing to Cisco thick (full standard) VPN client this issue goes away.

congrads.. !!!