T.38 fax issue

aemcomcco · ‎03-08-2011

Hi Experts, I currently use T.38 between Cisco IAD 2431 and Stone FAX Server without problem, but in these days I've a new case with failed fax trasmission.

Our customer uses Canon MF 5700 fax and it calls us via ISDN PRI. The call arrive on the E1 interface of the Cisco IAD wich uses H.323 - T.38 to send the call to the fax server.

CANON FAX ---PSTN---ISDN PRI---CISCO IAD---H.323 T.38 ---STONE FAX

This is the output of "debug fax relay t30 all" command:

*Apr 18 08:55:38.555: 1/1:15 4178796281 fr-entered=10(ms)
    timestamp=4178800711 fr-msg-tx CSI
    timestamp=4178801441 fr-msg-tx DIS
    timestamp=4178807281 fr-msg-tx CSI
    timestamp=4178808021 fr-msg-tx DIS
    timestamp=4178810231 fr-msg-det TSI
    timestamp=4178810931 fr-msg-det DCS
    timestamp=4178815611 fr-msg-tx CFR
*Apr 18 08:56:08.475: %VOIPAAA-5-VOIP_CALL_HISTORY: CallLegType 2, ConnectionId DE58926F 51E011D6 80B5A633 346CA21C, SetupTime *10:55:29.895 METDST Thu Apr 18 2002, PeerAddress ***, PeerSubAddress , DisconnectCause 10 , DisconnectText normal call clearing (16), ConnectTime *10:55:37.525 METDST Thu Apr 18 2002, DisconnectTime *10:56:08.475 METDST Thu Apr 18 2002, CallOrigin 1, ChargedUnits 0, InfoType 10, TransmitPackets 537, TransmitBytes 48186, ReceivePackets 78, ReceiveBytes 789
*Apr 18 08:56:08.519: %VOIPAAA-5-VOIP_CALL_HISTORY: CallLegType 1, ConnectionId DE58926F 51E011D6 80B5A633 346CA21C, SetupTime *10:55:29.889 METDST Thu Apr 18 2002, PeerAddress ***, PeerSubAddress , DisconnectCause 10 , DisconnectText normal call clearing (16), ConnectTime *10:55:37.529 METDST Thu Apr 18 2002, DisconnectTime *10:56:08.519 METDST Thu Apr 18 2002, CallOrigin 2, ChargedUnits 0, InfoType 10, TransmitPackets 78, TransmitBytes 1413, ReceivePackets 538, ReceiveBytes 48346

And this is the configuration of the IAD2431:

voice-port 1/1:15
no non-linear
no vad
playout-delay nominal 100
playout-delay fax 100
playout-delay mode fixed
bearer-cap Speech

dial-peer voice 201 voip
description FAX_IN_TO_SRV
destination-pattern 2255T
modem passthrough nse codec g711alaw
session target ipv4:FAX SERVER IP
dtmf-relay h245-alphanumeric
codec g711alaw
fax-relay ecm disable
fax rate 14400
fax nsf 000000
fax protocol t38 ls-redundancy 2 hs-redundancy 2 fallback pass-through g711alaw
no vad

dial-peer voice 300 pots
description INCOMING_DP

huntstop
destination-pattern ***

direct-inward-dial
port 1/1:15
forward-digits all
no register e164

In the debug output you can see a double transmission of CSI-DIS message from Canon. After that my fax server has received the confirm CFR message, the call is disconnected.

I supposed in a latency issue and so I tried to reduce the playout-delay buffer but the issue remains.

No errors on IP interfaces or ISDN controllers. The IOS version of the IAD is 12.4-25d.

Do you have any ideas?

Thanks in advance.

Christopher Graham · ‎03-08-2011

First off...you have the directionality of the T30 messages backwards. The fax server is SENDING the CFR, not receiving, and is also resending the CSI/DIS. However, this does not seem to be an issue, since the FS is sending the CFR.

In case you are not familiar, CFR is Confirmation to Receive. After this, we should see either an MCF or PPS coming in from Canon, but we don't. My guess is that either Canon is not receiving the CFR, or does not recognize it.

Check for packet drops between the IAD and FS (show call active voice br, or a packet capture would show this. Looks like you already have the later). Check your PRI for slips/errors (show controller e1).

aemcomcco · ‎03-09-2011

You have right, I've misunderstood the direction of fax call.

No errors on the fastethernet interfaces and no errors on controlles e1.

I've tried to upgrade IOS version to last 12.4T and also 15.1 but the situation is unchanged. Indeed it has worsened. No CFR messages in response of DCS.

*Mar 1 00:29:42.547: 1/1:15 1691733 fr-entered=10(ms)
    timestamp=1693139 fr-msg-det TSI
    timestamp=1693829 fr-msg-det DCS
    timestamp=1696143 fr-msg-tx CSI
    timestamp=1696753 FR_GOOD_CRC_LS_DATA 0x0 bytes
    timestamp=1696753 fr-msg-tx good crc, 0 bytes
    timestamp=1696863 fr-msg-tx DIS
    timestamp=1697023 FR_GOOD_CRC_LS_DATA 0x0 bytes
    timestamp=1699043 fr-msg-det TSI
    timestamp=1699743 fr-msg-det DCS
    timestamp=1702179 FR_GOOD_CRC_LS_DATA 0x0 bytes
    timestamp=1708073 FR_GOOD_CRC_LS_DATA 0x0 bytes
    timestamp=1709569 fr-msg-det TSI
    timestamp=1710259 fr-msg-det DCS
    timestamp=1715473 fr-msg-det TSI
    timestamp=1716173 fr-msg-det DCS
    timestamp=1717669 fr-msg-tx CSI
    timestamp=1718289 FR_GOOD_CRC_LS_DATA 0x0 bytes
    timestamp=1718289 fr-msg-tx good crc, 0 bytes
*Mar 1 00:30:09.163: %VOIPAAA-5-VOIP_CALL_HISTORY: CallLegType 2, ConnectionId A593513D14F211CC8571C8F83D16A5F1, SetupTime *01:29:27.973 METDST Mon Mar 1 1993, PeerAddress ***, PeerSubAddress , DisconnectCause 10 , DisconnectText normal call clearing (16), ConnectTime *01:29:35.683 METDST Mon Mar 1 1993, DisconnectTime *01:30:09.163 METDST Mon Mar 1 1993, CallOrigin 2, ChargedUnits 0, InfoType 2, TransmitPackets 1683, TransmitBytes 267408, ReceivePackets 1678, ReceiveBytes 266140

You wrote: "My guess is that either Canon is not receiving the CFR, or does not recognize it."

Can be a problem of latency caused by excessive playout-dely buffer?

Thanks.