T.38 CA Controlled MGCP - Can't get it to work

Answered Question
Dec 23rd, 2008
User Badges:

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:


ccm-manager mgcp

mgcp

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.

Correct Answer by Nicholas Matthews about 8 years 6 months ago

Hi Jordan,


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.


hth,

nick

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 5 (2 ratings)
Loading.
Nicholas Matthews Tue, 12/23/2008 - 20:07
User Badges:
  • Red, 2250 points or more

Hi Jordan,


For fax and modem calls between Cisco devices I find it easier to configure NSE based modem passthrough.


The config on both sides would look like this:

voice service voip

fax protocol none

modem passthrough nse codec g711u

!

no ccm fax protocol cisco


If you're using MGCP for modem passthrough:

mgcp modem passthrough voip mode nse

mgcp modem passthrough voip codec g711ulaw

no ccm fax protocol cisco



But it looks like you can get g711ulaw faxes to work.


You may want to try either of these commands to get t38 to work:

no mgcp fax t38 ecm

mgcp fax rate 14400


This will disable super-G3 which isn't supported with T38 that would otherwise work on modem passthrough.


You will want to use 'show voice call stat' 'show voice call summary' or 'show call active voice brief' to find out if the call is actually switching over to T38 or not.


The terminating gateway is responsible for sending the T38 notification, so you won't expect for CUCM to send T38 to both gateways.



hth,

nick


jordan.bean Tue, 12/23/2008 - 20:33
User Badges:

Thanks.


So, would you actually recommend that modem passthrough be used over T.38? Which have you found to be more reliable once the proper configuration is in place? I just assumed that T.38 would be the best way to go since it was specifically for FoIP.

Nicholas Matthews Tue, 12/23/2008 - 20:46
User Badges:
  • Red, 2250 points or more

Hi Jordan,


Modem passthrough has these two benefits:

-Reduces complexity. With T38 it requires switching the packets to a special codec, which then limits your ability to do things such as Super-G3, and you have to be more concerned with the 'content' of the faxes. Modem passthrough sets up a G711ulaw call, increases the playout delay bufers, and turns off echo cancellation. What this in turn does is simulate to the best of our ability the exact 'voice' coming out of the other end.


-Uses Cisco-proprietary RTP NSEs to signal switchover between devices. This means that the switchover does not require protocol support or for intermediary signaling devices (such as CUCM) to be involved. There is a direct packet exchange between the RTP endpoints, and you will be able to switch protocols and networks without worrying about signaling hops.



However, if a 3rd party enters the equation then protocol based T38 or protocol based pass-through are your only options. And most 3rd party fax servers are T38 based. Be careful though, Verizon SIP doesn't support T38!



hth,

nick

jordan.bean Thu, 12/25/2008 - 14:00
User Badges:

I've been working a bit more on this as I'd like to get T.38 up for testing. I upgraded the IOS on our 3745 and am now seeing the correct info in the MGCP packets.


When I attempt a FAX, I can see the connection and the FAX goes through fine with g711ulaw listed under the CODEC in 'show voice call summ'. I am using a 33.6 kbps FAX and it's working fine from what I can tell, but not with T38.


When I enter 'mgcp fax rate 14400' on both the VG224 and the 3745, I see the call connect at g711ulaw and I then see it switch to t38 as the codec.


My problem however is that the FAX machine cannot establish a connection. It shows a "no answer" in its report.


So, it looks like t38 is working, but the negotiation isn't taking place when we're forcing 14400 kbps. Any ideas?

jordan.bean Thu, 12/25/2008 - 14:32
User Badges:

Also, I've tried 'no mgcp fax t38 ecm' and also 'no ccm-manager fax protocol cisco' and neither has helped.

jordan.bean Fri, 12/26/2008 - 16:13
User Badges:

I finally got our setup working. It mostly came down to making sure we were running a version of 12.4T on the Cisco 3745 and also the VG224.


There is an undocumented bug in all 12.4.15T releases that causes a spurious memory access in our Ciso 3745 when it brings up our PRI's (after a reload). Contact me if you'd like to log it - I don't have access under my account.


VG224 IOS: 12.4(22)T

Relavent commands:

no ccm-manager fax protocol cisco

mgcp dtmf-relay voip codec all mode nse

mgcp modem passthrough voip mode nse

mgcp default-package fxr-package

mgcp fax t38 ls_redundancy 2

mgcp fax t38 hs_redundancy 2

mgcp fax-relay ans-disable


The 'mgcp fax-relay ans-disable' seemed to make a difference. That feature appears to be new and isn't documented anywhere. I thought that the 'mgcp fax-relay sg3-to-g3' command would be good enough, but it needed the second as well for some reason.


Cisco 3745 IOS: 12.4.9T7

Same commands as the VG224, excep the 'mgcp fax-relay ans-disable'. That command is not available.


When a FAX comes in, you can see it switch to t38 mode under 'show voice call summ' and you see 14400 listed under 'show voice call stat'.


Thus far I've received a 40 page doc from a long distance number and also sent a 40 page doc locally with no problems.

Correct Answer
Nicholas Matthews Mon, 12/29/2008 - 08:45
User Badges:
  • Red, 2250 points or more

Hi Jordan,


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.


hth,

nick

supportipsilan Mon, 07/06/2009 - 05:58
User Badges:

hi


I have a problem with modems connectted to a VG224. this modems are used with fax server to transmit fax. Some of them cannot transmit data to a specific destination.


here my configuration :

modem -->VG224 --> CUCM 6.1.2 --> ISR 3845 --> PSTN


I am using T38 for the fax and modem passthrough



on VG 224 configured in SCCP


voice service voip

allow-connections h323 to h323

allow-connections h323 to sip

allow-connections sip to h323

supplementary-service h450.12

fax protocol t38 nse force ls-redundancy 0 hs-redundancy 0 fallback cisco

h323

call preserve

modem passthrough nse codec g711ulaw

!

voice-port 2/0

mwi

ring frequency 50

disconnect-ack

cptone FR

timeouts initial 20

timeouts interdigit 20

timeouts ringing infinity

timing hookflash-in 200 150

bearer-cap Speech

caller-id enable


dial-peer voice 101 pots

fax rate disable

service stcapp

port 2/0


On my gateway

voice service voip

allow-connections h323 to h323

allow-connections h323 to sip

allow-connections sip to h323

allow-connections sip to sip

redirect ip2ip

fax protocol t38 nse ls-redundancy 0 hs-redundancy 0 fallback cisco

h323

modem passthrough nse codec g711ulaw

!

voice-port 0/0/0:15

echo-cancel coverage 64

cptone FR



Is there someone who have had the same problem?

thanks


Pamela




jordan.bean Mon, 07/06/2009 - 07:34
User Badges:

After opening this thread, we began rolling out VG224's and VG248's to provide analog lines to our customers. About 1/3 of them ended up having issues. Modems, FAX's, etc. couldn't negotiate. We tried nearly all settings. We ended up breaking a few channels off our PRI's before the termination into the gateways and provisioning customers off those channels. The disadvantage to this however is that we don't have any CDR data for those calls since they're routed before they hit CUCM.

Actions

This Discussion