Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations strongm on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Anti-Tromboning / Transfer issue

Status
Not open for further replies.

DFKSydney

Technical User
Jun 30, 2008
507
AU
An interesting, and frustrating problem...

2 systems... both 1000M one being Rel 4.5 the other being 4.0. The systems have a tie route configured including anti tromboning (and herein lies the start of my problem).

Almost all call scenarios except 1 that I have identified works. The one that doesn't is as follows:

A call is presented to an ANALOG extension (On the Rel 4.5 system and digitals are OK). The analog initiates an inquiry call to an IVR system over the tie line using LSE1 ccts and on the Rel 4 system. The IVR then initiates its own inquiry call back over the same tie route to the attendant DN (ATDN).

IF then the original initiating extension announces the call to the attendant then hangs up, the call does NOT transfer, nor anti-trombone. In fact the incoming caller to the original extension is still sitting on that extension, and the hangup disconnect would appear to fail. The result being that when the original extension picks up, the incoming caller is still there.

In a blind transfer situation, there is no issue. Also there are no identified issues in the above call scenario when the transfer is to either digital or analog extensions.

The failure appears to be related to the anti-tromboning as when the ESN is modified so that the IVRs use an alternate route back to the originating node the announced call transfer is successful.

Our systems are not currently fully patched, but a check on whats missing says that except for some "complex transfer patches" relating to call pilot.

Only programming issue that I can see as a possibility (and I may be wrong ) is that the PNI in the RDB on both systems are different.

Any suggestions on this would be greatly appreciated.


Thanx

Hopefully the above explanation makes some form of sense.
 
PNI's should be the same around your PABX network especially for CallPilot functionality

I would check your TRO (Trunk Route Optimisation) set that to NO as this causes problems with Tromboning Set to Yes
on the Routes

Cheers Mate!!



 
Just because it is not CallPilot does not mean that they will not fix your trouble. All that means is that is where the issue was identified and if it is similar enough to your issue I would put those patches in.

Signature===========================================

 
So if you do the same call as above but the finale destination is anyone but the Attendant everything works?
 
Had this almost same problem. Nortel wrote a patch (i'm sorry but I no longer have patch info) after about 6 months of Diag patches and tests.

Get Nortel involved.
 
Hi, and thanx to those that have responded....

Feedback:

SL1M1: have set the PNIs the same, and set TRO = NO, and we have the same result....

Hawks: The call failure is ONLY to the attendants. No other case has been identified as yet.

tnphoneman: No truer words have been said. There is a sad fact of life here that it is like pulling teeth to get a change control through for patch insertion. We are going through the motions at the moment to get them in. The transfer patches (if not part of the missing dependancies will certainly go in). It may be a few weeks til it happens though.

Reusser: If the failure is still there after patch upgrades then out vendor / nortel will be brought in.

Again thanx for the suggestions so far.....
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top