Incoming call fail on T2 (J1.410.40.c) <SOLVED>

[knightrider]

Hi,
I have a strange issue where I build a new CS on Appliance with R10.0 (J1.410.40.c)
I load OPS and no errors.

I create a new T2 Trunk Group (ISDN all Countries with DDI Transcoding) and configure for DDI. But when I dial in, the call fails and there is incident 6060 which does not even exist when you look at incinfo!!!

If I get a MAO database from a 9.1 system and translate it into my new R10.0 with patch 40c then no problem. But then when I delete & re-create the TG, again it fails on incoming

There is no problem with outgoing.

Meanwhile, I have rebuilt the CS with J1.410.38.c and I do not get the problem. Not sure if anyone has this issue... Can anyone check?
Thanks

[knightrider]

I am Surprised no-one has had this issue yet!
I have opened an eSR with ALU now - I will keep you all posted!

[knightrider]

OK, ALU have explained the problem and the fix is as follows...

With reference to the issue with inbound T2 calls; as per the incident and back trace issue seems to be a known as per the crms 00368146. These back traces are occurring in a place where the incident 6060 is being generated.

This incident will be generated only when we set the following parameter in trunk group.

Mgr-->trunk groups-->D/H-->trunk group-->R/M-->Trunk Group ID:
Reroute Anonymous Calls to Entity + TRUE/FALSE
it’s used by the feature PER 1059.
If you are going to use this feature you have to set the above Boolean as TRUE. At the same time you have to upgrade the system to j1.410.42.

If not you can disable the same. As a result you won’t get back traces and 6060 incident. To disable, change the parameter "Reroute anonymous calls" from NO to YES and then to NO the back trace will not present any more.

Use of the Boolean "Reroute Anonymous Calls to Entity" if OXE is receiving a secret identity call/number missing the call will be rerouted to entity.

I toggled the parameter as suggested and all is ok now. I do not know if I would have detected this problem if the incoming call had CLI present

[kupa]

OK, ALU have explained the problem and the fix is as follows...

With reference to the issue with inbound T2 calls; as per the incident and back trace issue seems to be a known as per the crms 00368146. These back traces are occurring in a place where the incident 6060 is being generated.

This incident will be generated only when we set the following parameter in trunk group.

Mgr-->trunk groups-->D/H-->trunk group-->R/M-->Trunk Group ID:
Reroute Anonymous Calls to Entity + TRUE/FALSE
it’s used by the feature PER 1059.
If you are going to use this feature you have to set the above Boolean as TRUE. At the same time you have to upgrade the system to j1.410.42.

If not you can disable the same. As a result you won’t get back traces and 6060 incident. To disable, change the parameter "Reroute anonymous calls" from NO to YES and then to NO the back trace will not present any more.

Use of the Boolean "Reroute Anonymous Calls to Entity" if OXE is receiving a secret identity call/number missing the call will be rerouted to entity.

I toggled the parameter as suggested and all is ok now. I do not know if I would have detected this problem if the incoming call had CLI present

Hi,
I have a strange issue where I build a new CS on Appliance with R10.0 (J1.410.40.c)
I load OPS and no errors.

I create a new T2 Trunk Group (ISDN all Countries with DDI Transcoding) and configure for DDI. But when I dial in, the call fails and there is incident 6060 which does not even exist when you look at incinfo!!!

If I get a MAO database from a 9.1 system and translate it into my new R10.0 with patch 40c then no problem. But then when I delete & re-create the TG, again it fails on incoming

There is no problem with outgoing.

Meanwhile, I have rebuilt the CS with J1.410.38.c and I do not get the problem. Not sure if anyone has this issue... Can anyone check?
Thanks

THANKS ALOT

[FN_DK]

Wrong post. Mod please delete