.
Attendant transfer problem, External part to QSIG.
Attendant can not transfer external part to QSIG part. Transfer after answer: With plugin patch 201 activated it is OK to make transfer after QSIG part have answered. (Without plugin 201 all parties is disconnected.) Transfer before answer, blind transfer: Attendant can not press rls key - nothing happens - can not get rid of call. A digital set can make transfer of this call types , booth before answer and after answer. Callscenario, transfer after answer: 1. Attendant dials external CO trunk ACCOD followed by area code and nr: 0700xxxxx8001# 2. Ext part answer call 3. Attendant dials QSIG trunk ACCOD and set nr in AAstra PBX: 07xxxxx86# 4. Set 72086 answers call 5. Att press rls key 6. OK , if plugin 201 is activated. Callscenario, blind transfer: 1. Attendant dials external CO trunk ACCOD followed by areacode and nr: 07000xxxxxxx001# 2. Ext part answer call 3. Attendant dials QSIG trunk ACCOD and set nr in AAstra PBX: 070xxxxx086# 4. Attendant press rls key, nothing happens - can not get rid of call.
Solution:
The operation with the Attendant console and ACOD is design intent. A regular set works in this scenario because it is a simpler setup with only one TN. The console has two TNs. One TN is the DID call, and the second is the TIE call. When dialing with the ACOD the DIGITLOAD counts all of the digits ACOD + Number, but the DIGITUNLOAD only counts the ACOD. This is normal operation. When the attendant hits release to join the two calls together the two calls must be simplified into one. The software does some checks before putting the two calls together. While the calls are on the console the console is the originator of both calls, but afterwards one of the two calls becomes the originator. Since there is a difference between DIGITLOAD and DIGITUNLOAD, the software cannot tell (without a lot more checking) if there is any outpulsing happening on the TIE call. The software was designed to block the transfer in this case because switching the originator of the call during outpulsing would be dangerous. Therefore this is not a bug, but intended safety built into the software. The reason it works with CDP is that CDP does not store the ACOD, just the destination number, so DIGITLOAD and DIGITUNLOAD are equal and the transfer is allowed.
Attendant can not transfer external part to QSIG part. Transfer after answer: With plugin patch 201 activated it is OK to make transfer after QSIG part have answered. (Without plugin 201 all parties is disconnected.) Transfer before answer, blind transfer: Attendant can not press rls key - nothing happens - can not get rid of call. A digital set can make transfer of this call types , booth before answer and after answer. Callscenario, transfer after answer: 1. Attendant dials external CO trunk ACCOD followed by area code and nr: 0700xxxxx8001# 2. Ext part answer call 3. Attendant dials QSIG trunk ACCOD and set nr in AAstra PBX: 07xxxxx86# 4. Set 72086 answers call 5. Att press rls key 6. OK , if plugin 201 is activated. Callscenario, blind transfer: 1. Attendant dials external CO trunk ACCOD followed by areacode and nr: 07000xxxxxxx001# 2. Ext part answer call 3. Attendant dials QSIG trunk ACCOD and set nr in AAstra PBX: 070xxxxx086# 4. Attendant press rls key, nothing happens - can not get rid of call.
Solution:
The operation with the Attendant console and ACOD is design intent. A regular set works in this scenario because it is a simpler setup with only one TN. The console has two TNs. One TN is the DID call, and the second is the TIE call. When dialing with the ACOD the DIGITLOAD counts all of the digits ACOD + Number, but the DIGITUNLOAD only counts the ACOD. This is normal operation. When the attendant hits release to join the two calls together the two calls must be simplified into one. The software does some checks before putting the two calls together. While the calls are on the console the console is the originator of both calls, but afterwards one of the two calls becomes the originator. Since there is a difference between DIGITLOAD and DIGITUNLOAD, the software cannot tell (without a lot more checking) if there is any outpulsing happening on the TIE call. The software was designed to block the transfer in this case because switching the originator of the call during outpulsing would be dangerous. Therefore this is not a bug, but intended safety built into the software. The reason it works with CDP is that CDP does not store the ACOD, just the destination number, so DIGITLOAD and DIGITUNLOAD are equal and the transfer is allowed.
