[asterisk-bugs] [JIRA] (ASTERISK-29035) chan_local: Multistream support breaks T.38 faxing

[Asterisk Team (JIRA)]

     [ https://issues.asterisk.org/jira/browse/ASTERISK-29035?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Asterisk Team updated ASTERISK-29035:
-------------------------------------

    Assignee: Asterisk Team  (was: Matthias Hensler)
      Status: Triage  (was: Waiting for Feedback)

> chan_local: Multistream support breaks T.38 faxing
> --------------------------------------------------
>
>                 Key: ASTERISK-29035
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-29035
>             Project: Asterisk
>          Issue Type: Bug
>      Security Level: None
>          Components: Channels/chan_local
>    Affects Versions: 16.12.0, 18.1.0
>         Environment: CentOS 7
>            Reporter: Matthias Hensler
>            Assignee: Asterisk Team
>              Labels: fax, patch
>      Target Release: 16.17.0, 18.3.0
>
>         Attachments: ASTERISK-29035.diff, Inbound-16.11.0-LocalChannel.pcap, Inbound-16.12.0-LocalChannel.pcap, Inbound-16.12.0-NoLocal.pcap
>
>
> After updating from 16.11.0 to 16.12.0 all faxes via SendFax() and ReceiveFax()-applications break, when placed on a Local-channel and T.38 is used.
> Our dialplan makes use of Local-channels when dialing internal numbers and is also used for issuing outgoing fax-traffic via an originate-call using the manager-API. With the rework of chan_local in 16.12.0 (I suspect ASTERISK-28938 here) this breaks our outgoing fax-traffic when the destination uses T.38. If G.711a is used the problem does not occur.
> When looking at some pcap-traces I can see, that the destination reinvites to T.38 after a call is established and sends lots of T.38 packets. However Asterisk simple ignores any T.38-packet and does not respond to any of these packets, until the call is then finally dropped and fax-transmission ultimately fails.
> Fortunately the problem is very easy to reproduce with an inbound fax also. For that I used an older test-instance of Asterisk 17.1.0 which dials in to our real Asterisk instance where the call is placed via a `Dial(Local/...)` to the appropriate extension where ReceiveFax() is running.
> When running Asterisk 16.11.0 everything works as expected (see Inbound-16.11.0-LocalChannel.pcap) where the connection is established with T.38 and the fax is received properly.
> When switching to Asterisk 16.12.0 on the receiving end the exact same setup breaks (see Inbound-16.12.0-LocalChannel.pcap). The connection is established with T.38 and packets are send from the test-instance, but no replies are issued by Asterisk 16.12.0 (we are running ReceiveFax() in debug mode and it does not log anything with 16.12.0, so obviously chan_local does not properly relays the T.38-frames).
> Just by removing the `Dial(Local/...)` from the dialplan and jumping directly to the ReceiveFax()-extension makes the setup work again on Asterisk 16.12.0 (see Inbound-16.12.0-NoLocal.pcap). So I am pretty sure that the culprit results from the recent changes to chan_local.
> I know that using local-channels is not the nicest thing to do, but we rely on it to process call redirections on local numbers, while still keeping proper call data records for correct billing.
> If more debug output besides the pcap-traces, or a proper dialplan example is needed, I am happy to provide it of course.



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