[asterisk-users] T.38 not working - help needed with log interpretation

Recursive lists at binarus.de
Mon Dec 15 03:34:53 CST 2014


On 14.12.2014 22:10, Larry Moore wrote:
> Asterisk 1.8 with the T.38 Gateway patch (not the one by Niccolò Belli) sends a T.38 invite to the ITSP when the fax tones are detected from the callee, the T.38 Gateway implementation in Asterisk 10 and Niccolò's back-port for Asterisk 1.8.11 does not behave this way.
> 
Just to be sure: Is this the situation with FAXOPT(gateway)=no or with FAXOPT(gateway)=yes?

> The real issue here is having current versions of Asterisk & T.38 working as expected all the way through.
>
Only my initial tries were with Asterisk 1.8. Since that didn't work in any way, I have downloaded and compiled Asterisk 13.0.1, and I am currently using no other major version than 13 when doing the tests.

> Perhaps you have a good reason for wanting to set up your firewall to handle SIP and RTP, presumably using a SIP ALG - for the sake of testing and confirming your problem is not related to your firewall's NAT wizardry I would advise you disable this on the firewall and enable NAT in Asterisk, this should only be required for the trunk or any other connection traversing your firewall to the Internet from Asterisk. Of course you will need to allow ports through for RTP and UDPTL, you can list the range of UDPTL ports using the command 'udptl show config'.
>

The first reason is that I am quite familiar with firewalls, but not with Asterisk :-) The second reason is that (as far as I have understood) you eventually have to enable port forwarding for the RTP packets in the firewall if you let Asterisk do the NAT. That's a thing I don't want to do for several reasons.

Instead, I prefer to let the firewall inspect the SIP packets and to open the associated ports for the associated streams dynamically. This works like a charm so far, for my fax tests as well as for my SIP phones (I don't have any problems with voice VoIP calls, inbound or outbound). I know that I eventually will get problems when it comes to encrypted calls, but that's a project for a later time.

However, I'll do what you suggested for testing purposes. But I'm wondering how that could change the situation. From my understanding, my problem is that asterisk hangs up the call because it believes that it didn't get a timely reply to a packet which it has sent to the _local_ fax software. There is _no_ firewall between Asterisk and the local fax software; they are in the same network (192.168.20.x).

> In Wireshark, have you used the 'VoIP Calls' option under Telephony then selected a sessions and clicked on the 'Flow' button, it may be helpful?
>
No, I just have captured all traffic on the machine where Asterisk runs (using tcpdump), have imported the dump into Wireshark and have filtered out all packets which are not IP packets to or from Asterisk (192.168.20.48). I am convinced that I am seeing the complete conversation after that.

> I suspect because you have set Session Timers to be rejected, one of the endpoints is relying upon this being enabled. There doesn't appear to be anything in the Asterisk logs relating to Session Timers!
>
I set session-timers = refuse because the ITSP instructed me to do so. I will change that and test.

> What is the 'Refresh' value returned from 'sip show registry'?
> 
*CLI> sip show registry
Host                     dnsmgr Username           Refresh State       Reg.Time                 
proxy.provider.net:5060  N      USERNAME_PROVIDER      585 Registered  Mon, 15 Dec 2014 09:33:44
1 SIP registrations.

> For asterisk 1.6 & 1.8 you would need to set 'canreinvite=no', I don't know what Asterisk 13 will do with this setting.
>
I suspect Asterisk 13 will just ignore it. To make things worse, there seems to be a configuration directive named reinvite (not a typo); I have found it in at least one example and one article, but with no documentation, so the difference between canreinvite and reinvite is completely unclear to me. chan_sip seems to be documented very poorly, unlike chan_pjsip / res_pjsip.

> For asterisk 1.6 & 1.8 you would need to set 'canreinvite=no', it may be safer to add 'directmedia=no' to your peer configurations in case you change the global setting.
> 
I'll add directmedia = no to the peer configuration, and I'll remove canreinvite at all since I definitely won't use Asterisk below major version 13 any more.

> With your firewall having the SIP and RTP wizadry disabled and Asterisk set up to use Session-Timers and NAT your connection (you may need to set up port forwardings for RTCP to work) it would be interesting to know if the following dialplan will allow T.38 to be established.
> 
> [david_t38_inbound]
> exten => _00., 1, NoOp()
>   same => n, Set(FAXOPT(gateway)=no)
>   same => n, Dial(SIP/${EXTEN}@USERNAME_PROVIDER)
>   same => n, Hangup()
> 
> 
> If no T.38 negotiation occurs I suspect your ITSP is not sending the T.38 re-invite for your outgoing call.
>
I'll try and report back.

Larry, thanks for your valuable time and hints. I will need some days to try all the things you suggested, to record the logs and to report the results.

But while doing so, I think we shouldn't forget that I'm almost there. At least, I obviously can transfer fax data via T.38, and I am convinced that it would work completely if Asterisk didn't hangup the call (seemingly) without any reason.

Although I would be happy if I could make T.38 work as intended by its designers, I would be happy as well if I only could make it work in practice, independent of the theory. Thus, hoping to not being flamed after having said this, since I'm almost there, it is not important for me who invites whom, but I think the key to success would be to find out why Asterisk hangs up the call prematurely.

Of course, I will try all your suggestions. But I am also still seeing a chance to solve the problem by looking into the logs. There must be something which explains the premature hangup, something which I have not seen yet due to my limited knowledge. Do you have any additional idea regarding this? Do you see any packet in the logs from Asterisk to the local fax software which is not answered timely and appropriately?

Thank you very much,

Recursive




More information about the asterisk-users mailing list