redirection for absent operator to hunt group not always working

[ursusK]

Hello all!

In my company when the operator is absent all the calls should be forwarded to a dect dt590, when that phone is busy, the call should be forwarded to another dt590.

The company who installed our MD110 BC12 implemented that with a huntgroup with those two numbers in it, and when the operator is absent the calls are being forwarded to the huntgroup.

I thought everything worked fine. But this is not always the case. Sometimes the following happens: de operator is absent but the dt590 are not ringing. When i dial from an internal number directly to the dt590 it rings. Only when i turn the dect off and back on the calls from outside are being redirected to the dect.

Do you have any ideas how to search for an answer for this problem? This does not always happen, i am still not able to reproduce the problem. But it happens once or twice a week.

Something similar happens with a telephone intercom (actually a phone) that dials an internal generic number with the same two dects in it.

Many thanks in advance for your help,

Björn Kreuger

 

[lalrl]

If DT590 does not ring, what hears the caller? Busy?

Then check aspaparnum=178

 

[TRIDENT100]

It`s better to use PELPI on the dect phone

/*Trident/*

 

[a179794]

I think that your Dect detach from network. How many bases stations on your site ? Do dect have handover between these base stations ? When the problem appears does the caller hears 3 or 4 normal tones and after busy tone ? If internal caller, can he see "unavailable" on his phone ?

 

[ursusK]

We have 26 dect basestations in and around our building. The one who has duty can walk freely in the building.

The caller indeed hears 4 (or maybe more) normal tones. And i heard that after a number of calls some callers hear a busy tone..

But the strange thing is, that the one with the dect can call inside as well as outside, while he is not reachable from outside. When he turns of his dect and turns it on again, then he is reachable from outside again..

Many thanks for your efforts to help me..

 

[a179794]

I think you'd better upgrade your bases stations software and portable phones if you don't have the last version (As well as I know, most recents soft for base stations are : Core R2B, Worf R3E)

 

[ursusK]

Is it something i can do myself? Or do i have to hire the company to do it for me?

 

[etompau]

If internal calls to the DECT extension is working OK, I can hardly see that upgrading of the base stations should have any impact on the problem.

As usual, try to analyze, isolate and reproduce the problem, before spening time on upgrading.

 

[a179794]

Hi etompau and ursusK,

I've had exactly the same problem on my site. After the upgrade of base stations, the apparition of this kind of problem have been reduced by about 70% (not enough but quite better). After that a Sweden expert of Ericsson came to try to understand... no more news up to now. May you'll be more lucky.

But etompau is right, you have to try to reproduce the problem before uprading base stations or ELU31.
I suppose that you'll be able to do this by :
- Moving in different places with your portable phone between different base stations (connected to different or same ELU31 boards) without communication). Thenafter (5 or 10 minutes), try to call your portable phone and, if the problem appears note the base station number and PARI thanks to Debugging mode. You should also try to verify le LEDS. Thanks to this operation, may be you will find a base station out of service. I found 2 Core base stations in this case on my site.

For in formation, to upgrade a Base station firmware:
CNBLI:BPOS=(board where are connected base stations),path=(path to the firmware file),ind=(position of the base station on the board - Don't forget this parameter!);.
To upgrade a Board firmware :
CNBLI:BPOS=(Board to be Upgraded),path=(path to the firmware file);

Post the results of your tests.

Please, post a cnbip:brdid=108,lim=all; to see if an upgrade is needed for your base stations or elu31 boards .
For me your problem can be due to :
- problem of handovers
- traffic.
but, unfortunatly, I think you'll have to contact your local support.
(sorry for my english)

 

[ursusK]

Hello a179794 and etompau,

I'm really glad that you experts are willing to help me!
Thank you for that..
Here is the output you asked for: Hopefully it reveals something..
CNBIP:BRDID=108,LIM=ALL;


DEVICE BOARD REVISION INFORMATION


DATE: 27JAN05 TIME: 14:20:31




BPOS BOARD/BRDID PRODUCT NUMBER REVISION STATUS ADD
/IND


001-0-40 ELU31 ROF1375412/1 R2C
CAA 158 0010 R9A
00 KRCNB 301 03/1 R2
R3B 2 R3B 2 EXE
CXCNB 101 108/3 R3B 3/06 EXE
01 KRCNB 301 03/1 R2
R3B 2 R3B 2 EXE
CXCNB 101 108/3 R3B 3/06 EXE
02 KRCNB 301 03/1 R3
R3C 2 R3C 2 EXE
CXCNB 101 108/3 R3E 3/06 EXE
03 KRCNB 301 03/1 R2
R3B 2 R3B 2 EXE
CXCNB 101 108/3 R3B 3/06 EXE
04 KRCNB 301 03/1 R3
R3C 2 R3C 2 EXE
CXCNB 101 108/3 R3E 3/06 EXE
05 KRCNB 301 03/1 R2
R3B 2 R3B 2 EXE
CXCNB 101 108/3 R3B 3/06 EXE
06 KRCNB 301 03/1 R2
R3B 2 R3B 2 EXE
CXCNB 101 108/3 R3B 3/06 EXE
07 KRCNB 301 03/1 R2
R3B 2 R3B 2 EXE
CXCNB 101 108/3 R3B 3/06 EXE
001-0-42 ELU31 ROF1375412/1 R2C
CAA 158 0010 R9A
00 KRCNB 301 03/1 R2
R3B 2 R3B 2 EXE
CXCNB 101 108/3 R3B 3/06 EXE
02 KRCNB 301 03/1 R2
R3B 2 R3B 2 EXE
CXCNB 101 108/3 R3B 3/06 EXE
04 KRCNB 301 03/1 R2
R3B 2 R3B 2 EXE
CXCNB 101 108/3 R3B 3/06 EXE
05 KRCNB 301 03/1 R2
R3B 2 R3B 2 EXE
CXCNB 101 108/3 R3B 3/06 EXE
06 KRCNB 301 03/1 R3
R3C 2 R3C 2 EXE
CXCNB 101 108/3 R3E 3/06 EXE
07 KRCNB 301 03/1 R2
R3B 2 R3B 2 EXE
CXCNB 101 108/3 R3B 3/06 EXE
001-1-40 ELU31 ROF1375412/1 R2C
CAA 158 0010 R9A
00 KRCNB 301 03/1 R2
R3B 2 R3B 2 EXE
CXCNB 101 108/3 R3B 3/06 EXE
01 KRCNB 301 03/1 R2
R3B 2 R3B 2 EXE
CXCNB 101 108/3 R3B 3/06 EXE
02 KRCNB 301 03/1 R2
R3B 2 R3B 2 EXE
CXCNB 101 108/3 R3B 3/06 EXE
03 KRCNB 301 03/1 R2
R3A 2 R3A 2 EXE
CXCNB 101 108/3 R3E 3/06 EXE
04 KRCNB 301 03/1 R2
R3B 2 R3B 2 EXE
CXCNB 101 108/3 R3B 3/06 EXE
05 KRCNB 301 03/1 R2
R3B 2 R3B 2 EXE
CXCNB 101 108/3 R3B 3/06 EXE
06 KRCNB 301 03/1 R2
R3B 2 R3B 2 EXE
CXCNB 101 108/3 R3B 3/06 EXE
07 KRCNB 301 03/1 R2
R3B 2 R3B 2 EXE
CXCNB 101 108/3 R3B 3/06 EXE
001-1-70 ELU31 ROF1375412/1 R2C
CAA 158 0010 R9A
00 KRCNB 301 03/1 R3
R3C 2 R3C 2 EXE
CXCNB 101 108/3 R3E 3/06 EXE
01 KRCNB 301 03/1 R3
R3C 2 R3C 2 EXE
CXCNB 101 108/3 R3E 3/06 EXE
02 KRCNB 301 03/1 R3
R3C 2 R3C 2 EXE
CXCNB 101 108/3 R3E 3/06 EXE


END
/* SUCCEED 14:20:42 */

 

[a179794]

The first thing I can see is that most of your bases stations can be upgraded. For example, before R3E Firmware, a cordless phone tried to connect to the nearer base station even if it was completly busy.

The second is that you probably have too much base stations on your 3 first ELU31 boards. (Max 16 speech connections per ELU31).

How many DECT phones are declared in your system ?
Are some base stations placed in areas where traffic is supposed to be low ? high ?
Are base stations covering as same area connected to the same ELU31 ?
Have you got 1 or 2 more ELU31 boards ?
Post a CNLIP:LIM=ALL,DEV=YES; to see if it's possible to add ELU31 boards.

Have you tried to reproduce the problem ? If yes, what's the result ?

Regards