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
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.
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
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.