[Freeswitch-users] refusing t38 in outgoing fax server transmission

Wed May 29 08:20:01 UTC 2019

Hello Sandro,

so, they want you to send out faxes with T30 in g711? That will be *very*
unreliable, you *want* to use T38.

Anyway, you want to use PCMA with normal packet size (eg, not 10 ms). You
just specify PCMA as absolute_codec string.

You do not have to refuse explicitly the call (no 488), you just do not
accept t38 fax transmission.

So, disable t38 everywhere, and do the fax over g711 (eg, over pcma).

That will be very unreliable. T38 has been created to solve that
unreliability.

If you happen to find a FreeSWITCH book, there is a chapter about faxes.

Hope this help,
-giovanni

On Wed, May 29, 2019 at 6:51 AM Sandro Bordacchini <
sandro.bordacchini at nems.it> wrote:

> Hello everyone.
>
> I am have a few FS installations interconnected with a voip provider;
> during outbound fax server transmissions, they told us that we need *to
> refuse T38 even if offered by the network*.
> The sdp offer/answer negotiation varies depending on the called number,
> probably due to a different routing in the voip provider's network.
> I experience some dropped calls (even before the fax transmission kicks
> in) using both FS versions 1.4.9 and 1.6.16.
>
> This is a successful sdp negotiation (after call is estabilished)
> First reinvite:
> 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..
> 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..
> Then, a second reinvite happens:
> 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..
> LOCAL 488
> Then, the last reinvite:
> 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..
> 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..
> And the fax is transmitted correctly
>
> This is an unsuccessful sdp negotiation:
> First reinvite
> 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 -..
> LOCAL 488
> and the remote hangs up.
>
> 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).
> 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?
> Should remote endpoint send another reinvite with only G711 or only T38
> before hanging up?
>
> Thanks in advance to whoever read till here :-)
> Any hints?
>
> S.
>
> P.s.:
> This is what i get in the log in the unsuccessful case during the reinvite
> (1.4.9 code):
> [...]
> 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]
> 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
> 2019-05-17 11:22:57.498389 [DEBUG] switch_core_media.c:3397 Set
> telephone-event payload to 96
> 2019-05-17 11:22:57.498389 [DEBUG] switch_core_media.c:3713 Set 2833 dtmf
> send payload to 96
> 2019-05-17 11:22:57.498389 [ERR] sofia.c:7065 Reinvite Codec Error!
> 2019-05-17 11:22:57.498389 [DEBUG] switch_core_session.c:1053 Send signal
> sofia/external/<calledfaxnumber> [BREAK]
> 2019-05-17 11:22:57.498389 [DEBUG] switch_core_session.c:1053 Send signal
> sofia/external/<calledfaxnumber> [BREAK]
> 2019-05-17 11:22:57.498389 [DEBUG] switch_core_media.c:2280 Already using
> PCMA
> 2019-05-17 11:22:57.498389 [DEBUG] sofia.c:6444 Channel
> sofia/external/<calledfaxnumber> entering state [ready][488]
> 2019-05-17 11:22:57.638443 [DEBUG] switch_core_session.c:1053 Send signal
> sofia/external/<calledfaxnumber> [BREAK]
> 2019-05-17 11:22:57.638443 [NOTICE] sofia.c:952 Hangup
> sofia/external/<calledfaxnumber> [CS_EXECUTE] [NORMAL_CLEARING]
> 2019-05-17 11:22:57.638443 [DEBUG] switch_channel.c:3222 Send signal
> sofia/external/<calledfaxnumber> [KILL]
> 2019-05-17 11:22:57.638443 [DEBUG] switch_core_session.c:1388 Send signal
> sofia/external/<calledfaxnumber> [BREAK]
> 2019-05-17 11:22:57.638443 [DEBUG] mod_spandsp_fax.c:293 FLOW T.30 Status
> changing to 'The call dropped prematurely'
>
> This are the most relevant settings on api originate:
> [DEBUG] switch_event.c:1688 Parsing variable [fax_use_ecm]=[off]
> [DEBUG] switch_event.c:1688 Parsing variable
> [absolute_codec_string]=[PCMA at 10i]
> [DEBUG] switch_event.c:1688 Parsing variable [fax_enable_t38]=[false]
> [DEBUG] switch_event.c:1688 Parsing variable
> [fax_enable_t38_request]=[false]
> [DEBUG] switch_event.c:1688 Parsing variable [refuse_t38]=[true]
> and on the external profile t38-passthru is set to false.
>
>
>
>
> --
>
> Ing. Sandro Bordacchini / System Engineering and Product Management
> sandro.bordacchini at nems.it
>
> _________________________________________________________________________
>
> The FreeSWITCH project is sponsored by SignalWire https://signalwire.com
> Enhance your FreeSWITCH install with disruptive priced SMS and PSTN
> services.
> Build your next product on our scalable cloud platform.
>
> Join our online community to chat in real time
> https://signalwire.community
>
> Professional FreeSWITCH Services
> sales at freeswitch.com
> https://freeswitch.com
>
> Official FreeSWITCH Sites
> https://freeswitch.com/oss
> https://freeswitch.org/confluence
> https://cluecon.com
>
> FreeSWITCH-users mailing list
> FreeSWITCH-users at lists.freeswitch.org
> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
> https://freeswitch.com

-- 
Sincerely,

Giovanni Maruzzelli
OpenTelecom.IT
cell: +39 347 266 56 18
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freeswitch.org/pipermail/freeswitch-users/attachments/20190529/b9d31e94/attachment.html>