Hi; I am attempting to get T38 Fax working between two FS/FusionPBX installations using mod_spandsp. I am unable to get into T.38 mode, T.30 used, successful fax. Note that zrtp is disabled for fax calls, due to T38 udpl (not rtp media) incompatibility Thanks Brian West!: "T.38 Fax takes place over UDPTL, There for it can NOT be encrypted as there was never really a standard for doing so." Details (both FS's): SIP Provider: freephoneline.ca (claims T38 capable) freeswitch - 1.4.18 x86_64 Topology: FS#1: rossco.org, using FusionPBX web GUI to send fax FS#2:rossco.duckdns.org, using spandsp extension to receive fax (spandsp txfax, x1020)FS#1 -> cloud -> FS#2(spandsp rxfax, x9000) Key variables for fax sender (FS#1), during call: $domain= rossco.org Spandsp Fax extension: 1020 t38_passthru = false zrtp_secure_media = false fax_enable_t38 = true fax_enable_t38_request = true fax_use_ecm = off inbound-late-negotiation = true ignore_early_media = false Key variables for fax receiver (FS#2), during call: $domain= rossco.duckdns.org Spandsp Fax extension: 9000 t38_passthru = false zrtp_secure_media = false fax_enable_t38 = true fax_enable_t38_request = true fax_use_ecm = off inbound-late-negotiation = true ignore_early_media = false Full Logs w/siptrace: Sender(rossco.org): https://pastebin.freeswitch.org/24115 Receiver(rossco.duckdns.org): https://pastebin.freeswitch.org/24116 Note that the SDP's are correct for T38: 590fc4c4-3035-438e-a4c7-4a9d8e51ee42 v=0 590fc4c4-3035-438e-a4c7-4a9d8e51ee42 o=FreeSWITCH 1428750600 1428750602 IN IP4 198.48.238.130 590fc4c4-3035-438e-a4c7-4a9d8e51ee42 s=FreeSWITCH 590fc4c4-3035-438e-a4c7-4a9d8e51ee42 c=IN IP4 198.48.238.130 590fc4c4-3035-438e-a4c7-4a9d8e51ee42 t=0 0 590fc4c4-3035-438e-a4c7-4a9d8e51ee42 m=image 16448 udptl t38 590fc4c4-3035-438e-a4c7-4a9d8e51ee42 a=T38FaxVersion:0 590fc4c4-3035-438e-a4c7-4a9d8e51ee42 a=T38MaxBitRate:14400 590fc4c4-3035-438e-a4c7-4a9d8e51ee42 a=T38FaxFillBitRemoval 590fc4c4-3035-438e-a4c7-4a9d8e51ee42 a=T38FaxRateManagement:transferredTCF 590fc4c4-3035-438e-a4c7-4a9d8e51ee42 a=T38FaxMaxBuffer:2000 590fc4c4-3035-438e-a4c7-4a9d8e51ee42 a=T38FaxMaxDatagram:400 590fc4c4-3035-438e-a4c7-4a9d8e51ee42 a=T38FaxUdpEC:t38UDPRedundancy Questions: 1 - According to my interpretation of logs, T38 is not negotiated, despite T38 SDP's 2 - What am I missing? Thanks; Bill Ross
you probably don't want to use fax_enable_t38_request = true unless you know for sure that you need it, and you would NEVER want that on both sides.
On Apr 11, 2015, at 12:04 PM, Bill Ross <rossbcan@gmail.com> wrote:
Hi;
I am attempting to get T38 Fax working between two FS/FusionPBX installations using mod_spandsp. I am unable to get into T.38 mode, T.30 used, successful fax. Note that zrtp is disabled for fax calls, due to T38 udpl (not rtp media) incompatibility Thanks Brian West!: “T.38 Fax takes place over UDPTL, There for it can NOT be encrypted as there was never really a standard for doing so.”
Details (both FS’s):
SIP Provider: freephoneline.ca <http://freephoneline.ca/> (claims T38 capable) freeswitch - 1.4.18 x86_64
Topology:
FS#1: rossco.org <http://rossco.org/>, using FusionPBX web GUI to send fax FS#2:rossco.duckdns.org <http://rossco.duckdns.org/>, using spandsp extension to receive fax
(spandsp txfax, x1020)FS#1 -> cloud -> FS#2(spandsp rxfax, x9000)
Key variables for fax sender (FS#1), during call: $domain= rossco.org <http://rossco.org/> Spandsp Fax extension: 1020 t38_passthru = false zrtp_secure_media = false fax_enable_t38 = true fax_enable_t38_request = true fax_use_ecm = off inbound-late-negotiation = true ignore_early_media = false
Key variables for fax receiver (FS#2), during call: $domain= rossco.duckdns.org <http://rossco.duckdns.org/> Spandsp Fax extension: 9000 t38_passthru = false zrtp_secure_media = false fax_enable_t38 = true fax_enable_t38_request = true fax_use_ecm = off inbound-late-negotiation = true ignore_early_media = false
Full Logs w/siptrace:
Sender(rossco.org <http://rossco.org/>): https://pastebin.freeswitch.org/24115 <https://pastebin.freeswitch.org/24115>
Receiver(rossco.duckdns.org <http://rossco.duckdns.org/>): https://pastebin.freeswitch.org/24116 <https://pastebin.freeswitch.org/24116>
Note that the SDP’s are correct for T38:
590fc4c4-3035-438e-a4c7-4a9d8e51ee42 v=0 590fc4c4-3035-438e-a4c7-4a9d8e51ee42 o=FreeSWITCH 1428750600 1428750602 IN IP4 198.48.238.130 590fc4c4-3035-438e-a4c7-4a9d8e51ee42 s=FreeSWITCH 590fc4c4-3035-438e-a4c7-4a9d8e51ee42 c=IN IP4 198.48.238.130 590fc4c4-3035-438e-a4c7-4a9d8e51ee42 t=0 0 590fc4c4-3035-438e-a4c7-4a9d8e51ee42 m=image 16448 udptl t38 590fc4c4-3035-438e-a4c7-4a9d8e51ee42 a=T38FaxVersion:0 590fc4c4-3035-438e-a4c7-4a9d8e51ee42 a=T38MaxBitRate:14400 590fc4c4-3035-438e-a4c7-4a9d8e51ee42 a=T38FaxFillBitRemoval 590fc4c4-3035-438e-a4c7-4a9d8e51ee42 a=T38FaxRateManagement:transferredTCF 590fc4c4-3035-438e-a4c7-4a9d8e51ee42 a=T38FaxMaxBuffer:2000 590fc4c4-3035-438e-a4c7-4a9d8e51ee42 a=T38FaxMaxDatagram:400 590fc4c4-3035-438e-a4c7-4a9d8e51ee42 a=T38FaxUdpEC:t38UDPRedundancy
Questions:
1 - According to my interpretation of logs, T38 is not negotiated, despite T38 SDP’s 2 - What am I missing?
Thanks; Bill Ross
Thanks Michael; I took your advice and set: fax_enable_t38_request = Not set for the fax receiver (FS#2) Made no difference and, I suspect two things: #1 – May actually be doing T.38 in both cases, fax transaction is using various values for: FLOW T.38T Set rx type 9 and FLOW T.38T Set tx type 9 And, the transaction ends with: FLOW T.38T FAX exchange complete Is this sufficient evidence that T.38 was used? The T.30 packet transfer messages caused me confusion. #2 – IMHO, the glare condition of both ends setting fax_enable_t38_request = true Is unavoidable due to lack of signalling / race condition knowledge regarding state of t38_request from the other end. Strongly suspect since freeswitch has supported T.38 for some time that FS already handles this condition. Gurus, please weigh in on this. Regards; Bill Ross From: freeswitch-users-bounces@lists.freeswitch.org [mailto:freeswitch-users-bounces@lists.freeswitch.org] On Behalf Of Michael Jerris Sent: April-13-15 9:03 AM To: FreeSWITCH Users Help Subject: Re: [Freeswitch-users] Freeswitch / FusionPBX T.38 Fax you probably don't want to use fax_enable_t38_request = true unless you know for sure that you need it, and you would NEVER want that on both sides. On Apr 11, 2015, at 12:04 PM, Bill Ross <rossbcan@gmail.com> wrote: Hi; I am attempting to get T38 Fax working between two FS/FusionPBX installations using mod_spandsp. I am unable to get into T.38 mode, T.30 used, successful fax. Note that zrtp is disabled for fax calls, due to T38 udpl (not rtp media) incompatibility Thanks Brian West!: “T.38 Fax takes place over UDPTL, There for it can NOT be encrypted as there was never really a standard for doing so.” Details (both FS’s): SIP Provider: <http://freephoneline.ca/> freephoneline.ca (claims T38 capable) freeswitch - 1.4.18 x86_64 Topology: FS#1: <http://rossco.org/> rossco.org, using FusionPBX web GUI to send fax FS#2: <http://rossco.duckdns.org/> rossco.duckdns.org, using spandsp extension to receive fax (spandsp txfax, x1020)FS#1 -> cloud -> FS#2(spandsp rxfax, x9000) Key variables for fax sender (FS#1), during call: $domain= <http://rossco.org/> rossco.org Spandsp Fax extension: 1020 t38_passthru = false zrtp_secure_media = false fax_enable_t38 = true fax_enable_t38_request = true fax_use_ecm = off inbound-late-negotiation = true ignore_early_media = false Key variables for fax receiver (FS#2), during call: $domain= <http://rossco.duckdns.org/> rossco.duckdns.org Spandsp Fax extension: 9000 t38_passthru = false zrtp_secure_media = false fax_enable_t38 = true fax_enable_t38_request = true fax_use_ecm = off inbound-late-negotiation = true ignore_early_media = false Full Logs w/siptrace: Sender( <http://rossco.org/> rossco.org): <https://pastebin.freeswitch.org/24115> https://pastebin.freeswitch.org/24115 Receiver( <http://rossco.duckdns.org/> rossco.duckdns.org): <https://pastebin.freeswitch.org/24116> https://pastebin.freeswitch.org/24116 Note that the SDP’s are correct for T38: 590fc4c4-3035-438e-a4c7-4a9d8e51ee42 v=0 590fc4c4-3035-438e-a4c7-4a9d8e51ee42 o=FreeSWITCH 1428750600 1428750602 IN IP4 198.48.238.130 590fc4c4-3035-438e-a4c7-4a9d8e51ee42 s=FreeSWITCH 590fc4c4-3035-438e-a4c7-4a9d8e51ee42 c=IN IP4 198.48.238.130 590fc4c4-3035-438e-a4c7-4a9d8e51ee42 t=0 0 590fc4c4-3035-438e-a4c7-4a9d8e51ee42 m=image 16448 udptl t38 590fc4c4-3035-438e-a4c7-4a9d8e51ee42 a=T38FaxVersion:0 590fc4c4-3035-438e-a4c7-4a9d8e51ee42 a=T38MaxBitRate:14400 590fc4c4-3035-438e-a4c7-4a9d8e51ee42 a=T38FaxFillBitRemoval 590fc4c4-3035-438e-a4c7-4a9d8e51ee42 a=T38FaxRateManagement:transferredTCF 590fc4c4-3035-438e-a4c7-4a9d8e51ee42 a=T38FaxMaxBuffer:2000 590fc4c4-3035-438e-a4c7-4a9d8e51ee42 a=T38FaxMaxDatagram:400 590fc4c4-3035-438e-a4c7-4a9d8e51ee42 a=T38FaxUdpEC:t38UDPRedundancy Questions: 1 - According to my interpretation of logs, T38 is not negotiated, despite T38 SDP’s 2 - What am I missing? Thanks; Bill Ross
You would typically have that on the receiver end, not the sender.
On Apr 13, 2015, at 10:41 AM, Bill Ross <rossbcan@gmail.com> wrote:
Thanks Michael;
I took your advice and set:
fax_enable_t38_request = Not set for the fax receiver (FS#2)
Made no difference and, I suspect two things:
#1 – May actually be doing T.38 in both cases, fax transaction is using various values for:
FLOW T.38T Set rx type 9 and FLOW T.38T Set tx type 9 And, the transaction ends with:
FLOW T.38T FAX exchange complete
Is this sufficient evidence that T.38 was used? The T.30 packet transfer messages caused me confusion.
#2 – IMHO, the glare condition of both ends setting fax_enable_t38_request = true Is unavoidable due to lack of signalling / race condition knowledge regarding state of t38_request from the other end. Strongly suspect since freeswitch has supported T.38 for some time that FS already handles this condition. Gurus, please weigh in on this.
Regards; Bill Ross
From: freeswitch-users-bounces@lists.freeswitch.org [mailto:freeswitch-users-bounces@lists.freeswitch.org] On Behalf Of Michael Jerris Sent: April-13-15 9:03 AM To: FreeSWITCH Users Help Subject: Re: [Freeswitch-users] Freeswitch / FusionPBX T.38 Fax
you probably don't want to use fax_enable_t38_request = true unless you know for sure that you need it, and you would NEVER want that on both sides.
On Apr 11, 2015, at 12:04 PM, Bill Ross <rossbcan@gmail.com <mailto:rossbcan@gmail.com>> wrote:
Hi;
I am attempting to get T38 Fax working between two FS/FusionPBX installations using mod_spandsp. I am unable to get into T.38 mode, T.30 used, successful fax. Note that zrtp is disabled for fax calls, due to T38 udpl (not rtp media) incompatibility Thanks Brian West!: “T.38 Fax takes place over UDPTL, There for it can NOT be encrypted as there was never really a standard for doing so.”
Details (both FS’s):
SIP Provider: freephoneline.ca <http://freephoneline.ca/> (claims T38 capable) freeswitch - 1.4.18 x86_64
Topology:
FS#1: rossco.org <http://rossco.org/>, using FusionPBX web GUI to send fax FS#2:rossco.duckdns.org <http://rossco.duckdns.org/>, using spandsp extension to receive fax
(spandsp txfax, x1020)FS#1 -> cloud -> FS#2(spandsp rxfax, x9000)
Key variables for fax sender (FS#1), during call: $domain= rossco.org <http://rossco.org/> Spandsp Fax extension: 1020 t38_passthru = false zrtp_secure_media = false fax_enable_t38 = true fax_enable_t38_request = true fax_use_ecm = off inbound-late-negotiation = true ignore_early_media = false
Key variables for fax receiver (FS#2), during call: $domain= rossco.duckdns.org <http://rossco.duckdns.org/> Spandsp Fax extension: 9000 t38_passthru = false zrtp_secure_media = false fax_enable_t38 = true fax_enable_t38_request = true fax_use_ecm = off inbound-late-negotiation = true ignore_early_media = false
Full Logs w/siptrace:
Sender(rossco.org <http://rossco.org/>): https://pastebin.freeswitch.org/24115 <https://pastebin.freeswitch.org/24115>
Receiver(rossco.duckdns.org <http://rossco.duckdns.org/>): https://pastebin.freeswitch.org/24116 <https://pastebin.freeswitch.org/24116>
Note that the SDP’s are correct for T38:
590fc4c4-3035-438e-a4c7-4a9d8e51ee42 v=0 590fc4c4-3035-438e-a4c7-4a9d8e51ee42 o=FreeSWITCH 1428750600 1428750602 IN IP4 198.48.238.130 590fc4c4-3035-438e-a4c7-4a9d8e51ee42 s=FreeSWITCH 590fc4c4-3035-438e-a4c7-4a9d8e51ee42 c=IN IP4 198.48.238.130 590fc4c4-3035-438e-a4c7-4a9d8e51ee42 t=0 0 590fc4c4-3035-438e-a4c7-4a9d8e51ee42 m=image 16448 udptl t38 590fc4c4-3035-438e-a4c7-4a9d8e51ee42 a=T38FaxVersion:0 590fc4c4-3035-438e-a4c7-4a9d8e51ee42 a=T38MaxBitRate:14400 590fc4c4-3035-438e-a4c7-4a9d8e51ee42 a=T38FaxFillBitRemoval 590fc4c4-3035-438e-a4c7-4a9d8e51ee42 a=T38FaxRateManagement:transferredTCF 590fc4c4-3035-438e-a4c7-4a9d8e51ee42 a=T38FaxMaxBuffer:2000 590fc4c4-3035-438e-a4c7-4a9d8e51ee42 a=T38FaxMaxDatagram:400 590fc4c4-3035-438e-a4c7-4a9d8e51ee42 a=T38FaxUdpEC:t38UDPRedundancy
Questions:
1 - According to my interpretation of logs, T38 is not negotiated, despite T38 SDP’s 2 - What am I missing?
Thanks; Bill Ross
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org <mailto:consulting@freeswitch.org> http://www.freeswitchsolutions.com <http://www.freeswitchsolutions.com/>
Official FreeSWITCH Sites http://www.freeswitch.org <http://www.freeswitch.org/> http://confluence.freeswitch.org <http://confluence.freeswitch.org/> http://www.cluecon.com <http://www.cluecon.com/>
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org <mailto:FreeSWITCH-users@lists.freeswitch.org> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users <http://lists.freeswitch.org/mailman/listinfo/freeswitch-users> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users <http://lists.freeswitch.org/mailman/options/freeswitch-users> http://www.freeswitch.org <http://www.freeswitch.org/>
Hi Michael; FusionPBX sets fax_enable_t38_request = true For the (created by fusionPBX) receive fax xml endpoint and the transmit fax (from web gui) php. Once this is sorted out, if changes required, I will spawn a fusionPBX bug. Regards; Bill From: freeswitch-users-bounces@lists.freeswitch.org [mailto:freeswitch-users-bounces@lists.freeswitch.org] On Behalf Of Michael Jerris Sent: April-13-15 10:54 AM To: FreeSWITCH Users Help Subject: Re: [Freeswitch-users] Freeswitch / FusionPBX T.38 Fax You would typically have that on the receiver end, not the sender. On Apr 13, 2015, at 10:41 AM, Bill Ross <rossbcan@gmail.com> wrote: Thanks Michael; I took your advice and set: Not set for the fax receiver (FS#2) Made no difference and, I suspect two things: #1 – May actually be doing T.38 in both cases, fax transaction is using various values for: FLOW T.38T Set rx type 9 and FLOW T.38T Set tx type 9 And, the transaction ends with: FLOW T.38T FAX exchange complete Is this sufficient evidence that T.38 was used? The T.30 packet transfer messages caused me confusion. #2 – IMHO, the glare condition of both ends setting fax_enable_t38_request = true Is unavoidable due to lack of signalling / race condition knowledge regarding state of t38_request from the other end. Strongly suspect since freeswitch has supported T.38 for some time that FS already handles this condition. Gurus, please weigh in on this. Regards; Bill Ross From: freeswitch-users-bounces@lists.freeswitch.org [mailto:freeswitch-users-bounces@lists.freeswitch.org] On Behalf Of Michael Jerris Sent: April-13-15 9:03 AM To: FreeSWITCH Users Help Subject: Re: [Freeswitch-users] Freeswitch / FusionPBX T.38 Fax you probably don't want to use fax_enable_t38_request = true unless you know for sure that you need it, and you would NEVER want that on both sides. On Apr 11, 2015, at 12:04 PM, Bill Ross < <mailto:rossbcan@gmail.com> rossbcan@gmail.com> wrote: Hi; I am attempting to get T38 Fax working between two FS/FusionPBX installations using mod_spandsp. I am unable to get into T.38 mode, T.30 used, successful fax. Note that zrtp is disabled for fax calls, due to T38 udpl (not rtp media) incompatibility Thanks Brian West!: “T.38 Fax takes place over UDPTL, There for it can NOT be encrypted as there was never really a standard for doing so.” Details (both FS’s): SIP Provider: <http://freephoneline.ca/> freephoneline.ca (claims T38 capable) freeswitch - 1.4.18 x86_64 Topology: FS#1: <http://rossco.org/> rossco.org, using FusionPBX web GUI to send fax FS#2: <http://rossco.duckdns.org/> rossco.duckdns.org, using spandsp extension to receive fax (spandsp txfax, x1020)FS#1 -> cloud -> FS#2(spandsp rxfax, x9000) Key variables for fax sender (FS#1), during call: $domain= <http://rossco.org/> rossco.org Spandsp Fax extension: 1020 t38_passthru = false zrtp_secure_media = false fax_enable_t38 = true fax_enable_t38_request = true fax_use_ecm = off inbound-late-negotiation = true ignore_early_media = false Key variables for fax receiver (FS#2), during call: $domain= <http://rossco.duckdns.org/> rossco.duckdns.org Spandsp Fax extension: 9000 t38_passthru = false zrtp_secure_media = false fax_enable_t38 = true fax_enable_t38_request = true fax_use_ecm = off inbound-late-negotiation = true ignore_early_media = false Full Logs w/siptrace: Sender( <http://rossco.org/> rossco.org): <https://pastebin.freeswitch.org/24115> https://pastebin.freeswitch.org/24115 Receiver( <http://rossco.duckdns.org/> rossco.duckdns.org): <https://pastebin.freeswitch.org/24116> https://pastebin.freeswitch.org/24116 Note that the SDP’s are correct for T38: 590fc4c4-3035-438e-a4c7-4a9d8e51ee42 v=0 590fc4c4-3035-438e-a4c7-4a9d8e51ee42 o=FreeSWITCH 1428750600 1428750602 IN IP4 198.48.238.130 590fc4c4-3035-438e-a4c7-4a9d8e51ee42 s=FreeSWITCH 590fc4c4-3035-438e-a4c7-4a9d8e51ee42 c=IN IP4 198.48.238.130 590fc4c4-3035-438e-a4c7-4a9d8e51ee42 t=0 0 590fc4c4-3035-438e-a4c7-4a9d8e51ee42 m=image 16448 udptl t38 590fc4c4-3035-438e-a4c7-4a9d8e51ee42 a=T38FaxVersion:0 590fc4c4-3035-438e-a4c7-4a9d8e51ee42 a=T38MaxBitRate:14400 590fc4c4-3035-438e-a4c7-4a9d8e51ee42 a=T38FaxFillBitRemoval 590fc4c4-3035-438e-a4c7-4a9d8e51ee42 a=T38FaxRateManagement:transferredTCF 590fc4c4-3035-438e-a4c7-4a9d8e51ee42 a=T38FaxMaxBuffer:2000 590fc4c4-3035-438e-a4c7-4a9d8e51ee42 a=T38FaxMaxDatagram:400 590fc4c4-3035-438e-a4c7-4a9d8e51ee42 a=T38FaxUdpEC:t38UDPRedundancy Questions: 1 - According to my interpretation of logs, T38 is not negotiated, despite T38 SDP’s 2 - What am I missing? Thanks; Bill Ross _________________________________________________________________________ Professional FreeSWITCH Consulting Services: <mailto:consulting@freeswitch.org> consulting@freeswitch.org <http://www.freeswitchsolutions.com/> http://www.freeswitchsolutions.com Official FreeSWITCH Sites <http://www.freeswitch.org/> http://www.freeswitch.org <http://confluence.freeswitch.org/> http://confluence.freeswitch.org <http://www.cluecon.com/> http://www.cluecon.com FreeSWITCH-users mailing list <mailto:FreeSWITCH-users@lists.freeswitch.org> FreeSWITCH-users@lists.freeswitch.org <http://lists.freeswitch.org/mailman/listinfo/freeswitch-users> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http:// <http://lists.freeswitch.org/mailman/options/freeswitch-users> lists.freeswitch.org/mailman/options/freeswitch-users <http://www.freeswitch.org/> http://www.freeswitch.org
participants (2)
-
Bill Ross
-
Michael Jerris