max-conn value causing media-loop error

[milind.patel]

Hi all CUBE gurus,

Can anyone please help out with below issue.

- We are restricting calls to a specific site using max-conn value assigned to dial-peer on main site CUBE router.

- Dial-peer is matched using incoming called-number for the site.

- Main site CUBE router is running IOS 15.1(4) M4

The issue is we are seeing below media loop error ONLY when that dial-peer runs out of connections (max-conn value is reached).

Can anyone please put some lights on what exactly happens when max-conn value is reached (apart from call being dropped) and why it would cause media loop error?

May 21 07:32:01.497: %CALL_CONTROL-6-MAX_CONNECTIONS: Maximum number of connections reached for dial-peer 1234

May 21 07:32:01.777: %VOIP_RTP-6-MEDIA_LOOP: The packet is seen traversing the system multiple times

May 21 07:32:44.197: %CALL_CONTROL-6-MAX_CONNECTIONS: Maximum number of connections reached for dial-peer 1234

May 21 07:32:44.453: %VOIP_RTP-6-MEDIA_LOOP: The packet is seen traversing the system multiple times

May 21 07:34:20.709: %CALL_CONTROL-6-MAX_CONNECTIONS: Maximum number of connections reached for dial-peer 1234

May 21 07:34:21.013: %VOIP_RTP-6-MEDIA_LOOP: The packet is seen traversing the system multiple times

Thanks in advance

[Dennis Mink]

Without configs, it's guesswork, please include configs of all components involved.

Thanks

[Ayodeji Okanlawon]

Hi,

We need to look at your config to see where the loop is happening. Basically when the maximum connection has been reached on a dial-peer, the gateway will try another dial-peer that macthes that destination. Hence it is possible that you have more than one dial-peer to this destination and it is the config on these other dial-peers that is not quite right. Until we see it we wont know

[milind.patel]

Thank you both for replying.

Unfortunately, I am unable to put config for the reasons you could imagine. However, I am happy to provide as much info without having to do it.

Aokanlawon

When max-conn is reached and If GW tries to match another dial-peer it will defeat the purpose of max-conn value. I have double checked the config there is no other dial-peer should be matched. However, there is a default hidden dial peer 0. If what you saying is correct, will it match the dial-peer 0?

[Ayodeji Okanlawon]

if you cant post config, can you post the output of

'debug voip ccapi inout'

[milind.patel]

We have increased the max-conn value under the dial-peer and it is less likely to reach the value at this time.

I am interested in knowing what exactly happens when max-conn value is reached from GW perspective. You mentioned it will try and match another dial-peer. Did you have any document mentioning that ? Also, If i assume what you said is correct then most likely callers did not get disconnected and call went through which defeated the purpose of max-conn value.

[Ayodeji Okanlawon]

For the puprose of redundancy and CAC you can have a scenario where when a certain amount of call is reached on a dial-peer, another dial-peer should be tried..

eg..dial-peer voice 1 voip

      destination-pattern 7777

    max-conn 2

  session target ipv4:10.10.10.10

dial-peer voice 2 pots

preference 1

destination-pattern 7777

port 0/0/0:15

In this scenario when when a total of two calls are ongoing, and a 3rd call arrives on that dial-peer you will get the following

%CALL_CONTROL-6-MAX_CONNECTIONS: Maximum number of connections reached for dial-peer 1

The call will then attempt to route via dial-peer 2.

So you can see why this can be very useful. It is not just use for stopping a certain number of calls exiting on a dial-peer, those calls can be routed via another route.

However if you say you dont have any other dp, then thats a different issue. the only way to verify is to look at a debug voip ccapi inout

[testeven]

Hi,

Do you see any errors such as:

%SYS-6-STACKLOW: Stack for process IP Input running low

There is a known bug that can cause the router to crash when having excessive loops:

CSCtb77593    router crashes when RTP loop exists in IPIPGW environment

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

Seems your versions has the fix, but you might want to double check.

Regards,

Tere.

If you find this post helpful, please rate!