G.711 Rightfax faxes failing at 15 minutes

[Tanner Jackson]

A change was recently made on one of our Rightfax Servers to use G.711 instead of T.38 and outbound faxes now drop at 15 minutes (change was made to avoid ongoing T.38 issues with transmission errors)

We see the initial outbound invite where the fax establishes as G.711 and we see another T.38 re-Invite 4 seconds later from the far end as that is their preferred method in which the Rightfax Server responds with a 488 Media Not Acceptable and the fax begins transmitting in G.711.

Call Manager sends another Invite at the 15 minute mark at which point the Rightfax Server responds with another 488 Media Not Acceptable and the fax drops. Cause code Q.850 reason 96

2 failed call flows are below. I believe the issue to be with the CUCM or Rightfax Servers responses to CUCM SIP keep alive methods at 15 minutes.

Fails at 15 minutes in BOTH scenarios:

G.711 Rightfax Server --> CUCM 12.5 --> T.38 Rightfax Server

G.711 Rightfax Server --> CUCM 12.5 --> CUBE --> Lumen Voice Complete (SIP) --> Far Endpoint

We see CUCM is indeed initiating the re-Invite at 15 minutes and believe that is behaving correctly but believe CUCM does not like the Rightfax Servers response.

Attached is packet capture screenshot between G.711 Rightfax Server and CUCM. RTP traffic omitted 

[Jonathan Schulenberg]

What SDP is in that RE-INVITE from CUCM? 
What does CUCM send toward CUBE around that same time? Basically is anything offering only T.38 that would justify RightFax dropping the call?

PS- G.711 will be less stable than T.38. IIRC not all of Lumen’s SBCs support T.38. I have another customer that had to be moved to specific SBCs for T.38 to be stable. Also ensure you have fax nsf 000000 on your dial-peers.

[Tanner Jackson]

Attached is SDP RE-INVITE info.

CUCM initiates the RE-INVITE to Rightfax, receives 488, sends 488 on to the far end, far end ACKs then CUCM sends BYE to far end.

We haven't dug into the CUBEs too deeply because we know the issue started when we changed the server from T.38 to G.711 and this problemed call flow (G.711 Rightfax Server --> CUCM --> T.38 Rightfax Server) there would be no CUBE, firewall, carrier, etc. and assume resolving that flow will fix the same issue with external customers.

[Jonathan Schulenberg]

That screenshot shows SDP with G.711 and RFC2833. RightFax may not like the DTMF capability. Is that present in the initial offer that it does accept? If yes - the SDP hasn't changed & this is merely a Session Refresh RE-INVITE - you probably need to ask OpenText support why they're refusing it.

[Tanner Jackson]

This is the SDP in the initial INVITE from RightFax.

[Jonathan Schulenberg]

That's G.711 u-law only. No RFC2833 support. RightFax is probably sending the 488 due to the SDP DTMF capability. The question now appears to be why CUCM is attempting to re-add RFC2833.

Is there an MTP involved? There shouldn't be; remove it if there is.

Is DTMF Preference on the RightFax SIP trunk set to No Preference?

[Tanner Jackson]

We've toggled Media Termination Point Required on and off without change.

DTMF Signaling Method is set to No Preference as well.

Could it be a SIP Profile setting of some sort? I see a lot of different SDP settings. SIP Security Profile doesn't appear to have anything that could be suspicious.

Since the G.711 change, we did upgrade our CUCM from 12.5 SU5 to SU7 due to the SQL vulnerability and had the issue before and after.

[Jonathan Schulenberg]

I can't think of a SIP Profile setting that would apply here. You may want to approach TAC now that you have a specific question: why does CUCM attempt to add RFC2833 on the session refresh RE-INVITE when it wasn't negotiated in the initial SDP exchange? AFAIK it shouldn't be doing that.

[Tanner Jackson]

Here is also the second INVITE requesting the preferred T.38 protocol if that's useful at all

[Tanner Jackson]

The Rightfax server is also configured to respond with the 488 under these circumstances:

sip_reject_unsupported_media=488
sip_reject_t38_renegotiation=488

[lhull]

We had a similar issue. We need to make a change on RightFax server Fax Transporting Protocol to T.38 with failback to G.711 passthough

[Tanner Jackson]

We've battled with T.38 for 3/4 years now and were forced to make the change back to G.711. Quality has improved and this timeout appears to be the only backlash so far

[lhull]

[Elliot Dierksen]

Do you have any idle timeouts configured in the CUBE/gateway? I have seen that be a problem with long fax calls.

[Tanner Jackson]

Not that I can see that reflects 15 minutes. We haven't looked much at the CUBE since this flow also does not work in which no CUBE is involved - G.711 Rightfax Server --> CUCM 12.5 --> T.38 Rightfax Server. We are going to try enabled the SIP session timer on the Rightfax side to see if that beats CUCM to the invite ultimately refreshing the session before CUCM does