SRST - incoming calls on fxo ports

[AnthonyRowe]

Platform: Cisco 1760 running 12.4(8) ipvoice with VIC4fxo module in slot 2.

Problem: When in SRST mode outbound calls work fine. The dial-peers steer all pstn calls out the fxo ports. However, when calling in on one of the pots lines connected to the fxo ports the caller hears one ring then nothing except maybe a couple of thumps. The target phone never rings and if you pick up the hand set anyway, you get dial tone. This is while the caller is still connected to the fxo port. The call stays up (the fxo port is busy and the light stays on) even after the caller hangs up. I then have to physically unplug the line cord from the fxo to get the port to hang up. I can see that the ephones successfully register with the router and their dn's are properly recorded. I can also ping each phone from the router. Callmanager 4.0 is configured so that each phone is using it's local router for srst. There is only one 1760 at each site and each has the same fxo module and config, no pri locally, just pots lines.

All of the remote sites (9) are experiencing the same symptoms. For inbound calls we are using connection plar statements in our dial peers.

I have included the config file from one of the routers.

[gpulos]

you may need a PLAR CONNECTION or INCOMING-CALLEDNUMBER setup in some dialPeers to get your incoming calls to goto the correct phone(s). i don't see any of this in your config. see the following link for more info:

http://www.cisco.com/en/US/partner/tech/tk652/tk90/technologies_tech_note09186a0080147524.shtml

also, as far as the line not hanging up, may be a different issue (fxo disconnect problem). see the following link for more info:

http://www.cisco.com/en/US/partner/tech/tk652/tk653/technologies_tech_note09186a00800ae2d1.shtml

[AnthonyRowe]

Here's the connection PLAR config:

voice-port 2/0

timing hookflash-out 50

timing inter-digit 100

connection plar 7900

description 877-6667

!

voice-port 2/1

timing hookflash-out 50

timing inter-digit 100

connection plar 7901

description 877-6668

!

voice-port 2/2

timing hookflash-out 50

timing inter-digit 100

connection plar 7902

description 877-6669

I was under the understanding that when the ephones register with the srst router, the router builds a table that associates the registered phones extension # with its IP addr. Therefore there is no need for inbound dial-peer. It couldn't be a voip dialpeer because the addresses are dhcp assigned and it couldn't be a pots dialpeer because they are voip phones and there's no guarantee that the ephone will get assigned the same dynamic voice port when in srst mode, i.e. the ports that are created such as 50/0/1 which the ip phones get associated with.

thanks for the links! Personally I think that the calls don't get diconnected because the voip phone never really gets the call and the router thinks it's connected so it never gets an on-hook signal from the voip phone therefore it never realeases the fxo port.

[a.gooding]

suggestions above are what im thinking. if the phones register with the same number (which it should) the plar should ring the phone. as for the suggestion about the disconnect, if not in srst mode, place a call and tell the end user not to answer, let the phone ring twice then hang up. if the phone continues to ring then you have an FXO disconnect issue.

the last thing is, i did a lab recently demonstrating srst. my lab was fine, and i decided for some reason unknown to me, to upgrade the router to a 12.4 version. not too sure which, but, my router stopped functioning. the calls did not come in.i eventually downgraded and it worked again. so, use a test rtr if all else fails try

12.4(3e) this is what im using for all systems now and it seems to be working properly.

[AnthonyRowe]

12.4(3e) ok, I'll try that. I upgraded from 12.3(8), which TAC said was defferred, to resolve this issue already. The configuration used to work but we found out recently that all sites now have this problem. The only change I know for sure that occurred to the config between now and then was a MoH config was added to allow streaming the .wav file directly from the router's flash rather than over the WAN connection from callmanager. This configuration sets up a multicast scenario for MoH locally at each site utilizing the router. Other than that the IOS may have been upgraded to 12.3(8) after we tested SRST. These are the only two changes that have happened site-wide. I am planning on removing the MoH config to see if that will resolve it but I can't imagine why that would be causing this problem.

[rhugo · Accepted solution]

I ran into several "FXO disconnect" issues with using 12.4 images and FXO ports and, per TAC recommendations, I rolled back the two routers in question to 12.3(11)T10, which they said has lately, proved to be the MOST stable for this issue. My issue was attributed to certain firmware on VIC-2 DSP cards that were factory loaded. The architecture had a flaw that caused corruption and, in turn, caused the port to remain seized after a call. All outbound calls would work, but inbound calls would ring several times and then DROP. You should also check with TAC Case Collection to see if this could be attributed to your problems.

CSCsa51921

This is the bug I was experiencing.

[AnthonyRowe]

At this point that is the only thing that makes sense. We have inbound calls coming into these same fxo ports all the time while it's operating in MGCP. So it doesn't seem to be a disconnect supervision setting thats wrong. We went from 12.3(8)T3 to 12.4(8) but the symptoms didn't change. I am scheduled to work with TAC on this today. I'll post what we find tomorrow. I'll try 12.3(11)T10 before that though just in case that fixes it. Thanks alot!

[AnthonyRowe]

12.3(11)T10 did indeed fix the disconnect issue. Thank you for that info. The incoming call issue was due to:

I believe I have discovered the cause of this issue. As you mentioned the other day the debugs reveal that the fxo module is trying to contact callmanager before it chooses a dial-peer so I thought about it and suddenly realized that the router could still be able to see callmanger even while the WAN is down. They have a BRI configured as a dial backup that connects to a site that hosts their main application, not the main site where call manager resides. Traffic is not supposed to be able to reach their main site through this isdn circuit but we discovered that it can. The access list on the dialer interface blocks traffic from the voice vlan but not traffic originating from the srst router itself. Therefore you have phones in srst mode but the router isn't. I disconnected both the FR wan circuit AND the bri line last night and suddenly inbound calls started working. I am going to configure an acl on the dialer interface that blocks traffic from callmanager and that should fix it.

[Steven Landon]

Anthony,

I am not sure of your exact architecture with the ISDN dial backup. If you are using dynamic routing, it may be better to just not advertise the network CallManager is on over that BRI. That way there just simply won't be a route. That is also assuming you don't have to advertise a default route in that situation as well.

My idea may not work.....just food for thought. I don't like using ACLs when you can simply manipulate routing tables.

Steve

[AnthonyRowe]

Steve, that is a much better idea thank you. That will save on cpu cycles.