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

Thu May 30 13:05:51 UTC 2019

Hi Giovanni.

The scenario is an outgoing fax transmission: FreeSWITCH is the
transmitting *fax server*.
I issue "api originate" command to create the call. These are the t38/g711
relevant settings:
[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.

When calling some recipients, i get from the remote party (a voip provider)
a reINVITE with sdp containing a double media (a "m=g711a" and a "m=T38").
At the present FreeSWITCH answers with a "488 not acceptable here". And the
voip provider hangs up.
*What i want to achieve* is FreeSWITCH to accept the g711a media and deny
the T38 media (putting t38 port=0? deleting the t38 media from the sdp
answer? i don't know exactly).

I haven't been able, so far, to find the parameters to pass to the api
originate (or parameters to set on the external profile) to get that kind
of behaviour.

I hope I have been more clear this time :-)

Thanks for your patience.
SB

Il giorno gio 30 mag 2019 alle ore 01:51 Giovanni Maruzzelli <
gmaruzz at gmail.com> ha scritto:

> On Thu, May 30, 2019 at 12:46 AM Sandro Bordacchini <
> sandro.bordacchini at nems.it> wrote:
>
>> I am just wondering if it's possible to configure FS to accept the G711
>> media and "turn off" the T38 media that have been received in the same sdp
>> (refer to reinvite in the unsuccessful case).
>> That would be really helpful for me but i wasnt able to get that kind of
>> behaviour.
>> Am I missing something?
>>
>
> Maybe I do not understand what you want to achieve. If you do not act on
> T38, then also if you are offered it, you will not take it in
> consideration, and just process the call as a call without T38
>
> If you are "proxying" T38 (eg inbound T38 outbound plain g711), then there
> are specific settings for it
>
> Check both of the links:
>
>
> https://freeswitch.org/confluence/display/FREESWITCH/T.38#T.38-Sofiaprofileparameters
>
> https://freeswitch.org/confluence/display/FREESWITCH/mod_spandsp
>
> -giovanni
>
>
>> Thanks a lot.
>> S
>>
>> Il giorno mer 29 mag 2019 alle ore 10:20 Giovanni Maruzzelli <
>> gmaruzz at gmail.com> ha scritto:
>>
>>> 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
>>>
>>> _________________________________________________________________________
>>>
>>> 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
>>
>>
>> _________________________________________________________________________
>>
>> 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
>
> _________________________________________________________________________
>
> 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

-- 

[image: NEMS S.r.l.] <http://www.nems.it>

Ing. Sandro Bordacchini / System Engineering and Product Management
(+39) 347 96 96 531 / sandro.bordacchini at nems.it

NEMS S.r.l. Office: (+39) 0587 466957 ext 204 / Fax: (+39) 0587 829177
Via Squartini, 18 - 56121 Pisa (PI) Italy
http://www.nems.it

[image: Facebook] <http://vcf.nems.it/facebook.png> [image: Linkedin]
<http://www.linkedin.com/company/5020065> [image: Twitter]
<http://www.twitter.com/nemssrl> [image: Google Plus]
<https://plus.google.com/117770114595753846641>

In ottemperanza con il nuovo Regolamento Europeo GDPR n. 679/2016, le
informazioni contenute in questo messaggio sono riservate e confidenziali.
Il loro utilizzo è consentito esclusivamente al destinatario del messaggio,
per le finalità indicate nel messaggio stesso. Qualora Lei non fosse la
persona a cui il presente messaggio è destinato, La invitiamo ad eliminarlo
dal Suo Sistema ed a distruggere le varie copie o stampe, dandocene
gentilmente comunicazione. Ogni utilizzo improprio è contrario ai principi
del nuovo Regolamento Europeo GDPR n. 679/2016.
NEMS S.r.l. opera in conformità al nuovo Regolamento Europeo GDPR n.
679/2016. Per qualsiasi informazione a riguardo si prega di contattare
l’indirizzo mail: info at nems.it
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freeswitch.org/pipermail/freeswitch-users/attachments/20190530/deddf4fc/attachment-0001.html>