Avaya Agent\Station stays logged in after network disconnection 2

[7deedtz]

Good day,


We hope we could some guidance or assistance to resolve or advise on the following issue described;

Due to users working from home, we have noticed that the Avaya systems (CMS & CM) shows the Agent-ID as available after network disconnects.
• The station also stays registered for the same period, 5 minutes.
During this scenario however if a call is queued to the skill, the call will be in a waiting state on the skill even though the disconnected Agent is available state.

Our Avaya Business Partner suggested we change System parameters customer option H.323 timer from 5 Minutes to a lower value or change IP-Network-Region setting
TCP SIGNALING LINK ESTABLISHMENT FOR AVAYA H.323 ENDPOINTS
Near End Establishes TCP Signaling Socket? n (From no to Yes)

When we asked about what impact this may cause to the overall system stability & functionality no clear or definitive explanation was given.

While we are trying to resolve for the Agents/Stations to be logged out immediately, we do not want to cause system instabilities or degradation of services.

May the gurus assist us here.

Thank you in advance.

Regards,

Deedtz

 

[kyle555]

Redirect on IP Failure - ROIF

https://downloads.avaya.com/css/P8/documents/101038033

Do you have it administered? It so, is the agent put into aux/logged out immediately once the queued call hits the available agent? If so, I'd say it's working the way it should.

 

[7deedtz]

We have not made the change(s) as yet. We are trying to understand the impact this change may have on the environment. We are on Avaya CM 7.1.3

 

[kyle555]

• The station also stays registered for the same period, 5 minutes.
During this scenario however if a call is queued to the skill, the call will be in a waiting state on the skill even though the disconnected Agent is available state.

What would you like to happen instead?

When I turned it on for one of my systems, the reported issue was that those softphone agents that had dropped but were still available were getting calls sent to them with dead air for the caller so they'd have to call back.
ROIF does a check to make sure the agent is still online before sending a call. It doesn't sound like that's the problem you're having based on the description.

Nobody on the internet can tell you exactly what impact it will have on your environment. Give it a try and find out.

 

[7deedtz]

Hi Gurus,

We thank you all for the feedback.

We would like to understand what impact these changes will have on Avaya CM performance once we change any of these.
1) Change System parameters customer option H.323 timer from 5 Minutes
2) TCP SIGNALING LINK ESTABLISHMENT FOR AVAYA H.323 ENDPOINTS, Near End Establishes TCP Signaling Socket? n (From no to Yes)

Your assistance will be greatly appreciated.

Regards,

Deedtz

 

[kyle555]

5 minutes is the link loss delay timer. Once CM loses connection to a phone, it'll consider the registration abandoned in 5 minutes.

To say, suppose you and me have phones on a LAN switch and we call each other through CM with direct audio. And suppose we kill the uplink to that switch. We can still talk direct audio, but we can't use any features like hold or anything. If that uplink comes back in 4 minutes, we can resume mid-call features.

Now, based on your original post, you say you see the agent available after network disconnects. Can we also assume that those network disconnects could also happen at times when they're on a call and they lose the call because of it? It seems obvious, but unless your agents are available most of the time and only seldom take calls, then the frequency of the issue should also drop the occasional call. Just want to make sure or else you might have a separate problem.

The TCP link establishment has to do with the time to service feature

https://downloads.avaya.com/css/P8/documents/100016254

I've only turned it off for banks and police and types with heavy network security and firewalls between phones and CM. CM (the near end) establishing the socket is default and preferred. That way, when a core WAN outage resolves and 10K phones are sending UDP RAS messages, the firewall team won't block a flood of TCP SYN packets from all the phones to CM looking like a DDoS attack. CM upon receiving the UDP packet on 1719 sends outgoing traffic to the phone to establish the link.

The problem with that is that it's not protocol compliant H323, so if you have an H323 aware firewall between CM and the phones, it can drop them because it expected the phone to send to CM and not the other way around. So, in short, if you need that option at no, setting it to yes could break all phones in that NR.

In short, touching those 2 options won't help you.

 

[7deedtz]

Thank you Everyone for the responses.

The issue has been escalated to Avaya for a GRIP request.

We are awaiting outcome.

Thank you all

 

[mattKnight]

CM upon receiving the UDP packet on 1719 sends outgoing traffic to the phone to establish the link.
The problem with that is that it's not protocol compliant H323, so if you have an H323 aware firewall between CM and the phones, it can drop them because it expected the phone to send to CM and not the other way around. So, in short, if you need that option at no, setting it to yes could break all phones in that NR.

That's a massively useful nugget of information! Thanks

Take Care

Matt
I have always wished that my computer would be as easy to use as my telephone.
My wish has come true. I no longer know how to use my telephone.

 

[swils31]

@7deedtz did you get an answer back from Avaya? We have the 5 minute issue too and it causes more calls to be placed in queue because intelligent queueing shows the agents available.