Outbound FAX issue T.38 H323 to SIP

f.sorrentino · ‎11-12-2014

Hi All,

Looking for a bit of assistance with some configuration. Am i missing or mis-configured something here? If any other debugging is needed pls let me know. I ahve attached a ccapi inout debug of a fax transmission

The issue is that the fax keeps coming back with busy message. It can however receive faxes with no issues and the number is not busy as we provide the DDI.

When the user sends the fax I can see the call being set up and billed for meaning the connection has been established but the fax transmission itself fails.

The router hosting the fax is using h323 and the fax is termination on a SIP trunk.

voice service voip
fax protocol t38 version 0 ls-redundancy 0 hs-redundancy 0 fallback none
fax-relay ans-disable
h323
no call service stop
sip
call service stop

voice class codec 10
codec preference 1 g729r8 bytes 40
codec preference 2 g729br8 bytes 40

dial-peer voice 2226 pots
destination-pattern 2226
port 0/2/0

!
dial-peer voice 123 voip
destination-pattern .T
session protocol sipv2
session target ipv4:X.X.X.X
voice-class codec 10
dtmf-relay rtp-nte
fax-relay ecm disable
fax-relay sg3-to-g3
fax rate 9600
fax nsf 000000
fax protocol t38 version 3 ls-redundancy 0 hs-redundancy 0 fallback none
no vad
!

Thanks

Francisco Granados · ‎11-12-2014

Just to confirm, is the Fax as directly attached to the router via FXS port?

Also, could you please post results of "Debug ccsip messages"

My company does a LOT of faxing and most of the times the issues are with media negotiation, I want to see if your fax is negotiating t.38 or codec pass through.

Thanks,

Frank

f.sorrentino · ‎11-13-2014

Hi Frank,

The fax is directly connected to the Fax via FXS. Their is an MTP translating between the H323 GW and the SIP connection to our provider so there are no end to end SIP messages.

I have noticed whilst checked the sho voice call sum that when the port is in "digit_collect" or "alerting" the codec used is G711uLAW then it goes to G729br8 when the FXS port in "Connect" then changes to S_Fax. SO i am wondering if the 729 codec is causing some distortion in the tones which would be contributing to the failures.

I will try configuring a dial peer with a incoming number configured and set the codec as G711uLAW.

Do you have any other ideas failing that?

Thanks.

PORT           CODEC     VAD VTSP STATE            VPM STATE
============== ========= === ==================== ======================
0/2/0         g711ulaw   n S_DIGIT_COLLECT       FXSLS_OFFHOOK
0/2/1         -          - -                     FXSLS_ONHOOK
0/2/2         -          - -                     FXSLS_ONHOOK
0/2/3         -          - -                     FXSLS_ONHOOK

PORT           CODEC     VAD VTSP STATE            VPM STATE
============== ========= === ==================== ======================
0/2/0         g729br8    n S_CONNECT             FXSLS_CONNECT
0/2/1         -          - -                     FXSLS_ONHOOK
0/2/2         -          - -                     FXSLS_ONHOOK
0/2/3         -          - -                     FXSLS_ONHOOK

PORT           CODEC     VAD VTSP STATE            VPM STATE
============== ========= === ==================== ======================
0/2/0         t38        n S_FAX                 FXSLS_CONNECT
0/2/1         -          - -                     FXSLS_ONHOOK
0/2/2         -          - -                     FXSLS_ONHOOK
0/2/3         -          - -                     FXSLS_ONHOOK

Francisco Granados · ‎11-13-2014

G.729 can work, as long as the end result is to do t.38. I actually have all my fax machines start the call with G.729 and then negotiate T.38.

Looking at your debug it shows disconnect cause = 38, means your network is out of order, usually a configuration problem with the h323 voip gateway, but also it looks like your caller-id is going out as 2226 and not a full DID, if the carrier is not accepting your outgoing calls this might explain why you can receive but not send:

 ----- ccCallInfo IE subfields -----
   cisco-ani=2226

Can you post a sh run?

Thanks,

Frank

Francisco Granados · ‎11-13-2014

By the way you should still be able to do "debug ccsip messages", that way we can confirm the caller ID sent to the carrier and if that's why it's failing, there's high probability that is it.

f.sorrentino · ‎11-14-2014

Hi Frank,

I have the voice team revert back to the PSTN away from SIP and I created new Dial peer to ensure G711 is used. I also added a station ID to ensure the ANI confirmed to e.164 Standard. Fax is now working to a possible issue with the SIP provider negotiation.

I will revert back to SIP, adjust Dialpeer back to T38 and see if it works.

I will try and get the ccsip debug messages also.

Thanks.

Francisco Granados · ‎11-14-2014

In the meantime, you can create a "Test dial peer" with a fax number and point it to the SIP trunk, that way you won't affect all of the other calls. If you don't want to modify your station id you could also create a translation rule to transform 2226 into XXX XXX 2226. Let me know if you need help with any of that, or testing, you can use my fax #.

Thanks,

Frank

f.sorrentino · ‎11-15-2014

OK Thanks Frank.

Will be Monday before the Voice team is back in so will see how it goes then,

Cheers,

Jayanth Velkuri · ‎11-14-2014

your call flow is not clear

is this your call flow

Fax server--h.323---VG--FXS--fax machine?

post sh run and which end are you having fax issues

if the call flow is above

enable below and send the logs

deb voip ccapi inout

deb h225 asn1

deb h245 asn1