| 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-0600 | Date Closed: | 2012-01-09 09:24:09.000-0600 |
| Priority: | Major | Regression? | |
| Status: | Closed/Complete | Components: | Channels/chan_sip/T.38 |
| Versions: | 1.8.7.2 | Frequency of Occurrence | Constant |
| Related Issues: | |||
| 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 1.8.7.1, 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. | ||