[Home]

Summary:ASTERISK-27424: PJSIP T.38 Re-Invites fail between 2 extensions running Fax Voip FSP Windows Fax Service Provider
Reporter:Jared Davison (jdast)Labels:
Date Opened:2017-11-15 17:36:29.000-0600Date Closed:
Priority:MinorRegression?
Status:Open/NewComponents:Resources/res_pjsip_session Resources/res_pjsip_t38
Versions:15.1.0 Frequency of
Occurrence		Constant
Related
Issues:
Environment:1 x Asterisk server 2 x Windows 10 workstations, each workstation has: 1. "Windows Fax & Scan" (WFS.exe) 2. Fax Voip FSP Windows Fax Service Provider (FSP) (note that virtual machines are not recommended by Voip FSP faq). 15 Day trial available here: http://www.t38faxvoip.com/fsp/ 3. Wireshark packet capture software running on both Windows computers. 4. Configure an extension in asterisk for each FSP. The extensions endpoints in the asterisk pjsip.conf should have the following settings added: t38_udptl=yes t38_udptl_ec=redundancy fax_detect=no t38_udptl_nat=yes For debug logging ensure that logger.conf has has debug specified eg.: console => debug,error,notice,verbose,warning full => debug,error,notice,verbose,warning $asterisk -r freepbx*CLI> core set debug 9 Core debug was OFF and is now 9. freepbx*CLI> pjsip set logger on PJSIP Logging enabled 1 .Setup SIP extensions in "Fax Voip FSP Windows Fax Service Provider " software. Fax Voip FSP->VOIP->SIP->Registrations 2.Check box Fax Voip FSP->VOIP->SIP->T.38 Fax->T.38 Fax reception -> Switch to T.38 on CNG tone received. Other scenarios should probably work but this one would be a good starting point.Attachments:( 0) 3.zip
( 1) 4.zip
( 2) T.38_Fax_Asterisk_Log_2.txt
( 3) T.38_Fax_Receiver_2.pcapng
( 4) T.38_Fax_Sender_2.pcapng
( 5) T.38_Fax_via_3CX.pcapng
Description:Sending a T.38 fax between two extensions running the "Fax Voip FSP Windows Fax Service Provider " on the same Asterisk PBX fails.

My suggestion is to reproduce the scenario of one side sending to the other in order to understand the issues completely, and test any fixes.

In Windows Fax and Scan create a fax and send it to the extension on the other computer.

Please see the notes and discussion on the asterisk community forum (see external issue ID) which lead to this case's creation.
https://community.asterisk.org/t/t-38-fax-passthrough-via-using-pjsip-extensions/72632/3
Comments:By: Asterisk Team (asteriskteam) 2017-11-15 17:36:30.184-0600

Thanks for creating a report! The issue has entered the triage process. That means the issue will wait in this status until a Bug Marshal has an opportunity to review the issue. Once the issue has been reviewed you will receive comments regarding the next steps towards resolution.

A good first step is for you to review the [Asterisk Issue Guidelines|https://wiki.asterisk.org/wiki/display/AST/Asterisk+Issue+Guidelines] if you haven't already. The guidelines detail what is expected from an Asterisk issue report.

Then, if you are submitting a patch, please review the [Patch Contribution Process|https://wiki.asterisk.org/wiki/display/AST/Patch+Contribution+Process].
By: Jared Davison (jdast) 2017-11-15 17:42:28.210-0600

Here is the 2nd example of logged data from my post on the community forum:
 See attachments "T.38 Fax Asterisk Log 2.txt", "T.38 Fax Receiver 2.pcapng", "T.38 Fax Sender 2.pcapng" (Use wireshark to view).

For interpreting the packet captures:
192.168.2.92 is the sender T.38 fax client
192.168.90.131 is the asterisk server
192.168.90.15 is the receiver T.38 fax client
By: Jared Davison (jdast) 2017-11-15 17:50:23.787-0600

The same scenario was performed with the 3CX PBX and that was successful with the same fax client software. The attachment "T.38 Fax via 3CX.pcapng" shows this. Note that in that scenerio:

192.168.2.92 is both the PBX and the Sender fax software
192.168.90.15 is the receiver fax software
By: Richard Mudgett (rmudgett) 2017-11-16 18:03:39.890-0600

Things get confused when the reINVITE collision between Asterisk and the sender (192.168.2.92) happens.  Asterisk is sending its reINVITE to reduce the negotiated codecs from alaw and ulaw to just ulaw.  I'm not sure why the sender is trying to reINVITE because it is asking for ulaw *and* whatever this NSE codec is that we declined earlier.  Because of the collision, the T.38 reINVITE is delayed and Asterisk appears to get confused.  The T.38 communication between channels also appears to get confused so the receiver (192.168.15) doesn't get a response to the reINVITE after the failed T.38 reINVITE.

You could try removing the alaw codec from the allowed codecs in the pjsip endpoints to prevent Asterisk from sending its reINVITE to try avoiding the reINVITE collision.
By: Jared Davison (jdast) 2017-11-21 02:15:07.535-0600

Thank you Richard for your time to analyze this and for providing a suggestion. It sounds like a step in the right direction. I have run the test again.

In this scenario I have set the T.38 Fax receiver client to reinvite t.38 on receiving CNG tone.

See 3.zip containing packet captures and asterisk pjsip logging, and pjsip.endpoint.conf

Thanks for your help.
By: Jared Davison (jdast) 2017-11-21 02:26:28.382-0600

I have had some success!  See 4.zip.

By changing the T.38 Fax client config as follows:

Sending Fax: Switch to T.38 after 0 seconds
Receiver Fax: do not force switching

This is excellent progress for me. Thanks for the help.

I'm not sure why the other reinvites in scenario 3  do not work, may be that is a case for further investigation.

I will keep experimenting with other scenarios.
By: Richard Mudgett (rmudgett) 2017-11-21 07:57:16.664-0600

In the 3.zip log, the sequence gets derailed because the sender (192.168.2.92) is not completing the Asterisk's T.38 reINVITE transaction.

As a note to who looks at the issue:  Asterisk is not sending a 100 Trying in response to the T.38 reINVITE's received for some reason.  Doing this would at least stop the T.38 reINVITE retransmissions while Asterisk waits for a response to the bridged peer.

By: Jared Davison (jdast) 2017-11-21 19:39:20.755-0600

I have just noticed that "disallow" is missing from the pjsip show output. Also, it doesn't appear to be an effective in disabling alaw. I actually have to remove alaw from the allow list. Is this is a bug or by design?  PJSIP docs specify "disallow" https://wiki.asterisk.org/wiki/display/AST/Asterisk+15+Configuration_res_pjsip

pbx*CLI> pjsip show endpoint 800
aggregate_mwi                      : true
allow                              : (ulaw|alaw|gsm|g726|g722)
allow_overlap                      : true
...
cos_video                          : 0
device_state_busy_at               : 0
direct_media                       : true
direct_media_glare_mitigation      : none
direct_media_method                : invite
disable_direct_media_on_nat        : false
dtls_ca_file                       :
dtls_ca_path                       :
dtls_cert_file                     :
dtls_cipher                        :
dtls_fingerprint                   : SHA-256
dtls_private_key                   :
dtls_rekey                         : 0
dtls_setup                         : active
dtls_verify                        : No
dtmf_mode                          : rfc4733
fax_detect                         : false

By: Richard Mudgett (rmudgett) 2017-11-22 10:47:12.840-0600

The disallow is not missing in the output.  That allow line is showing you all codecs that are currently enabled on the endpoint and thus includes the effect of any disallow.  The allow and disallow options are cumulative from the start of the config section and also indicate order of precedence.
{noformat}
disallow=all
allow=g722
allow=g726
allow=gsm
allow=ulaw
allow=alaw
allow=ilbc
disallow=alaw
{noformat}
The above can be more clearly expressed all at once.
{noformat}
allow=!all,g722,g726,gsm,ulaw,ilbc
{noformat}
With the above codecs selected the pjsip show endpoint allow line would be
{noformat}
allow : (g722|g726|gsm|ulaw|ilbc)
{noformat}

By: Jared Davison (jdast) 2017-11-23 03:20:51.914-0600

Excellent! thanks for the explanation, that makes sense. I prefer the single line entry.

I have had success today in getting asterisk passing through T.38 fax calls to and from the PSTN network via a T.38 SIP provider!

I am very happy!

Thank you so much to both of you for your help in my learning exercise!!



By: Richard Mudgett (rmudgett) 2017-11-27 13:37:41.638-0600

Opening this issue up.  There is enough information here to setup sipp scenarios to figure out what is happening with the T.38 state machine.  It is obviously getting confused.