cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1365
Views
7
Helpful
5
Replies

Max-conn not working properly?

chesebrgr
Level 1
Level 1

I seem to have a problem with max-conn on a dial-peer. This is a 3745, IOS 12.4 r4.

Router#sh run | begin dial-peer voice 18

dial-peer voice 18 voip

service MyTCLService

max-conn 400

incoming called-number .T

After a busy night of traffic, I get complaints that this gateway is refusing calls. So I run the following - results cropped to show relevant info:

Router#sh dial-peer voice 18

        incoming called-number = `.T', connections/maximum = 400/400

Router#sh call acti voi bri

Telephony call-legs: 0

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: 0

Router#sh call appl voi | inc Instances

       Exec Instances: 0


Clearly it is refusing calls because the max-conn has been reached. Yet there are no calls in progress and no instances of the TCL code running. So it seems the calls are clearing properly, and the TCL code is terminating properly. Yet the max-conn counter is not being reset for some calls. What should I be looking at here? How can I find out why the connections are not being freed up after the calls finish? And is there any way of finding out which calls are not freeing up their connection slots?

When I run it in a test environment it all works fine, ie. I make a call, end it, the max-conn DOES go back to zero. In fact multiple test calls all seem to indicate that everything is fine. But after a busy night of traffic, the max-conn is always run out. In fact it is not a case of the first 400 calls get in and subsequent ones are refused; the gateway routes about 50,000 calls in a night... but it seems on some calls the connection is not freed up... so over the course of a night this number steadily increases to 400, and then it rejects calls.

1 Accepted Solution

Accepted Solutions

Hi Mark,

There are two ways to address this issue.

The first way is to open a TAC case to find out the real cause. Most probably you will encounter a bug, because the behavior in your GWs case in not normal. Most probably the TAC will run "debug voip ccapi inout" to figure out which sessions are active.

The second way is go for a upgrade because the code which you are running on the gateway is pretty old. In TAC, they always suggest to upgrade the IOS first, because if it is a new Defect, we can create a Bug for it and engage the developers.

On a personal note, I think you are already running into a bug. Have a look into this Bug id and make the decision.

http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&bugId=CSCsb81156

Regards,

Arun Kumar

Please rate useful posts !!!

View solution in original post

5 Replies 5

paolo bevilacqua
Hall of Fame
Hall of Fame

Try updating IOS, and hope for good.

Is that the standard answer, like asking a Windows user if he's turned it off and on again?

Is this a known issue in that IOS, or would I be purchasing a SmartNET, upgrading the IOS, risking introducing other issues that a new IOS can bring, and potentially still have the same problem?

Is there any way to actually diagnose this problem? Like find out the GUID of calls that the dial-peer thinks are in progress?

Hi Mark,

There are two ways to address this issue.

The first way is to open a TAC case to find out the real cause. Most probably you will encounter a bug, because the behavior in your GWs case in not normal. Most probably the TAC will run "debug voip ccapi inout" to figure out which sessions are active.

The second way is go for a upgrade because the code which you are running on the gateway is pretty old. In TAC, they always suggest to upgrade the IOS first, because if it is a new Defect, we can create a Bug for it and engage the developers.

On a personal note, I think you are already running into a bug. Have a look into this Bug id and make the decision.

http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&bugId=CSCsb81156

Regards,

Arun Kumar

Please rate useful posts !!!

Mark Alliban wrote:

Is that the standard answer, like asking a Windows user if he's turned it off and on again?

Is this a known issue in that IOS, or would I be purchasing a SmartNET, upgrading the IOS, risking introducing other issues that a new IOS can bring, and potentially still have the same problem?

Is there any way to actually diagnose this problem? Like find out the GUID of calls that the dial-peer thinks are in progress?

You can follow suggestions coming from experience, or stick with the problem, your choice. Good luck.

OK, will try that. Thanks for the help.

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: