I have a KXTD1232 V7. They want to be able to transfer calls to an extension that can forward to a cellphone.

the FWD is set to all calls 9Pxxx-xxx-xxxx

1) If you intercom call the extension from another extension it will pick up an outside line, call the cellphone and bridge the call.

2) From the outside world, if you call the DID assigned to extension it will pick up an outside line, call the cell phone and bridge the call.

3) From the outside world, if you call in and the call is ANSWERED FIRST and then TRANSFERED to the extension it will pick up an outside line, call the cell phone.

Here is where it gets weird. If the party doing the transfer remains on the line until after the cellphone picks up before hanging up, it gets bridged. However if the transferring party hangs up just after the ringing starts like on a normal transfer, the outbound line gets dropped and the call never completes. Oddly it continues to audibly ring to the original inbound caller.

Make sure Trans to CO and CFWD to CO is on in COS.
Also try to put in a few "P" at the end of the dial string.

Thank you for responding Brokeda!
Both those were checked off in the COS. Like I said the calls will go as long as the transferring party stays in it until answered.

SO put a few pauses at the end of the dial string? I'll be going back in a day or so and will try that.

Panasonic said could be a corrupted procesor and may not be able to be fixed. They suggested defaulting the cabinet and starting over but I think it was snowing when they said that.

I tried putting several pauses after the outbound dial string and it didn't seem to help any. Unless the transfering party stays on the line until answered the outbound line gets dropped.

I still have trouble believing the processor is corrrupted and this is the only problem they are having. As per Panasonic Support I backed it up, defaulted the KSU and reloaded.

This made no difference either. OH... Except now their ISDN DID's apparently quit around the same time so I'm on my way back. UGH I hate when it gets worse after I touched something. Maybe it's the carrier? Yeah I ain't that lucky.

Did not notice the PRI thing.
Check with Carrier and see if they have allowed Trunk to trunk Transfer, or whatever they call it. Sounds as if Conf is OK but not xfer.

R, R, R... The ISDN thing WAS the carrier upgrading at night and now not sending the clock. I happened to be in the wrong place at the wrong time.... again.

Dumbass me took too long presuming it was something I had done. Carrier swore it was all working but after I asked them to re synch it all came back to life.

I STILL can't do the offsite transfer without them staying on the line though. I KNOW this has to be wrong but what the heck could it be?

The calls they were trying to transfer are on the POTS lines of the system.

Why would the carrier trunk to trunk transfer be an issue if the Panasonic is doing the bridging?

I think they would be better off USING the carrier's transfer and drop feature and eliminate the DB loss inherent in tying 2 lines together.

Then try Fxxx-xxx-xxxx as the xfer if they have transfer disconnect on those lines.

They don't have Xfer drop YET. That's what I am recommending. We'll see.

Just another oddity of my life....

I did what Tech Support told me to try. I backed up the Dsys file, defaulted the cabinet and then reloaded the file I had just saved. Everything seemed to come backj up just fine. However, I got a call the next day that the VM was grabbing the inc. faxes. They had a DIL from one of the DID to their fax 216. That DID was now DIL'd to 168. How do things just change like that?
????????????????????

Rocky, I think it's something in the hat.