T.38 gateway and peer/self
Hello, we have the following screnario * The caller, a local fax machine (Fax, ATA and Freeswitch) with T.38, is behind a slow line so therefore T.38 is needed here * a central Freeswitch fax server serves as a central gateway to the SIP provider * the SIP provider sometimes reinvites T.38 and sometimes not. * In case, the SIP provider does NOT answer with T.38, the central Freeswitch fax server shall act as a T.38 gateway and transcode between local fax (T.38) and SIP provider (T.30) * In case, the SIP provider does answer with T.38, the central Freeswitch fax server shall pass T.38 to the local fax ,machine (T.38) How we set this up * according to the wiki we have a dialplan as follows: (this is what CLI shows) Dialplan: sofia/internalvpn2/49274xxxxx@10.7.0.1 Action set(fax_enable_t38=true) Dialplan: sofia/internalvpn2/49274xxxxx@10.7.0.1 Action set(fax_enable_t38_request=true) Dialplan: sofia/internalvpn2/49274xxxxx@10.7.0.1 Action set(execute_on_answer=t38_gateway self) Dialplan: sofia/internalvpn2/49274xxxxx@10.7.0.1 Action ring_ready() Dialplan: sofia/internalvpn2/49274xxxxx@10.7.0.1 Action bridge(sofia/gateway/sip.provider.com/xxxxxxxxxxxxxxx@sip.provider.com) In all profiles, we have <param name="t38-passthru" value="true"/> In case, the SIP provider does NOT answer with T.38, it works. The caller's side is reinvited with T.38, the SIP provider side is T.30 What the problem is: When the SIP provider' side IS answering with T.38, then (sometimes, when I send it via cli from the local freeswitch near the sending fax machine, it works) * caller initiates a call * call is bridged to the SIP provider' side * we receive a T.38 Reinvite from the SIP provider' side * Freeswitch sends Trying back to the the SIP provider' side * Freeswitch logs: set(execute_on_answer=t38_gateway self) * Freeswitch sends a T.38 Reinvite to the caller, establishes T.38 on this side. * But the T.38 Reinvite from the SIP provider' side is not answerered * So the SIP provider' sidehangs up after 10 sec of timeout. What are we doing wrong here? Is it possible to act as a t.38 passthrough router and a T.38 gateway in the same dialplan? -- With kind regards Peter Steinbach Telefaks Services GmbH mailto:lists (att) telefaks.de Internet: www.telefaks.de
What revision of FreeSWITCH are you on? These behaviors have been solidified in 1.6.15, Sadly MOST of the details of how it all works is locked up in my head, I've just not had the time to write it all down and update the documentation. Can you outline all the scenarios you need to cover and if you have the ability know ahead of time which one needs to apply? /b On Thu, Feb 23, 2017 at 8:23 AM, Peter Steinbach <lists@telefaks.de> wrote:
Hello,
we have the following screnario
- The caller, a local fax machine (Fax, ATA and Freeswitch) with T.38, is behind a slow line so therefore T.38 is needed here - a central Freeswitch fax server serves as a central gateway to the SIP provider - the SIP provider sometimes reinvites T.38 and sometimes not. - In case, the SIP provider does NOT answer with T.38, the central Freeswitch fax server shall act as a T.38 gateway and transcode between local fax (T.38) and SIP provider (T.30) - In case, the SIP provider does answer with T.38, the central Freeswitch fax server shall pass T.38 to the local fax ,machine (T.38)
How we set this up
- according to the wiki we have a dialplan as follows: (this is what CLI shows)
Dialplan: sofia/internalvpn2/49274xxxxx@10.7.0.1 Action set(fax_enable_t38=true) Dialplan: sofia/internalvpn2/49274xxxxx@10.7.0.1 Action set(fax_enable_t38_request=true) Dialplan: sofia/internalvpn2/49274xxxxx@10.7.0.1 Action set(execute_on_answer=t38_gateway self) Dialplan: sofia/internalvpn2/49274xxxxx@10.7.0.1 Action ring_ready() Dialplan: sofia/internalvpn2/49274xxxxx@10.7.0.1 Action bridge( sofia/gateway/sip.provider.com/xxxxxxxxxxxxxxx@sip.provider.com)
In all profiles, we have <param name="t38-passthru" value="true"/>
In case, the SIP provider does NOT answer with T.38, it works. The caller's side is reinvited with T.38, the SIP provider side is T.30
What the problem is: When the SIP provider' side IS answering with T.38, then (sometimes, when I send it via cli from the local freeswitch near the sending fax machine, it works)
- caller initiates a call - call is bridged to the SIP provider' side - we receive a T.38 Reinvite from the SIP provider' side - Freeswitch sends Trying back to the the SIP provider' side - Freeswitch logs: set(execute_on_answer=t38_gateway self) - Freeswitch sends a T.38 Reinvite to the caller, establishes T.38 on this side. - But the T.38 Reinvite from the SIP provider' side is not answerered - So the SIP provider' sidehangs up after 10 sec of timeout.
What are we doing wrong here? Is it possible to act as a t.38 passthrough router and a T.38 gateway in the same dialplan?
-- With kind regards Peter Steinbach
Telefaks Services GmbHmailto:lists <lists> (att) telefaks.de Internet: www.telefaks.de
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
Official FreeSWITCH Sites http://www.freeswitch.org http://confluence.freeswitch.org http://www.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 http://www.freeswitch.org
-- *Brian West* brian@freeswitch.org *Twitter: @FreeSWITCH , @briankwest* http://www.freeswitchbook.com http://www.freeswitchcookbook.com Allison prompts for FreeSWITCH: *https://www.gofundme.com/allison-prompts-for-freeswitch* <https://www.gofundme.com/allison-prompts-for-freeswitch> Wish to schedule a meeting? http://app.timebridge.com/#/meet/freeswitch Got Bugs? Report them here <https://freeswitch.org/jira>! | Reddit: /r/freeswitch <https://www.reddit.com/r/freeswitch> *T:*+19184209001 | *F:*+19184209002 | *M:*+1918424WEST (9378) *Skype:*briankwest
Hello Brian, this Version of Freeswitch is from 09-Feb-2016. So I think, we should update. We need to cover 2 scenarios * send fax to SIP Provider(b leg) and have T.38 Re-invite from SIP Provider and pass it to a-leg * send fax to SIP Provider(b leg), do NOT receive T.38 Re-invite from SIP Provider and then do T.38 Gateway in FS. And no: We cannot foresee, whether the SIp provider will do T.38 and not. Here in Germany, the main incumbant PSTN provider did not implement T.38, so it depends on the target number and actual route, if this will be T.38 or not. A call to a certain number can be T.38 today and tomorrow it will be T.30 only, as some peering partner changed the routes in the meantime. Best regards Peter On 02/23/17 20:38, Brian West wrote:
What revision of FreeSWITCH are you on? These behaviors have been solidified in 1.6.15, Sadly MOST of the details of how it all works is locked up in my head, I've just not had the time to write it all down and update the documentation. Can you outline all the scenarios you need to cover and if you have the ability know ahead of time which one needs to apply?
/b
On Thu, Feb 23, 2017 at 8:23 AM, Peter Steinbach <lists@telefaks.de <mailto:lists@telefaks.de>> wrote:
Hello,
we have the following screnario
* The caller, a local fax machine (Fax, ATA and Freeswitch) with T.38, is behind a slow line so therefore T.38 is needed here * a central Freeswitch fax server serves as a central gateway to the SIP provider * the SIP provider sometimes reinvites T.38 and sometimes not. * In case, the SIP provider does NOT answer with T.38, the central Freeswitch fax server shall act as a T.38 gateway and transcode between local fax (T.38) and SIP provider (T.30) * In case, the SIP provider does answer with T.38, the central Freeswitch fax server shall pass T.38 to the local fax ,machine (T.38)
How we set this up
* according to the wiki we have a dialplan as follows: (this is what CLI shows)
Dialplan: sofia/internalvpn2/49274xxxxx@10.7.0.1 <mailto:sofia/internalvpn2/49274xxxxx@10.7.0.1> Action set(fax_enable_t38=true) Dialplan: sofia/internalvpn2/49274xxxxx@10.7.0.1 <mailto:sofia/internalvpn2/49274xxxxx@10.7.0.1> Action set(fax_enable_t38_request=true) Dialplan: sofia/internalvpn2/49274xxxxx@10.7.0.1 <mailto:sofia/internalvpn2/49274xxxxx@10.7.0.1> Action set(execute_on_answer=t38_gateway self) Dialplan: sofia/internalvpn2/49274xxxxx@10.7.0.1 <mailto:sofia/internalvpn2/49274xxxxx@10.7.0.1> Action ring_ready() Dialplan: sofia/internalvpn2/49274xxxxx@10.7.0.1 <mailto:sofia/internalvpn2/49274xxxxx@10.7.0.1> Action bridge(sofia/gateway/sip.provider.com/xxxxxxxxxxxxxxx@sip.provider.com <mailto:sofia/gateway/sip.provider.com/xxxxxxxxxxxxxxx@sip.provider.com>)
In all profiles, we have <param name="t38-passthru" value="true"/>
In case, the SIP provider does NOT answer with T.38, it works. The caller's side is reinvited with T.38, the SIP provider side is T.30
What the problem is: When the SIP provider' side IS answering with T.38, then (sometimes, when I send it via cli from the local freeswitch near the sending fax machine, it works)
* caller initiates a call * call is bridged to the SIP provider' side * we receive a T.38 Reinvite from the SIP provider' side * Freeswitch sends Trying back to the the SIP provider' side * Freeswitch logs: set(execute_on_answer=t38_gateway self) * Freeswitch sends a T.38 Reinvite to the caller, establishes T.38 on this side. * But the T.38 Reinvite from the SIP provider' side is not answerered * So the SIP provider' sidehangs up after 10 sec of timeout.
What are we doing wrong here? Is it possible to act as a t.38 passthrough router and a T.38 gateway in the same dialplan?
-- With kind regards Peter Steinbach
Telefaks Services GmbH mailto:lists (att) telefaks.de <http://telefaks.de> Internet: www.telefaks.de <http://www.telefaks.de>
_________________________________________________________________________ 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://confluence.freeswitch.org <http://confluence.freeswitch.org> 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
--
*/Brian West/* brian@freeswitch.org <mailto:brian@freeswitch.org>
*/Twitter: @FreeSWITCH , @briankwest/*
http://www.freeswitchbook.com http://www.freeswitchcookbook.com
Allison prompts for FreeSWITCH:
*https://www.gofundme.com/allison-prompts-for-freeswitch*
Wish to schedule a meeting?
http://app.timebridge.com/#/meet/freeswitch
Got Bugs? Report them here <https://freeswitch.org/jira>! | Reddit: /r/freeswitch <https://www.reddit.com/r/freeswitch>
*T:*+19184209001 | *F:*+19184209002 | *M:*+1918424WEST (9378) *Skype:*briankwest
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
Official FreeSWITCH Sites http://www.freeswitch.org http://confluence.freeswitch.org http://www.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 http://www.freeswitch.org
-- With kind regards Peter Steinbach Telefaks Services GmbH mailto:lists (att) telefaks.de Internet: www.telefaks.de
Hi Brian/Peter Sorry to jump in on your thread! Brian I have a use case that I'm having some trouble with - what do I need to do in this scenario: Carrier sends call to FS (g711) FS sends call to endpoint (g711) endpoint answers then quickly sends a T38 (RE)INVITE back to FS So in this case we would like to accept this customer (re)invite - do T38 with the customer endpoint and transcode that to 711 back to the A leg with the carrier. I've tried every combination of dialplan / parameters from the T38 bits at https://freeswitch.org/confluence/display/FREESWITCH/mod_spandsp and they mostly result in FS sending a not acceptable here back to the T38 invite. Thanks, Brian On Fri, Feb 24, 2017 at 7:52 AM, Peter Steinbach <lists@telefaks.de> wrote:
Hello Brian,
this Version of Freeswitch is from 09-Feb-2016. So I think, we should update.
We need to cover 2 scenarios
- send fax to SIP Provider(b leg) and have T.38 Re-invite from SIP Provider and pass it to a-leg - send fax to SIP Provider(b leg), do NOT receive T.38 Re-invite from SIP Provider and then do T.38 Gateway in FS.
And no: We cannot foresee, whether the SIp provider will do T.38 and not. Here in Germany, the main incumbant PSTN provider did not implement T.38, so it depends on the target number and actual route, if this will be T.38 or not. A call to a certain number can be T.38 today and tomorrow it will be T.30 only, as some peering partner changed the routes in the meantime.
Best regards Peter
On 02/23/17 20:38, Brian West wrote:
What revision of FreeSWITCH are you on? These behaviors have been solidified in 1.6.15, Sadly MOST of the details of how it all works is locked up in my head, I've just not had the time to write it all down and update the documentation. Can you outline all the scenarios you need to cover and if you have the ability know ahead of time which one needs to apply?
/b
On Thu, Feb 23, 2017 at 8:23 AM, Peter Steinbach <lists@telefaks.de> wrote:
Hello,
we have the following screnario
- The caller, a local fax machine (Fax, ATA and Freeswitch) with T.38, is behind a slow line so therefore T.38 is needed here - a central Freeswitch fax server serves as a central gateway to the SIP provider - the SIP provider sometimes reinvites T.38 and sometimes not. - In case, the SIP provider does NOT answer with T.38, the central Freeswitch fax server shall act as a T.38 gateway and transcode between local fax (T.38) and SIP provider (T.30) - In case, the SIP provider does answer with T.38, the central Freeswitch fax server shall pass T.38 to the local fax ,machine (T.38)
How we set this up
- according to the wiki we have a dialplan as follows: (this is what CLI shows)
Dialplan: sofia/internalvpn2/49274xxxxx@10.7.0.1 Action set(fax_enable_t38=true) Dialplan: sofia/internalvpn2/49274xxxxx@10.7.0.1 Action set(fax_enable_t38_request=true) Dialplan: sofia/internalvpn2/49274xxxxx@10.7.0.1 Action set(execute_on_answer=t38_gateway self) Dialplan: sofia/internalvpn2/49274xxxxx@10.7.0.1 Action ring_ready() Dialplan: sofia/internalvpn2/49274xxxxx@10.7.0.1 Action bridge( sofia/gateway/sip.provider.com/xxxxxxxxxxxxxxx@sip.provider.com)
In all profiles, we have <param name="t38-passthru" value="true"/>
In case, the SIP provider does NOT answer with T.38, it works. The caller's side is reinvited with T.38, the SIP provider side is T.30
What the problem is: When the SIP provider' side IS answering with T.38, then (sometimes, when I send it via cli from the local freeswitch near the sending fax machine, it works)
- caller initiates a call - call is bridged to the SIP provider' side - we receive a T.38 Reinvite from the SIP provider' side - Freeswitch sends Trying back to the the SIP provider' side - Freeswitch logs: set(execute_on_answer=t38_gateway self) - Freeswitch sends a T.38 Reinvite to the caller, establishes T.38 on this side. - But the T.38 Reinvite from the SIP provider' side is not answerered - So the SIP provider' sidehangs up after 10 sec of timeout.
What are we doing wrong here? Is it possible to act as a t.38 passthrough router and a T.38 gateway in the same dialplan?
-- With kind regards Peter Steinbach
Telefaks Services GmbHmailto:lists <lists> (att) telefaks.de Internet: www.telefaks.de
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
Official FreeSWITCH Sites http://www.freeswitch.org http://confluence.freeswitch.org http://www.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 http://www.freeswitch.org
--
*Brian West* brian@freeswitch.org
*Twitter: @FreeSWITCH , @briankwest*
http://www.freeswitchbook.com http://www.freeswitchcookbook.com
Allison prompts for FreeSWITCH:
*https://www.gofundme.com/allison-prompts-for-freeswitch* <https://www.gofundme.com/allison-prompts-for-freeswitch>
Wish to schedule a meeting?
http://app.timebridge.com/#/meet/freeswitch
Got Bugs? Report them here <https://freeswitch.org/jira>! | Reddit: /r/freeswitch <https://www.reddit.com/r/freeswitch>
*T:*+19184209001 <(918)%20420-9001> | *F:*+19184209002 <(918)%20420-9002> | *M:*+1918424WEST (9378) *Skype:*briankwest
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.orghttp://www.freeswitchsolutions.com
Official FreeSWITCH Siteshttp://www.freeswitch.orghttp://confluence.freeswitch.orghttp://www.cluecon....
FreeSWITCH-users mailing listFreeSWITCH-users@lists.freeswitch.orghttp://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-usershttp://www.frees...
-- With kind regards Peter Steinbach
Telefaks Services GmbHmailto:lists <lists> (att) telefaks.de Internet: www.telefaks.de
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
Official FreeSWITCH Sites http://www.freeswitch.org http://confluence.freeswitch.org http://www.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 http://www.freeswitch.org
Hello Brian, I just updated to latest GIT. Dialplan ist still Dialplan: sofia/internalvpn2/492927aaaaaa@10.7.0.1 Action set(fax_enable_t38=true) Dialplan: sofia/internalvpn2/492927aaaaaa@10.7.0.1 Action set(fax_enable_t38_request=true) Dialplan: sofia/internalvpn2/492927aaaaaa@10.7.0.1 Action set(execute_on_answer=t38_gateway self) Dialplan: sofia/internalvpn2/492927aaaaaa@10.7.0.1 Action ring_ready() Dialplan: sofia/internalvpn2/492927aaaaaa@10.7.0.1 Action bridge(sofia/gateway/sip.provider.com/4940bbbbbbbbbbbbbbb@sip.provider.com) However the behavour changed now 2017-02-24 13:50:18.913016 [NOTICE] switch_ivr_originate.c:3633 Channel [sofia/internalvpn2/492927aaaaaa@10.7.0.1] has been answered 2017-02-24 13:50:18.913016 [DEBUG] sofia.c:7241 Channel sofia/internalvpn2/492927aaaaaa@10.7.0.1 entering state [completed][200] *EXECUTE sofia/internalvpn2/492927aaaaaa@10.7.0.1 t38_gateway(peer)* 2017-02-24 13:50:18.913016 [DEBUG] switch_core_media_bug.c:841 Attaching BUG to sofia/internalvpn2/492927aaaaaa@10.7.0.1 2017-02-24 13:50:18.913016 [DEBUG] switch_channel.c:3780 (sofia/internalvpn2/492927aaaaaa@10.7.0.1) Callstate Change RINGING -> ACTIVE 2017-02-24 13:50:18.913016 [DEBUG] switch_ivr_originate.c:3691 Originate Resulted in Success: [sofia/external/4940bbbbbbbbbbbbbbb@sip.provider.com] 2017-02-24 13:50:18.913016 [DEBUG] switch_ivr_bridge.c:1696 (sofia/external/4940bbbbbbbbbbbbbbb@sip.provider.com) State Change CS_CONSUME_MEDIA -> CS_EXCHANGE_MEDIA 2017-02-24 13:50:18.913016 [DEBUG] switch_core_state_machine.c:584 (sofia/external/4940bbbbbbbbbbbbbbb@sip.provider.com) Running State Change CS_EXCHANGE_MEDIA (Cur 2 Tot 10) 2017-02-24 13:50:18.913016 [DEBUG] switch_core_state_machine.c:653 (sofia/external/4940bbbbbbbbbbbbbbb@sip.provider.com) State EXCHANGE_MEDIA 2017-02-24 13:50:18.913016 [DEBUG] mod_sofia.c:645 SOFIA EXCHANGE_MEDIA 2017-02-24 13:50:18.953025 [DEBUG] sofia.c:7241 Channel sofia/internalvpn2/492927aaaaaa@10.7.0.1 entering state [ready][200] 2017-02-24 13:50:18.953025 [DEBUG] switch_rtp.c:7021 Correct audio ip/port confirmed. 2017-02-24 13:50:19.333126 [DEBUG] switch_rtp.c:7021 Correct audio ip/port confirmed. 2017-02-24 13:50:19.333126 [DEBUG] switch_core_io.c:448 Setting BUG Codec PCMA:8 2017-02-24 13:50:26.013047 [DEBUG] sofia.c:7241 Channel sofia/external/4940bbbbbbbbbbbbbbb@sip.provider.com entering state [received][100] 2017-02-24 13:50:26.013047 [DEBUG] sofia.c:7251 Remote SDP: v=0 o=HuaweiSoftX3000 1487923856 1487923858 IN IP4 185.39.xx.yy s=HuaweiSoftX3000 c=IN IP4 185.39.xx.yy t=0 0 m=image 16762 udptl t38 a=T38FaxVersion:0 a=T38MaxBitRate:14400 a=T38FaxRateManagement:transferredTCF a=T38FaxMaxBuffer:500 a=T38FaxMaxDatagram:500 a=T38FaxUdpEC:t38UDPRedundancy *2017-02-24 13:50:26.013047 [DEBUG] switch_core_media.c:4634 sofia/external/4940bbbbbbbbbbbbbbb@sip.provider.com T38 REFUSE on request* 2017-02-24 13:50:26.013047 [DEBUG] sofia.c:8152 Reinvite resulted in codec negotiation failure. *2017-02-24 13:50:26.033201 [DEBUG] sofia.c:7234 Channel sofia/external/4940bbbbbbbbbbbbbbb@sip.provider.com skipping state [ready][488]* *2017-02-24 13:50:31.993164 [DEBUG] mod_spandsp_fax.c:2212 Fax Tone Detected. [peer][]* *2017-02-24 13:50:31.993164 [DEBUG] mod_spandsp_fax.c:2080 sofia/internalvpn2/492927aaaaaa@10.7.0.1 starting gateway mode to sofia/external/4940bbbbbbbbbbbbbbb@sip.provider.com* 2017-02-24 13:50:31.993164 [DEBUG] mod_spandsp_fax.c:2098 (sofia/internalvpn2/492927aaaaaa@10.7.0.1) State Change CS_EXECUTE -> CS_RESET 2017-02-24 13:50:31.993164 [DEBUG] mod_spandsp_fax.c:2101 (sofia/external/4940bbbbbbbbbbbbbbb@sip.provider.com) State Change CS_EXCHANGE_MEDIA -> CS_RESET 2017-02-24 13:50:31.993164 [DEBUG] switch_core_media_bug.c:1208 Removing BUG from sofia/internalvpn2/492927aaaaaa@10.7.0.1 2017-02-24 13:50:31.993164 [DEBUG] switch_ivr_bridge.c:792 sofia/external/4940bbbbbbbbbbbbbbb@sip.provider.com ending bridge by request from write function In this case the sip provider comes back with T.38 reinvite and Freeswitch refuses it. As you mentioned that there are further settings and variables (I see e.g. "fax_t38_tx_reinvite_packet_count" in the release notes), I am wondering how I will neeed to set this up in order to have in one single dialplan: * send fax to SIP Provider(b leg) and have T.38 Re-invite from SIP Provider and pass it to a-leg * send fax to SIP Provider(b leg), do NOT receive T.38 Re-invite from SIP Provider and then do T.38 Gateway in FS. Best regards Peter On 02/24/17 08:52, Peter Steinbach wrote:
Hello Brian,
this Version of Freeswitch is from 09-Feb-2016. So I think, we should update.
We need to cover 2 scenarios
* send fax to SIP Provider(b leg) and have T.38 Re-invite from SIP Provider and pass it to a-leg * send fax to SIP Provider(b leg), do NOT receive T.38 Re-invite from SIP Provider and then do T.38 Gateway in FS.
And no: We cannot foresee, whether the SIp provider will do T.38 and not. Here in Germany, the main incumbant PSTN provider did not implement T.38, so it depends on the target number and actual route, if this will be T.38 or not. A call to a certain number can be T.38 today and tomorrow it will be T.30 only, as some peering partner changed the routes in the meantime.
Best regards Peter
On 02/23/17 20:38, Brian West wrote:
What revision of FreeSWITCH are you on? These behaviors have been solidified in 1.6.15, Sadly MOST of the details of how it all works is locked up in my head, I've just not had the time to write it all down and update the documentation. Can you outline all the scenarios you need to cover and if you have the ability know ahead of time which one needs to apply?
/b
On Thu, Feb 23, 2017 at 8:23 AM, Peter Steinbach <lists@telefaks.de <mailto:lists@telefaks.de>> wrote:
Hello,
we have the following screnario
* The caller, a local fax machine (Fax, ATA and Freeswitch) with T.38, is behind a slow line so therefore T.38 is needed here * a central Freeswitch fax server serves as a central gateway to the SIP provider * the SIP provider sometimes reinvites T.38 and sometimes not. * In case, the SIP provider does NOT answer with T.38, the central Freeswitch fax server shall act as a T.38 gateway and transcode between local fax (T.38) and SIP provider (T.30) * In case, the SIP provider does answer with T.38, the central Freeswitch fax server shall pass T.38 to the local fax ,machine (T.38)
How we set this up
* according to the wiki we have a dialplan as follows: (this is what CLI shows)
Dialplan: sofia/internalvpn2/49274xxxxx@10.7.0.1 <mailto:sofia/internalvpn2/49274xxxxx@10.7.0.1> Action set(fax_enable_t38=true) Dialplan: sofia/internalvpn2/49274xxxxx@10.7.0.1 <mailto:sofia/internalvpn2/49274xxxxx@10.7.0.1> Action set(fax_enable_t38_request=true) Dialplan: sofia/internalvpn2/49274xxxxx@10.7.0.1 <mailto:sofia/internalvpn2/49274xxxxx@10.7.0.1> Action set(execute_on_answer=t38_gateway self) Dialplan: sofia/internalvpn2/49274xxxxx@10.7.0.1 <mailto:sofia/internalvpn2/49274xxxxx@10.7.0.1> Action ring_ready() Dialplan: sofia/internalvpn2/49274xxxxx@10.7.0.1 <mailto:sofia/internalvpn2/49274xxxxx@10.7.0.1> Action bridge(sofia/gateway/sip.provider.com/xxxxxxxxxxxxxxx@sip.provider.com <mailto:sofia/gateway/sip.provider.com/xxxxxxxxxxxxxxx@sip.provider.com>)
In all profiles, we have <param name="t38-passthru" value="true"/>
In case, the SIP provider does NOT answer with T.38, it works. The caller's side is reinvited with T.38, the SIP provider side is T.30
What the problem is: When the SIP provider' side IS answering with T.38, then (sometimes, when I send it via cli from the local freeswitch near the sending fax machine, it works)
* caller initiates a call * call is bridged to the SIP provider' side * we receive a T.38 Reinvite from the SIP provider' side * Freeswitch sends Trying back to the the SIP provider' side * Freeswitch logs: set(execute_on_answer=t38_gateway self) * Freeswitch sends a T.38 Reinvite to the caller, establishes T.38 on this side. * But the T.38 Reinvite from the SIP provider' side is not answerered * So the SIP provider' sidehangs up after 10 sec of timeout.
What are we doing wrong here? Is it possible to act as a t.38 passthrough router and a T.38 gateway in the same dialplan?
-- With kind regards Peter Steinbach
Telefaks Services GmbH mailto:lists (att) telefaks.de <http://telefaks.de> Internet: www.telefaks.de <http://www.telefaks.de>
_________________________________________________________________________ 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://confluence.freeswitch.org <http://confluence.freeswitch.org> 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
--
*/Brian West/* brian@freeswitch.org <mailto:brian@freeswitch.org>
*/Twitter: @FreeSWITCH , @briankwest/*
http://www.freeswitchbook.com http://www.freeswitchcookbook.com
Allison prompts for FreeSWITCH:
*https://www.gofundme.com/allison-prompts-for-freeswitch*
Wish to schedule a meeting?
http://app.timebridge.com/#/meet/freeswitch
Got Bugs? Report them here <https://freeswitch.org/jira>! | Reddit: /r/freeswitch <https://www.reddit.com/r/freeswitch>
*T:*+19184209001 | *F:*+19184209002 | *M:*+1918424WEST (9378) *Skype:*briankwest
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
Official FreeSWITCH Sites http://www.freeswitch.org http://confluence.freeswitch.org http://www.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 http://www.freeswitch.org
-- With kind regards Peter Steinbach
Telefaks Services GmbH mailto:lists (att) telefaks.de Internet: www.telefaks.de
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
Official FreeSWITCH Sites http://www.freeswitch.org http://confluence.freeswitch.org http://www.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 http://www.freeswitch.org
-- With kind regards Peter Steinbach Telefaks Services GmbH mailto:lists (att) telefaks.de Internet: www.telefaks.de
I finally found a solution, for those who are interested. * I switched back to old Freeswitch from Feb 2016, as new FS always answered with 488 on T.38 reinvite from the B-Leg * Then I implemented the following (coding outside of FS with XML-Curl) o When call is done with T.38 on boths legs, do not anything special, just use a minimum dialplan o if B-leg does not answer with T.38, this normally fails in my environment. I then store a Value NOT38 to the dialled number for 1/2 hour in a cache + when then the fax machine is retrying the same call, I lookup the cache and return another dialplan with T38 gateway (self) enabled That way, pure T.38 calls work nicely, and calls with T.39 on the B-leg work on the second try. Hope this helps. At last here in Germany, we have to find some workarounds, as fax implementation on some carrier's side (to say the positive) does not improve. Best regards Peter On 02/24/17 14:29, Peter Steinbach wrote:
Hello Brian,
I just updated to latest GIT. Dialplan ist still
Dialplan: sofia/internalvpn2/492927aaaaaa@10.7.0.1 Action set(fax_enable_t38=true) Dialplan: sofia/internalvpn2/492927aaaaaa@10.7.0.1 Action set(fax_enable_t38_request=true) Dialplan: sofia/internalvpn2/492927aaaaaa@10.7.0.1 Action set(execute_on_answer=t38_gateway self) Dialplan: sofia/internalvpn2/492927aaaaaa@10.7.0.1 Action ring_ready() Dialplan: sofia/internalvpn2/492927aaaaaa@10.7.0.1 Action bridge(sofia/gateway/sip.provider.com/4940bbbbbbbbbbbbbbb@sip.provider.com)
However the behavour changed now 2017-02-24 13:50:18.913016 [NOTICE] switch_ivr_originate.c:3633 Channel [sofia/internalvpn2/492927aaaaaa@10.7.0.1] has been answered 2017-02-24 13:50:18.913016 [DEBUG] sofia.c:7241 Channel sofia/internalvpn2/492927aaaaaa@10.7.0.1 entering state [completed][200] *EXECUTE sofia/internalvpn2/492927aaaaaa@10.7.0.1 t38_gateway(peer)* 2017-02-24 13:50:18.913016 [DEBUG] switch_core_media_bug.c:841 Attaching BUG to sofia/internalvpn2/492927aaaaaa@10.7.0.1 2017-02-24 13:50:18.913016 [DEBUG] switch_channel.c:3780 (sofia/internalvpn2/492927aaaaaa@10.7.0.1) Callstate Change RINGING -> ACTIVE 2017-02-24 13:50:18.913016 [DEBUG] switch_ivr_originate.c:3691 Originate Resulted in Success: [sofia/external/4940bbbbbbbbbbbbbbb@sip.provider.com] 2017-02-24 13:50:18.913016 [DEBUG] switch_ivr_bridge.c:1696 (sofia/external/4940bbbbbbbbbbbbbbb@sip.provider.com) State Change CS_CONSUME_MEDIA -> CS_EXCHANGE_MEDIA 2017-02-24 13:50:18.913016 [DEBUG] switch_core_state_machine.c:584 (sofia/external/4940bbbbbbbbbbbbbbb@sip.provider.com) Running State Change CS_EXCHANGE_MEDIA (Cur 2 Tot 10) 2017-02-24 13:50:18.913016 [DEBUG] switch_core_state_machine.c:653 (sofia/external/4940bbbbbbbbbbbbbbb@sip.provider.com) State EXCHANGE_MEDIA 2017-02-24 13:50:18.913016 [DEBUG] mod_sofia.c:645 SOFIA EXCHANGE_MEDIA 2017-02-24 13:50:18.953025 [DEBUG] sofia.c:7241 Channel sofia/internalvpn2/492927aaaaaa@10.7.0.1 entering state [ready][200] 2017-02-24 13:50:18.953025 [DEBUG] switch_rtp.c:7021 Correct audio ip/port confirmed. 2017-02-24 13:50:19.333126 [DEBUG] switch_rtp.c:7021 Correct audio ip/port confirmed. 2017-02-24 13:50:19.333126 [DEBUG] switch_core_io.c:448 Setting BUG Codec PCMA:8 2017-02-24 13:50:26.013047 [DEBUG] sofia.c:7241 Channel sofia/external/4940bbbbbbbbbbbbbbb@sip.provider.com entering state [received][100] 2017-02-24 13:50:26.013047 [DEBUG] sofia.c:7251 Remote SDP: v=0 o=HuaweiSoftX3000 1487923856 1487923858 IN IP4 185.39.xx.yy s=HuaweiSoftX3000 c=IN IP4 185.39.xx.yy t=0 0 m=image 16762 udptl t38 a=T38FaxVersion:0 a=T38MaxBitRate:14400 a=T38FaxRateManagement:transferredTCF a=T38FaxMaxBuffer:500 a=T38FaxMaxDatagram:500 a=T38FaxUdpEC:t38UDPRedundancy
*2017-02-24 13:50:26.013047 [DEBUG] switch_core_media.c:4634 sofia/external/4940bbbbbbbbbbbbbbb@sip.provider.com T38 REFUSE on request* 2017-02-24 13:50:26.013047 [DEBUG] sofia.c:8152 Reinvite resulted in codec negotiation failure. *2017-02-24 13:50:26.033201 [DEBUG] sofia.c:7234 Channel sofia/external/4940bbbbbbbbbbbbbbb@sip.provider.com skipping state [ready][488]* *2017-02-24 13:50:31.993164 [DEBUG] mod_spandsp_fax.c:2212 Fax Tone Detected. [peer][]* *2017-02-24 13:50:31.993164 [DEBUG] mod_spandsp_fax.c:2080 sofia/internalvpn2/492927aaaaaa@10.7.0.1 starting gateway mode to sofia/external/4940bbbbbbbbbbbbbbb@sip.provider.com* 2017-02-24 13:50:31.993164 [DEBUG] mod_spandsp_fax.c:2098 (sofia/internalvpn2/492927aaaaaa@10.7.0.1) State Change CS_EXECUTE -> CS_RESET 2017-02-24 13:50:31.993164 [DEBUG] mod_spandsp_fax.c:2101 (sofia/external/4940bbbbbbbbbbbbbbb@sip.provider.com) State Change CS_EXCHANGE_MEDIA -> CS_RESET 2017-02-24 13:50:31.993164 [DEBUG] switch_core_media_bug.c:1208 Removing BUG from sofia/internalvpn2/492927aaaaaa@10.7.0.1 2017-02-24 13:50:31.993164 [DEBUG] switch_ivr_bridge.c:792 sofia/external/4940bbbbbbbbbbbbbbb@sip.provider.com ending bridge by request from write function
In this case the sip provider comes back with T.38 reinvite and Freeswitch refuses it.
As you mentioned that there are further settings and variables (I see e.g. "fax_t38_tx_reinvite_packet_count" in the release notes), I am wondering how I will neeed to set this up in order to have in one single dialplan:
* send fax to SIP Provider(b leg) and have T.38 Re-invite from SIP Provider and pass it to a-leg * send fax to SIP Provider(b leg), do NOT receive T.38 Re-invite from SIP Provider and then do T.38 Gateway in FS.
Best regards Peter
On 02/24/17 08:52, Peter Steinbach wrote:
Hello Brian,
this Version of Freeswitch is from 09-Feb-2016. So I think, we should update.
We need to cover 2 scenarios
* send fax to SIP Provider(b leg) and have T.38 Re-invite from SIP Provider and pass it to a-leg * send fax to SIP Provider(b leg), do NOT receive T.38 Re-invite from SIP Provider and then do T.38 Gateway in FS.
And no: We cannot foresee, whether the SIp provider will do T.38 and not. Here in Germany, the main incumbant PSTN provider did not implement T.38, so it depends on the target number and actual route, if this will be T.38 or not. A call to a certain number can be T.38 today and tomorrow it will be T.30 only, as some peering partner changed the routes in the meantime.
Best regards Peter
On 02/23/17 20:38, Brian West wrote:
What revision of FreeSWITCH are you on? These behaviors have been solidified in 1.6.15, Sadly MOST of the details of how it all works is locked up in my head, I've just not had the time to write it all down and update the documentation. Can you outline all the scenarios you need to cover and if you have the ability know ahead of time which one needs to apply?
/b
On Thu, Feb 23, 2017 at 8:23 AM, Peter Steinbach <lists@telefaks.de <mailto:lists@telefaks.de>> wrote:
Hello,
we have the following screnario
* The caller, a local fax machine (Fax, ATA and Freeswitch) with T.38, is behind a slow line so therefore T.38 is needed here * a central Freeswitch fax server serves as a central gateway to the SIP provider * the SIP provider sometimes reinvites T.38 and sometimes not. * In case, the SIP provider does NOT answer with T.38, the central Freeswitch fax server shall act as a T.38 gateway and transcode between local fax (T.38) and SIP provider (T.30) * In case, the SIP provider does answer with T.38, the central Freeswitch fax server shall pass T.38 to the local fax ,machine (T.38)
How we set this up
* according to the wiki we have a dialplan as follows: (this is what CLI shows)
Dialplan: sofia/internalvpn2/49274xxxxx@10.7.0.1 <mailto:sofia/internalvpn2/49274xxxxx@10.7.0.1> Action set(fax_enable_t38=true) Dialplan: sofia/internalvpn2/49274xxxxx@10.7.0.1 <mailto:sofia/internalvpn2/49274xxxxx@10.7.0.1> Action set(fax_enable_t38_request=true) Dialplan: sofia/internalvpn2/49274xxxxx@10.7.0.1 <mailto:sofia/internalvpn2/49274xxxxx@10.7.0.1> Action set(execute_on_answer=t38_gateway self) Dialplan: sofia/internalvpn2/49274xxxxx@10.7.0.1 <mailto:sofia/internalvpn2/49274xxxxx@10.7.0.1> Action ring_ready() Dialplan: sofia/internalvpn2/49274xxxxx@10.7.0.1 <mailto:sofia/internalvpn2/49274xxxxx@10.7.0.1> Action bridge(sofia/gateway/sip.provider.com/xxxxxxxxxxxxxxx@sip.provider.com <mailto:sofia/gateway/sip.provider.com/xxxxxxxxxxxxxxx@sip.provider.com>)
In all profiles, we have <param name="t38-passthru" value="true"/>
In case, the SIP provider does NOT answer with T.38, it works. The caller's side is reinvited with T.38, the SIP provider side is T.30
What the problem is: When the SIP provider' side IS answering with T.38, then (sometimes, when I send it via cli from the local freeswitch near the sending fax machine, it works)
* caller initiates a call * call is bridged to the SIP provider' side * we receive a T.38 Reinvite from the SIP provider' side * Freeswitch sends Trying back to the the SIP provider' side * Freeswitch logs: set(execute_on_answer=t38_gateway self) * Freeswitch sends a T.38 Reinvite to the caller, establishes T.38 on this side. * But the T.38 Reinvite from the SIP provider' side is not answerered * So the SIP provider' sidehangs up after 10 sec of timeout.
What are we doing wrong here? Is it possible to act as a t.38 passthrough router and a T.38 gateway in the same dialplan?
-- With kind regards Peter Steinbach
Telefaks Services GmbH mailto:lists (att) telefaks.de <http://telefaks.de> Internet: www.telefaks.de <http://www.telefaks.de>
_________________________________________________________________________ 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://confluence.freeswitch.org <http://confluence.freeswitch.org> 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
--
*/Brian West/* brian@freeswitch.org <mailto:brian@freeswitch.org>
*/Twitter: @FreeSWITCH , @briankwest/*
http://www.freeswitchbook.com http://www.freeswitchcookbook.com
Allison prompts for FreeSWITCH:
*https://www.gofundme.com/allison-prompts-for-freeswitch*
Wish to schedule a meeting?
http://app.timebridge.com/#/meet/freeswitch
Got Bugs? Report them here <https://freeswitch.org/jira>! | Reddit: /r/freeswitch <https://www.reddit.com/r/freeswitch>
*T:*+19184209001 | *F:*+19184209002 | *M:*+1918424WEST (9378) *Skype:*briankwest
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
Official FreeSWITCH Sites http://www.freeswitch.org http://confluence.freeswitch.org http://www.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 http://www.freeswitch.org
-- With kind regards Peter Steinbach
Telefaks Services GmbH mailto:lists (att) telefaks.de Internet: www.telefaks.de
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
Official FreeSWITCH Sites http://www.freeswitch.org http://confluence.freeswitch.org http://www.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 http://www.freeswitch.org
-- With kind regards Peter Steinbach
Telefaks Services GmbH mailto:lists (att) telefaks.de Internet: www.telefaks.de
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
Official FreeSWITCH Sites http://www.freeswitch.org http://confluence.freeswitch.org http://www.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 http://www.freeswitch.org
-- With kind regards Peter Steinbach Telefaks Services GmbH mailto:lists (att) telefaks.de Internet: www.telefaks.de
If you have to switch to older free switch, that is a problem, we need to figure out exactly what is going on with current freeswitch or the issue will just never get fixed. Please lets look at what happens when its running on latest 1.6 release not older release and figure out how to get that working properly.
On Feb 24, 2017, at 3:46 PM, Peter Steinbach <lists@telefaks.de> wrote:
I finally found a solution, for those who are interested. I switched back to old Freeswitch from Feb 2016, as new FS always answered with 488 on T.38 reinvite from the B-Leg Then I implemented the following (coding outside of FS with XML-Curl) When call is done with T.38 on boths legs, do not anything special, just use a minimum dialplan if B-leg does not answer with T.38, this normally fails in my environment. I then store a Value NOT38 to the dialled number for 1/2 hour in a cache when then the fax machine is retrying the same call, I lookup the cache and return another dialplan with T38 gateway (self) enabled That way, pure T.38 calls work nicely, and calls with T.39 on the B-leg work on the second try. Hope this helps. At last here in Germany, we have to find some workarounds, as fax implementation on some carrier's side (to say the positive) does not improve.
Best regards Peter
On 02/24/17 14:29, Peter Steinbach wrote:
Hello Brian,
I just updated to latest GIT. Dialplan ist still
Dialplan: sofia/internalvpn2/492927aaaaaa@10.7.0.1 <mailto:sofia/internalvpn2/492927aaaaaa@10.7.0.1> Action set(fax_enable_t38=true) Dialplan: sofia/internalvpn2/492927aaaaaa@10.7.0.1 <mailto:sofia/internalvpn2/492927aaaaaa@10.7.0.1> Action set(fax_enable_t38_request=true) Dialplan: sofia/internalvpn2/492927aaaaaa@10.7.0.1 <mailto:sofia/internalvpn2/492927aaaaaa@10.7.0.1> Action set(execute_on_answer=t38_gateway self) Dialplan: sofia/internalvpn2/492927aaaaaa@10.7.0.1 <mailto:sofia/internalvpn2/492927aaaaaa@10.7.0.1> Action ring_ready() Dialplan: sofia/internalvpn2/492927aaaaaa@10.7.0.1 <mailto:sofia/internalvpn2/492927aaaaaa@10.7.0.1> Action bridge(sofia/gateway/sip.provider.com/4940bbbbbbbbbbbbbbb@sip.provider.com)
However the behavour changed now 2017-02-24 13:50:18.913016 [NOTICE] switch_ivr_originate.c:3633 Channel [sofia/internalvpn2/492927aaaaaa@10.7.0.1 <mailto:sofia/internalvpn2/492927aaaaaa@10.7.0.1>] has been answered 2017-02-24 13:50:18.913016 [DEBUG] sofia.c:7241 Channel sofia/internalvpn2/492927aaaaaa@10.7.0.1 <mailto:sofia/internalvpn2/492927aaaaaa@10.7.0.1> entering state [completed][200] EXECUTE sofia/internalvpn2/492927aaaaaa@10.7.0.1 <mailto:sofia/internalvpn2/492927aaaaaa@10.7.0.1> t38_gateway(peer) 2017-02-24 13:50:18.913016 [DEBUG] switch_core_media_bug.c:841 Attaching BUG to sofia/internalvpn2/492927aaaaaa@10.7.0.1 <mailto:sofia/internalvpn2/492927aaaaaa@10.7.0.1> 2017-02-24 13:50:18.913016 [DEBUG] switch_channel.c:3780 (sofia/internalvpn2/492927aaaaaa@10.7.0.1 <mailto:sofia/internalvpn2/492927aaaaaa@10.7.0.1>) Callstate Change RINGING -> ACTIVE 2017-02-24 13:50:18.913016 [DEBUG] switch_ivr_originate.c:3691 Originate Resulted in Success: [sofia/external/4940bbbbbbbbbbbbbbb@sip.provider.com <mailto:sofia/external/4940bbbbbbbbbbbbbbb@sip.provider.com>] 2017-02-24 13:50:18.913016 [DEBUG] switch_ivr_bridge.c:1696 (sofia/external/4940bbbbbbbbbbbbbbb@sip.provider.com <mailto:sofia/external/4940bbbbbbbbbbbbbbb@sip.provider.com>) State Change CS_CONSUME_MEDIA -> CS_EXCHANGE_MEDIA 2017-02-24 13:50:18.913016 [DEBUG] switch_core_state_machine.c:584 (sofia/external/4940bbbbbbbbbbbbbbb@sip.provider.com <mailto:sofia/external/4940bbbbbbbbbbbbbbb@sip.provider.com>) Running State Change CS_EXCHANGE_MEDIA (Cur 2 Tot 10) 2017-02-24 13:50:18.913016 [DEBUG] switch_core_state_machine.c:653 (sofia/external/4940bbbbbbbbbbbbbbb@sip.provider.com <mailto:sofia/external/4940bbbbbbbbbbbbbbb@sip.provider.com>) State EXCHANGE_MEDIA 2017-02-24 13:50:18.913016 [DEBUG] mod_sofia.c:645 SOFIA EXCHANGE_MEDIA 2017-02-24 13:50:18.953025 [DEBUG] sofia.c:7241 Channel sofia/internalvpn2/492927aaaaaa@10.7.0.1 <mailto:sofia/internalvpn2/492927aaaaaa@10.7.0.1> entering state [ready][200] 2017-02-24 13:50:18.953025 [DEBUG] switch_rtp.c:7021 Correct audio ip/port confirmed. 2017-02-24 13:50:19.333126 [DEBUG] switch_rtp.c:7021 Correct audio ip/port confirmed. 2017-02-24 13:50:19.333126 [DEBUG] switch_core_io.c:448 Setting BUG Codec PCMA:8 2017-02-24 13:50:26.013047 [DEBUG] sofia.c:7241 Channel sofia/external/4940bbbbbbbbbbbbbbb@sip.provider.com <mailto:sofia/external/4940bbbbbbbbbbbbbbb@sip.provider.com> entering state [received][100] 2017-02-24 13:50:26.013047 [DEBUG] sofia.c:7251 Remote SDP: v=0 o=HuaweiSoftX3000 1487923856 1487923858 IN IP4 185.39.xx.yy s=HuaweiSoftX3000 c=IN IP4 185.39.xx.yy t=0 0 m=image 16762 udptl t38 a=T38FaxVersion:0 a=T38MaxBitRate:14400 a=T38FaxRateManagement:transferredTCF a=T38FaxMaxBuffer:500 a=T38FaxMaxDatagram:500 a=T38FaxUdpEC:t38UDPRedundancy
2017-02-24 13:50:26.013047 [DEBUG] switch_core_media.c:4634 sofia/external/4940bbbbbbbbbbbbbbb@sip.provider.com <mailto:sofia/external/4940bbbbbbbbbbbbbbb@sip.provider.com> T38 REFUSE on request 2017-02-24 13:50:26.013047 [DEBUG] sofia.c:8152 Reinvite resulted in codec negotiation failure. 2017-02-24 13:50:26.033201 [DEBUG] sofia.c:7234 Channel sofia/external/4940bbbbbbbbbbbbbbb@sip.provider.com <mailto:sofia/external/4940bbbbbbbbbbbbbbb@sip.provider.com> skipping state [ready][488] 2017-02-24 13:50:31.993164 [DEBUG] mod_spandsp_fax.c:2212 Fax Tone Detected. [peer][] 2017-02-24 13:50:31.993164 [DEBUG] mod_spandsp_fax.c:2080 sofia/internalvpn2/492927aaaaaa@10.7.0.1 <mailto:sofia/internalvpn2/492927aaaaaa@10.7.0.1> starting gateway mode to sofia/external/4940bbbbbbbbbbbbbbb@sip.provider.com <mailto:sofia/external/4940bbbbbbbbbbbbbbb@sip.provider.com> 2017-02-24 13:50:31.993164 [DEBUG] mod_spandsp_fax.c:2098 (sofia/internalvpn2/492927aaaaaa@10.7.0.1 <mailto:sofia/internalvpn2/492927aaaaaa@10.7.0.1>) State Change CS_EXECUTE -> CS_RESET 2017-02-24 13:50:31.993164 [DEBUG] mod_spandsp_fax.c:2101 (sofia/external/4940bbbbbbbbbbbbbbb@sip.provider.com <mailto:sofia/external/4940bbbbbbbbbbbbbbb@sip.provider.com>) State Change CS_EXCHANGE_MEDIA -> CS_RESET 2017-02-24 13:50:31.993164 [DEBUG] switch_core_media_bug.c:1208 Removing BUG from sofia/internalvpn2/492927aaaaaa@10.7.0.1 <mailto:sofia/internalvpn2/492927aaaaaa@10.7.0.1> 2017-02-24 13:50:31.993164 [DEBUG] switch_ivr_bridge.c:792 sofia/external/4940bbbbbbbbbbbbbbb@sip.provider.com <mailto:sofia/external/4940bbbbbbbbbbbbbbb@sip.provider.com> ending bridge by request from write function
In this case the sip provider comes back with T.38 reinvite and Freeswitch refuses it.
As you mentioned that there are further settings and variables (I see e.g. "fax_t38_tx_reinvite_packet_count" in the release notes), I am wondering how I will neeed to set this up in order to have in one single dialplan: send fax to SIP Provider(b leg) and have T.38 Re-invite from SIP Provider and pass it to a-leg send fax to SIP Provider(b leg), do NOT receive T.38 Re-invite from SIP Provider and then do T.38 Gateway in FS.
Best regards Peter
On 02/24/17 08:52, Peter Steinbach wrote:
Hello Brian,
this Version of Freeswitch is from 09-Feb-2016. So I think, we should update.
We need to cover 2 scenarios send fax to SIP Provider(b leg) and have T.38 Re-invite from SIP Provider and pass it to a-leg send fax to SIP Provider(b leg), do NOT receive T.38 Re-invite from SIP Provider and then do T.38 Gateway in FS. And no: We cannot foresee, whether the SIp provider will do T.38 and not. Here in Germany, the main incumbant PSTN provider did not implement T.38, so it depends on the target number and actual route, if this will be T.38 or not. A call to a certain number can be T.38 today and tomorrow it will be T.30 only, as some peering partner changed the routes in the meantime.
Best regards Peter
On 02/23/17 20:38, Brian West wrote:
What revision of FreeSWITCH are you on? These behaviors have been solidified in 1.6.15, Sadly MOST of the details of how it all works is locked up in my head, I've just not had the time to write it all down and update the documentation. Can you outline all the scenarios you need to cover and if you have the ability know ahead of time which one needs to apply?
/b
On Thu, Feb 23, 2017 at 8:23 AM, Peter Steinbach <lists@telefaks.de <mailto:lists@telefaks.de>> wrote: Hello,
we have the following screnario The caller, a local fax machine (Fax, ATA and Freeswitch) with T.38, is behind a slow line so therefore T.38 is needed here a central Freeswitch fax server serves as a central gateway to the SIP provider the SIP provider sometimes reinvites T.38 and sometimes not. In case, the SIP provider does NOT answer with T.38, the central Freeswitch fax server shall act as a T.38 gateway and transcode between local fax (T.38) and SIP provider (T.30) In case, the SIP provider does answer with T.38, the central Freeswitch fax server shall pass T.38 to the local fax ,machine (T.38) How we set this up according to the wiki we have a dialplan as follows: (this is what CLI shows) Dialplan: sofia/internalvpn2/49274xxxxx@10.7.0.1 <mailto:sofia/internalvpn2/49274xxxxx@10.7.0.1> Action set(fax_enable_t38=true) Dialplan: sofia/internalvpn2/49274xxxxx@10.7.0.1 <mailto:sofia/internalvpn2/49274xxxxx@10.7.0.1> Action set(fax_enable_t38_request=true) Dialplan: sofia/internalvpn2/49274xxxxx@10.7.0.1 <mailto:sofia/internalvpn2/49274xxxxx@10.7.0.1> Action set(execute_on_answer=t38_gateway self) Dialplan: sofia/internalvpn2/49274xxxxx@10.7.0.1 <mailto:sofia/internalvpn2/49274xxxxx@10.7.0.1> Action ring_ready() Dialplan: sofia/internalvpn2/49274xxxxx@10.7.0.1 <mailto:sofia/internalvpn2/49274xxxxx@10.7.0.1> Action bridge(sofia/gateway/sip.provider.com/xxxxxxxxxxxxxxx@sip.provider.com <mailto:sofia/gateway/sip.provider.com/xxxxxxxxxxxxxxx@sip.provider.com>)
In all profiles, we have <param name="t38-passthru" value="true"/> In case, the SIP provider does NOT answer with T.38, it works. The caller's side is reinvited with T.38, the SIP provider side is T.30 What the problem is: When the SIP provider' side IS answering with T.38, then (sometimes, when I send it via cli from the local freeswitch near the sending fax machine, it works) caller initiates a call call is bridged to the SIP provider' side we receive a T.38 Reinvite from the SIP provider' side Freeswitch sends Trying back to the the SIP provider' side Freeswitch logs: set(execute_on_answer=t38_gateway self) Freeswitch sends a T.38 Reinvite to the caller, establishes T.38 on this side. But the T.38 Reinvite from the SIP provider' side is not answerered So the SIP provider' sidehangs up after 10 sec of timeout. What are we doing wrong here? Is it possible to act as a t.38 passthrough router and a T.38 gateway in the same dialplan?
-- With kind regards Peter Steinbach
Telefaks Services GmbH mailto:lists <mailto:lists> (att) telefaks.de <http://telefaks.de/> Internet: www.telefaks.de <http://www.telefaks.de/>
_________________________________________________________________________ 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/>
-- Brian West brian@freeswitch.org <mailto:brian@freeswitch.org> Twitter: @FreeSWITCH , @briankwest
http://www.freeswitchbook.com <http://www.freeswitchbook.com/> http://www.freeswitchcookbook.com <http://www.freeswitchcookbook.com/>
Allison prompts for FreeSWITCH:
https://www.gofundme.com/allison-prompts-for-freeswitch <https://www.gofundme.com/allison-prompts-for-freeswitch> Wish to schedule a meeting?
http://app.timebridge.com/#/meet/freeswitch <http://app.timebridge.com/#/meet/freeswitch> Got Bugs? Report them here <https://freeswitch.org/jira>! | Reddit: /r/freeswitch <https://www.reddit.com/r/freeswitch> T:+19184209001 | F:+19184209002 | M:+1918424WEST (9378) Skype:briankwest
_________________________________________________________________________ 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/>
-- With kind regards Peter Steinbach
Telefaks Services GmbH mailto:lists <mailto:lists> (att) telefaks.de Internet: www.telefaks.de <http://www.telefaks.de/>
_________________________________________________________________________ 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/>
-- With kind regards Peter Steinbach
Telefaks Services GmbH mailto:lists <mailto:lists> (att) telefaks.de Internet: www.telefaks.de <http://www.telefaks.de/>
_________________________________________________________________________ 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/>
-- With kind regards Peter Steinbach
Telefaks Services GmbH mailto:lists <mailto:lists> (att) telefaks.de Internet: www.telefaks.de <http://www.telefaks.de/>
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
Official FreeSWITCH Sites http://www.freeswitch.org http://confluence.freeswitch.org http://www.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 http://www.freeswitch.org
Hello Michael, I just updated a test machine with current Freeswitch from GIT. He I did not find any T.38 reinvite issue. Best regards Peter On 02/24/17 22:06, Michael Jerris wrote:
If you have to switch to older free switch, that is a problem, we need to figure out exactly what is going on with current freeswitch or the issue will just never get fixed.
Please lets look at what happens when its running on latest 1.6 release not older release and figure out how to get that working properly.
On Feb 24, 2017, at 3:46 PM, Peter Steinbach <lists@telefaks.de <mailto:lists@telefaks.de>> wrote:
I finally found a solution, for those who are interested.
* I switched back to old Freeswitch from Feb 2016, as new FS always answered with 488 on T.38 reinvite from the B-Leg * Then I implemented the following (coding outside of FS with XML-Curl) o When call is done with T.38 on boths legs, do not anything special, just use a minimum dialplan o if B-leg does not answer with T.38, this normally fails in my environment. I then store a Value NOT38 to the dialled number for 1/2 hour in a cache + when then the fax machine is retrying the same call, I lookup the cache and return another dialplan with T38 gateway (self) enabled
That way, pure T.38 calls work nicely, and calls with T.39 on the B-leg work on the second try.
Hope this helps. At last here in Germany, we have to find some workarounds, as fax implementation on some carrier's side (to say the positive) does not improve.
Best regards Peter
On 02/24/17 14:29, Peter Steinbach wrote:
Hello Brian,
I just updated to latest GIT. Dialplan ist still
Dialplan: sofia/internalvpn2/492927aaaaaa@10.7.0.1 Action set(fax_enable_t38=true) Dialplan: sofia/internalvpn2/492927aaaaaa@10.7.0.1 Action set(fax_enable_t38_request=true) Dialplan: sofia/internalvpn2/492927aaaaaa@10.7.0.1 Action set(execute_on_answer=t38_gateway self) Dialplan: sofia/internalvpn2/492927aaaaaa@10.7.0.1 Action ring_ready() Dialplan: sofia/internalvpn2/492927aaaaaa@10.7.0.1 Action bridge(sofia/gateway/sip.provider.com/ <http://sip.provider.com/>4940bbbbbbbbbbbbbbb@sip.provider.com)
However the behavour changed now 2017-02-24 13:50:18.913016 [NOTICE] switch_ivr_originate.c:3633 Channel [sofia/internalvpn2/492927aaaaaa@10.7.0.1] has been answered 2017-02-24 13:50:18.913016 [DEBUG] sofia.c:7241 Channel sofia/internalvpn2/492927aaaaaa@10.7.0.1 entering state [completed][200] *EXECUTE sofia/internalvpn2/492927aaaaaa@10.7.0.1 t38_gateway(peer)* 2017-02-24 13:50:18.913016 [DEBUG] switch_core_media_bug.c:841 Attaching BUG to sofia/internalvpn2/492927aaaaaa@10.7.0.1 2017-02-24 13:50:18.913016 [DEBUG] switch_channel.c:3780 (sofia/internalvpn2/492927aaaaaa@10.7.0.1) Callstate Change RINGING -> ACTIVE 2017-02-24 13:50:18.913016 [DEBUG] switch_ivr_originate.c:3691 Originate Resulted in Success: [sofia/external/4940bbbbbbbbbbbbbbb@sip.provider.com] 2017-02-24 13:50:18.913016 [DEBUG] switch_ivr_bridge.c:1696 (sofia/external/4940bbbbbbbbbbbbbbb@sip.provider.com) State Change CS_CONSUME_MEDIA -> CS_EXCHANGE_MEDIA 2017-02-24 13:50:18.913016 [DEBUG] switch_core_state_machine.c:584 (sofia/external/4940bbbbbbbbbbbbbbb@sip.provider.com) Running State Change CS_EXCHANGE_MEDIA (Cur 2 Tot 10) 2017-02-24 13:50:18.913016 [DEBUG] switch_core_state_machine.c:653 (sofia/external/4940bbbbbbbbbbbbbbb@sip.provider.com) State EXCHANGE_MEDIA 2017-02-24 13:50:18.913016 [DEBUG] mod_sofia.c:645 SOFIA EXCHANGE_MEDIA 2017-02-24 13:50:18.953025 [DEBUG] sofia.c:7241 Channel sofia/internalvpn2/492927aaaaaa@10.7.0.1 entering state [ready][200] 2017-02-24 13:50:18.953025 [DEBUG] switch_rtp.c:7021 Correct audio ip/port confirmed. 2017-02-24 13:50:19.333126 [DEBUG] switch_rtp.c:7021 Correct audio ip/port confirmed. 2017-02-24 13:50:19.333126 [DEBUG] switch_core_io.c:448 Setting BUG Codec PCMA:8 2017-02-24 13:50:26.013047 [DEBUG] sofia.c:7241 Channel sofia/external/4940bbbbbbbbbbbbbbb@sip.provider.com entering state [received][100] 2017-02-24 13:50:26.013047 [DEBUG] sofia.c:7251 Remote SDP: v=0 o=HuaweiSoftX3000 1487923856 1487923858 IN IP4 185.39.xx.yy s=HuaweiSoftX3000 c=IN IP4 185.39.xx.yy t=0 0 m=image 16762 udptl t38 a=T38FaxVersion:0 a=T38MaxBitRate:14400 a=T38FaxRateManagement:transferredTCF a=T38FaxMaxBuffer:500 a=T38FaxMaxDatagram:500 a=T38FaxUdpEC:t38UDPRedundancy
*2017-02-24 13:50:26.013047 [DEBUG] switch_core_media.c:4634 sofia/external/4940bbbbbbbbbbbbbbb@sip.provider.com T38 REFUSE on request* 2017-02-24 13:50:26.013047 [DEBUG] sofia.c:8152 Reinvite resulted in codec negotiation failure. *2017-02-24 13:50:26.033201 [DEBUG] sofia.c:7234 Channel sofia/external/4940bbbbbbbbbbbbbbb@sip.provider.com skipping state [ready][488]* *2017-02-24 13:50:31.993164 [DEBUG] mod_spandsp_fax.c:2212 Fax Tone Detected. [peer][]* *2017-02-24 13:50:31.993164 [DEBUG] mod_spandsp_fax.c:2080 sofia/internalvpn2/492927aaaaaa@10.7.0.1 starting gateway mode to sofia/external/4940bbbbbbbbbbbbbbb@sip.provider.com* 2017-02-24 13:50:31.993164 [DEBUG] mod_spandsp_fax.c:2098 (sofia/internalvpn2/492927aaaaaa@10.7.0.1) State Change CS_EXECUTE -> CS_RESET 2017-02-24 13:50:31.993164 [DEBUG] mod_spandsp_fax.c:2101 (sofia/external/4940bbbbbbbbbbbbbbb@sip.provider.com) State Change CS_EXCHANGE_MEDIA -> CS_RESET 2017-02-24 13:50:31.993164 [DEBUG] switch_core_media_bug.c:1208 Removing BUG from sofia/internalvpn2/492927aaaaaa@10.7.0.1 2017-02-24 13:50:31.993164 [DEBUG] switch_ivr_bridge.c:792 sofia/external/4940bbbbbbbbbbbbbbb@sip.provider.com ending bridge by request from write function
In this case the sip provider comes back with T.38 reinvite and Freeswitch refuses it.
As you mentioned that there are further settings and variables (I see e.g. "fax_t38_tx_reinvite_packet_count" in the release notes), I am wondering how I will neeed to set this up in order to have in one single dialplan:
* send fax to SIP Provider(b leg) and have T.38 Re-invite from SIP Provider and pass it to a-leg * send fax to SIP Provider(b leg), do NOT receive T.38 Re-invite from SIP Provider and then do T.38 Gateway in FS.
Best regards Peter
On 02/24/17 08:52, Peter Steinbach wrote:
Hello Brian,
this Version of Freeswitch is from 09-Feb-2016. So I think, we should update.
We need to cover 2 scenarios
* send fax to SIP Provider(b leg) and have T.38 Re-invite from SIP Provider and pass it to a-leg * send fax to SIP Provider(b leg), do NOT receive T.38 Re-invite from SIP Provider and then do T.38 Gateway in FS.
And no: We cannot foresee, whether the SIp provider will do T.38 and not. Here in Germany, the main incumbant PSTN provider did not implement T.38, so it depends on the target number and actual route, if this will be T.38 or not. A call to a certain number can be T.38 today and tomorrow it will be T.30 only, as some peering partner changed the routes in the meantime.
Best regards Peter
On 02/23/17 20:38, Brian West wrote:
What revision of FreeSWITCH are you on? These behaviors have been solidified in 1.6.15, Sadly MOST of the details of how it all works is locked up in my head, I've just not had the time to write it all down and update the documentation. Can you outline all the scenarios you need to cover and if you have the ability know ahead of time which one needs to apply?
/b
On Thu, Feb 23, 2017 at 8:23 AM, Peter Steinbach <lists@telefaks.de <mailto:lists@telefaks.de>> wrote:
Hello,
we have the following screnario
* The caller, a local fax machine (Fax, ATA and Freeswitch) with T.38, is behind a slow line so therefore T.38 is needed here * a central Freeswitch fax server serves as a central gateway to the SIP provider * the SIP provider sometimes reinvites T.38 and sometimes not. * In case, the SIP provider does NOT answer with T.38, the central Freeswitch fax server shall act as a T.38 gateway and transcode between local fax (T.38) and SIP provider (T.30) * In case, the SIP provider does answer with T.38, the central Freeswitch fax server shall pass T.38 to the local fax ,machine (T.38)
How we set this up
* according to the wiki we have a dialplan as follows: (this is what CLI shows)
Dialplan: sofia/internalvpn2/49274xxxxx@10.7.0.1 <mailto:sofia/internalvpn2/49274xxxxx@10.7.0.1> Action set(fax_enable_t38=true) Dialplan: sofia/internalvpn2/49274xxxxx@10.7.0.1 <mailto:sofia/internalvpn2/49274xxxxx@10.7.0.1> Action set(fax_enable_t38_request=true) Dialplan: sofia/internalvpn2/49274xxxxx@10.7.0.1 <mailto:sofia/internalvpn2/49274xxxxx@10.7.0.1> Action set(execute_on_answer=t38_gateway self) Dialplan: sofia/internalvpn2/49274xxxxx@10.7.0.1 <mailto:sofia/internalvpn2/49274xxxxx@10.7.0.1> Action ring_ready() Dialplan: sofia/internalvpn2/49274xxxxx@10.7.0.1 <mailto:sofia/internalvpn2/49274xxxxx@10.7.0.1> Action bridge(sofia/gateway/sip.provider.com/xxxxxxxxxxxxxxx@sip.provider.com <mailto:sofia/gateway/sip.provider.com/xxxxxxxxxxxxxxx@sip.provider.com>)
In all profiles, we have <param name="t38-passthru" value="true"/>
In case, the SIP provider does NOT answer with T.38, it works. The caller's side is reinvited with T.38, the SIP provider side is T.30
What the problem is: When the SIP provider' side IS answering with T.38, then (sometimes, when I send it via cli from the local freeswitch near the sending fax machine, it works)
* caller initiates a call * call is bridged to the SIP provider' side * we receive a T.38 Reinvite from the SIP provider' side * Freeswitch sends Trying back to the the SIP provider' side * Freeswitch logs: set(execute_on_answer=t38_gateway self) * Freeswitch sends a T.38 Reinvite to the caller, establishes T.38 on this side. * But the T.38 Reinvite from the SIP provider' side is not answerered * So the SIP provider' sidehangs up after 10 sec of timeout.
What are we doing wrong here? Is it possible to act as a t.38 passthrough router and a T.38 gateway in the same dialplan?
-- With kind regards Peter Steinbach
Telefaks Services GmbH mailto:lists (att) telefaks.de <http://telefaks.de/> Internet: www.telefaks.de <http://www.telefaks.de/>
_________________________________________________________________________ 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/>
--
*/Brian West/* brian@freeswitch.org <mailto:brian@freeswitch.org>
*/Twitter: @FreeSWITCH , @briankwest/*
http://www.freeswitchbook.com <http://www.freeswitchbook.com/> http://www.freeswitchcookbook.com <http://www.freeswitchcookbook.com/>
Allison prompts for FreeSWITCH:
*https://www.gofundme.com/allison-prompts-for-freeswitch*
Wish to schedule a meeting?
http://app.timebridge.com/#/meet/freeswitch
Got Bugs? Report them here <https://freeswitch.org/jira>! | Reddit: /r/freeswitch <https://www.reddit.com/r/freeswitch>
*T:*+19184209001 | *F:*+19184209002 | *M:*+1918424WEST (9378) *Skype:*briankwest
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
Official FreeSWITCH Sites http://www.freeswitch.org http://confluence.freeswitch.org http://www.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 http://www.freeswitch.org
-- With kind regards Peter Steinbach
Telefaks Services GmbH mailto:lists (att) telefaks.de <http://telefaks.de> Internet: www.telefaks.de
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
Official FreeSWITCH Sites http://www.freeswitch.org http://confluence.freeswitch.org http://www.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 http://www.freeswitch.org
-- With kind regards Peter Steinbach
Telefaks Services GmbH mailto:lists (att) telefaks.de <http://telefaks.de> Internet: www.telefaks.de
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
Official FreeSWITCH Sites http://www.freeswitch.org http://confluence.freeswitch.org http://www.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 http://www.freeswitch.org
-- With kind regards Peter Steinbach
Telefaks Services GmbH mailto:lists (att) telefaks.de <http://telefaks.de> Internet: www.telefaks.de
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org <mailto:consulting@freeswitch.org> http://www.freeswitchsolutions.com
Official FreeSWITCH Sites http://www.freeswitch.org http://confluence.freeswitch.org http://www.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 http://www.freeswitch.org
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
Official FreeSWITCH Sites http://www.freeswitch.org http://confluence.freeswitch.org http://www.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 http://www.freeswitch.org
-- With kind regards Peter Steinbach Telefaks Services GmbH mailto:lists (att) telefaks.de Internet: www.telefaks.de
I need to point out that there was a slight behavior change in fax handling in 1.6.14+, It was related to 488 handling, We do not now by default accept a t.38 re-invite, You must set fax_enable_t38=true, or we will 488 the re-invite, and some devices do not handle this well. You can restore the previous default behavior by setting fax_enable_t38=true in vars.xml I had sent this out, the is the second time a behavior change notice has gone out and very few have seen it. /b On Mon, Feb 27, 2017 at 6:40 AM, Peter Steinbach <lists@telefaks.de> wrote:
Hello Michael,
I just updated a test machine with current Freeswitch from GIT. He I did not find any T.38 reinvite issue.
Best regards Peter
On 02/24/17 22:06, Michael Jerris wrote:
If you have to switch to older free switch, that is a problem, we need to figure out exactly what is going on with current freeswitch or the issue will just never get fixed.
Please lets look at what happens when its running on latest 1.6 release not older release and figure out how to get that working properly.
On Feb 24, 2017, at 3:46 PM, Peter Steinbach <lists@telefaks.de> wrote:
I finally found a solution, for those who are interested.
- I switched back to old Freeswitch from Feb 2016, as new FS always answered with 488 on T.38 reinvite from the B-Leg - Then I implemented the following (coding outside of FS with XML-Curl) - When call is done with T.38 on boths legs, do not anything special, just use a minimum dialplan - if B-leg does not answer with T.38, this normally fails in my environment. I then store a Value NOT38 to the dialled number for 1/2 hour in a cache - when then the fax machine is retrying the same call, I lookup the cache and return another dialplan with T38 gateway (self) enabled
That way, pure T.38 calls work nicely, and calls with T.39 on the B-leg work on the second try. Hope this helps. At last here in Germany, we have to find some workarounds, as fax implementation on some carrier's side (to say the positive) does not improve.
Best regards Peter
On 02/24/17 14:29, Peter Steinbach wrote:
Hello Brian,
I just updated to latest GIT. Dialplan ist still
Dialplan: sofia/internalvpn2/492927aaaaaa@10.7.0.1 Action set(fax_enable_t38=true) Dialplan: sofia/internalvpn2/492927aaaaaa@10.7.0.1 Action set(fax_enable_t38_request=true) Dialplan: sofia/internalvpn2/492927aaaaaa@10.7.0.1 Action set(execute_on_answer=t38_gateway self) Dialplan: sofia/internalvpn2/492927aaaaaa@10.7.0.1 Action ring_ready() Dialplan: sofia/internalvpn2/492927aaaaaa@10.7.0.1 Action bridge(sofia/gateway/sip.provider.com/4940bbbbbbbbbbbbbbb@sip.provider.com)
However the behavour changed now 2017-02-24 13:50:18.913016 [NOTICE] switch_ivr_originate.c:3633 Channel [ sofia/internalvpn2/492927aaaaaa@10.7.0.1] has been answered 2017-02-24 13:50:18.913016 [DEBUG] sofia.c:7241 Channel sofia/internalvpn2/492927aaaaaa@10.7.0.1 entering state [completed][200] *EXECUTE sofia/internalvpn2/492927aaaaaa@10.7.0.1 <sofia/internalvpn2/492927aaaaaa@10.7.0.1> t38_gateway(peer)* 2017-02-24 13:50:18.913016 [DEBUG] switch_core_media_bug.c:841 Attaching BUG to sofia/internalvpn2/492927aaaaaa@10.7.0.1 2017-02-24 13:50:18.913016 [DEBUG] switch_channel.c:3780 ( sofia/internalvpn2/492927aaaaaa@10.7.0.1) Callstate Change RINGING -> ACTIVE 2017-02-24 13:50:18.913016 [DEBUG] switch_ivr_originate.c:3691 Originate Resulted in Success: [sofia/external/4940bbbbbbbbbbbbbbb@sip.provider.com] 2017-02-24 13:50:18.913016 [DEBUG] switch_ivr_bridge.c:1696 ( sofia/external/4940bbbbbbbbbbbbbbb@sip.provider.com) State Change CS_CONSUME_MEDIA -> CS_EXCHANGE_MEDIA 2017-02-24 13:50:18.913016 [DEBUG] switch_core_state_machine.c:584 ( sofia/external/4940bbbbbbbbbbbbbbb@sip.provider.com) Running State Change CS_EXCHANGE_MEDIA (Cur 2 Tot 10) 2017-02-24 13:50:18.913016 [DEBUG] switch_core_state_machine.c:653 ( sofia/external/4940bbbbbbbbbbbbbbb@sip.provider.com) State EXCHANGE_MEDIA 2017-02-24 13:50:18.913016 [DEBUG] mod_sofia.c:645 SOFIA EXCHANGE_MEDIA 2017-02-24 13:50:18.953025 [DEBUG] sofia.c:7241 Channel sofia/internalvpn2/492927aaaaaa@10.7.0.1 entering state [ready][200] 2017-02-24 13:50:18.953025 [DEBUG] switch_rtp.c:7021 Correct audio ip/port confirmed. 2017-02-24 13:50:19.333126 [DEBUG] switch_rtp.c:7021 Correct audio ip/port confirmed. 2017-02-24 13:50:19.333126 [DEBUG] switch_core_io.c:448 Setting BUG Codec PCMA:8 2017-02-24 13:50:26.013047 [DEBUG] sofia.c:7241 Channel sofia/external/ 4940bbbbbbbbbbbbbbb@sip.provider.com entering state [received][100] 2017-02-24 13:50:26.013047 [DEBUG] sofia.c:7251 Remote SDP: v=0 o=HuaweiSoftX3000 1487923856 1487923858 IN IP4 185.39.xx.yy s=HuaweiSoftX3000 c=IN IP4 185.39.xx.yy t=0 0 m=image 16762 udptl t38 a=T38FaxVersion:0 a=T38MaxBitRate:14400 a=T38FaxRateManagement:transferredTCF a=T38FaxMaxBuffer:500 a=T38FaxMaxDatagram:500 a=T38FaxUdpEC:t38UDPRedundancy
*2017-02-24 13:50:26.013047 [DEBUG] switch_core_media.c:4634 sofia/external/4940bbbbbbbbbbbbbbb@sip.provider.com <sofia/external/4940bbbbbbbbbbbbbbb@sip.provider.com> T38 REFUSE on request* 2017-02-24 13:50:26.013047 [DEBUG] sofia.c:8152 Reinvite resulted in codec negotiation failure. *2017-02-24 13:50:26.033201 [DEBUG] sofia.c:7234 Channel sofia/external/4940bbbbbbbbbbbbbbb@sip.provider.com <sofia/external/4940bbbbbbbbbbbbbbb@sip.provider.com> skipping state [ready][488]* *2017-02-24 13:50:31.993164 [DEBUG] mod_spandsp_fax.c:2212 Fax Tone Detected. [peer][]* *2017-02-24 13:50:31.993164 [DEBUG] mod_spandsp_fax.c:2080 sofia/internalvpn2/492927aaaaaa@10.7.0.1 <sofia/internalvpn2/492927aaaaaa@10.7.0.1> starting gateway mode to sofia/external/4940bbbbbbbbbbbbbbb@sip.provider.com <sofia/external/4940bbbbbbbbbbbbbbb@sip.provider.com>* 2017-02-24 13:50:31.993164 [DEBUG] mod_spandsp_fax.c:2098 ( sofia/internalvpn2/492927aaaaaa@10.7.0.1) State Change CS_EXECUTE -> CS_RESET 2017-02-24 13:50:31.993164 [DEBUG] mod_spandsp_fax.c:2101 (sofia/external/ 4940bbbbbbbbbbbbbbb@sip.provider.com) State Change CS_EXCHANGE_MEDIA -> CS_RESET 2017-02-24 13:50:31.993164 [DEBUG] switch_core_media_bug.c:1208 Removing BUG from sofia/internalvpn2/492927aaaaaa@10.7.0.1 2017-02-24 13:50:31.993164 [DEBUG] switch_ivr_bridge.c:792 sofia/external/ 4940bbbbbbbbbbbbbbb@sip.provider.com ending bridge by request from write function
In this case the sip provider comes back with T.38 reinvite and Freeswitch refuses it.
As you mentioned that there are further settings and variables (I see e.g. "fax_t38_tx_reinvite_packet_count" in the release notes), I am wondering how I will neeed to set this up in order to have in one single dialplan:
- send fax to SIP Provider(b leg) and have T.38 Re-invite from SIP Provider and pass it to a-leg - send fax to SIP Provider(b leg), do NOT receive T.38 Re-invite from SIP Provider and then do T.38 Gateway in FS.
Best regards Peter
On 02/24/17 08:52, Peter Steinbach wrote:
Hello Brian,
this Version of Freeswitch is from 09-Feb-2016. So I think, we should update.
We need to cover 2 scenarios
- send fax to SIP Provider(b leg) and have T.38 Re-invite from SIP Provider and pass it to a-leg - send fax to SIP Provider(b leg), do NOT receive T.38 Re-invite from SIP Provider and then do T.38 Gateway in FS.
And no: We cannot foresee, whether the SIp provider will do T.38 and not. Here in Germany, the main incumbant PSTN provider did not implement T.38, so it depends on the target number and actual route, if this will be T.38 or not. A call to a certain number can be T.38 today and tomorrow it will be T.30 only, as some peering partner changed the routes in the meantime.
Best regards Peter
On 02/23/17 20:38, Brian West wrote:
What revision of FreeSWITCH are you on? These behaviors have been solidified in 1.6.15, Sadly MOST of the details of how it all works is locked up in my head, I've just not had the time to write it all down and update the documentation. Can you outline all the scenarios you need to cover and if you have the ability know ahead of time which one needs to apply?
/b
On Thu, Feb 23, 2017 at 8:23 AM, Peter Steinbach <lists@telefaks.de> wrote:
Hello,
we have the following screnario
- The caller, a local fax machine (Fax, ATA and Freeswitch) with T.38, is behind a slow line so therefore T.38 is needed here - a central Freeswitch fax server serves as a central gateway to the SIP provider - the SIP provider sometimes reinvites T.38 and sometimes not. - In case, the SIP provider does NOT answer with T.38, the central Freeswitch fax server shall act as a T.38 gateway and transcode between local fax (T.38) and SIP provider (T.30) - In case, the SIP provider does answer with T.38, the central Freeswitch fax server shall pass T.38 to the local fax ,machine (T.38)
How we set this up
- according to the wiki we have a dialplan as follows: (this is what CLI shows)
Dialplan: sofia/internalvpn2/49274xxxxx@10.7.0.1 Action set(fax_enable_t38=true) Dialplan: sofia/internalvpn2/49274xxxxx@10.7.0.1 Action set(fax_enable_t38_request=true) Dialplan: sofia/internalvpn2/49274xxxxx@10.7.0.1 Action set(execute_on_answer=t38_gateway self) Dialplan: sofia/internalvpn2/49274xxxxx@10.7.0.1 Action ring_ready() Dialplan: sofia/internalvpn2/49274xxxxx@10.7.0.1 Action bridge( sofia/gateway/sip.provider.com/xxxxxxxxxxxxxxx@sip.provider.com)
In all profiles, we have <param name="t38-passthru" value="true"/>
In case, the SIP provider does NOT answer with T.38, it works. The caller's side is reinvited with T.38, the SIP provider side is T.30
What the problem is: When the SIP provider' side IS answering with T.38, then (sometimes, when I send it via cli from the local freeswitch near the sending fax machine, it works)
- caller initiates a call - call is bridged to the SIP provider' side - we receive a T.38 Reinvite from the SIP provider' side - Freeswitch sends Trying back to the the SIP provider' side - Freeswitch logs: set(execute_on_answer=t38_gateway self) - Freeswitch sends a T.38 Reinvite to the caller, establishes T.38 on this side. - But the T.38 Reinvite from the SIP provider' side is not answerered - So the SIP provider' sidehangs up after 10 sec of timeout.
What are we doing wrong here? Is it possible to act as a t.38 passthrough router and a T.38 gateway in the same dialplan?
-- With kind regards Peter Steinbach
Telefaks Services GmbHmailto:lists <lists> (att) telefaks.de Internet: www.telefaks.de
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
Official FreeSWITCH Sites http://www.freeswitch.org http://confluence.freeswitch.org http://www.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 http://www.freeswitch.org
--
*Brian West* brian@freeswitch.org
*Twitter: @FreeSWITCH , @briankwest*
http://www.freeswitchbook.com http://www.freeswitchcookbook.com
Allison prompts for FreeSWITCH:
*https://www.gofundme.com/allison-prompts-for-freeswitch* <https://www.gofundme.com/allison-prompts-for-freeswitch>
Wish to schedule a meeting?
http://app.timebridge.com/#/meet/freeswitch
Got Bugs? Report them here <https://freeswitch.org/jira>! | Reddit: /r/freeswitch <https://www.reddit.com/r/freeswitch>
*T:*+19184209001 <(918)%20420-9001> | *F:*+19184209002 <(918)%20420-9002> | *M:*+1918424WEST (9378) *Skype:*briankwest
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.orghttp://www.freeswitchsolutions.com
Official FreeSWITCH Siteshttp://www.freeswitch.orghttp://confluence.freeswitch.orghttp://www.cluecon....
FreeSWITCH-users mailing listFreeSWITCH-users@lists.freeswitch.orghttp://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-usershttp://www.frees...
-- With kind regards Peter Steinbach
Telefaks Services GmbHmailto:lists <lists> (att) telefaks.de Internet: www.telefaks.de
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.orghttp://www.freeswitchsolutions.com
Official FreeSWITCH Siteshttp://www.freeswitch.orghttp://confluence.freeswitch.orghttp://www.cluecon....
FreeSWITCH-users mailing listFreeSWITCH-users@lists.freeswitch.orghttp://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-usershttp://www.frees...
-- With kind regards Peter Steinbach
Telefaks Services GmbHmailto:lists <lists> (att) telefaks.de Internet: www.telefaks.de
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.orghttp://www.freeswitchsolutions.com
Official FreeSWITCH Siteshttp://www.freeswitch.orghttp://confluence.freeswitch.orghttp://www.cluecon....
FreeSWITCH-users mailing listFreeSWITCH-users@lists.freeswitch.orghttp://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-usershttp://www.frees...
-- With kind regards Peter Steinbach
Telefaks Services GmbHmailto:lists <lists> (att) telefaks.de Internet: www.telefaks.de
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
Official FreeSWITCH Sites http://www.freeswitch.org http://confluence.freeswitch.org http://www.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 http://www.freeswitch.org
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.orghttp://www.freeswitchsolutions.com
Official FreeSWITCH Siteshttp://www.freeswitch.orghttp://confluence.freeswitch.orghttp://www.cluecon....
FreeSWITCH-users mailing listFreeSWITCH-users@lists.freeswitch.orghttp://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-usershttp://www.frees...
-- With kind regards Peter Steinbach
Telefaks Services GmbHmailto:lists <lists> (att) telefaks.de Internet: www.telefaks.de
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
Official FreeSWITCH Sites http://www.freeswitch.org http://confluence.freeswitch.org http://www.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 http://www.freeswitch.org
-- *Brian West* brian@freeswitch.org *Twitter: @FreeSWITCH , @briankwest* http://www.freeswitchbook.com http://www.freeswitchcookbook.com Allison prompts for FreeSWITCH: *https://www.gofundme.com/allison-prompts-for-freeswitch* <https://www.gofundme.com/allison-prompts-for-freeswitch> Wish to schedule a meeting? http://app.timebridge.com/#/meet/freeswitch Got Bugs? Report them here <https://freeswitch.org/jira>! | Reddit: /r/freeswitch <https://www.reddit.com/r/freeswitch> *T:*+19184209001 | *F:*+19184209002 | *M:*+1918424WEST (9378) *Skype:*briankwest
Also there was a small logic bug in 1.6.14 that was fixed in FS-9943 6ff51458e25c2759e2e4d39965174604007a0cc7 We would 488 the reinvite, and switch to udptl mode anyway. Thats fixed in 1.6.15. Or worked around in 1.6.14 by setting fax_enable_t38=true in vars.xml /b On Mon, Feb 27, 2017 at 9:15 AM, Brian West <brian@freeswitch.org> wrote:
I need to point out that there was a slight behavior change in fax handling in 1.6.14+, It was related to 488 handling, We do not now by default accept a t.38 re-invite, You must set fax_enable_t38=true, or we will 488 the re-invite, and some devices do not handle this well. You can restore the previous default behavior by setting fax_enable_t38=true in vars.xml
I had sent this out, the is the second time a behavior change notice has gone out and very few have seen it.
/b
On Mon, Feb 27, 2017 at 6:40 AM, Peter Steinbach <lists@telefaks.de> wrote:
Hello Michael,
I just updated a test machine with current Freeswitch from GIT. He I did not find any T.38 reinvite issue.
Best regards Peter
On 02/24/17 22:06, Michael Jerris wrote:
If you have to switch to older free switch, that is a problem, we need to figure out exactly what is going on with current freeswitch or the issue will just never get fixed.
Please lets look at what happens when its running on latest 1.6 release not older release and figure out how to get that working properly.
On Feb 24, 2017, at 3:46 PM, Peter Steinbach <lists@telefaks.de> wrote:
I finally found a solution, for those who are interested.
- I switched back to old Freeswitch from Feb 2016, as new FS always answered with 488 on T.38 reinvite from the B-Leg - Then I implemented the following (coding outside of FS with XML-Curl) - When call is done with T.38 on boths legs, do not anything special, just use a minimum dialplan - if B-leg does not answer with T.38, this normally fails in my environment. I then store a Value NOT38 to the dialled number for 1/2 hour in a cache - when then the fax machine is retrying the same call, I lookup the cache and return another dialplan with T38 gateway (self) enabled
That way, pure T.38 calls work nicely, and calls with T.39 on the B-leg work on the second try. Hope this helps. At last here in Germany, we have to find some workarounds, as fax implementation on some carrier's side (to say the positive) does not improve.
Best regards Peter
On 02/24/17 14:29, Peter Steinbach wrote:
Hello Brian,
I just updated to latest GIT. Dialplan ist still
Dialplan: sofia/internalvpn2/492927aaaaaa@10.7.0.1 Action set(fax_enable_t38=true) Dialplan: sofia/internalvpn2/492927aaaaaa@10.7.0.1 Action set(fax_enable_t38_request=true) Dialplan: sofia/internalvpn2/492927aaaaaa@10.7.0.1 Action set(execute_on_answer=t38_gateway self) Dialplan: sofia/internalvpn2/492927aaaaaa@10.7.0.1 Action ring_ready() Dialplan: sofia/internalvpn2/492927aaaaaa@10.7.0.1 Action bridge(sofia/gateway/sip.provider.com/4940bbbbbbbbbbbbbbb@si p.provider.com)
However the behavour changed now 2017-02-24 13:50:18.913016 [NOTICE] switch_ivr_originate.c:3633 Channel [ sofia/internalvpn2/492927aaaaaa@10.7.0.1] has been answered 2017-02-24 13:50:18.913016 [DEBUG] sofia.c:7241 Channel sofia/internalvpn2/492927aaaaaa@10.7.0.1 entering state [completed][200] *EXECUTE sofia/internalvpn2/492927aaaaaa@10.7.0.1 <sofia/internalvpn2/492927aaaaaa@10.7.0.1> t38_gateway(peer)* 2017-02-24 13:50:18.913016 [DEBUG] switch_core_media_bug.c:841 Attaching BUG to sofia/internalvpn2/492927aaaaaa@10.7.0.1 2017-02-24 13:50:18.913016 [DEBUG] switch_channel.c:3780 ( sofia/internalvpn2/492927aaaaaa@10.7.0.1) Callstate Change RINGING -> ACTIVE 2017-02-24 13:50:18.913016 [DEBUG] switch_ivr_originate.c:3691 Originate Resulted in Success: [sofia/external/4940bbbbbbbbbbbbbbb@sip.provider.com ] 2017-02-24 13:50:18.913016 [DEBUG] switch_ivr_bridge.c:1696 ( sofia/external/4940bbbbbbbbbbbbbbb@sip.provider.com) State Change CS_CONSUME_MEDIA -> CS_EXCHANGE_MEDIA 2017-02-24 13:50:18.913016 [DEBUG] switch_core_state_machine.c:584 ( sofia/external/4940bbbbbbbbbbbbbbb@sip.provider.com) Running State Change CS_EXCHANGE_MEDIA (Cur 2 Tot 10) 2017-02-24 13:50:18.913016 [DEBUG] switch_core_state_machine.c:653 ( sofia/external/4940bbbbbbbbbbbbbbb@sip.provider.com) State EXCHANGE_MEDIA 2017-02-24 13:50:18.913016 [DEBUG] mod_sofia.c:645 SOFIA EXCHANGE_MEDIA 2017-02-24 13:50:18.953025 [DEBUG] sofia.c:7241 Channel sofia/internalvpn2/492927aaaaaa@10.7.0.1 entering state [ready][200] 2017-02-24 13:50:18.953025 [DEBUG] switch_rtp.c:7021 Correct audio ip/port confirmed. 2017-02-24 13:50:19.333126 [DEBUG] switch_rtp.c:7021 Correct audio ip/port confirmed. 2017-02-24 13:50:19.333126 [DEBUG] switch_core_io.c:448 Setting BUG Codec PCMA:8 2017-02-24 13:50:26.013047 [DEBUG] sofia.c:7241 Channel sofia/external/4940bbbbbbbbbbbbbbb@sip.provider.com entering state [received][100] 2017-02-24 13:50:26.013047 [DEBUG] sofia.c:7251 Remote SDP: v=0 o=HuaweiSoftX3000 1487923856 1487923858 IN IP4 185.39.xx.yy s=HuaweiSoftX3000 c=IN IP4 185.39.xx.yy t=0 0 m=image 16762 udptl t38 a=T38FaxVersion:0 a=T38MaxBitRate:14400 a=T38FaxRateManagement:transferredTCF a=T38FaxMaxBuffer:500 a=T38FaxMaxDatagram:500 a=T38FaxUdpEC:t38UDPRedundancy
*2017-02-24 13:50:26.013047 [DEBUG] switch_core_media.c:4634 sofia/external/4940bbbbbbbbbbbbbbb@sip.provider.com <sofia/external/4940bbbbbbbbbbbbbbb@sip.provider.com> T38 REFUSE on request* 2017-02-24 13:50:26.013047 [DEBUG] sofia.c:8152 Reinvite resulted in codec negotiation failure. *2017-02-24 13:50:26.033201 [DEBUG] sofia.c:7234 Channel sofia/external/4940bbbbbbbbbbbbbbb@sip.provider.com <sofia/external/4940bbbbbbbbbbbbbbb@sip.provider.com> skipping state [ready][488]* *2017-02-24 13:50:31.993164 [DEBUG] mod_spandsp_fax.c:2212 Fax Tone Detected. [peer][]* *2017-02-24 13:50:31.993164 [DEBUG] mod_spandsp_fax.c:2080 sofia/internalvpn2/492927aaaaaa@10.7.0.1 <sofia/internalvpn2/492927aaaaaa@10.7.0.1> starting gateway mode to sofia/external/4940bbbbbbbbbbbbbbb@sip.provider.com <sofia/external/4940bbbbbbbbbbbbbbb@sip.provider.com>* 2017-02-24 13:50:31.993164 [DEBUG] mod_spandsp_fax.c:2098 ( sofia/internalvpn2/492927aaaaaa@10.7.0.1) State Change CS_EXECUTE -> CS_RESET 2017-02-24 13:50:31.993164 [DEBUG] mod_spandsp_fax.c:2101 ( sofia/external/4940bbbbbbbbbbbbbbb@sip.provider.com) State Change CS_EXCHANGE_MEDIA -> CS_RESET 2017-02-24 13:50:31.993164 [DEBUG] switch_core_media_bug.c:1208 Removing BUG from sofia/internalvpn2/492927aaaaaa@10.7.0.1 2017-02-24 13:50:31.993164 [DEBUG] switch_ivr_bridge.c:792 sofia/external/4940bbbbbbbbbbbbbbb@sip.provider.com ending bridge by request from write function
In this case the sip provider comes back with T.38 reinvite and Freeswitch refuses it.
As you mentioned that there are further settings and variables (I see e.g. "fax_t38_tx_reinvite_packet_count" in the release notes), I am wondering how I will neeed to set this up in order to have in one single dialplan:
- send fax to SIP Provider(b leg) and have T.38 Re-invite from SIP Provider and pass it to a-leg - send fax to SIP Provider(b leg), do NOT receive T.38 Re-invite from SIP Provider and then do T.38 Gateway in FS.
Best regards Peter
On 02/24/17 08:52, Peter Steinbach wrote:
Hello Brian,
this Version of Freeswitch is from 09-Feb-2016. So I think, we should update.
We need to cover 2 scenarios
- send fax to SIP Provider(b leg) and have T.38 Re-invite from SIP Provider and pass it to a-leg - send fax to SIP Provider(b leg), do NOT receive T.38 Re-invite from SIP Provider and then do T.38 Gateway in FS.
And no: We cannot foresee, whether the SIp provider will do T.38 and not. Here in Germany, the main incumbant PSTN provider did not implement T.38, so it depends on the target number and actual route, if this will be T.38 or not. A call to a certain number can be T.38 today and tomorrow it will be T.30 only, as some peering partner changed the routes in the meantime.
Best regards Peter
On 02/23/17 20:38, Brian West wrote:
What revision of FreeSWITCH are you on? These behaviors have been solidified in 1.6.15, Sadly MOST of the details of how it all works is locked up in my head, I've just not had the time to write it all down and update the documentation. Can you outline all the scenarios you need to cover and if you have the ability know ahead of time which one needs to apply?
/b
On Thu, Feb 23, 2017 at 8:23 AM, Peter Steinbach <lists@telefaks.de> wrote:
Hello,
we have the following screnario
- The caller, a local fax machine (Fax, ATA and Freeswitch) with T.38, is behind a slow line so therefore T.38 is needed here - a central Freeswitch fax server serves as a central gateway to the SIP provider - the SIP provider sometimes reinvites T.38 and sometimes not. - In case, the SIP provider does NOT answer with T.38, the central Freeswitch fax server shall act as a T.38 gateway and transcode between local fax (T.38) and SIP provider (T.30) - In case, the SIP provider does answer with T.38, the central Freeswitch fax server shall pass T.38 to the local fax ,machine (T.38)
How we set this up
- according to the wiki we have a dialplan as follows: (this is what CLI shows)
Dialplan: sofia/internalvpn2/49274xxxxx@10.7.0.1 Action set(fax_enable_t38=true) Dialplan: sofia/internalvpn2/49274xxxxx@10.7.0.1 Action set(fax_enable_t38_request=true) Dialplan: sofia/internalvpn2/49274xxxxx@10.7.0.1 Action set(execute_on_answer=t38_gateway self) Dialplan: sofia/internalvpn2/49274xxxxx@10.7.0.1 Action ring_ready() Dialplan: sofia/internalvpn2/49274xxxxx@10.7.0.1 Action bridge( sofia/gateway/sip.provider.com/xxxxxxxxxxxxxxx@sip.provider.com)
In all profiles, we have <param name="t38-passthru" value="true"/>
In case, the SIP provider does NOT answer with T.38, it works. The caller's side is reinvited with T.38, the SIP provider side is T.30
What the problem is: When the SIP provider' side IS answering with T.38, then (sometimes, when I send it via cli from the local freeswitch near the sending fax machine, it works)
- caller initiates a call - call is bridged to the SIP provider' side - we receive a T.38 Reinvite from the SIP provider' side - Freeswitch sends Trying back to the the SIP provider' side - Freeswitch logs: set(execute_on_answer=t38_gateway self) - Freeswitch sends a T.38 Reinvite to the caller, establishes T.38 on this side. - But the T.38 Reinvite from the SIP provider' side is not answerered - So the SIP provider' sidehangs up after 10 sec of timeout.
What are we doing wrong here? Is it possible to act as a t.38 passthrough router and a T.38 gateway in the same dialplan?
-- With kind regards Peter Steinbach
Telefaks Services GmbHmailto:lists <lists> (att) telefaks.de Internet: www.telefaks.de
____________________________________________________________ _____________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
Official FreeSWITCH Sites http://www.freeswitch.org http://confluence.freeswitch.org http://www.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 http://www.freeswitch.org
--
*Brian West* brian@freeswitch.org
*Twitter: @FreeSWITCH , @briankwest*
http://www.freeswitchbook.com http://www.freeswitchcookbook.com
Allison prompts for FreeSWITCH:
*https://www.gofundme.com/allison-prompts-for-freeswitch* <https://www.gofundme.com/allison-prompts-for-freeswitch>
Wish to schedule a meeting?
http://app.timebridge.com/#/meet/freeswitch
Got Bugs? Report them here <https://freeswitch.org/jira>! | Reddit: /r/freeswitch <https://www.reddit.com/r/freeswitch>
*T:*+19184209001 <(918)%20420-9001> | *F:*+19184209002 <(918)%20420-9002> | *M:*+1918424WEST (9378) *Skype:*briankwest
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.orghttp://www.freeswitchsolutions.com
Official FreeSWITCH Siteshttp://www.freeswitch.orghttp://confluence.freeswitch.orghttp://www.cluecon....
FreeSWITCH-users mailing listFreeSWITCH-users@lists.freeswitch.orghttp://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-usershttp://www.frees...
-- With kind regards Peter Steinbach
Telefaks Services GmbHmailto:lists <lists> (att) telefaks.de Internet: www.telefaks.de
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.orghttp://www.freeswitchsolutions.com
Official FreeSWITCH Siteshttp://www.freeswitch.orghttp://confluence.freeswitch.orghttp://www.cluecon....
FreeSWITCH-users mailing listFreeSWITCH-users@lists.freeswitch.orghttp://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-usershttp://www.frees...
-- With kind regards Peter Steinbach
Telefaks Services GmbHmailto:lists <lists> (att) telefaks.de Internet: www.telefaks.de
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.orghttp://www.freeswitchsolutions.com
Official FreeSWITCH Siteshttp://www.freeswitch.orghttp://confluence.freeswitch.orghttp://www.cluecon....
FreeSWITCH-users mailing listFreeSWITCH-users@lists.freeswitch.orghttp://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-usershttp://www.frees...
-- With kind regards Peter Steinbach
Telefaks Services GmbHmailto:lists <lists> (att) telefaks.de Internet: www.telefaks.de
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
Official FreeSWITCH Sites http://www.freeswitch.org http://confluence.freeswitch.org http://www.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 http://www.freeswitch.org
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.orghttp://www.freeswitchsolutions.com
Official FreeSWITCH Siteshttp://www.freeswitch.orghttp://confluence.freeswitch.orghttp://www.cluecon....
FreeSWITCH-users mailing listFreeSWITCH-users@lists.freeswitch.orghttp://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-usershttp://www.frees...
-- With kind regards Peter Steinbach
Telefaks Services GmbHmailto:lists <lists> (att) telefaks.de Internet: www.telefaks.de
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
Official FreeSWITCH Sites http://www.freeswitch.org http://confluence.freeswitch.org http://www.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 http://www.freeswitch.org
--
*Brian West* brian@freeswitch.org
*Twitter: @FreeSWITCH , @briankwest*
http://www.freeswitchbook.com http://www.freeswitchcookbook.com
Allison prompts for FreeSWITCH:
*https://www.gofundme.com/allison-prompts-for-freeswitch* <https://www.gofundme.com/allison-prompts-for-freeswitch>
Wish to schedule a meeting?
http://app.timebridge.com/#/meet/freeswitch
Got Bugs? Report them here <https://freeswitch.org/jira>! | Reddit: /r/freeswitch <https://www.reddit.com/r/freeswitch>
*T:*+19184209001 <(918)%20420-9001> | *F:*+19184209002 <(918)%20420-9002> | *M:*+1918424WEST (9378) *Skype:*briankwest
-- *Brian West* brian@freeswitch.org *Twitter: @FreeSWITCH , @briankwest* http://www.freeswitchbook.com http://www.freeswitchcookbook.com Allison prompts for FreeSWITCH: *https://www.gofundme.com/allison-prompts-for-freeswitch* <https://www.gofundme.com/allison-prompts-for-freeswitch> Wish to schedule a meeting? http://app.timebridge.com/#/meet/freeswitch Got Bugs? Report them here <https://freeswitch.org/jira>! | Reddit: /r/freeswitch <https://www.reddit.com/r/freeswitch> *T:*+19184209001 | *F:*+19184209002 | *M:*+1918424WEST (9378) *Skype:*briankwest
http://lists.freeswitch.org/pipermail/freeswitch-users/2017-January/124459.h... On Mon, Feb 27, 2017 at 9:18 AM, Brian West <brian@freeswitch.org> wrote:
Also there was a small logic bug in 1.6.14 that was fixed in FS-9943 6ff51458e25c2759e2e4d39965174604007a0cc7
We would 488 the reinvite, and switch to udptl mode anyway. Thats fixed in 1.6.15. Or worked around in 1.6.14 by setting fax_enable_t38=true in vars.xml
/b
On Mon, Feb 27, 2017 at 9:15 AM, Brian West <brian@freeswitch.org> wrote:
I need to point out that there was a slight behavior change in fax handling in 1.6.14+, It was related to 488 handling, We do not now by default accept a t.38 re-invite, You must set fax_enable_t38=true, or we will 488 the re-invite, and some devices do not handle this well. You can restore the previous default behavior by setting fax_enable_t38=true in vars.xml
I had sent this out, the is the second time a behavior change notice has gone out and very few have seen it.
/b
On Mon, Feb 27, 2017 at 6:40 AM, Peter Steinbach <lists@telefaks.de> wrote:
Hello Michael,
I just updated a test machine with current Freeswitch from GIT. He I did not find any T.38 reinvite issue.
Best regards Peter
On 02/24/17 22:06, Michael Jerris wrote:
If you have to switch to older free switch, that is a problem, we need to figure out exactly what is going on with current freeswitch or the issue will just never get fixed.
Please lets look at what happens when its running on latest 1.6 release not older release and figure out how to get that working properly.
On Feb 24, 2017, at 3:46 PM, Peter Steinbach <lists@telefaks.de> wrote:
I finally found a solution, for those who are interested.
- I switched back to old Freeswitch from Feb 2016, as new FS always answered with 488 on T.38 reinvite from the B-Leg - Then I implemented the following (coding outside of FS with XML-Curl) - When call is done with T.38 on boths legs, do not anything special, just use a minimum dialplan - if B-leg does not answer with T.38, this normally fails in my environment. I then store a Value NOT38 to the dialled number for 1/2 hour in a cache - when then the fax machine is retrying the same call, I lookup the cache and return another dialplan with T38 gateway (self) enabled
That way, pure T.38 calls work nicely, and calls with T.39 on the B-leg work on the second try. Hope this helps. At last here in Germany, we have to find some workarounds, as fax implementation on some carrier's side (to say the positive) does not improve.
Best regards Peter
On 02/24/17 14:29, Peter Steinbach wrote:
Hello Brian,
I just updated to latest GIT. Dialplan ist still
Dialplan: sofia/internalvpn2/492927aaaaaa@10.7.0.1 Action set(fax_enable_t38=true) Dialplan: sofia/internalvpn2/492927aaaaaa@10.7.0.1 Action set(fax_enable_t38_request=true) Dialplan: sofia/internalvpn2/492927aaaaaa@10.7.0.1 Action set(execute_on_answer=t38_gateway self) Dialplan: sofia/internalvpn2/492927aaaaaa@10.7.0.1 Action ring_ready() Dialplan: sofia/internalvpn2/492927aaaaaa@10.7.0.1 Action bridge(sofia/gateway/sip.provider.com/4940bbbbbbbbbbbbbbb@si p.provider.com)
However the behavour changed now 2017-02-24 13:50:18.913016 [NOTICE] switch_ivr_originate.c:3633 Channel [ sofia/internalvpn2/492927aaaaaa@10.7.0.1] has been answered 2017-02-24 13:50:18.913016 [DEBUG] sofia.c:7241 Channel sofia/internalvpn2/492927aaaaaa@10.7.0.1 entering state [completed][200] *EXECUTE sofia/internalvpn2/492927aaaaaa@10.7.0.1 <sofia/internalvpn2/492927aaaaaa@10.7.0.1> t38_gateway(peer)* 2017-02-24 13:50:18.913016 [DEBUG] switch_core_media_bug.c:841 Attaching BUG to sofia/internalvpn2/492927aaaaaa@10.7.0.1 2017-02-24 13:50:18.913016 [DEBUG] switch_channel.c:3780 ( sofia/internalvpn2/492927aaaaaa@10.7.0.1) Callstate Change RINGING -> ACTIVE 2017-02-24 13:50:18.913016 [DEBUG] switch_ivr_originate.c:3691 Originate Resulted in Success: [sofia/external/4940bbbbbbbbbb bbbbb@sip.provider.com] 2017-02-24 13:50:18.913016 [DEBUG] switch_ivr_bridge.c:1696 ( sofia/external/4940bbbbbbbbbbbbbbb@sip.provider.com) State Change CS_CONSUME_MEDIA -> CS_EXCHANGE_MEDIA 2017-02-24 13:50:18.913016 [DEBUG] switch_core_state_machine.c:584 ( sofia/external/4940bbbbbbbbbbbbbbb@sip.provider.com) Running State Change CS_EXCHANGE_MEDIA (Cur 2 Tot 10) 2017-02-24 13:50:18.913016 [DEBUG] switch_core_state_machine.c:653 ( sofia/external/4940bbbbbbbbbbbbbbb@sip.provider.com) State EXCHANGE_MEDIA 2017-02-24 13:50:18.913016 [DEBUG] mod_sofia.c:645 SOFIA EXCHANGE_MEDIA 2017-02-24 13:50:18.953025 [DEBUG] sofia.c:7241 Channel sofia/internalvpn2/492927aaaaaa@10.7.0.1 entering state [ready][200] 2017-02-24 13:50:18.953025 [DEBUG] switch_rtp.c:7021 Correct audio ip/port confirmed. 2017-02-24 13:50:19.333126 [DEBUG] switch_rtp.c:7021 Correct audio ip/port confirmed. 2017-02-24 13:50:19.333126 [DEBUG] switch_core_io.c:448 Setting BUG Codec PCMA:8 2017-02-24 13:50:26.013047 [DEBUG] sofia.c:7241 Channel sofia/external/4940bbbbbbbbbbbbbbb@sip.provider.com entering state [received][100] 2017-02-24 13:50:26.013047 [DEBUG] sofia.c:7251 Remote SDP: v=0 o=HuaweiSoftX3000 1487923856 1487923858 IN IP4 185.39.xx.yy s=HuaweiSoftX3000 c=IN IP4 185.39.xx.yy t=0 0 m=image 16762 udptl t38 a=T38FaxVersion:0 a=T38MaxBitRate:14400 a=T38FaxRateManagement:transferredTCF a=T38FaxMaxBuffer:500 a=T38FaxMaxDatagram:500 a=T38FaxUdpEC:t38UDPRedundancy
*2017-02-24 13:50:26.013047 [DEBUG] switch_core_media.c:4634 sofia/external/4940bbbbbbbbbbbbbbb@sip.provider.com <sofia/external/4940bbbbbbbbbbbbbbb@sip.provider.com> T38 REFUSE on request* 2017-02-24 13:50:26.013047 [DEBUG] sofia.c:8152 Reinvite resulted in codec negotiation failure. *2017-02-24 13:50:26.033201 [DEBUG] sofia.c:7234 Channel sofia/external/4940bbbbbbbbbbbbbbb@sip.provider.com <sofia/external/4940bbbbbbbbbbbbbbb@sip.provider.com> skipping state [ready][488]* *2017-02-24 13:50:31.993164 [DEBUG] mod_spandsp_fax.c:2212 Fax Tone Detected. [peer][]* *2017-02-24 13:50:31.993164 [DEBUG] mod_spandsp_fax.c:2080 sofia/internalvpn2/492927aaaaaa@10.7.0.1 <sofia/internalvpn2/492927aaaaaa@10.7.0.1> starting gateway mode to sofia/external/4940bbbbbbbbbbbbbbb@sip.provider.com <sofia/external/4940bbbbbbbbbbbbbbb@sip.provider.com>* 2017-02-24 13:50:31.993164 [DEBUG] mod_spandsp_fax.c:2098 ( sofia/internalvpn2/492927aaaaaa@10.7.0.1) State Change CS_EXECUTE -> CS_RESET 2017-02-24 13:50:31.993164 [DEBUG] mod_spandsp_fax.c:2101 ( sofia/external/4940bbbbbbbbbbbbbbb@sip.provider.com) State Change CS_EXCHANGE_MEDIA -> CS_RESET 2017-02-24 13:50:31.993164 [DEBUG] switch_core_media_bug.c:1208 Removing BUG from sofia/internalvpn2/492927aaaaaa@10.7.0.1 2017-02-24 13:50:31.993164 [DEBUG] switch_ivr_bridge.c:792 sofia/external/4940bbbbbbbbbbbbbbb@sip.provider.com ending bridge by request from write function
In this case the sip provider comes back with T.38 reinvite and Freeswitch refuses it.
As you mentioned that there are further settings and variables (I see e.g. "fax_t38_tx_reinvite_packet_count" in the release notes), I am wondering how I will neeed to set this up in order to have in one single dialplan:
- send fax to SIP Provider(b leg) and have T.38 Re-invite from SIP Provider and pass it to a-leg - send fax to SIP Provider(b leg), do NOT receive T.38 Re-invite from SIP Provider and then do T.38 Gateway in FS.
Best regards Peter
On 02/24/17 08:52, Peter Steinbach wrote:
Hello Brian,
this Version of Freeswitch is from 09-Feb-2016. So I think, we should update.
We need to cover 2 scenarios
- send fax to SIP Provider(b leg) and have T.38 Re-invite from SIP Provider and pass it to a-leg - send fax to SIP Provider(b leg), do NOT receive T.38 Re-invite from SIP Provider and then do T.38 Gateway in FS.
And no: We cannot foresee, whether the SIp provider will do T.38 and not. Here in Germany, the main incumbant PSTN provider did not implement T.38, so it depends on the target number and actual route, if this will be T.38 or not. A call to a certain number can be T.38 today and tomorrow it will be T.30 only, as some peering partner changed the routes in the meantime.
Best regards Peter
On 02/23/17 20:38, Brian West wrote:
What revision of FreeSWITCH are you on? These behaviors have been solidified in 1.6.15, Sadly MOST of the details of how it all works is locked up in my head, I've just not had the time to write it all down and update the documentation. Can you outline all the scenarios you need to cover and if you have the ability know ahead of time which one needs to apply?
/b
On Thu, Feb 23, 2017 at 8:23 AM, Peter Steinbach <lists@telefaks.de> wrote:
Hello,
we have the following screnario
- The caller, a local fax machine (Fax, ATA and Freeswitch) with T.38, is behind a slow line so therefore T.38 is needed here - a central Freeswitch fax server serves as a central gateway to the SIP provider - the SIP provider sometimes reinvites T.38 and sometimes not. - In case, the SIP provider does NOT answer with T.38, the central Freeswitch fax server shall act as a T.38 gateway and transcode between local fax (T.38) and SIP provider (T.30) - In case, the SIP provider does answer with T.38, the central Freeswitch fax server shall pass T.38 to the local fax ,machine (T.38)
How we set this up
- according to the wiki we have a dialplan as follows: (this is what CLI shows)
Dialplan: sofia/internalvpn2/49274xxxxx@10.7.0.1 Action set(fax_enable_t38=true) Dialplan: sofia/internalvpn2/49274xxxxx@10.7.0.1 Action set(fax_enable_t38_request=true) Dialplan: sofia/internalvpn2/49274xxxxx@10.7.0.1 Action set(execute_on_answer=t38_gateway self) Dialplan: sofia/internalvpn2/49274xxxxx@10.7.0.1 Action ring_ready() Dialplan: sofia/internalvpn2/49274xxxxx@10.7.0.1 Action bridge( sofia/gateway/sip.provider.com/xxxxxxxxxxxxxxx@sip.provider.com)
In all profiles, we have <param name="t38-passthru" value="true"/>
In case, the SIP provider does NOT answer with T.38, it works. The caller's side is reinvited with T.38, the SIP provider side is T.30
What the problem is: When the SIP provider' side IS answering with T.38, then (sometimes, when I send it via cli from the local freeswitch near the sending fax machine, it works)
- caller initiates a call - call is bridged to the SIP provider' side - we receive a T.38 Reinvite from the SIP provider' side - Freeswitch sends Trying back to the the SIP provider' side - Freeswitch logs: set(execute_on_answer=t38_gateway self) - Freeswitch sends a T.38 Reinvite to the caller, establishes T.38 on this side. - But the T.38 Reinvite from the SIP provider' side is not answerered - So the SIP provider' sidehangs up after 10 sec of timeout.
What are we doing wrong here? Is it possible to act as a t.38 passthrough router and a T.38 gateway in the same dialplan?
-- With kind regards Peter Steinbach
Telefaks Services GmbHmailto:lists <lists> (att) telefaks.de Internet: www.telefaks.de
____________________________________________________________ _____________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
Official FreeSWITCH Sites http://www.freeswitch.org http://confluence.freeswitch.org http://www.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/free switch-users http://www.freeswitch.org
--
*Brian West* brian@freeswitch.org
*Twitter: @FreeSWITCH , @briankwest*
http://www.freeswitchbook.com http://www.freeswitchcookbook.com
Allison prompts for FreeSWITCH:
*https://www.gofundme.com/allison-prompts-for-freeswitch* <https://www.gofundme.com/allison-prompts-for-freeswitch>
Wish to schedule a meeting?
http://app.timebridge.com/#/meet/freeswitch
Got Bugs? Report them here <https://freeswitch.org/jira>! | Reddit: /r/freeswitch <https://www.reddit.com/r/freeswitch>
*T:*+19184209001 <(918)%20420-9001> | *F:*+19184209002 <(918)%20420-9002> | *M:*+1918424WEST (9378) *Skype:*briankwest
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.orghttp://www.freeswitchsolutions.com
Official FreeSWITCH Siteshttp://www.freeswitch.orghttp://confluence.freeswitch.orghttp://www.cluecon....
FreeSWITCH-users mailing listFreeSWITCH-users@lists.freeswitch.orghttp://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-usershttp://www.frees...
-- With kind regards Peter Steinbach
Telefaks Services GmbHmailto:lists <lists> (att) telefaks.de Internet: www.telefaks.de
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.orghttp://www.freeswitchsolutions.com
Official FreeSWITCH Siteshttp://www.freeswitch.orghttp://confluence.freeswitch.orghttp://www.cluecon....
FreeSWITCH-users mailing listFreeSWITCH-users@lists.freeswitch.orghttp://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-usershttp://www.frees...
-- With kind regards Peter Steinbach
Telefaks Services GmbHmailto:lists <lists> (att) telefaks.de Internet: www.telefaks.de
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.orghttp://www.freeswitchsolutions.com
Official FreeSWITCH Siteshttp://www.freeswitch.orghttp://confluence.freeswitch.orghttp://www.cluecon....
FreeSWITCH-users mailing listFreeSWITCH-users@lists.freeswitch.orghttp://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-usershttp://www.frees...
-- With kind regards Peter Steinbach
Telefaks Services GmbHmailto:lists <lists> (att) telefaks.de Internet: www.telefaks.de
____________________________________________________________ _____________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
Official FreeSWITCH Sites http://www.freeswitch.org http://confluence.freeswitch.org http://www.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 http://www.freeswitch.org
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.orghttp://www.freeswitchsolutions.com
Official FreeSWITCH Siteshttp://www.freeswitch.orghttp://confluence.freeswitch.orghttp://www.cluecon....
FreeSWITCH-users mailing listFreeSWITCH-users@lists.freeswitch.orghttp://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-usershttp://www.frees...
-- With kind regards Peter Steinbach
Telefaks Services GmbHmailto:lists <lists> (att) telefaks.de Internet: www.telefaks.de
____________________________________________________________ _____________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
Official FreeSWITCH Sites http://www.freeswitch.org http://confluence.freeswitch.org http://www.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 http://www.freeswitch.org
--
*Brian West* brian@freeswitch.org
*Twitter: @FreeSWITCH , @briankwest*
http://www.freeswitchbook.com http://www.freeswitchcookbook.com
Allison prompts for FreeSWITCH:
*https://www.gofundme.com/allison-prompts-for-freeswitch* <https://www.gofundme.com/allison-prompts-for-freeswitch>
Wish to schedule a meeting?
http://app.timebridge.com/#/meet/freeswitch
Got Bugs? Report them here <https://freeswitch.org/jira>! | Reddit: /r/freeswitch <https://www.reddit.com/r/freeswitch>
*T:*+19184209001 <(918)%20420-9001> | *F:*+19184209002 <(918)%20420-9002> | *M:*+1918424WEST (9378) *Skype:*briankwest
--
*Brian West* brian@freeswitch.org
*Twitter: @FreeSWITCH , @briankwest*
http://www.freeswitchbook.com http://www.freeswitchcookbook.com
Allison prompts for FreeSWITCH:
*https://www.gofundme.com/allison-prompts-for-freeswitch* <https://www.gofundme.com/allison-prompts-for-freeswitch>
Wish to schedule a meeting?
http://app.timebridge.com/#/meet/freeswitch
Got Bugs? Report them here <https://freeswitch.org/jira>! | Reddit: /r/freeswitch <https://www.reddit.com/r/freeswitch>
*T:*+19184209001 <(918)%20420-9001> | *F:*+19184209002 <(918)%20420-9002> | *M:*+1918424WEST (9378) *Skype:*briankwest
-- *Brian West* brian@freeswitch.org *Twitter: @FreeSWITCH , @briankwest* http://www.freeswitchbook.com http://www.freeswitchcookbook.com Allison prompts for FreeSWITCH: *https://www.gofundme.com/allison-prompts-for-freeswitch* <https://www.gofundme.com/allison-prompts-for-freeswitch> Wish to schedule a meeting? http://app.timebridge.com/#/meet/freeswitch Got Bugs? Report them here <https://freeswitch.org/jira>! | Reddit: /r/freeswitch <https://www.reddit.com/r/freeswitch> *T:*+19184209001 | *F:*+19184209002 | *M:*+1918424WEST (9378) *Skype:*briankwest
participants (4)
-
Brian :
-
Brian West
-
Michael Jerris
-
Peter Steinbach