04-12-2012 12:23 PM - edited 03-16-2019 10:36 AM
Kind of at my wits end on this one. We have recently moved some of our customers to SIP for IB and OB calling. Along with this we have fax machines connected to ATA's. I can get IB faxes to work by changing a few things on the CUBE;
voice service voip
allow-connections sip to sip
fax protocol none
modem passthrough nse codec g711ulaw
And creating a Dial-Peer for each fax machine;
dial-peer voice 920 voip
destination-pattern +15551234567
no modem passthrough
session protocol sipv2
session target ipv4:10.x.x.x
incoming called-number +15551234567
dtmf-relay rtp-nte
codec g711ulaw
fax-relay ecm disable
fax-relay sg3-to-g3
no vad
However I cannot get OB faxing to work. I have tried T.38/Fax-Passthrough, different speeds, and disabling ECM on the ATA's and the Fax machines themselves.
Any help would be appreciated.
Thanks.
05-17-2012 03:55 PM
What model ATAs as i do know that 186s do not support T38? Also I always set the modem speed on the fax to 9600. Disable ECM. and make sure G3 is on if the fax machine supports it. Usually works like that every time with a traditional PRI or POTS lines.
I have the exact opposite problem you do, OB faxes work fine but IB faxes do not, you get about 1 sec of initial fax tone then the audio drops. You can see the call is still active but no transmission occurs if I dial in through SIP connection. I have a second CME MPLS attached and I can 4 digit dial from a fax to ATA to MPLS to CME to CME to ATA to fax, just fine both ways. Any call terminated through the SIP connection doesnt succeed.
I can send you a copy of my config if you like and I will try what you have done above to see if it resolves my issue as i can already see that the voice service voip fax protocol none is not what i have rather fax protocol pass-through g711ulaw.
email: jimmy at camsbluewiretech.com
05-17-2012 05:02 PM
Nse based faxing will not work with sip trunk, you either need protocol based t38 or pass through. Check with your provider in which one they support.
Chris
Sent from Cisco Technical Support iPhone App
05-17-2012 05:43 PM
I recently have had issues with RightFax servers faxing across a SIP trunk. The preferred medium for faxing across SIP trunks is T38, that being said there are several configuration considerations that come in play:
if you using T38 be sure you configure the following globally under voice service voip and or on the outgoing dial-peer to the Service provider:
fax protocol t38 version 0 ls-redundancy 0 hs-redundancy 0 fallback none
your dial peers on the CUBE should look similar to this:
dial-peer voice 2000 voip
description ** From Service Provider TFN INBOUND **
session protocol sipv2
session target sip-server
incoming called-number +.T
voice-class codec 1
voice-class sip pass-thru content sdp
dtmf-relay rtp-nte
fax protocol t38 version 0 ls-redundancy 0 hs-redundancy 0 fallback none
no vad
!
dial-peer voice 2001 voip
description ** From Service Provider and TFN sent to Call Processing Server **
destination-pattern 9T
session protocol sipv2
session target ipv4:10.224.1.12:5060
session transport tcp
voice-class codec 1
dtmf-relay rtp-nte digit-drop
fax protocol t38 version 0 ls-redundancy 0 hs-redundancy 0 fallback none
no vad
!
dial-peer voice 5000 voip
description ** FAXING - INBOUND FROM Call processing Server Local/LD g711 upspeed**
session protocol sipv2
session target sip-server
incoming called-number +.T
voice-class codec 1
voice-class sip pass-thru content sdp
dtmf-relay rtp-nte
fax protocol t38 version 0 ls-redundancy 0 hs-redundancy 0 fallback none
no vad
!
dial-peer voice 5001 voip
description ** FAXING OUTBOUND To Service Provider Local and LD g711 upspeed **
destination-pattern +.T
session protocol sipv2
session target sip-server
voice-class codec 1
voice-class sip pass-thru content sdp
dtmf-relay rtp-nte
fax protocol t38 version 0 ls-redundancy 0 hs-redundancy 0 fallback none
no vad
!
the ip address of the fax server should be included in the "ip address trusted list" under voice service voip config.
Be sure you have QOS marked correctly along the fax call path, to prioritize (may match either CS5 or EF) Fax calls just like Voice calls. Be sure all your interfaces, especially closer to the ATA's trust DSCP values: using the command "mls qos trust dscp"
Hope some of these help
Regards,
Ted.
05-17-2012 06:20 PM
I should have posted earlier, but I ended up using steering digits to force OB Faxing to use a specific Dial-Peer. This is a multi-tenant environment, so I had to find some way other than sending out our PRI's. I'm not very good with Dial-peers, but this is what I did.
dial-peer voice 3642 voip
description outbound FAX DP(pairs with 3645)
translation-profile outgoing Strip-329
huntstop
destination-pattern ^329...........$
voice-class codec 2
session protocol sipv2
session target sip-server
dtmf-relay rtp-nte
fax-relay ecm disable
fax-relay sg3-to-g3
fax rate disable
fax protocol t38 ls-redundancy 0 hs-redundancy 0 fallback pass-through g711ulaw
no vad
!
dial-peer voice 3645 voip
description inbound from CUCM for 329(pairs with 3642)
session protocol sipv2
session target sip-server
incoming called-number ^329...........$
dtmf-relay sip-kpml rtp-nte
codec g711ulaw
no vad
voice service voip
allow-connections sip to sip
fax protocol none
modem passthrough nse codec g711ulaw
sip
early-offer forced
midcall-signaling passthru
sip-profiles 100
My concern moving forward is that we want to move our RF service to this trunk, but I'm not sure it will work with this config.
voice service voip
allow-connections sip to sip
fax protocol none
modem passthrough nse codec g711ulaw
sip
early-offer forced
midcall-signaling passthru
sip-profiles 100
05-17-2012 07:34 PM
First off I know you would definitely need to use T.38 as fax medium when using Rightfax. and yes the config I provided above should definitely work on the CUBE for RightFax. You have two alternatives, you could directly point RightFax to the CUBE, and or for Manipulating routes using Route Patterns/List/Groups at the Callmanager level, have it point to CUCM using a SIP trunk, then another SIP Trunk from CUCM to the CUBE gateway, can get hairy, when it comes to using trunks and MTP allocations, you may or may not need to check the MTP required option on the SIP trunks, but in the scenario we have, hardware MTP's on the CUBE are being invoked, using the MRGL assigned at the Device Pool level for the SIP trunk.
Hope it helps somewhat, Good luck, maybe you can have another post when its time to actually deploy it.
Regards,
Ted.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide