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

[Larry Moore]

Just a thought regarding testing.

Create a suitable TIFF file with more than 30 seconds worth of data and 
send it from Asterisk using SendFAX() to convince yourself whether 
Asterisk will work with your ITSP, you may still need to enable session 
timers.

Have you considered setting up an extension on your Asterisk server 
which will receive the fax e.g. using ReceiveFAX() and see if your 
connection problem persists?

Larry.


On 15/12/2014 5:10 AM, Larry Moore wrote:
>
>
> On 14/12/2014 7:24 PM, Recursive wrote:
>>
>> On 11.12.2014 11:53, Larry Moore wrote:
>>> You may very well find getting T.38 working in your environment in a
>>> way you would like will consume a large amount of your time, you will
>>> also find yourself doing a lot of research. What you should have
>>> found out by now (or perhaps deduced) is that the T.38 is a standard
>>> that is varied thus one cannot be assured a T.38 solution will always
>>> work.
>>
>> Agreed. But firstly, I really need a working fax, and secondly, I am
>> just trying to make it work with one specific provider (I have
>> identified two providers in Germany which could be a possibility and
>> have signed up a full account with both of them for testing purposes
>> (no problem since the fees are small and the cancellation period is
>> short in both cases), and as soon as one of these works like expected
>> I'll cancel the contract with the other one). So I don't need to have
>> a general solution which works with every provider around the world.
>>
>>>> exten => _00., 1, NoOp()
>>>> same => n, Answer()
>>>> same => n, Progress()
>>>> same => n, Set(FAXOPT(gateway)=yes)
>>>> same => n, Dial(SIP/${EXTEN}@27XgY8YwfI2S9NAg)
>>>> same => n, Hangup()
>>>
>>> One may assume this is your dialplan for the outgoing connection with
>>> which you want T.38 to be supported.
>>
>> You are right.
>>
>>> To obtain better assistance you will need to include information such
>>> as what the local T.38 endpoint is and how it connects to your
>>> system. If it is in fact a T.38 capable endpoint then you should
>>> setting FAXOPT(gateway) to no. having Answer()& Progress() for an
>>> outgoing T.38 connection doesn't seem to make sense to me!
>>
>> The endpoint is T.38 capable. I have configured FAXOPT(gateway)=yes
>> because I have read that the gateway automatically goes out of the way
>> if Asterisk determines that the two endpoints which should be
>> connected use the same protocols and parameters, and otherwise
>> translates between the endpoints (see
>> https://wiki.asterisk.org/wiki/display/AST/T.38+Fax+Gateway, section
>> "Using T.38 gateway mode").
>>
>> Furthermore, T.38 passthrough never worked for me. My initial tries
>> were with Asterisk 1.8 which is included in Debian wheezy (and does
>> not have the gateway capability anyway), but whatever I did there, no
>> T.38 INVITE was accepted by Asterisk (this was some weeks ago, so I
>> don't remember the details). I then downloaded, compiled and installed
>> Asterisk 13.0.1 and tried T.38 passthrough, but to no avail as well.
>> When I added FAXOPT(gateway)=yes, I saw correct T.38 INVITEs for the
>> first time.
>>
>
> See comment regarding 'canreinvite'.
>
>> Regarding Progress(), I am not sure if I need this. I think one day I
>> could solve a certain problem by using it, but I really have done a
>> million of tries and don't remember every one.
>>
>> Regarding Answer(), I think I need this. Without Answer(), no T.38
>> would be used in many cases; it seems that switching from initial
>> G.711 to T.38 is done in-band, and that couldn't be done without the
>> Answer() in the dialplan, could it?
>>
>
> Your ITSP should be sending the T.38 invite to Asterisk when they detect
> the fax tones from the answered call (callee), it would appear you are
> _forcing_ the T.38 session by using the Answer() function, you are then
> relying on the activity detection period of the FAXOPT(gateway) function
> for the call to be established.
>
> 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.
>
> The real issue here is having current versions of Asterisk & T.38
> working as expected all the way through.
>
>>> You should also include information relating to your SIP
>>> configuration (with appropriate obfuscations) for the connection to
>>> peer 27XgY8YwfI2S9NAg as well as what T.38 options you have set in
>>> the general section of sip.conf.
>>
>> You are right. I will now provide every detail and the logs. By the
>> way, I have switched back to chan_sip today for the purpose of testing
>> again and generating logs.
>>
>> General remarks:
>>
>> - Asterisk runs on the IP address 192.168.20.48.
>> - The hostname spock-asterisk.home.omeganet.de resolves to that IP
>> address.
>> - The fax software is Tobit David which is T.38 capable. I can't use
>> another fax software; an extensive explanation for that would be
>> off-topic here, but if somebody is interested, I will send respective
>> information via PM.
>> - The fax software runs on another machine than Asterisk.
>> - The fax software runs on the IP address 192.168.20.14.
>> - I don't want Asterisk to do any NAT wizardry because I have
>> configured my firewall to do the NAT for SIP and RTP.
>> - I am very sure that NAT is not the problem.
>
> 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'.
>
>> - In extensions.conf, I basically have configured only one extension
>> pattern for outbound fax calls (to keep tests simple). The pattern is
>> _00. (for testing, I make the fax software call numbers which always
>> begin with 0049, so this pattern is sufficient).
>> - In sip.conf, the context for the provider is "unauthenticated" since
>> the first step is to send a fax (and not to receive one, which I think
>> is more complicated).
>>
>> Wireshark overview log remarks:
>>
>> - The overview log shows that it works in principle: A first INVITE
>> series happens, and some G.711 data is exchanged between Asterisk and
>> the fax software.
>> - After this, a second INVITE series happens, everybody switches to
>> T.38, and UDPTL packets are exchanged.
>> - The second INVITE series starts at second 15 (packet 28879).
>> - The second INVITE series is begun by the local fax software with
>> CSeq 4264.
>> - Up to this point, all INVITEs, OKs and ACKs are in the right order.
>> - The training begins and is finished successfully, and the actual fax
>> data begins to flow.
>> - Every few seconds, Asterisk send an OK message (with CSeq 4264 (as
>> in original INVITE)) to the local fax software.
>> - Please note that the local fax software *always* correctly ACKs
>> these OK messages (with CSeq 4264 (as in original INVITE)).
>> - Nevertheless, at about second 47, Asterisk says "BYE" to both
>> parties (i.e. local fax software and provider) *although* the fax
>> transfer is not finished yet.
>> - Note that there are 32 seconds between the begin of the second
>> INVITE series and the BYE messages.
>>
>>
>
> 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?
>
> 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!
>
>
>>
>> ********************
>> This is my sip.conf:
>> ********************
>>
>> [general]
>> session-timers = refuse
>
> Try 'session-timers=accept'
>
>> context=unauthenticated
>> allowguest=no
>> allowoverlap=no
>> udpbindaddr=192.168.20.48:5060
>> tcpenable=no
>> tcpbindaddr=192.168.20.48:5060
>> tlsenable=no
>> tlsbindaddr=192.168.20.48:5061
>> transport=udp
>> srvlookup=no
>> defaultexpiry=600
>>
>> nat = no
>> directmedia = no
>> ignoresdpversion=yes
>>
>> register =>
>> USERNAME_PROVIDER:PASSWORD_PROVIDER at proxy.provider.net/USERNAME_PROVIDER
>>
>
> What is the 'Refresh' value returned from 'sip show registry'?
>
>> [authentication]
>>
>> ;David T38 endpoint
>> [bCo9m7OfHWK2Y2sb]
>> context = david_t38_inbound
>> type = peer
>> host = dynamic
>> secret = PASSWORD_FAX
>> t38pt_udptl = yes,redundancy,maxdatagram=400
>> t38pt_rtp = no
>> t38pt_tcp = no
>> insecure = port,invite
>> canreinvite = yes
>>
>
> 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.
>
>> ;Trunk (SIP provider)
>> [USERNAME_PROVIDER]
>> context = unauthenticated
>> type = peer
>> host = proxy.provider.net
>> outboundproxy = proxy.provider.net
>> defaultuser = USERNAME_PROVIDER
>> fromuser = USERNAME_PROVIDER
>> fromdomain = proxy.provider.net
>> remotesecret = PASSWORD_PROVIDER
>> insecure = port,invite
>> t38pt_udptl = yes,redundancy,maxdatagram=400
>> t38_rtp = no
>> t38_tcp = no
>> canreinvite = yes
>>
>
> 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.
>
>>
>> ***************************
>> This is my extensions.conf:
>> ***************************
>>
>> [general]
>> static=yes
>> writeprotect=no
>> clearglobalvars=no
>>
>> [globals]
>>
>> [default]
>> exten => s, 1, Hangup()
>>
>> [unauthenticated]
>> exten => s, 1, Hangup()
>>
>> [david_t38_inbound]
>> exten => _00., 1, NoOp()
>> same => n, Answer()
>> same => n, Progress()
>> same => n, Set(FAXOPT(gateway)=yes)
>> same => n, Dial(SIP/${EXTEN}@USERNAME_PROVIDER)
>> same => n, Hangup()
>>
>>
>
> 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.
>
> Cheers,
>
> Larry.