12 thoughts on - T.38 Not Working – Help Needed With Log Interpretation

• Hi,

  – Could you share the details of the SDP in each INVITE and OK packet?
  – How are your SIP endpoints configured in asterisk sip.conf? (the SIP
  trunk provider and the local endpoint)
  – What type is the local endpoint?

  Cheers,

  Frederic

• Hello,

  at first, thanks for helping!

  In the meantime, I have done a lot of research and trial and error, and I could solve that specific problem. Obviously, the dialplan application “Answer” was playing a key role here. My original dialplan snippet (which produced that problem) was:

  exten => _00., 1, NoOp()
  same => n, Set(FAXOPT(gateway)=yes)
  same => n, Dial(SIP/${EXTEN}@27XgY8YwfI2S9NAg)
  same => n, Hangup()

  The problem vanished when I changed that to:

  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()

  However, I got another problem then:

  The fax training now went well, and a part of the fax was transmitted, i.e. switching from G711 to T32 now worked. But after 32 seconds (measured from the begin of the transmission) Asterisk claimed that there was a timeout with receiving an answer to a critical packet, and ended the transmission (by sending BYE messages to both ends).

  Wireshark and SIP debug analysis have shown that this error message is completely humbug. I have thoroughly gone through the logs line by line more times that I could count, and (by following the CSeq) I every time have seen that the error message was relating to one or more OK messages which Asterisk had sent to the provider, but I swear that the provider correctly had ACKed every single of these OK messages. So I really can’t imagine how Asterisk came to the idea that it hadn’t received the answer. Maybe my interpretation of the logs is wrong, but if Wireshark’s logs show an ACK for every OK, all should be well, shouldn’t it?

  Anyway, that means that I now can send an average one page fax document to fast endpoints which do the training quickly and provide high data rates. But if the endpoint is slower or if the fax document has multiple pages or a disadvantageous structure, it will take more than 32 seconds to transmit and thus will be cut by Asterisk. The receiving fax machine in this case either sees a part of the page or some weird random patterns.

  I think that this is a bug in chan_sip which seemingly does not have the best reputation when it comes to T38. The erroneous behaviour has shown in every test I have done (4 different fax machines at the other end serviced by three different providers, each tested with two different SIP providers (trunks)).

  At this point, I have given up chan_sip and hoped that pjsip would behave correctly, but what a frustration: Although spending three complete days with it, I even couldn’t make it do the training. It always makes the SIP provider switch to T38 at once at the very beginning of the transmission which of course won’t work. I think I’ll open another thread about that problem; it’s somehow off-topic here.

  Regards and thank you very much,

  Recursive

• 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.

  One may assume this is your dialplan for the outgoing connection with which you want T.38 to be supported.

  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!

  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.

  Larry.

• 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.

  You are right.

  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.

  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?

  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.

  Unfortunately, the moderator rejected this message in the first version due to oversize (40 kB limit), so I now have removed the logs and instead have put them onto a web server for download.

  The Wireshark overview log (all packets of the fax transmission) is here: http://www.omeganet.de/t38-overview-log.txt

  The detailed packet contents of all INVITE, OK and ACK packets are here: http://www.omeganet.de/t38-detailed-log.txt

  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.
  – 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.

  Asterisk console log remarks:

  – I do the tests after having started Asterisk by “asterisk -c” so that I immediately see serious errors or warnings at the console.
  – In this case, after having freshly started Asterisk, having re-registered the fax software endpoint, and having tried to send the fax, there are two console messages. The first one claims that the critical packet with CSeq 4264 timed out after 32 seconds, and the second one tells us that Asterisk hung up due to this.
  – Please note that the 32 seconds are exactly the time between the second INVITE series and the BYE messages in the Wireshark overview log.
  – This means that Asterisk thinks that packet CSeq 4264 has timed out *although* the Wireshark overview log clearly shows that every packet of this CSeq has been ACKed by the local fax software.

  Oddities which I have seen myself so far (which may or may not be responsible for the failures – this is beyond my current knowledge):

  – At the begin of the T.38 communication (packet 28879), the local fax software invites Asterisk with 0049…@…, and Asterisk then invites the provider with 49…@…, i.e. Asterisk cuts off the leading two zeroes. Why? I don’t think my dialplan does Asterisk instruct to do so.
  – In packet 28887, Asterisk gives 0049…@192.168.20.48 as contact. But in the original invite in packet 28879, the contact was 0049…@spock-asterisk.home.omeganet.de. Is this bad?

  Thank you very much in advance to everybody who tries to help.

  Regards,

  Recursive

  ********************
  This is my sip.conf:
  ********************

  [general]
  session-timers = refuse context=unauthenticated allowguest=no allowoverlap=no udpbindaddr2.168.20.48:5060
  tcpenable=no tcpbindaddr2.168.20.48:5060
  tlsenable=no tlsbindaddr2.168.20.48:5061
  transport=udp srvlookup=no defaultexpiry`0

  nat = no directmedia = no ignoresdpversion=yes

  register => USERNAME_PROVIDER:PASSWORD_PROVIDER@proxy.provider.net/USERNAME_PROVIDER

  [authentication]

  ;David T38 endpoint
  [bCo9m7OfHWK2Y2sb]
  context = david_t38_inbound type = peer host = dynamic secret = PASSWORD_FAX
  t38pt_udptl = yes,redundancy,maxdatagram@0
  t38pt_rtp = no t38pt_tcp = no insecure = port,invite canreinvite = yes

  ;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@0
  t38_rtp = no t38_tcp = no canreinvite = yes

  ***************************
  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()

  *********************************************
  These are the messages in Asterisk’s console:
  *********************************************

  *CLI> [Dec 13 12:51:01] WARNING[5651]: chan_sip.c:4046 retrans_pkt: Retransmission timeout reached on transmission 24edd33abaae904f for seqno 4264 (Critical Response) — See https://wiki.asterisk.org/wiki/display/AST/SIP+Retransmissions Packet timed out after 32000ms with no response
  [Dec 13 12:51:01] WARNING[5651]: chan_sip.c:4075 retrans_pkt: Hanging up call 24edd33abaae904f – no reply to our critical packet (see https://wiki.asterisk.org/wiki/display/AST/SIP+Retransmissions).

• Frederic, I now have tried to describe the situation very clearly, and I have provided some logs for download. Sorry for not directly including them, but they are too lengthy so the moderator rejected the respective message.

  I would be grateful if you could refer to my message from some minutes ago. I have provided all the details there.

  Thank you very much,

  Recursive

• Just to be sure: Is this the situation with FAXOPT(gateway)=no or with FAXOPT(gateway)=yes?

  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).

  *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.

  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.

  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

  —

• I’m just going to comment on the ‘directmedia’/’canreinvite’ points here.

  1) There is no ‘reinvite’ setting in chan_sip. If you patched Asterisk, than your mileage may vary.
  2) ‘directmedia’ is the same thing as ‘canreinvite’. They are the same setting. ‘directmedia’ replaced the nomenclature ‘canreinvite’ because it actually describes what the setting does: it determines whether or not Asterisk will attempt to re-INVITE media directly between RTP
  capable peers.
  3) While documentation sometimes is lacking for some parts of Asterisk, this setting is actually pretty well documented in sip.conf.sample:

  {quote}
  ; By default, Asterisk tries to re-invite media streams to an optimal path. If there’s
  ; no reason for Asterisk to stay in the media path, the media will be redirected.
  ; This does not really work well in the case where Asterisk is outside and the
  ; clients are on the inside of a NAT. In that case, you want to set directmedia=nonat.
  ;
  ;directmedia=yes ; Asterisk by default tries to redirect the
  ; RTP media stream to go directly from
  ; the caller to the callee. Some devices do not
  ; support this (especially if one of them is behind a NAT).
  ; The default setting is YES. If you have all clients
  ; behind a NAT, or for some other reason want Asterisk to
  ; stay in the audio path, you may want to turn this off.

  ; This setting also affect direct RTP
  ; at call setup (a new feature in 1.4
  – setting up the
  ; call directly between the endpoints instead of sending
  ; a re-INVITE).

  ; Additionally this option does not disable all reINVITE operations.
  ; It only controls Asterisk generating reINVITEs for the specific
  ; purpose of setting up a direct media path. If a reINVITE is
  ; needed to switch a media stream to inactive (when placed on
  ; hold) or to T.38, it will still be done, regardless of this
  ; setting. Note that direct T.38 is not supported.

  ;directmedia=nonat ; An additional option is to allow media path redirection
  ; (reinvite) but only when the peer where the media is being
  ; sent is known to not be behind a NAT
  (as the RTP core can
  ; determine it based on the apparent IP address the media
  ; arrives from).

  ;directmedia=update ; Yet a third option… use UPDATE for media path redirection,
  ; instead of INVITE. This can be combined with ‘nonat’, as
  ; ‘directmedia=update,nonat’. It implies ‘yes’.

  ;directmedia=outgoing ; When sending directmedia reinvites, do not send an immediate
  ; reinvite on an incoming call leg. This option is useful when
  ; peered with another SIP user agent that is known to send
  ; immediate direct media reinvites upon call establishment. Setting
  ; the option in this situation helps to prevent potential glares.
  ; Setting this option implies ‘yes’.

  {quote}

  Note that none of this matters until you are in a bridge. If you are in a bridge, I would expect Asterisk to re-INVITE the media back to Asterisk when one of the sides offers T.38 (and, in fact, we have automated tests that check for this sort of thing). You shouldn’t have to set directmedia to ‘no’, but – in the interest of making your system easier to debug and to remove variables – you may want to set it to ‘no’ for the involved peers.

  Just use ‘directmedia’. They are the same setting (snippet from chan_sip’s configuration parsing):

  } else if (!strcasecmp(v->name, “directmedia”) ||
  !strcasecmp(v->name, “canreinvite”)) {
  ast_set_flag(&mask[0], SIP_REINVITE);
  …

  Note that these settings and their behaviour is the same from 1.8
  through 13. While I’m glad to see anyone using the latest and greatest
  – yay Asterisk 13! – this isn’t a reason to go to Asterisk 13.

  Matt

• Matt, thank you very much for your help!

  I didn’t patch. Just using “vanilla” Asterisk from your website …

  This information is very valuable to me as it drastically cuts the number possible parameter combinations.

  You are right. After compiling, I have made and installed the configuration sample files and have read those of them which I thought I needed. Thus, I already have read the section regarding directmedia, but I never would have come to the idea that this could be the same as canreinvite. Most examples around the net still use both without further explanation; even my ITSP sent me a sample configuration which also used both. Once again, thanks for clarifying!

  I think I am in a bridge. As far as I can recall, I have seen respective messages in the Asterisk console after having started Asterisk with -vvvc, and as far as I have understood, there is no support for direct T38. I’ll test again …

  Thanks again … very instructive.

  For me, the reason was that I thought that I needed the gateway capability for faxing via T.38 (seems that I was wrong here), and that I didn’t see any T.38 packet in the logs when using 1.8.x (regardless of which configuration parameters I was using).

  Matt, I nearly don’t dare to ask, but could you eventually take a quick look into the logs I have provided? Do you see any reason why asterisk hangs up, claiming a critical packet timeout, although all packets seemingly have been answered timely and appropriately?

  Regards,

  Recursive

• 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.

  —

• Hi,

  According to the detailed trace asterisk is indeed retransmitting SIP
  OK messages:

  
  Session Initiation Protocol (200)
  Status-Line: SIP/2.0 200 OK
  Status-Code: 200
  [Resent Packet: True]
  [Suspected resend of frame: 28887]
  [Request Frame: 28888]
  [Response Time (ms): 592]
  

  It does this although the other endpoint does respond with an ACK
  message. My guess is that there’s something in the ACK messages that asterisk does not like and thus discards. The 32 seconds you mention correlate to the default 32 seconds Timer-B value. Have you tried to enable SIP debugging and asterisk debugging? There should be a clue in the asterisk debug log. You can try increasing the timerb value in sip.conf to confirm this:
  quote from sip.conf.sample
  ;timerb2000 ; Call setup timer. If a provisional response is not received
  ; in this amount of time, the call will autocongest
  ; Defaults to 64*timert1

  Apart from that, I would indeed advise to remove the Answer and Progress applications from the dialplan. Just dial the peer and let it handle the session.

  Cheers,

  Frederic

• Until now, I only have tested the sending direction (from the fax software’s point of view) since the ITSP told me that would be the easy part.

  Some days ago, I made a dialplan with ReceiveFax() and was able to send a fax with multiple pages from the fax software to Asterisk. The TIFF file which Asterisk produced did not contain any errors, and there were no errors in the Asterisk logs or in the fax software’s GUI.

  As a next step, I took that TIFF, made another dialplan with SendFax() and used that to send the TIFF file to another fax machine which is serviced by another ITSP (ISDN + PBX). Once again, this happened without any errors (same ITSP, same settings).

  So the problems seem to arise only when Asterisk is in the middle.

  I did not test the receive direction yet.

  I’ll now backup my Asterisk configuration for future reference and research and start to try all the suggestions from the helpful people here step by step. I’ll report back as soon I have a result.

  Regards,

  Recursive

• Dear Frederic, Larry and Matt,

  I believe I now have tried all suggestions which you have made.

  Unfortunately, none of them worked. Generally, I am still unable to send faxes. I now have one fax machine (serviced by another provider) to which I can reliably send faxes with arbitrary size (i.e. arbitrary number of pages), but trying to send faxes to other fax machines still reliably fails for seemingly weird reasons, either Asterisk, the ITSP or my local fax software initiating the hangup, depending on the configuration.

  So, I now have decided to give up on chan_sip and to try res_pjsip / chan_pjsip instead.

  Thank you very much again to all who tried to help.

  Regards,

  Recursive