[asterisk-bugs] [JIRA] (ASTERISK-27424) PJSIP T.38 Re-Invites fail between 2 extensions running Fax Voip FSP Windows Fax Service Provider

[Richard Mudgett (JIRA)]

    [ https://issues.asterisk.org/jira/browse/ASTERISK-27424?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=240092#comment-240092 ] 

Richard Mudgett commented on ASTERISK-27424:
--------------------------------------------

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.

> PJSIP T.38 Re-Invites fail between 2 extensions running Fax Voip FSP Windows Fax Service Provider
> -------------------------------------------------------------------------------------------------
>
>                 Key: ASTERISK-27424
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-27424
>             Project: Asterisk
>          Issue Type: Bug
>      Security Level: None
>          Components: Resources/res_pjsip_session, Resources/res_pjsip_t38
>    Affects Versions: 15.1.0
>         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.
>            Reporter: Jared Davison
>            Severity: Minor
>         Attachments: T.38 Fax Asterisk Log 2.txt, T.38 Fax Receiver 2.pcapng, T.38 Fax Sender 2.pcapng, T.38 Fax via 3CX.pcapng
>
>
> 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



--
This message was sent by Atlassian JIRA
(v6.2#6252)