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

FXO Disconnect

I have the following topology:

Telephone "A"<->PBX<->1750(FXO)<->5350(ISDN)<->PSTN<->Telephone "B"

When "A" calls "B" and "B" answers, after both sides hanging up, the channel between the PBX and the 1750 *never* gets disconnected (I waited for more than an hour).

When "A" calls "B" and "B" does NOT answer, the line between the PBX and the 1750 is disconnected after 2-3 minutes (after "A" hanging up).

What happens? I use 12.2(8)T on the 1750, with VIC-2FXO-M1. The PBX, though, has NO supervisory on disconnection (no battery reversal) and I use loop start (no ground-start available on the PBX).

Thank you very much,

Paulo.

8 REPLIES
New Member

Re: FXO Disconnect

well u can try 12.2(2)T.; that one has supervisory disconnectand the remaining parameters u might need

Abdelaziz

New Member

Re: FXO Disconnect

Hi, Abdelaziz, if I'm already using 12.2(8)T, do I still need to go back to 12.2(2)T?

Thank you

Paulo.

New Member

Re: FXO Disconnect

well, i guess u should stick to what u have, but i tried the 12.2(2)T and it qworked out well;supervisory disconnect and all that

New Member

Re: FXO Disconnect

I understand. But in your case, I think the PBX supported supervisory disconnection.

Thank you

Paulo.

New Member

Re: FXO Disconnect

what kinda pbx r u using?is it a lucent definity?it might beyour pbx doesn't support it.In my own case, the setup is shown below:

T1--->channel-bank--->T1-controller---->router-->fxo

New Member

Re: FXO Disconnect

I'm using a Siemens Hicom 150. I think it's the PBX too. They told me it doesn't support any type of supervisory disconnection on the extension lines.

My topology is similar to yours, except for the fact that I use E1 instead of T1.

Thank you

Paulo.

New Member

Re: FXO Disconnect

Did you solve disconnect problem with Siemens Hicom? We have one too with same problem.

New Member

Re: FXO Disconnect

Not yet. But I got news: my ITSP told me that the problem may not be on the FXO interfaces, but in the ITSP's connection to the PSTN. This connection is holding some calls, and they have not solved this problem yet. Indeed, the problem I found was strange, because I expected to find exactly the opposite: I mean, the not answered calls being held and the answered calls being released after some time.

I'll make more tests, to different regions and see what happens.

188
Views
0
Helpful
8
Replies
CreatePlease to create content