cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
5000
Views
0
Helpful
5
Replies

SIP Faxing

mjerickson
Level 1
Level 1

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.

5 Replies 5

jwyble
Level 1
Level 1

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

Chris Deren
Hall of Fame
Hall of Fame

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

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.

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

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.