CDR File accounting on voip leg show network out of order (38) and no call duration

Unanswered Question
Sep 3rd, 2009

I enabled call accounting on a UC520-48U-T/E/F-K9 with Ver 12.4(20) T2

The voip leg record always gives the network out of order (38) error and no call duration. So we can not have a record of the calling number with  called number and call duration.

This is an example of the CDR

125198615925270115684A5BD 97C811DE 9B6ECC64 312B6600897009:55:56.848 AST Thu Sep 3 200909:55:59.108 AST Thu Sep 3 200909:55:59.108 AST Thu Sep 3 200910normal call clearing (16)00000897089700 ms20176458329000 msNone0Tariff:Unknown0ton:0,npi:0,pi:0,si:0,#:8970RegularLineTWC55:56.889700322915684A5BD 97C811DE 9B6ECC64 312B660062B6
1251986187252711157E2621D 97C811DE 9B72CC64 312B6600571709:55:59.150 AST Thu Sep 3 200909:56:20.620 AST Thu Sep 3 200909:56:27.800 AST Thu Sep 3 200910normal call clearing (16)0008761401605717571713980 ms201013213200013980 msg711ulaw7Tariff:Unknown0ton:0,npi:0,pi:0,si:0,#:5717914079777328RegularLineTWC55:59.1571703229257E2621D 97C811DE 9B72CC64 312B660062B7
1251986168252721257E2621D 97C811DE 9B72CC64 312B66009.1408E+1109:56:08.310 AST Thu Sep 3 200909:56:08.320 AST Thu Sep 3 200909:56:08.320 AST Thu Sep 3 200926network out of order (38)0000057175717914079777328550014800g729r8 pre-ietf01720disable0 ms0 ms0 ms0 ms0 ms0 ms0 ms00001.1.186.5.83.00ton:0,npi:0,pi:0,si:0,#:5717ton:0,npi:0,#:914079777328ton:0,npi:0,pi:0,si:0,#:5717914079777328RegularLineciscoTWC56:08.3571791407977732803229357E2621D 97C811DE 9B72CC64 312B660062B8
1251986188252731157E2621D 97C811DE 9B72CC64 312B66001407977732809:56:08.470 AST Thu Sep 3 200909:56:10.210 AST Thu Sep 3 200909:56:20.610 AST Thu Sep 3 200909:56:28.060 AST Thu Sep 3 200910normal call clearing (16)08761471688781404807.88E+0978772580801407977732817580 ms63103396-6717580 msg711ulaw7Tariff:Unknown0ALL_T1E10/1:2ton:0,npi:0,pi:0,si:0,#:5717ton:0,npi:0,#:14079777328ton:0,npi:0,pi:0,si:0,#:7877258080914079777328RegularLineTWC56:08.378772580801407977732803229457E2621D 97C811DE 9B72CC64 312B660062B9


Any help will be greatly appreciated,

Thanks

I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
Loading.
Saurabh Verma Thu, 09/03/2009 - 11:32

How is the dialplan designed? Are you expecting to reach the far end using the VoIP dialpeer (and fallback to PRI)? Looks like on the VoIP call leg, you are not stripping off the "9" prefix. Can you send the running configuration of the system? And the desired behavior?

Thanks,

Saurabh

lerichner Thu, 09/03/2009 - 12:27

In response of

"Are you expecting to reach the far end using the VoIP dialpeer (and fallback to PRI)?"

No. We expect only 2 legs, voip -> uc500 -> PSTN via pri

I am including the running config.

Thanks

Saurabh Verma Thu, 09/03/2009 - 12:59

Is this the incoming dial-peer for that call?

!
dial-peer voice 5500 voip
description domestic calls
service clid_authen_collect
destination-pattern 91[2-9]..[2-9]......
session target ipv4:10.1.10.1
incoming called-number 91[2-9]..[2-9]......
dtmf-relay h245-alphanumeric
codec g711ulaw
no vad
!

I noticed that you have the g711ulaw codec defined under this dial-peer, however, from the CDR, it appeared that the call was being setup as a g729 call. Can you check the two H.323 ends to make sure that the codec is matched? Also make sure that the VAD setting is matched.

Thanks,

Saurabh

lerichner Thu, 09/03/2009 - 13:26

Yes,

This dial peer was a remanent of trying to enable the authentication. I deleted it and I don't get the error now but then I don't get a CDR record with the calling, called number and direction of call for billing purpose

I now get only 2 records none with the 8970 (calling ext) 14079777328 (called number) and 13020ms (call duration) 

1252007556,26494,1,1,"1FD727DE 97FA11DE A77FCC64 312B6600","8970","","15:52:19.948 AST Thu Sep 3 2009","","15:52:28.418 AST Thu Sep 3 2009","15:52:36.638 AST Thu Sep 3 2009","10  ","normal call clearing (16)","",0,"",0,0,648,103680,"8970","8970","","","","9580 ms",20176,458,329,0,0,"9580 ms","","","g711ulaw","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","",8,"Tariff:Unknown","","0","","","","","","","","","","","","","","","","","","","","","","","","ton:0,npi:0,pi:0,si:0,#:8970","","","","","","","","","914079777328","","","RegularLine","","","","","","TWC","09/03/2009 15:52:19.950","8970","",0,33894,1FD727DE 97FA11DE A77FCC64 312B6600,677E,"","","",""

1252007556,26495,1,1,"1FD727DE 97FA11DE A77FCC64 312B6600","14079777328","","15:52:21.664 AST Thu Sep 3 2009","15:52:23.604 AST Thu Sep 3 2009","15:52:28.414 AST Thu Sep 3 2009","15:52:36.904 AST Thu Sep 3 2009","10  ","normal call clearing (16)","",0,"",648,108864,650,104000,"7877258080","7877258080","14079777328","","","13020 ms",63,103,28,30,-67,"13020 ms","","","g711ulaw","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","",8,"Tariff:Unknown","","0","","","","","","","","","","","ALL_T1E1","","0/1:6","","","","","","","","","","","ton:0,npi:0,pi:0,si:0,#:8970","","","","ton:0,npi:0,#:14079777328","ton:0,npi:0,pi:0,si:0,#:7877258080","","","","914079777328","","","RegularLine","","","","","","TWC","09/03/2009 15:52:21.566","7877258080","14079777328",0,33895,1FD727DE 97FA11DE A77FCC64 312B6600,677F,"","","",""

thanks,

Saurabh Verma Thu, 09/03/2009 - 14:38

Here's something you can do. Both call legs will have the same GUID which in this case is1FD727DE 97FA11DE A77FCC64 312B6600. Incoming call leg will normally have a lower number call reference value (677E in this case). The Outgoing call leg will have a higher number call reference value (677F in this case). You will need to build this logic in your billing system.

HTH,

Saurabh

lerichner Thu, 09/03/2009 - 14:47

Thanks Saurabh. I passed this info to the person doing the billing and told me that he can work with this.

Actions

This Discussion