I have a 9100 CCIS to a 2000 we can

[AKgreatland]

I have a 9100 CCIS to a 2000 we can transfer callers form the 9100 to the 2000 no issues but when we try to transfer from the 2000 to the 9100 has soon as you hang up caller is recalled back to the transfering extension. Any ideas what may need to change?


Thanks
AKGreatland

It's just another beautiful day in the land of communications.

 

[3racefan3]

Allow route to route connections in command 36 would be the first thing to look at.

 

[AKgreatland]

We have route to route set to allow in command 36. Any other thoughts. Thanks for the help


AKGreatland
It's just another beautiful day in the land of communications

 

[belevedere]

If you wait for the caller to answer before hanging up, does it work?

 

[AKgreatland]

No we tried and neither blind transfer or supervised transfer work.

 

[belevedere]

IP or TDM CCIS?

 

[AKgreatland]

IP we are going thru the IPLB blade

 

[belevedere]

Some items for either IP or TDM;
08> 028> 0 EXE = allow trunk to trunk connection.
08> 253> 0 EXE = allow ring transfer.
08> 373> 0 EXE = send call forward information through CCIS.
08> 379> 0 EXE = maximum number of digits over CCIS is 24.
360 allowed for ALL routes including the D channel route.
A8

 

[AKgreatland]

We verified all these settings and they are set like you said they should be. we can also do conference calls between the two sites as well

 

[belevedere]

I seem to remember 08>062 was backwards in some software levels. Try it both ways.

 

[belevedere]

Make sure 1522, 90, 91 are all set to allow.

 

[AKgreatland]

This is getting good. I always love these trouble shooting scenarios. If I call out from 2000 and connect to outside person I can transfer the caller to the 9100. if an outside caller calls in to the 2000 and I try to transfer to the 9100 it fails.

1522 trunk to trunk is set to allow for all 15 classes of service
1590 set to allow
1591 set to allow
tried both ways on 08>062

let me know if you have any other suggestions and as always thanks for the help

 

[belevedere]

This sure sounds like CMD 360 is not set for the incoming route to the outgoing route.
I always set it like this:
PRI rt 31 + 30
CCIS rt 21 + 20
360>3131>0
3130>0
3030>0
3130>0
3121>0
2131>0
2121>0
3120>0
2020>0
2031>0, etc.
All possible combinations including the "D" channel routes.

 

[AKgreatland]

Thanks for the help. We didn't do the original install on the 2000 and apparently the tech did not realize there was a second PRI card. Set route 60 on the second PRI and all is working. Again thanks for all the help.

AKGreatland
Just another beautiful day in the land of communications

 

[AKgreatland]

Another issue has popped up and I don't know if it is related. When we call forward out of the 2000 to a cell phone we have one way audio. The person calling and being forwarded out can hear just fine but the user who forwarded their phone only has one way audio. Thanks for the help

AKGreatland

 

[belevedere]

Usually a one way audio comes back to the DSP's not available. With an older 2000, you probably have a 8 or 32 IPLA card. Check to see if more ports were assigned than what the hardware provided can supply. A 32 IPLA requires all 32 ports available, and no cards installed after it to accommodate all 32. If you have only 16 assigned, make sure that the 17th port was not programmed in. The same holds true for the 8IPLA card. Perform a LENs list and look for assignments of DD000-DDXXX to determine how many DSP's, or ports are assigned. Verify against the number of hardware ports installed.
Also reset the IPLA card to retrain it. Make all types of calls, ext to ext, ext to pri, ext to page, etc.

 

[AKgreatland]

So if you are doing a call transfer to outside caller it all works fine. if you are call forwarding your desk phone then the user only hears one way audio. IF we are going in and out on legacy PRI cards would the DSP resources still come in to play? As always thank you for your help

AKGreatland

 

[belevedere]

I looked it over again, and the DSP's are not in use in your problem. I'd contact the PRI vendor and see if it is doing is doing a TDM to IP conversion in their system. Possibly on their end.