Errors when using Busy-Out Feature

[Anonymous]

I added the busy-out feature to the PRI trunks on a NV 644 and the logs have filled up with errors.

Here are my settings:

probe drop-trunk icmp-echo

  destination <ip of softswitch>

  period 5

  tolerance consecutive fail 3 pass 2

  no shutdown

track test-track

  test if probe drop-trunk

  no shutdown

voice trunk T02 type isdn

  busy-out monitor track test-track

  resource-selection circular descending

  connect isdn-group 1

  modem-passthrough

  t38

  t38 redundancy high-speed 3

  t38 redundancy low-speed 2

  t38 max-rate 9600

  rtp delay-mode adaptive

  codec-group DefaultCodec

Here are the errors:

2013.01.30 14:28:20 TM.T02 21 IsdnTmStateIdle::ClearCall - unexpected

2013.01.30 14:28:20 TM.T02 21 IsdnTmStateIdle::CallRelease - unexpected

2013.01.30 14:28:20 TM.T02 21 IsdnTmStateIdling - clear trunk appearance

2013.01.30 14:29:02 TM.T02 0 TA:13 available, acIsdnChannel not NULL

2013.01.30 14:29:02 TM.T02 14 IsdnTmStateIdle::ClearCall - unexpected

2013.01.30 14:29:02 TM.T02 14 IsdnTmStateIdle::CallRelease - unexpected

2013.01.30 14:29:02 TM.T02 14 IsdnTmStateIdling - clear trunk appearance

2013.01.30 14:29:03 TM.T02 02 AcceptCall processed by IsdnTmState base

2013.01.30 14:29:40 TM.T02 17 IsdnTmStateIdle::ClearCall - unexpected

2013.01.30 14:29:40 TM.T02 17 IsdnTmStateIdle::CallRelease - unexpected

2013.01.30 14:29:40 TM.T02 17 IsdnTmStateIdling - clear trunk appearance

2013.01.30 14:29:51 TM.T02 19 IsdnTmStateIdle::ClearCall - unexpected

2013.01.30 14:29:51 TM.T02 19 IsdnTmStateIdle::CallRelease - unexpected

2013.01.30 14:29:51 TM.T02 19 IsdnTmStateIdling - clear trunk appearance

2013.01.30 14:29:56 TM.T02 18 IsdnTmStateIdle::ClearCall - unexpected

2013.01.30 14:29:56 TM.T02 18 IsdnTmStateIdle::CallRelease - unexpected

2013.01.30 14:29:56 TM.T02 18 IsdnTmStateIdling - clear trunk appearance

2013.01.30 14:30:03 TM.T02 11 IsdnTmStateIdle::ClearCall - unexpected

2013.01.30 14:30:03 TM.T02 11 IsdnTmStateIdle::CallRelease - unexpected

2013.01.30 14:30:03 TM.T02 11 IsdnTmStateIdling - clear trunk appearance

2013.01.30 14:30:04 TM.T02 09 IsdnTmStateIdle::ClearCall - unexpected

2013.01.30 14:30:04 TM.T02 09 IsdnTmStateIdle::CallRelease - unexpected

2013.01.30 14:30:04 TM.T02 09 IsdnTmStateIdling - clear trunk appearance

2013.01.30 14:30:05 TM.T02 18 AcceptCall processed by IsdnTmState base

2013.01.30 14:30:05 TM.T02 12 IsdnTmStateIdle::ClearCall - unexpected

2013.01.30 14:30:06 TM.T02 12 IsdnTmStateIdle::CallRelease - unexpected

2013.01.30 14:30:06 TM.T02 12 IsdnTmStateIdling - clear trunk appearance

2013.01.30 14:30:20 TM.T02 08 IsdnTmStateIdle::ClearCall - unexpected

2013.01.30 14:30:20 TM.T02 08 IsdnTmStateIdle::CallRelease - unexpected

2013.01.30 14:30:20 TM.T02 08 IsdnTmStateIdling - clear trunk appearance

2013.01.30 14:30:42 TM.T02 16 IsdnTmStateIdle::ClearCall - unexpected

2013.01.30 14:30:42 TM.T02 16 IsdnTmStateIdle::CallRelease - unexpected

2013.01.30 14:30:42 TM.T02 16 IsdnTmStateIdling - clear trunk appearance

2013.01.30 14:31:08 TM.T02 23 IsdnTmStateIdle::ClearCall - unexpected

2013.01.30 14:31:08 TM.T02 23 IsdnTmStateIdle::CallRelease - unexpected

2013.01.30 14:31:08 TM.T02 23 IsdnTmStateIdling - clear trunk appearance

2013.01.30 14:34:53 TM.T02 22 IsdnTmStateIdle::ClearCall - unexpected

2013.01.30 14:34:53 TM.T02 22 IsdnTmStateIdle::CallRelease - unexpected

2013.01.30 14:34:53 TM.T02 22 IsdnTmStateIdling - clear trunk appearance

2013.01.30 14:35:20 TM.T02 20 IsdnTmStateIdle::ClearCall - unexpected

2013.01.30 14:35:20 TM.T02 20 IsdnTmStateIdle::CallRelease - unexpected

2013.01.30 14:35:20 TM.T02 20 IsdnTmStateIdling - clear trunk appearance

[Anonymous]

Unified,

Thanks for posting!  I have a few questions so that I might try to reproduce the issue.

1. What firmware are you using? 

2. Does this output continue to scroll by or does this only happen when first applying the busy-out monitor to the trunk?

3. Does the output of "debug probe" and "debug track" remain stable?   In other words, is the state of both the probe and track stable?

4. Can you reply with the output of the following?

show probe

show track

show interface pri 1

Thanks!

David

[Anonymous · Accepted solution]

I’m running R10.3.2

I did a little more testing and it looks like it only happens if the monitor is activated while there are calls.

Once all the calls disconnect and new ones are setup there are no longer errors.

I guess this is normal behavior.