Hi All

Here is our scenario -

A CM7 solution with 2 AES servers (patch level 7.0.1.0.5) and 2 Call Recorders (acting independently).

Call recorder server A uses AES server A (with TSAPI and DMCC) to create an additional registration for extension X

Call recorder server B uses AES server B (with TSAPI and DMCC) to create an additional registration for extension X

If I status the station on CM I see 3 registrations - one for a the station itself and then two additional API_A ones for the two AES servers.

If we restart Call recorder A it will unregister extension X - however it not only unregisters extension X from Call Recorder A it also unregisters extension X from Call Recorder B.

All Call Recorder supplier has suggested it may be down to the same user ID being used on both AES servers (AES has SDB for DMCC enabled and the user IDs have Unrestricted access). However, I wasn't aware that he AES servers talk to each other (I was under the impression the only talked to the CM via ASAI) so I'm confused as to why using the same user ID on AES would result in the message being propagated.

Any ideas what might be going on here?

Many Thanks

Tim

Hi Tim,

The AE Services do not communicate with each other. In the case of registering/unregistering terminals, they each use a RAS connection with Communication Manager.

What you are seeing is not what I would expect. Indeed, it is not what I saw when I tried to simulate this scenario in my lab a few minutes ago using the DMCC Dashboard.

I think the first thing you should try is to run the command "list trace ras ip-stations X" on Communication Manager (where X is the station number). Restart Call Recorder A and see what trace is produced. You should see a single URQ and UCF, each with an endpt of AES A.

Martin

Hi Martin

Many thanks for your response. It will be next week before I get another opportunity to give this another try. However, we did capture some logs on the recorder from the tests we did yesterday.

The unregistration event in Avaya log when the Stopped services on Recorder B

2018-09-05 20:19:01.558 INFO  DMCC: 

[9999][EndpointUnregisteredEvent][ns1:monitorCrossRefID]679

[device][ns2:deviceIdentifier]***station X***:CM:0.0.0.0:0 [eptDevice][ns3:deviceIdentifier]***station X***:CM:***CM7 IP Address***:0 [endpointAddress]***AES B IP Address***[dependencyMode]DEPENDENT[reason]The

user has logged-off the endpoint.[code]LOGOFF[setType]9611

[signallingProtocolType]H323[serviceState]inService

The unregistration event in Avaya log on Recorder A when the Stopped services on Recorder B

2018-09-05 20:19:01.655 INFO  DMCC: 

[9999][EndpointUnregisteredEvent][ns1:monitorCrossRefID]735

[device][ns2:deviceIdentifier]***station X***:CM:0.0.0.0:0 [eptDevice][ns3:deviceIdentifier]***station X***:CM:***CM7 IP Address***:0 [endpointAddress]***AES B IP Address***[dependencyMode]DEPENDENT[reason]The

user has logged-off the endpoint.[code]LOGOFF[setType]9611

[signallingProtocolType]H323[serviceState]inService

The endpointAddress is correct in each case (i.e. it is the AES Server associated with the Recorder on which the services were stopped. However, should this message be being sent to Recorder A at all? If so, then I guess it may be an error on the Recorder side where it is misinterpretting the message as being related to the AES A registration (it then goes on to request the extension is deregistered from AES A).

I do have some station traces - which contain some of the RAS messages but not the URQ ones (I assume I need to do that via a "list trace ras" instead as per your suggestion.

19:24:04   snd UCF ext ***station X***

                   endpt  [***AES A IP Address***]:27901

                   switch [***CM7 IP Address***]:1719

19:24:09   rcv GRQ ext ***station X***

                   endpt  [***AES A IP Address***]:27697

                   switch [***CM7 IP Address***]:1719

19:24:09   snd GCF ext ***station X***

                   endpt  [***AES A IP Address***]:27697

                   switch [***CM7 IP Address***]:1719

19:24:09   rcv RRQ ext ***station X***

                   endpt  [***AES A IP Address***]:27697

                   switch [***CM7 IP Address***]:1719

19:24:09   TCP connected (ne)

                   endpt  [***AES A IP Address***]:25472

                   switch [***CM7 IP Address***]:61442

19:24:09   Q.931 Setup received

                   endpt  [***AES A IP Address***]:25472

                   switch [***CM7 IP Address***]:61442

19:24:09   Q.931 CallProc sent

                   endpt  [***AES A IP Address***]:25472

                   switch [***CM7 IP Address***]:61442

19:24:09   Q.931 Connect sent

                   endpt  [***AES A IP Address***]:25472

                   switch [***CM7 IP Address***]:61442

19:24:11   snd UCF ext ***station X***

                   endpt  [***AES B IP Address***]:23411

                   switch [***CM7 IP Address***]:1719

19:24:17   rcv GRQ ext ***station X***

                   endpt  [***AES B IP Address***]:22276

                   switch [***CM7 IP Address***]:1719

19:24:17   snd GCF ext ***station X***

                   endpt  [***AES B IP Address***]:22276

                   switch [***CM7 IP Address***]:1719

19:24:17   rcv RRQ ext ***station X***

                   endpt  [***AES B IP Address***]:22276

                   switch [***CM7 IP Address***]:1719

19:24:17   TCP connected (ne)

                   endpt  [***AES B IP Address***]:24574

                   switch [***CM7 IP Address***]:61440

19:24:17   Q.931 Setup received

                   endpt  [***AES B IP Address***]:24574

                   switch [***CM7 IP Address***]:61440

19:24:17   Q.931 CallProc sent

                   endpt  [***AES B IP Address***]:24574

                   switch [***CM7 IP Address***]:61440

19:24:17   Q.931 Connect sent

                   endpt  [***AES B IP Address***]:24574

                   switch [***CM7 IP Address***]:61440

Thanks

Tim

> However, should this message be being sent to Recorder A at all?

Yes. If an application monitors for endpoint registration events for a station ID, it will get an event whenever any terminal registers/unregisters at the station ID. The terminal need not have been registered by this application.

From your trace, I see Communication Manager sending UCFs (to AES A at 19:24:04 and to AES B at 10:24:11). However, I do not see AE Services requesting the unregistration. So, to me, it looks like maybe the unregistrations were initiated by Communication Manager for some reason.

Martin