FAX T.38 Outound Failed

[fendra.lp]

Hi All,

Please help,

I am integrating the router to SIP PSTN Provider and we have fax on fxs port in our ISR. we use T38 protocol as FAX and i already configured. 

The incoming FAX is working fine, but when we try to send it's cannot. on fax receiver said its just connecting but no fax has been received, after that fax machine was disconnected from the session. Here is the simple topology  :

                                           FAX Machine <<<fxs>>> ISR 28xx <<<sip>>> Provider

The difference from the sending and receiving from the log is : 

Sending FAX : re-invite is only once for T38 protocol negotiate which is from Provider, the provider is successfully tested to another fax machine.

Receiving FAX : re-invite is twice, once for T38 protocol negotiate and other is for media i believe and this is from our Cisco router. 

Is there any config in VG to force sending fax when there is only one reinvite from Provider? 

Here i attach the configuration and Log what i got.

[Jonathan Unger · Accepted solution]

Hi There,

I took a look at the debugs, here is a breakdown of what I can see:

1. CALL #1 - INBOUND FAX (Working) -Fax log 01 receiving.txt
   
   
   1. SIP Invite comes in from the PSTN, early offer with several codecs (normal)
   2. CUBE responds with a 100 Trying and 183 Session Progress with SDP - Tries to negotiate G711U
   3. FAX Machine picks up and the OK is sent from CUBE to the SIP PSTN, at this point in time media is setup as G711U
   4. Approximately 24 seconds after the G711u audio call is established, CUBE sends a re-invite to the SIP PSTN attempting to negotiate T.38 with SDP as follows

      1. Content-Length: 396
         v=0
         o=CiscoSystemsSIP-GW-UserAgent 9038 9970 IN IP4 10.10.135.90
         s=SIP Call
         c=IN IP4 10.10.135.90
         t=0 0
         m=image 18704 udptl t38
         c=IN IP4 10.10.135.90
         a=T38FaxVersion:0
         a=T38MaxBitRate:9600
         a=T38FaxFillBitRemoval:0
         a=T38FaxTranscodingMMR:0
         a=T38FaxTranscodingJBIG:0
         a=T38FaxRateManagement:transferredTCF
         a=T38FaxMaxBuffer:200
         a=T38FaxMaxDatagram:320
         a=T38FaxUdpEC:t38UDPRedundancy

   5. SIP PSTN provider responds with an OK accepting T.38

      1. Content-Length: 355
         v=0
         o=nsc 1562725338 1562725340 IN IP4 10.10.255.34
         s=nsc
         c=IN IP4 10.10.255.34
         t=0 0
         m=image 16856 udptl t38
         a=T38FaxVersion:0
         a=T38MaxBitRate:9600
         a=T38FaxFillBitRemoval:0
         a=T38FaxTranscodingMMR:0
         a=T38FaxTranscodingJBIG:0
         a=T38FaxRateManagement:transferredTCF
         a=T38FaxMaxBuffer:200
         a=T38FaxMaxDatagram:410
         a=T38FaxUdpEC:t38UDPRedundancy

   6. 48 seconds later the CUBE sends another re-invite attempting to negotiate back to G.711U again.

      1. Content-Length: 247
         v=0
         o=CiscoSystemsSIP-GW-UserAgent 9038 9970 IN IP4 10.10.135.90
         s=SIP Call
         c=IN IP4 10.10.135.90
         t=0 0
         m=audio 18704 RTP/AVP 0 101
         c=IN IP4 10.10.135.90
         a=rtpmap:0 PCMU/8000
         a=rtpmap:101 telephone-event/8000
         a=fmtp:101 0-16
         a=ptime:20

   7. The provider accepts this switchover back to G.711U

      1. Content-Length: 240
         v=0
         o=nsc 1562725338 1562725341 IN IP4 10.10.255.34
         s=nsc
         c=IN IP4 10.10.255.34
         t=0 0
         m=audio 16856 RTP/AVP 0 101
         a=rtpmap:0 PCMU/8000
         a=rtpmap:101 telephone-event/8000
         a=fmtp:101 0-16
         a=ptime:20
         a=rtcp:16857 IN IP4 10.10.255.34

   8. The call is then ended with a BYE initiated by the provider with a normal call clearing cause code.
      
      
2. CALL #2 - OUTBOUND FAX (Broken) -Fax log 01 sending.txt
   
   
   1. SIP Invite is sent from CUBE to the PSTN, early offer with several codecs (normal)
   2. SIP PSTN responds with a 100 Trying and 183 Session Progress with SDP - Tries to negotiate G711U
   3. FAX Machine picks up and the OK is sent from the PSTN to CUBE, at this point in time media is setup as G711U
   4. Approximately 4 seconds after the G711u audio call is established, the SIP PSTN sends a re-invite to the CUBE attempting to negotiate T.38 with SDP as follows

      1. Content-Length: 269
         X-FS-Support: update_display,send_info
         v=0
         o=nsc 1562715889 1562715892 IN IP4 10.10.255.34
         s=nsc
         c=IN IP4 10.10.255.34
         t=0 0
         m=image 26004 udptl t38
         a=T38FaxVersion:0
         a=T38MaxBitRate:9600
         a=T38FaxRateManagement:transferredTCF
         a=T38FaxMaxBuffer:500
         a=T38FaxMaxDatagram:515
         a=T38FaxUdpEC:t38UDPFEC

   5. CUBE responds with an OK accepting T.38

      1. Content-Length: 285
         v=0
         o=CiscoSystemsSIP-GW-UserAgent 7345 8793 IN IP4 10.10.135.90
         s=SIP Call
         c=IN IP4 10.10.135.90
         t=0 0
         m=image 17664 udptl t38
         c=IN IP4 10.10.135.90
         a=T38FaxVersion:0
         a=T38MaxBitRate:9600
         a=T38FaxRateManagement:transferredTCF
         a=T38FaxMaxBuffer:200
         a=T38FaxMaxDatagram:320

   6. SIP PSTN initiates a BYE to end the call 38 seconds later with a normal call clearing cause code. Nothing jumps out as odd with this call...

Notes:

1. The expected flow for T.38 FAX switchover is
   1. Call is setup using G.711
   2. A device in the path detects fax signals
   3. The device that has detected the signals attempts to re-negotiate the media stream as T.38
   4. Fax proceeds as T.38
   5. If T.38 negotiation fails, the call can simply just fall back to a regular G.711 call again
      
      
2. In the case of call #1, the call appears to setup as a regular audio call, then successfully switches over to T.38, then right before the BYE is sent from the SIP PSTN (call teardown) CUBE is attempting to yet again re-negotiate back to a regular audio call (this seems odd to me).
   
   
3. There is a slight difference between the dial-peer selected for the call leg between the PSTN SIP provider and the CUBE for the 2 types of calls. The call FROM the PSTN uses dial-peer 101, and the call TO the PSTN uses dial-peer 100. Even though the differences in the dial-peer configuration are most likely not significant for testing purposes I think it makes sense to make them consistent. Since you noted the call FROM the PSTN works and the call TO the PSTN does not, I think it makes sense to mirror the dial-peer configuration of peer 101 onto peer 100 and test again, this gives us a level playing field. The following commands can be applied to dial-peer voice 100 to accomplish this:
   

   dial-peer voice 100
     no dtmf-relay h245-signal rtp-nte
     dtmf-relay rtp-nte sip-notify
     no fax nsf 000000
     no modem passthrough
     fax-relay sg3-to-g3

4. There are some optimizations you could make to your dial-peers to clean up the configuration (however, these should not really be affecting the problems you are experiencing).

   1. fax protocol t38 version 0 ls-redundancy 0 hs-redundancy 0 fallback pass-through g711ulaw

      This has been defined at the voice service voip level, it does not also need to exist on your dial-peers and can be removed from them.
      
      

   2. dtmf-relay h245-signal rtp-nte

      Is configured on your SIP dial-peers, you can remove the h245-signal component
      
      

   3. fax-relay ecm disable
       fax-relay sg3-to-g3

      Unless you are using the Cisco fax-relay protocol (proprietary), you can remove these commands from your configuration, they are not related to T.38.
      
      
   4. Your inbound VOIP dial-peer is not configured for the SIP protocol, consider adding the following to dial-peer voice 200 (unless you are also processing some inbound H.323 calls through this CUBE).

      session protocol sipv2

Follow up questions:

1. Can you please confirm that the fax which DID work was FROM the PSTN? Because if you did not tell me which one did not work and just provided the logs, I would have expected the call FROM the PSTN (Call #1) to have failed since the SIP media negotiation flip flops between G.711 to T.38 then back to G.711. The call TO the PSTN looks like a pretty normal T.38 fax relay call to me.

I would be interested to see if anyone else here has input (there are many smarter folks on these forums than I). If not then it might be time to engage TAC and/or your SIP provider to see if they can help pinpoint the issue. Let us know how it goes!

[Maren Mahoney]

+5 to @Jonathan Unger for the super-thorough analysis!