Hello,

we test our DMCC based call recording application by registering 140 stations. Registration in Dependent mode went very well and all the phones were registered. BUt while we run it for 3 to 4 days , it was noticed that some of the stations are not registered and not generating any media events at all. AES version is 5.2.3 , CM version 6.0 . When checking the status of DMCC stations registerd in dependent mode in multiple registration with corresponding monitored stations, those DMCC stations are showing IDLE status in the AES. But from our DMCC application , we are not getting any unregistered events or any notifications when the DMCC station get unregistered. Any possible reason for this behaviour ? Any help on resolving this issue is highly appreciated.

Thanks and Regards
Rasheed

what types of monitors did you place on the stations?

do a simple test. register a DMCC station in dependent mode (using the DMCC Dashboard). Verify it is successful. now go to the physical station and ungreister it. If you have set up your monitors properly you should get an unregistered event (it may take a couple of minutes).

Independant and multiple registrations behave differently in so much as they are not dependant on the physical station being registered, BUT in order to get events like call originate and media start, there must be a physical station taking action for those events to occur.

Hi John,

THanks for your response. Everything work perfect with the application at the time of registration and we are getting media and other events as expected. But after running it for 1 day, we notice that the dependent stations are not getting any events from the corresponding phones and these stations are shown as of status IDLE in the AES and ofcourse we didnt get any unregister event. So our worry is why these stations are going to an IDLE state without any events and the reason for this need to be identified. Is it related to the number of switch connections between AES and CM ? I am asking this because if a dependent station goes to IDLE state even when the main station to which the dependent station is registered with , is still working. can this be becuase AES-CM switch connection is not allowing enough messages to be passed between it and hence it make the station as IDLE since there is no HEART BEAT . Its just my thought , i dont have any logs available with me to prove it now. THe DMCC logs which i have taken didnt say anything about this issue in it.

Thanks and Regards
Rasheed

It seems to me that the most likely explanation is that the real phone became unregistered at some stage. Maybe the user logged out and then back in again. When this happens, any DMCC terminal that was registered in Dependent mode at that station ID will be come unregistered. As the application still has control of the DeviceID, it will appear on the AE Services web interface list of terminals but in IDLE state.

I suggest that you add a listener for EndpointRegistered and EndpointUnregistered events for each station. You will then receive an event whenever a phone logs out or in. Your application can then register the terminal when a user logs back in.

Martin

Hello Martin,

It took me some time to get back to you on this issue. I added a listener for EndpointRegistered event. But still the end points get unregistered without any events like EndpointRegistered not being triggered to the application. But i could take a DMCC log from the AES which clearly shows that there was a unregister happened in the station as given below.

FINE: invokeID= 1372 Received session[null] ch.ecma.csta.binding.reset.ResetApplicationSessionTimerPosResponse@1b8cbb1<mailto:ch.ecma.csta.binding.reset.ResetApplicationSessionTimerPosResponse@1b8cbb1> in response to session[session 223EF2EDDDDC4095BB6A01ACA16332A9-119] ch.ecma.csta.binding.reset.ResetApplicationSessionTimer@18fcc77<mailto:ch.ecma.csta.binding.reset.ResetApplicationSessionTimer@18fcc77>
2017-09-26 07.22.44,077 com.avaya.mvcs.station.h323.ras.IncomingRASHandlerImpl receivedUnregistrationRequest
FINE: [10.100.115.75:2820:0] Received unregistration request (URQ)
2017-09-26 07.22.44,077 com.avaya.mvcs.station.h323.ras.OutgoingRASHandlerImpl shutdown
FINE: [10.100.115.75:2820:0] Shutting down registration.
2017-09-26 07.22.44,077 com.avaya.mvcs.station.h323.ras.OutgoingRASHandlerImpl sendUnregistrationConfirmation
FINE: [10.100.115.75:2820:0] Send unregistration confirm (UCF)
2017-09-26 07.22.44,078 com.avaya.mvcs.terminal.h323.TerminalH323 tearDownDevice
FINE: [10.100.115.75:2820:0] Tearing down station
2017-09-26 07.22.44,078 com.avaya.mvcs.station.h323.ras.DefaultTerminalDevice cancelQ931DisconnectTimer
FINE: [10.100.115.75:2820:0] cancelling Q931Disconnect timer
2017-09-26 07.22.44,078 com.avaya.mvcs.station.h323.ras.DefaultTerminalDevice unregisterDevice
FINE: [10.100.115.75:2820:0] Client API call - unregisterDevice
2017-09-26 07.22.44,078 com.avaya.mvcs.station.h323.ras.DefaultTerminalDevice cancelQ931DisconnectTimer
FINE: [10.100.115.75:2820:0] cancelling Q931Disconnect timer




Please find the attached complete logs which contain the above extract of logs also. Hoping to get a quick response from you soon.

Thanks and Regards
Rasheed

Did you run the super simple test I suggested on 07/07/2017 @ 09:47:45 CT?

Use the DMCC Dashboard (or your application), register a device in dependent mode against a physical station. set the same monitors your application sets. Log the extension out of the physical phone. Observe the DMCC Dashboard. Verify an event is received indicating that the device has been unregistered. If it isn't, increase the DMCC logging to FINEST, and retest. See if AES makes any attempt to notify the application when the device gets unregistered. AES 5.2.3 is a very old release. It is no longer under manufacturer support (https://downloads.avaya.com/css/P8/documents/100172510) , it could be that the issue lies with the version of software you are using.

Sorry, I didn't realize that you were using such old software. EndpointUnregistered events were added in a later release so they are not available to you.

Make sure you have started a Phone monitor and have requested TerminalUnregisteredEvent. You should then receive a TerminalUnregisteredEvent when your terminal becomes unregistered. It will include a reason code which may indicate why the terminal became unregistered.

Martin

Thanks Martin,

i will try it out and will get back to you soon.

Best Regards
Rasheed