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

Mon Dec 15 01:51:17 CST 2014

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.

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

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... at ..., and Asterisk then invites the provider with 49... at ..., 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... at 192.168.20.48 as contact. But in the original invite in packet 28879, the contact was 0049... at 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
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

[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

;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

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