T38 fax relay between H.323 and MGCP gateways

Alexander.Khlemanov_2 · ‎11-26-2007

Hi,

We have got a 1760 H.323 voice gateway with BRI interface connected to a fax server. We also have a VG224 configured for MGCP. Both gateways are configured for T38 fax relay. When we try to place a fax call from VG224 to the fax server via BRI interface the call fails. The "debug fax relay t30 all" shows the following:

BRI H.323 -

*Oct 10 01:05:26.541: %ISDN-6-CONNECT: Interface BRI0/1:1 is now connected to 00

76 N/A

*Oct 10 01:05:29.954: 0/1 (251) 1665848486 fr-entered=10(ms)

*Oct 10 01:05:30.074: 0/1 (251) 1665848600 fr-pkt-loss 9

*Oct 10 01:05:30.227: 0/1 (251) 1665848750 fr-pkt-loss 9

timestamp=1665849400 fr-msg-det CSI

timestamp=1665850090 fr-msg-det DIS

timestamp=1665854770 fr-msg-det CSI

timestamp=1665855460 fr-msg-det DIS

timestamp=1665860140 fr-msg-det CSI

timestamp=1665860830 fr-msg-det DIS

timestamp=1665865510 fr-msg-det CSI

timestamp=1665866200 fr-msg-det DIS

timestamp=1665870870 fr-msg-det CSI

timestamp=1665871560 fr-msg-det DIS

timestamp=1665876190 fr-msg-det CSI

timestamp=1665876880 fr-msg-det DIS

timestamp=1665881530 fr-msg-det CSI

timestamp=1665882220 fr-msg-det DIS

*Oct 10 01:06:08.353: %ISDN-6-DISCONNECT: Interface BRI0/1:1 disconnected from

0076 , call lasted 41 seconds

VG224 MGCP -

*Mar 22 03:44:42.234: %SYS-5-CONFIG_I: Configured from console by vty0 (10.210.10.8)

*Mar 22 03:45:17.854: //675/0AF8035683B3/CCAPI/cc_api_inband_msg_received:

Payload=100, Event=200, Interface=0x6272C76C, Call Id=675

*Mar 22 03:45:17.942: 2/3 (675) 1824523096 fr-entered=10(ms)

*Mar 22 03:45:19.094: 2/3 (675) timestamp=1824524246 fr-msg-tx CSI

*Mar 22 03:45:19.782: 2/3 (675) timestamp=1824524936 fr-msg-tx DIS

*Mar 22 03:45:20.034: 2/3 (675) timestamp=1824525186 FR_BAD_CRC_LS_DATA 0x0 bytes

*Mar 22 03:45:24.462: 2/3 (675) timestamp=1824529616 fr-msg-tx CSI

*Mar 22 03:45:25.162: 2/3 (675) timestamp=1824530316 fr-msg-tx DIS

*Mar 22 03:45:25.414: 2/3 (675) timestamp=1824530566 FR_BAD_CRC_LS_DATA 0x0 bytes

*Mar 22 03:45:29.854: 2/3 (675) timestamp=1824535006 fr-msg-tx CSI

*Mar 22 03:45:30.542: 2/3 (675) timestamp=1824535696 fr-msg-tx DIS

*Mar 22 03:45:30.794: 2/3 (675) timestamp=1824535946 FR_BAD_CRC_LS_DATA 0x0 bytes

*Mar 22 03:45:35.202: 2/3 (675) timestamp=1824540356 fr-msg-tx CSI

*Mar 22 03:45:35.894: 2/3 (675) timestamp=1824541046 fr-msg-tx DIS

*Mar 22 03:45:36.142: 2/3 (675) timestamp=1824541296 FR_BAD_CRC_LS_DATA 0x0 bytes

*Mar 22 03:45:40.562: 2/3 (675) timestamp=1824545716 fr-msg-tx CSI

*Mar 22 03:45:41.274: 2/3 (675) timestamp=1824546426 fr-msg-tx DIS

*Mar 22 03:45:41.454: 2/3 (675) timestamp=1824546606 FR_BAD_CRC_LS_DATA 0x0 bytes

*Mar 22 03:45:45.882: 2/3 (675) timestamp=1824551036 fr-msg-tx CSI

*Mar 22 03:45:46.594: 2/3 (675) timestamp=1824551746 fr-msg-tx DIS

*Mar 22 03:45:46.774: 2/3 (675) timestamp=1824551926 FR_BAD_CRC_LS_DATA 0x0 bytes

*Mar 22 03:45:51.222: 2/3 (675) timestamp=1824556376 fr-msg-tx CSI

*Mar 22 03:45:51.914: 2/3 (675) timestamp=1824557066 fr-msg-tx DIS

*Mar 22 03:45:52.122: 2/3 (675) timestamp=1824557276 FR_BAD_CRC_LS_DATA 0x0 bytes

*Mar 22 03:45:56.594: 2/3 (675) timestamp=1824561746 FR_BAD_CRC_LS_DATA 0x0 bytes

Does anybody know what does this "FR_BAD_CRC_LS_DATA" mean and why do we get it???

Thanks a lot!

bwilmoth · ‎12-03-2007

Try using the command "mgcp fax t38 gateway force" on the mgcp gateway

http://www.cisco.com/en/US/products/sw/iosswrel/ps1834/products_feature_guide09186a008008015d.html

Alexander.Khlemanov_2 · ‎12-03-2007

Hi,

Well, this command was actually used on MGCP gateways. The problem is that T.38 is working - I can see it on a different trace. The problem is with this particular error message - I have never seen it anywhere before and I do not understand what it means. I suspect the problem is with the syncronization but I am not sure.

whanson · ‎07-20-2009

Did you ever resolve this issue?

Alexander.Khlemanov_2 · ‎07-20-2009

No. The customer has decided to stop paying the money to get it fixed so I have not got any chance to spend more time on it.

whanson · ‎07-21-2009

Thanks, I think our customer is about to give up to. I cannot make it work to save my life.

Bill

d.marsh · ‎09-23-2011

This could have been a codec issues just seen a similar thing on my system and found that making it use a particular codec fixed the issues. i needed G711ulaw not sure what you would need in this instance.