Summary:	ASTERISK-28441: fax: T38 fallback to voice does not change codec
Reporter:	Simone Freddio (sioux1977)	Labels:	fax pjsip
Date Opened:	2019-06-10 08:23:39	Date Closed:
Priority:	Minor	Regression?
Status:	Open/New	Components:	Channels/chan_pjsip Resources/res_fax
Versions:	13.26.0 13.27.0 16.4.1	Frequency of Occurrence	Constant
Related Issues:	is related to ASTERISK-28982 res_pjsip_t38: Does not resume as audio when negotiation fails
Environment:		Attachments:	( 0) ast13-27-ata-t38-verso-ata-no-t38.cap ( 1) bug.pcap ( 2) callflow_asterisk_16.4.1.png ( 3) fax_fallback_g711_ok.cap ( 4) fax_with_asterisk_16_filtrato.cap ( 5) t38_audio_fallback_patch
Description:	Enviroment: Same problem on customer site, i have replicated the same issue in my lab: Linksys SPA112 (t38 enabled) <—> asterisk 13.27.0 <—> Linksys SPA112 (t38 disabled) The t38 disabled linksys mean disabled by the web interface, the pjsip endpoint still has t38_udptl=true. Initial call phase goes up with g729 on first and second leg, first leg (t38 enabled ata) send a reinvite to start t38, asterisk forware the invite to the t38 disabled ata that refuse it. Asterisk forward the 488 unacceptable here to first leg that after a while send a reinvite with g711 (was g729); at this point asterisk didn't forward the reinvite to the second leg that remain in g729. The call fail. I have also tried with FAXOPT(gateway)=yes and in this case, after 488 i have no audio at all; in 'core debug' i find: starting T.38 gateway for T.38 channel PJSIP/dev6004-00000007 and G.711 channel PJSIP/dev6005-00000008 but channel PJSIP/dev6005 is still in g729! After a while i have a lot of: DEBUG[5497][C-00000001] translate.c: Sample size different 160 vs 1280
Comments:	By: Asterisk Team (asteriskteam) 2019-06-10 08:23:40.385-0500 Thanks for creating a report! The issue has entered the triage process. That means the issue will wait in this status until a Bug Marshal has an opportunity to review the issue. Once the issue has been reviewed you will receive comments regarding the next steps towards resolution. A good first step is for you to review the [Asterisk Issue Guidelines|https://wiki.asterisk.org/wiki/display/AST/Asterisk+Issue+Guidelines] if you haven't already. The guidelines detail what is expected from an Asterisk issue report. Then, if you are submitting a patch, please review the [Patch Contribution Process|https://wiki.asterisk.org/wiki/display/AST/Patch+Contribution+Process]. Please note that once your issue enters an open state it has been accepted. As Asterisk is an open source project there is no guarantee or timeframe on when your issue will be looked into. If you need expedient resolution you will need to find and pay a suitable developer. Asking for an update on your issue will not yield any progress on it and will not result in a response. All updates are posted to the issue when they occur. By: Simone Freddio (sioux1977) 2019-06-10 08:44:13.319-0500 wireshark trace of described issue By: Joshua C. Colp (jcolp) 2019-06-17 05:08:46.004-0500 Support for changing the audio codec to ulaw is not currently supported by either chan_sip or chan_pjsip. It falls back to what was previously negotiated. This has never been supported as far as I can see and in fact the ability to change codecs like that is only a fairly recent development for chan_pjsip. Is this something you would be adding support for? By: Simone Freddio (sioux1977) 2019-06-17 05:21:08.028-0500 Hi Joshua, thank you for your feedback. I think there is bug in fax call handling when using FAXOPT(gateway)=yes... in this case, when the called side refuse T.38, the core debug says: [Jun 10 14:47:35] DEBUG[5497][C-00000001] res_fax.c: PJSIP/dev6004-00000002 attempted to negotiate T.38 but PJSIP/dev6005-00000003 refused the request [Jun 10 14:47:35] DEBUG[5497][C-00000001] res_fax.c: starting T.38 gateway for T.38 channel PJSIP/dev6004-00000002 and G.711 channel PJSIP/dev6005-00000003 but PJSIP/dev6005 is still in G729, from that point asterisk discard all packet from that peer and i have no more audio; i think that this is not the expected behaviour... By: Joshua C. Colp (jcolp) 2019-06-17 05:25:29.292-0500 The log message has "G.711" hard coded because it never expected to have to renegotiate to G.711, and the ability to do that didn't exist until recent versions. What you are trying to do just isn't supported and never has been. If you do not plan on implementing such functionality I can accept this as a bug, but there is absolutely no time frame on when it would get looked into and it would only be supported on Asterisk 16. Versions prior to that do not have the ability to have an application such as res_fax renegotiate. By: Simone Freddio (sioux1977) 2019-06-17 05:32:43.938-0500 I can try with Asterisk 16 in my lab, if it work, i can upgrade asterisk version also un customer site. By: Joshua C. Colp (jcolp) 2019-06-17 05:40:30.169-0500 This has not been fixed or touched in Asterisk 16. What I am saying is that if someone does fix it, it will only be fixed in Asterisk 16 because the ability to renegotiate the codec only exists there. By: Simone Freddio (sioux1977) 2019-06-18 02:28:55.413-0500 Hi Joshua, i still think that res_fax should handle the g711 fallback renegotiating codec on both leg... at the moment i found a workaround forcing codec to g711 for fax calls using PJSIP_MEDIA_OFFER e PJSIP_SEND_SESSION_REFRESH. Into next days il dig into code to try fixing it by myself. Please leave this issue opened so i can attach my code. By: Simone Freddio (sioux1977) 2019-07-15 08:12:00.050-0500 Hi joshua, i am trying to fix this issue myself and after some test i'll decided to try with asterisk 16 as you suggested in your previous post. I am afraid that in asterisk 16 things goes worst: 6004 start t38, asterisk send reinvite to 6005 with t38, 6005 refuse it, asterisk propagate back the '488 not acceptable here' to 6004; 6004 send a new invite with g711 for audio fallback; at this point asterisk 16 send another time a reinvite to 6005 with t38 and from this point things goes really wrong, asterisk respond to 6004 with SDP g711 with media port value 0, 6005 that has already refused t38, refuse it again; asterisk send a BYE to both leg and calls drop. I would really like to fix my issue but asterisk 16 is really a mess. I really think this is a bug, can someone give it an eyes? (in attach tha call flow and the packet capture). By: Simone Freddio (sioux1977) 2019-07-15 08:13:37.637-0500 call flow with asterisk 16.4.1 By: Simone Freddio (sioux1977) 2019-07-15 08:15:15.563-0500 packet trace asterisk 16 By: Joshua C. Colp (jcolp) 2019-07-15 08:39:33.801-0500 The issue has been accepted and is in queue. There is no time frame on when it will be looked into. By: Simone Freddio (sioux1977) 2019-07-16 04:58:00.524-0500 Hi Joshua, i get it working on 13.21-cert3... can be a starting point... By: Simone Freddio (sioux1977) 2019-07-16 04:59:15.064-0500 packet trace with patch applied on 13.21-cert3 By: Christian Berger (Christian_Berger) 2020-07-03 09:55:57.759-0500 We seem to have the same issue. We can replicate this with both 13.32.0 and 16.11.1 However in our case we always negotiated alaw and switching back to alaw after a failed attempt at T.38 doesn't work. By: Simone Freddio (sioux1977) 2020-07-05 12:34:33.719-0500 Hi Christian, i wrote a patch for asterisk 13.21-cert3 with a simple workaround... not so clean but fully working also in production... on patch line: ast_format_cap_update_by_allow_disallow(session->req_caps, "!all,alaw,ulaw", 1) you can modify wanted codec in fallback case. In the patch attached to jira, i disable all codec (!all) and then i enable alaw and ulaw, the priority is alaw first and then ulaw. My patch is only a prof of concept but is fully working (i have passed certification test with main italian public carriers with this). Joshua Colp (the pjsip_t38 mantainer and author) accept the issue as a bug, but he says: "The issue has been accepted and is in queue. There is no time frame on when it will be looked into". So... good luck... By: Christian Berger (Christian_Berger) 2020-07-06 02:28:37.175-0500 Hi Simone, I have tried that patch, and it seems to go into "t38_reinvite_response_cb". However this function does not seem to be called. Instead t38_fallback_response_cb is called. It is perhaps noteworthy that the rejection of the T.38 reinvite includes an SDP body.