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...@..., 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 [email protected] as contact. But in the
original invite in packet 28879, the contact was
[email protected]. 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:[email protected]/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).
--
_____________________________________________________________________
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
New to Asterisk? Join us for a live introductory webinar every Thurs:
http://www.asterisk.org/hello
asterisk-users mailing list
To UNSUBSCRIBE or update options visit:
http://lists.digium.com/mailman/listinfo/asterisk-users
