Conversaion Delay Issues with calls to Hunt Group

madmacs · Post by **madmacs** » 01 Apr 2010 12:33

Good Day

Scenario : Calls comes in on the PRI and is routed to a Sales Hunt Group (HG) via an opt-1 selection in the AA. There are 15 phones in the hunt group. All phones ring, but there is a delay of up to 10secs before conversation happens bidirectionaly.

The phone are IPTouch IPs (various models) which are connected to are connected to POE OmniAccess (OA) switches. The OXO is directly connected to the OA as well. The Dynamic Routing information is at 0 sec with no routing for the hunt group.

When there are up to 3-4 phones in the HG, there is no delay.
When there are 4 or more phones, the delay progresses as more phones are added

In a different test, dialing to the HG directly, as setup in the Pubic Dialing Plans, caused the same result.

Has anyone seen this?

(OS = R7.1.28)

etc · Post by **etc** » 05 Apr 2010 01:37

R 710.028 isn't current release. Today current release - R710.056.002. One of Corrections: Incoming transferred call has one way speech. Calls trough AA are transferred calls. Install new one patch.

madmacs · Post by **madmacs** » 05 Apr 2010 07:59

etc wrote:R 710.028 isn't current release. Today current release - R710.056.002. One of Corrections: Incoming transferred call has one way speech. Calls trough AA are transferred calls. Install new one patch.

Actually, we had a problem R..56.. (English) wereas we could not get the second CoCPU to be recognized, no matter how many times we LoLa'd the system. We achieved success with R..28.. version. I know it's strange.

Please remember, 1st, that the phones are IP along 3 POE OA switches , 2nd the system works with 3-4 phones in the HG, with no noticeable delay. However, when more phones are added the delay increases per phone added. And 3rd, the delay is bi-directional. Neither end can here each other. So there is no uni-directional conversation, as mentioned.

We also did a terminal download to make sure the phones have the latest software.

Thank you, Your help is much appreciated!!

brainwave · Post by **brainwave** » 09 Apr 2010 05:48

Note : A new flag: CFHgrpP is present in OMC, Other Labels.

Path : OMC > system miscelleneous > Memory Read > Other Labels.

By default, this flag is 00 => means release will be processed first. Hence there will be a delay on caller.
If this flag is set to 01 => connect will be processed first. Now there will be no delay on caller.

This timer is available since R710/28.001

brainwave · Post by **brainwave** » 10 Apr 2010 06:14

@madmacs

The correction is delivered in R710/28.001.

Note : A new flag: CFHgrpP is present in OMC, Other Labels.

Path : OMC > system miscelleneous > Memory Read > Other Labels.

By default, this flag is 00 => means release will be processed first. Hence there will be a delay on caller.
If this flag is set to 01 => connect will be processed first. Now there will be no delay on caller.

This solves the problem at customer site here at the Netherlands who has the same problem. With less than four phones there was no problem but with more then four at a hunt goup the delay was not acceptable.

I got this information from Alcatel-Lucent helpdesk after placing a eRequest

brainwave · Post by **brainwave** » 10 Apr 2010 06:17

@etc

Thats right but from R710/28.001 there is a new flag: CFHgrpP is present in OMC, Other Labels.

By default, this flag is 00 => means release will be processed first. Hence there will be a delay on caller.
If this flag is set to 01 => connect will be processed first. Now there will be no delay on caller.

madmacs · Post by **madmacs** » 12 Apr 2010 08:09

Thank You, I am waiting for customer feed back with these changes.