Summary:ASTERISK-19048: T.38 Fallback to G.711 fails upon 503 response
Reporter:Spenser Gruis (sgruis)Labels:
Date Opened:2011-12-14 15:36:38.000-0600Date Closed:2012-01-09 09:24:09.000-0600
Versions: Frequency of
Environment:Attachments:( 0) 503_ack_term.pcap
( 1) t38_decline_503.diff
Description:When a fax call is placed from a T.38 enabled and compatible endpoint to a non-compatible endpoint the call gets setup as G.711 first, then the enabled side reinvites to T.38 upon reception of a fax tone.  The non-T.38 complient device returns a "503" service unavailable message at which point the asterisk device simple sends an "ACK" and terminates the call without a BYE message, it does not try to reinvite back to G.711 for a voice fax call.  This particular scenario when tried on adjacent hardware (non-asterisk) the endpoints re-invite back to g.711 on a 503 and the fax completes.  If the system receives a "488" vs a "503" it will reinvite as well.

Attached is a wireshark trace that details the above explanation (there are 2 calls in the trace with the same behavior).

The actual version is, but it would not let me select this in the above field
Comments:By: Spenser Gruis (sgruis) 2011-12-14 15:39:42.344-0600

wireshark trace of 503 message

By: Kinsey Moore (kmoore) 2012-01-06 10:34:29.631-0600

If this problem is as simple as I think (and hope) it is, the attached patch should solve the problem you're seeing.  Could you try it out?  I haven't yet had a chance to reproduce this.

By: Spenser Gruis (sgruis) 2012-01-09 09:23:23.807-0600

Much to my surprise the upstream switch received a software upgrade in the duration this ticket has been open and the message coming back has changed from a 503 to a "proper" 488 message; all calls are re-inviting as expected now.  Problem is that I cannot verify this patch now that I cannot get a 503 back - I have patched my deployment as suggested should a 503 be received. In my experience the switch should not send a 500 code unless the call is set to drop for 1 reason or another - not re-invite, it is possible this was discovered and they modified the response to a proper 400 code.  Thanks for all the efforts on this!

By: Spenser Gruis (sgruis) 2012-01-09 09:24:09.247-0600

View Comments

By: Kinsey Moore (kmoore) 2012-01-09 09:45:10.288-0600

In that case, I'll leave this uncommitted since it seems to be nonstandard (and now nonexistent) behavior.  It will be here if it comes up again.