refusing t38 in outgoing fax server transmission
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@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@nems.it
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@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@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@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@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@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
Hi Giovanni. Thanks for your reply. Yes, I know T38 is the way to go with faxes :-) Unfortunately, interconnection specs with this provider are not negotiable. I already have set absolute_codec_string as PCMA (i also tried as PCMA@10i because the remote reinvite i am receiving has a ptime of 10), i get the same result. As you can see at the bottom of my previous email, i also have set t38 off. 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? Thanks a lot. S Il giorno mer 29 mag 2019 alle ore 10:20 Giovanni Maruzzelli < gmaruzz@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@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@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@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@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@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@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@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users https://freeswitch.com
On Thu, May 30, 2019 at 12:46 AM Sandro Bordacchini < sandro.bordacchini@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-Sofiaprofilep... 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@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@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@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@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@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@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@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@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@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@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
Update, this has been fixed for quite a while. On Wed, May 29, 2019 at 6:52 PM Giovanni Maruzzelli <gmaruzz@gmail.com> wrote:
On Thu, May 30, 2019 at 12:46 AM Sandro Bordacchini < sandro.bordacchini@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-Sofiaprofilep...
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@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@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@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@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@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@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@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@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@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@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@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@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users https://freeswitch.com
-- Brian West | Co-founder and Developer Need Commercial support? email sales@freeswitch.com FreeSWITCH Solutions | 17345 Civic Drive #2531 Brookfield, WI 53045 <https://maps.google.com/?q=17345+Civic+Drive+%232531+Brookfield,+WI+53045&entry=gmail&source=g> Email: brian@freeswitch.com Mobile: 918-424-9378 Website: https://www.FreeSWITCH.com <https://www.freeswitch.com/> [image: https://www.facebook.com/signalwireinc?src=email] <https://www.facebook.com/freeswitch> [image: https://twitter.com/freeswitch] <https://twitter.com/freeswitch>
Hello Brian, thanks for your reply. Can you point me out to the bug so i can check in which versions it has been fixed? Thanks a lot. S Il giorno gio 30 mag 2019 alle ore 01:58 Brian West <brian@freeswitch.com> ha scritto:
Update, this has been fixed for quite a while.
On Wed, May 29, 2019 at 6:52 PM Giovanni Maruzzelli <gmaruzz@gmail.com> wrote:
On Thu, May 30, 2019 at 12:46 AM Sandro Bordacchini < sandro.bordacchini@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-Sofiaprofilep...
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@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@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@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@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@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@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@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@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@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@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@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@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users https://freeswitch.com
--
Brian West | Co-founder and Developer
Need Commercial support? email sales@freeswitch.com
FreeSWITCH Solutions | 17345 Civic Drive #2531 Brookfield, WI 53045 <https://maps.google.com/?q=17345+Civic+Drive+%232531+Brookfield,+WI+53045&entry=gmail&source=g>
Email: brian@freeswitch.com
Mobile: 918-424-9378
Website: https://www.FreeSWITCH.com <https://www.freeswitch.com/>
[image: https://www.facebook.com/signalwireinc?src=email] <https://www.facebook.com/freeswitch> [image: https://twitter.com/freeswitch] <https://twitter.com/freeswitch> _________________________________________________________________________
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@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@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@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@nems.it
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@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@gmail.com> ha scritto:
On Thu, May 30, 2019 at 12:46 AM Sandro Bordacchini < sandro.bordacchini@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-Sofiaprofilep...
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@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@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@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@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@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@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@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@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@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@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@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@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@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@nems.it
participants (3)
-
Brian West
-
Giovanni Maruzzelli
-
Sandro Bordacchini