-> QUEUED23 QUEUED :38 itn x3d75 sp 126 pri 2 ewt 0 size 18 msgseq 125926 net 5 seq 667 stamp $h1469230763
# IGNORED waiting idling event
-> DCON23 DCON :38 itn x3d75 pos x1329 sk 126 lv 1 pfsk= 0 surp= 2 size 17 msgseq 125927 net 5 seq 667 stamp $h1469230763
Line 5028: -> IDLE23 IDLE :42 itn x3d75 rabort= 0 size 11 msgseq 125932 net 5 seq 667 stamp $h1469230763
# IGNORED waiting idling event
Line 5713: -> TAUDIT20 IDLE :31 itn x3d75 size 3 msgseq 126427
Line 7394: -> TAUDIT20 IDLE :42 itn x3d75 size 3 msgseq 127865
Line 8684: -> TAUDIT20 IDLE :53 itn x3d75 size 3 msgseq 129099
Line 10433: -> TAUDIT20 IDLE :06 itn x3d75 size 3 msgseq 130564
Line 12021: -> TAUDIT20 IDLE :19 itn x3d75 size 3 msgseq 131949
Line 13810: -> TAUDIT20 IDLE :31 itn x3d75 size 3 msgseq 133435
So looks like some trunk status is still set to maintenance busy on CMS side at 7:00 am July 23, thus CMS had ignored message and UCID was not captured for it. After there is a call coming and the call is released, the idle status is correctly updated to CMS, thus later on this issue automatically fixed by itself
Culprit most likely is due to CM operation and maintenance, some trunk status are set to maintenance busy, but when these trunk are released, the updated status are not popped up to CMS side correctly. So CMS will still regard these trunk as maintenance busy and will ignore the call traffic on these lines.
So next time, after CM trunk are set to maintenance busy and released, please manually switch on and off data collection on cms side, this will initialize all CM unit status on CMS again.