<div dir="ltr"><div>Hello Sandro,</div><div><br></div><div>so, they want you to send out faxes with T30 in g711? That will be *very* unreliable, you *want* to use T38.</div><div><br></div><div>Anyway, you want to use PCMA with normal packet size (eg, not 10 ms). You just specify PCMA as absolute_codec string.</div><div><br></div><div>You do not have to refuse explicitly the call (no 488), you just do not accept t38 fax transmission.</div><div><br></div><div>So, disable t38 everywhere, and do the fax over g711 (eg, over pcma).</div><div><br></div><div>That will be very unreliable. T38 has been created to solve that unreliability.</div><div><br></div><div>If you happen to find a FreeSWITCH book, there is a chapter about faxes.</div><div><br></div><div><br></div><div>Hope this help,</div><div>-giovanni</div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, May 29, 2019 at 6:51 AM Sandro Bordacchini <<a href="mailto:sandro.bordacchini@nems.it">sandro.bordacchini@nems.it</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><div>Hello everyone.</div><div><br></div><div>I am have a few FS installations interconnected with a voip provider; during outbound fax server transmissions, they told us that we need <b>to refuse T38 even if offered by the network</b>.</div><div></div><div>The sdp offer/answer negotiation varies depending on the called number, probably due to a different routing in the voip provider's network.</div><div>I experience some dropped calls (even before the fax transmission kicks in) using both FS versions 1.4.9 and 1.6.16.
</div><div><br></div><div>This is a successful sdp negotiation (after call is estabilished)<br></div>First reinvite:<br><div>REMOTE INVITE with SDP: v=0..o=LucentPCSF 413445855 413445856 IN IP4 10.198.1.230..s=-..c=IN IP4 10.198.1.230..t=0 0..m=audio 15756 RTP/AVP 8 96 4..a=rtpmap:96 telephone-event/8000..a=fmtp:96 0-15..a=ptime:20..a=X-sqn: 0..a=X-cap: 1 image udptl t38..</div><div>LOCAL 200OK with SDP: v=0..o=FreeSWITCH 1558069426 1558069428 IN IP4 10.197.98.6..s=FreeSWITCH..c=IN IP4 10.197.98.6..t=0 0..m=audio 30394 RTP/AVP 8 96..a=rtpmap:8 PCMA/8000..a=rtpmap:96 telephone-event/8000..a=fmtp:96 0-16..a=silenceSupp:off - - - -..a=ptime:20..</div><div></div><div>Then, a second reinvite happens:<br></div>REMOTE INVITE with SDP: v=0..o=LucentPCSF 413445855 413445857 IN IP4 10.198.1.230..s=-..c=IN IP4 10.198.1.230..t=0 0..m=audio 0 RTP/AVP 0..c=IN IP4 10.198.1.230..m=image 12834 udptl t38..a=X-sqn: 0..a=X-cap: 1 image udptl t38..<br><div>LOCAL 488 <br></div><div></div>Then, the last reinvite:<br>REMOTE INVITE with SDP: v=0..o=LucentPCSF 413445855 413445858 IN IP4 10.198.1.230..s=-..c=IN IP4 10.198.1.230..t=0 0..m=audio 15756 RTP/AVP 8 96 4..a=rtpmap:96 telephone-event/8000..a=fmtp:96 0-15..a=ptime:20..a=X-sqn: 0..a=X-cap: 1 image udptl t38..m=image 0 udptl t38..c=IN IP4 10.198.1.230..<br>LOCAL 200OK with SDP: v=0..o=FreeSWITCH 1558069426 1558069429 IN IP4 10.197.98.6..s=FreeSWITCH..c=IN IP4 10.197.98.6..t=0 0..m=audio 30394 RTP/AVP 8 96..a=rtpmap:8 PCMA/8000..a=rtpmap:96 telephone-event/8000..a=fmtp:96 0-16..a=silenceSupp:off - - - -..a=ptime:20..m=image 0 udptl t38..<br></div><div>And the fax is transmitted correctly</div><div><br></div><div>This is an unsuccessful sdp negotiation:</div><div>First reinvite<br></div>REMOTE INVITE with SDP: v=0..o=LucentPCSF 579041281 579041282 IN IP4 10.198.1.230..s=-..c=IN IP4 10.198.1.230..t=0 0..m=audio 13302 RTP/AVP 8 96..a=rtpmap:96 telephone-event/8000..a=ptime:10..a=ecan:fb on -..a=Fax..m=image 17522 udptl t38..a=T38FaxVersion:0..a=T38MaxBitRate:14400..a=T38FaxRateManagement:transferredTCF..a=T38FaxMaxBuffer:1800..a=T38FaxMaxDatagram:260..a=T38FaxUdpEC:t38UDPRedundancy..a=ecan:fb on -..<br>LOCAL 488<br><div>and the remote hangs up.</div><div><br></div><div>
My point is that, in case of unsuccessful negotiation, FS receives a reinvite with two "m=" in the sdp, one G711A (port 13302) and one T38 (port 17522).</div><div>Is it ok for FS to refuse "all the sdp" with 488 just because it has to refuse T38 or it should be configured to refuse only the T38 media?</div><div>Should remote endpoint send another reinvite with only G711 or only T38 before hanging up?<br></div><div><br></div><div>Thanks in advance to whoever read till here :-)</div><div>Any hints?</div><div><br></div><div>S.<br></div><div></div><div><br></div><div>P.s.:<br></div><div><div>This is what i get in the log in the unsuccessful case during the reinvite (1.4.9 code):</div><div>[...]<br></div><div>
2019-05-17 11:22:57.498389 [DEBUG] switch_core_media.c:3476 Audio Codec Compare [PCMA:8:8000:10:64000:1]/[PCMA:8:8000:10:64000:1]<br>2019-05-17 11:22:57.498389 [DEBUG] switch_core_media.c:3531 Audio Codec Compare [PCMA:8:8000:10:64000:1] ++++ is saved as a match<br>2019-05-17 11:22:57.498389 [DEBUG] switch_core_media.c:3397 Set telephone-event payload to 96<br>2019-05-17 11:22:57.498389 [DEBUG] switch_core_media.c:3713 Set 2833 dtmf send payload to 96<br>2019-05-17 11:22:57.498389 [ERR] sofia.c:7065 Reinvite Codec Error!<br>2019-05-17 11:22:57.498389 [DEBUG] switch_core_session.c:1053 Send signal sofia/external/<calledfaxnumber> [BREAK]<br>2019-05-17 11:22:57.498389 [DEBUG] switch_core_session.c:1053 Send signal sofia/external/<calledfaxnumber>
[BREAK]<br>2019-05-17 11:22:57.498389 [DEBUG] switch_core_media.c:2280 Already using PCMA<br>2019-05-17 11:22:57.498389 [DEBUG] sofia.c:6444 Channel sofia/external/<calledfaxnumber>
entering state [ready][488]<br>2019-05-17 11:22:57.638443 [DEBUG] switch_core_session.c:1053 Send signal sofia/external/<calledfaxnumber>
[BREAK]<br>2019-05-17 11:22:57.638443 [NOTICE] sofia.c:952 Hangup sofia/external/<calledfaxnumber>
[CS_EXECUTE] [NORMAL_CLEARING]<br>2019-05-17 11:22:57.638443 [DEBUG] switch_channel.c:3222 Send signal sofia/external/<calledfaxnumber>
[KILL]<br>2019-05-17 11:22:57.638443 [DEBUG] switch_core_session.c:1388 Send signal sofia/external/<calledfaxnumber>
[BREAK]<br>2019-05-17 11:22:57.638443 [DEBUG] mod_spandsp_fax.c:293 FLOW T.30 Status changing to 'The call dropped prematurely'<br></div><div><br></div><div>This are the most relevant settings on api originate:</div><div>[<span style="color:rgb(0,0,0);font-family:Geneva,Helvetica,Arial,sans-serif;font-size:12px;font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration-style:initial;text-decoration-color:initial;display:inline;float:none">DEBUG] switch_event.c:1688 Parsing variable [fax_use_ecm]=[off]</span><br style="color:rgb(0,0,0);font-family:Geneva,Helvetica,Arial,sans-serif;font-size:12px;font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration-style:initial;text-decoration-color:initial"><span style="color:rgb(0,0,0);font-family:Geneva,Helvetica,Arial,sans-serif;font-size:12px;font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration-style:initial;text-decoration-color:initial;display:inline;float:none">[DEBUG] switch_event.c:1688 Parsing variable [absolute_codec_string]=[PCMA@10i]<br>[DEBUG] switch_event.c:1688 Parsing variable [fax_enable_t38]=[false]<br>[DEBUG] switch_event.c:1688 Parsing variable [fax_enable_t38_request]=[false]<br>[DEBUG] switch_event.c:1688 Parsing variable [refuse_t38]=[true]<br></span>and on the external profile t38-passthru is set to false.</div><div><br></div><div><br></div><div><br></div><div><br>-- <br><div class="gmail-m_-1624498182130010320gmail_signature"><div><div><div><p style="font-family:Helvetica,Arial,sans-serif;font-size:12px;line-height:14px"></p>
<p style="font-family:Helvetica,Arial,sans-serif;font-size:12px;line-height:14px;color:rgb(153,153,153)"><span style="font-weight:bold">Ing. Sandro Bordacchini</span>
<span>/</span> System Engineering and Product Management<br><span></span><a href="mailto:sandro.bordacchini@nems.it" style="color:rgb(255,0,0)" target="_blank">sandro.bordacchini@nems.it</a></p><br></div></div></div></div></div></div></div>
_________________________________________________________________________<br>
<br>
The FreeSWITCH project is sponsored by SignalWire <a href="https://signalwire.com" rel="noreferrer" target="_blank">https://signalwire.com</a><br>
Enhance your FreeSWITCH install with disruptive priced SMS and PSTN services.<br>
Build your next product on our scalable cloud platform.<br>
<br>
Join our online community to chat in real time <a href="https://signalwire.community" rel="noreferrer" target="_blank">https://signalwire.community</a><br>
<br>
Professional FreeSWITCH Services<br>
<a href="mailto:sales@freeswitch.com" target="_blank">sales@freeswitch.com</a><br>
<a href="https://freeswitch.com" rel="noreferrer" target="_blank">https://freeswitch.com</a><br>
<br>
Official FreeSWITCH Sites<br>
<a href="https://freeswitch.com/oss" rel="noreferrer" target="_blank">https://freeswitch.com/oss</a><br>
<a href="https://freeswitch.org/confluence" rel="noreferrer" target="_blank">https://freeswitch.org/confluence</a><br>
<a href="https://cluecon.com" rel="noreferrer" target="_blank">https://cluecon.com</a><br>
<br>
FreeSWITCH-users mailing list<br>
<a href="mailto:FreeSWITCH-users@lists.freeswitch.org" target="_blank">FreeSWITCH-users@lists.freeswitch.org</a><br>
<a href="http://lists.freeswitch.org/mailman/listinfo/freeswitch-users" rel="noreferrer" target="_blank">http://lists.freeswitch.org/mailman/listinfo/freeswitch-users</a><br>
UNSUBSCRIBE:<a href="http://lists.freeswitch.org/mailman/options/freeswitch-users" rel="noreferrer" target="_blank">http://lists.freeswitch.org/mailman/options/freeswitch-users</a><br>
<a href="https://freeswitch.com" rel="noreferrer" target="_blank">https://freeswitch.com</a></blockquote></div><br clear="all"><br>-- <br><div dir="ltr" class="gmail_signature">Sincerely,<br><br>Giovanni Maruzzelli<br>OpenTelecom.IT<br>cell: +39 347 266 56 18<br><br></div>