We're running CUCM 6.1. We have a Cisco 3745 terminating our PRI's. I have a VGA224 setup. Both the 3745 and VG224 are running MGCP. I can send a FAX in either direction fine over the G711 connection that is established. I cannot get T.38 to work. The config on both devices are identical:
mgcp call-agent 10.10.10.10 2427 service-type mgcp version 0.1
mgcp dtmf-relay voip codec all mode nse
mgcp rtp unreachable timeout 1000 action notify
mgcp modem passthrough voip mode nse
mgcp package-capability rtp-package
mgcp package-capability sst-package
mgcp package-capability pre-package
mgcp default-package fxr-package
no mgcp package-capability res-package
no mgcp timer receive-rtcp
mgcp sdp simple
mgcp fax t38 ls_redundancy 2
mgcp fax t38 hs_redundancy 2
mgcp rtp payload-type g726r16 static
mgcp bind control source-interface FastEthernet0/0
mgcp bind media source-interface FastEthernet0/0
mgcp profile default
'show mgcp' shows that T38 is enabled and everything looks good.
I enable debugging on both devices. On the VG224 side, I see various messages containing t38. All lines below are RECEIVED FROM 10.10.10.10 (CUCM):
RQNT: R: L/hu, D/[0-9ABCD*#], L/hf, FXR/t38
CRCX: L: p:20, a:PCMU, s:off, t:b8, fxr/fx:t38
MDCX: L: p:20, a:PCMU, s:off, t:b8, fxr/fx:t38
On the 3745 side, I don't see t38. Again, these are RECEIVED messages from 10.10.10.10 (CUCM):
RQNT: R: D/[0-9ABCD*#]
CRCX: L: p:20, a:PCMU, s:off, t:b8
MDCX: L: p:20, a:PCMU, s:off, t:b8
So, I'm pretty sure the problem is with the 3745 or CUCM. In CUCM I have "Fax Relay" enabled on the MGCP gateway.
Any assistance would be greatly appreciated.
The reason that changing the fax rate to 14400 works is that Super G3 only runs at 33600 (and maybe faster). When you set the speed to 14400 it disables Super G3. Modem passthrough should be able to support Super G3, but T38 doesn't support it.
Without listening to the audio stream, it's hard to tell you why the ans-disable command is making a difference.
I'm glad you were able to get this to work. If you'd like, you can email me the 'show ver' and the spurious memory logging commands, and I'll probably be able to give you a bug ID if you're so inclined. Most of the spurious memory access, tracebacks, and memory chunk errors are discovered pretty quickly so it's probably already been documented somewhere.