Re: SRST Problem

dgoswick · ‎10-15-2001

I have a few sites with a small staff of around 10 people. We use centralized call processing and SRST as a backup. Recently, our backup kicked in at two sites due to a network outage. Everything seemed to work fine, except for one thing. The main number that comes into the office is set up as a 'shared line' on everyone's phone. This line produced a busy signal to anyone calling in. Being that this was the main number, it wasn't good. Has anyone seen this, or maybe Dave has heard of this from others?

Markus Schneider · ‎10-16-2001

What kind of a gateway and what kind of interface are you using for the outside callers to dial in? Is this the same interface/GW you use when things aren't in SRS mode?

A guess would be that you have plar configured on an FXO port to a certain number that exists during regular operation (i.e. it's this is being sent to the callmanager) but not in SRS mode. It would be good to see a 'show ephone' in SRS mode to look at all the numbers that the router knows about and then to see what number is being received (either look at the 'connection plar' statement, or 'debug isdn q931' or something) when the call comes in.

I'm assuming that the way you fixed this was by getting the WAN back up (i.e. rebooting the phone or router or something didn't fix it).

dgoswick · ‎10-16-2001

No PLAR configured. The gateway is simply an ISDN PRI in a 4224. Rebooting it did in fact fix this problem on one occasion.

The following error appears 30 to 40 times in a row as soon as the phones try to home to the 4224. It does this on all of my 4224's.

3d20h: %DIALPEER_DB-3-ADDPEER_MEM_THRESHOLD: Addition of dial-peers limited by available memory

There is a total of 20 phones in this office and 46 DN lines total.

Let me throw this at you. The following represents two phone calls. The first call was a simple long distance call placed directly to the main number of the office. The second call was a call to an 800 number that is pointing to the same exact number as the first. The only difference is that while dialing the 800 number, I received no ringback, even though it was in fact ringing on the other end. This only occurs while in SRST mode.

3d22h: ISDN Se1/0:23: RX <- SETUP pd = 8 callref = 0x0499

3d22h: Bearer Capability i = 0x8090A2

3d22h: Channel ID i = 0xA98397

3d22h: Progress Ind i = 0x8281 - Call not end-to-end ISDN, may have in-b

and info

3d22h: Calling Party Number i = 0x00C3, Plan:Unknown, Type:Unknown

3d22h: Called Party Number i = 0xC1, '1070', Plan:ISDN, Type:Subscriber(

local)

3d22h: ISDN Se1/0:23: TX -> CALL_PROC pd = 8 callref = 0x8499

3d22h: Channel ID i = 0xA98397

3d22h: ISDN Se1/0:23: TX -> ALERTING pd = 8 callref = 0x8499

3d22h: ISDN Se1/0:23: RX <- DISCONNECT pd = 8 callref = 0x0499

3d22h: Cause i = 0x8290 - Normal call clearing

3d22h: ISDN Se1/0:23: TX -> RELEASE pd = 8 callref = 0x8499

3d22h: ISDN Se1/0:23: RX <- RELEASE_COMP pd = 8 callref = 0x0499

3d22h: ISDN Se1/0:23: RX <- SETUP pd = 8 callref = 0x086A

3d22h: Bearer Capability i = 0x9090A2

3d22h: Channel ID i = 0xA98397

3d22h: Calling Party Number i = 0x2183, '7708052000', Plan:ISDN, Type:Na

tional

3d22h: Called Party Number i = 0xC1, '1070', Plan:ISDN, Type:Subscriber(

local)

3d22h: ISDN Se1/0:23: TX -> CALL_PROC pd = 8 callref = 0x886A

3d22h: Channel ID i = 0xA98397

3d22h: ISDN Se1/0:23: TX -> ALERTING pd = 8 callref = 0x886A

3d22h: ISDN Se1/0:23: RX <- DISCONNECT pd = 8 callref = 0x086A

3d22h: Cause i = 0x8290 - Normal call clearing

3d22h: ISDN Se1/0:23: TX -> RELEASE pd = 8 callref = 0x886A

3d22h: ISDN Se1/0:23: RX <- RELEASE_COMP pd = 8 callref = 0x086A

Markus Schneider · ‎10-18-2001

The issue with the DIALPEER_DB-3 ADDPEER_MEM_THRESHOLD message has to do with memory. The router won't allow you to add more dial-peers (and therefore consume more memory) if more than 75% of available processor memory is used up (you can get the amount of processor memory via the 'show mem sum' command). These dial-peers are built only during failover; they are dynamically created as DN's register to the SRS router.

As for the 2nd problem (ringback), check out the progress indicators for the respective calls and take a look at:

http://www.cisco.com/warp/public/788/voip/busytone.html

rkoulagi · ‎10-18-2001

It could be that because there is no memory available to create these dial peers, the dial peer for the main

shared line is not created and hence the call fails. 'show call-manager-fallback dial-peers' will show

where there is a dial peer created for that shared line or not. If you dont see the dial peer, that explains

the problem and you will need more processor memory on this box.

dgoswick · ‎10-19-2001

That makes sense. I lowered the IO memory resulting in more Processor memory. I no longer get these errors. I'll have to wait and see if it solves that problem.