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

lerichner · ‎09-03-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

1251986159	25270	1	1	5684A5BD 97C811DE 9B6ECC64 312B6600	8970	09:55:56.848 AST Thu Sep 3 2009		09:55:59.108 AST Thu Sep 3 2009	09:55:59.108 AST Thu Sep 3 2009	10	normal call clearing (16)	0	0	0	0	8970	8970		0 ms	20176	458	329	0	0	0 ms		None														0	Tariff:Unknown				ton:0,npi:0,pi:0,si:0,#:8970				RegularLine		TWC	55:56.8	8970		32291	5684A5BD 97C811DE 9B6ECC64 312B6600	62B6
1251986187	25271	1	1	57E2621D 97C811DE 9B72CC64 312B6600	5717	09:55:59.150 AST Thu Sep 3 2009		09:56:20.620 AST Thu Sep 3 2009	09:56:27.800 AST Thu Sep 3 2009	10	normal call clearing (16)	0	0	876	140160	5717	5717		13980 ms	20101	321	320	0	0	13980 ms		g711ulaw														7	Tariff:Unknown				ton:0,npi:0,pi:0,si:0,#:5717			914079777328	RegularLine		TWC	55:59.1	5717		32292	57E2621D 97C811DE 9B72CC64 312B6600	62B7
1251986168	25272	1	2	57E2621D 97C811DE 9B72CC64 312B6600	9.1408E+11	09:56:08.310 AST Thu Sep 3 2009		09:56:08.320 AST Thu Sep 3 2009	09:56:08.320 AST Thu Sep 3 2009	26	network out of order (38)	0	0	0	0	5717	5717	914079777328		5500	148	0				0	g729r8 pre-ietf	0	1720	disable	0 ms	0 ms	0 ms	0 ms	0 ms	0 ms	0 ms	0	0	0	0		1.1.186.5.83.0			ton:0,npi:0,pi:0,si:0,#:5717	ton:0,npi:0,#:914079777328	ton:0,npi:0,pi:0,si:0,#:5717	914079777328	RegularLine	cisco	TWC	56:08.3	5717	914079777328	32293	57E2621D 97C811DE 9B72CC64 312B6600	62B8
1251986188	25273	1	1	57E2621D 97C811DE 9B72CC64 312B6600	14079777328	09:56:08.470 AST Thu Sep 3 2009	09:56:10.210 AST Thu Sep 3 2009	09:56:20.610 AST Thu Sep 3 2009	09:56:28.060 AST Thu Sep 3 2009	10	normal call clearing (16)	876	147168	878	140480	7.88E+09	7877258080	14079777328	17580 ms	63	103	39	6	-67	17580 ms		g711ulaw														7	Tariff:Unknown		ALL_T1E1	0/1:2	ton:0,npi:0,pi:0,si:0,#:5717	ton:0,npi:0,#:14079777328	ton:0,npi:0,pi:0,si:0,#:7877258080	914079777328	RegularLine		TWC	56:08.3	7877258080	14079777328	32294	57E2621D 97C811DE 9B72CC64 312B6600	62B9

Any help will be greatly appreciated,

Thanks

Saurabh Verma · ‎09-03-2009

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 · ‎09-03-2009

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 · ‎09-03-2009

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 · ‎09-03-2009

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 · ‎09-03-2009

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 · ‎09-03-2009

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