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:[email protected]/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.
