Hairpinning on FXO ports stay-up

Unanswered Question
Feb 25th, 2009

We have this occasional problem in one of our remote sites. It seems (based from the "show call active" output below) that when a user hairpinned and call another FXO user on the same router/gateway, the call will stay-up indefinitely. Any ideas?

Telephony call-legs: 1

SIP call-legs: 0

H323 call-legs: 1

Call agent controlled call-legs: 0

SCCP call-legs: 0

Multicast call-legs: 0

Total call-legs: 2

12F2 : 241 1044109390ms.1 +17190 pid:2 Answer active

dur 01:59:19 tx:103160/2864221 rx:42581/838969

Tele 0/0/1 (241) [0/0/1] tx:7153710/840930/0ms g729r8 noise:-64 acom:30 i/0:-6

6/-79 dBm

12F2 : 242 1044122720ms.1 +3860 pid:500 Originate 916504293300 active

dur 01:59:19 tx:42536/838069 rx:103160/2038941

IP 192.168.10.106:16612 SRTP: off rtt:86ms pl:2027960/4620ms lost:937/94/414 de

lay:60/60/250ms g729r8

media inactive detected:n media contrl rcvd:n/a timestamp:n/a

Telephony call-legs: 1

SIP call-legs: 0

H323 call-legs: 1

Call agent controlled call-legs: 0

SCCP call-legs: 0

Multicast call-legs: 0

Total call-legs: 2

I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 4 (1 ratings)
Loading.
robertdm1973 Wed, 02/25/2009 - 12:09

Sorry have posted the wrong router. It should be this:

Telephony call-legs: 4

SIP call-legs: 0

H323 call-legs: 0

Call agent controlled call-legs: 0

SCCP call-legs: 0

Multicast call-legs: 0

Total call-legs: 4

152E : 750 1837322490ms.1 +3790 pid:7 Answer active

dur 05:36:23 tx:0/0 rx:0/0

Tele 0/1/2 (750) [0/1/2] tx:0/0/0ms None noise:0 acom:0 i/0:0/0 dBm

152E : 751 1837324060ms.1 +2220 pid:1 Originate 105 active

dur 05:36:23 tx:0/0 rx:0/0

Tele 0/0/0 (751) [0/0/0] tx:0/0/0ms None noise:0 acom:0 i/0:0/0 dBm

1531 : 752 1837345340ms.1 +4500 pid:4 Answer active

dur 05:35:59 tx:0/0 rx:0/0

Tele 0/1/0 (752) [0/1/0] tx:0/0/0ms None noise:0 acom:0 i/0:0/0 dBm

1531 : 753 1837347620ms.1 +2220 pid:6 Originate 139 active

dur 05:35:59 tx:0/0 rx:0/0

Tele 0/1/1 (753) [0/1/1] tx:0/0/0ms None noise:0 acom:0 i/0:0/0 dBm

Telephony call-legs: 4

SIP call-legs: 0

H323 call-legs: 0

Call agent controlled call-legs: 0

SCCP call-legs: 0

Multicast call-legs: 0

Total call-legs: 4

Nicholas Matthews Wed, 02/25/2009 - 18:10

Hi Robert,

This is one of the ways that FXO disconnect supervision manifests. To test - call an IP phone through your FXO port. Hang up on the FXO side. The call will stay up indefinitely.

You need to figure out how to get the disconnect supervision from your provider to work.

This link is a good starting place:

http://www.cisco.com/en/US/docs/ios/12_2t/12_2t2/feature/guide/ft_ansds.html#wp11109

hth,

nick

robertdm1973 Thu, 02/26/2009 - 12:26

Thanks Nick for the reply. I do not have this disconnect problem when the router is calling from POTS (via FXO) - VOIP. It's only POTS - POTS.

I've read some old threads on the forum having a similar problem, and they disabled local-bypass ("no local-bypass) on the voice card as their work-around.

Have put that on mine, but it's a bit early to determine if it really fix the problem.

Regards,

Robert

Nicholas Matthews Thu, 02/26/2009 - 13:06

Hi Robert,

That's very odd. Nearly 98% of the time this is a manifestation of disconnect supervision.

Most people overlook the fact that the only reason the FXO port is ever disconnecting is because the IP phone hangs up.

Are you sure that your phone calls disconnect if the IP phone doesn't hang up?

-nick

robertdm1973 Thu, 02/26/2009 - 13:18

Yup. I actually have that disconnect problem (FXO-VoIP) before when I'm starting this project. The FXO port will stay "off-hook" even if the other end hangs-up, but this config fix it:

voice-port 0/0/0

supervisory disconnect dualtone mid-call

no battery-reversal

cptone IT

timeouts call-disconnect 5

timeouts wait-release 5

impedance complex2

But again, it's a bit early to say that disabling local-bypass will fix the FX0-FX0 problem as specified on the previous thread.

Regards,

Robert

Nicholas Matthews Thu, 02/26/2009 - 14:29

I wouldn't suspect for local bypass to fix this. DSPs have done less weird things, however.

It may be possible to run FXO debugs to see if we're getting the disconnect and ignoring it (which would have to be the case if there isn't a normal FXO disconnect issue), but it doesn't sound like something you're able to recreate.

hth,

nick

robertdm1973 Thu, 02/26/2009 - 14:41

Yes, the router's in Europe and it's a bit difficult to re-create. I'm just waiting for someone to do an FXO-FXO call transfer again.

But enabling the FXO debug *now* will be smart, just in case. What the best debug command for this?

Thanks,

Robert

robertdm1973 Thu, 02/26/2009 - 15:06

Thanks Nick. I'll enable that and in case the problem returns, will post the "show log" here.

Regards,

Robert

Actions

This Discussion