Cisco Support Community
Showing results for 
Search instead for 
Did you mean: 
Community Member

FXO to FXO call transfer.....not getting released!!!

Hi guys!!!

I am having 8 analog lines, all with same number, connected to 2811CME thru 8 fxo ports....the problem is when we call an outside pstn number and transfer it to another pstn number, i e using two fxo ports, the call is not getting cleared even after the endpoints hang up, the ports are enganged for 10 or 15 hours...please help me in this issue


Re: FXO to FXO call transfer.....not getting released!!!

Hi, found this on an old Cisco document:

If you permit call forwarding of incoming PSTN calls into outgoing PSTN calls where your PSTN interface uses simple analog Foreign Exchange Office (FXO) ports, you may have a problem with disconnect supervision. In many cases, your PSTN provider will not have enabled call disconnect signaling on the PSTN subscriber lines connected to your FXO ports. For the case of a PSTN FXO-to-FXO hairpin call path, this can result in hung voice ports, because there is no signaling of disconnect when the remote PSTN parties hang up. If you encounter this problem, you need to contact your PSTN service provider and have it enable disconnect supervision on your PSTN phone lines.


Community Member

Hello,We are facing same


We are facing same issue, would you please tell us how you fix it ?


Community Member

Re: FXO to FXO call transfer.....not getting released!!!

Just taken a look at your posted config, assuming your cptone and supervisory disconnect commands are correct. You will also need to apply this command.

#voice-card 0

#no local-bypass

Because both legs of the call are analogue, the DSP drops out of the call path since it is technically no longer required. Therefore the audio stream from one port is directly connected to another. And as a result the supervisory disconnect tone feature is not active since the DSP is no longer part of the call path to monitor the audio stream for the disconnect tones.

This ultimately causes the FXO ports to remain in an off-hook state for calls which have been forwarded back out another FXO even when the caller/receiver has gone on-hook.

Let us know how it goes.



CreatePlease to create content