asterisk users - Dec 2014 - T.38 not working - help needed with log interpretation

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



On 10.12.2014 11:42, Frederic Van Espen wrote:
> Hi,
> 
> On Tue, Dec 2, 2014 at 9:24 AM, Recursive <lists at binarus.de>
wrote:
>> - Packets 14313, 14314: The provider re-invites asterisk for T.38
(confirmed by viewing the packet's details), asterisk answers "Trying
..." to the provider
>> - Packets 14315, 14321, 14322: Asterisk re-invites the local endpoint
(again confirmed by looking into the packet's details), the local endpoint
answers "OK", and asterisk ACKs the OK.
>> - Packets 14323, 14329: Asterisk accepts the invitation from the
provider by sending "OK" to the provider, and the provider ACKs the
OK.
>> - Packets 14453, 14454 and 14649: The local endpoint again tries to
re-invite asterisk for T.38 (confirmed by looking into the packet's
details), Asterisk answers "Trying" and then refuses, saying
"488: Not acceptable here"
>> - From then on, things go horribly wrong (probably, the local endpoint
is still expecting G.711 packets, but gets T.38 packets)
>>
>> I have provided all packets which are relevant. The packet numbers are
not contiguous since asterisk currently is on a test server which runs many
other services (the packets of which I have filtered out).
>>
>> I didn't want to clutter this post too much, thus I have only
provided an overview and not the details of each packet. Furthermore, please
forgive me that it's much easier for me to read Wireshark's logs than
Asterisk's logs. Of course, I will provide every log anybody trying to help
out asks me for.
>>
>> But my first question is a very simple one:
>>
>> From the log above, I am quite sure that switching to T.38 is done
right up to (and including) packet 14329. I think that my local endpoint then
misbehaves by again re-inviting asterisk for T.38 (as all parties already have
agreed upon T.38).
>>
>> Thus, is my endpoint really misbehaving, and if yes, is there anything
I can do about it on Asterisk's side? Or do the SIP/T.38 state machines
allow such (seemingly superfluous) re-invite, and it's Asterisk's fault
to answer with 488?
> 
> - 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
>

On 11/12/2014 4:52 PM, Recursive wrote:
> 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:
>
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.
> 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()
>
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.

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

On 14.12.2014 22:10, Larry Moore wrote:
> 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.
> 
Just to be sure: Is this the situation with FAXOPT(gateway)=no or with
FAXOPT(gateway)=yes?
> The real issue here is having current versions of Asterisk & T.38
working as expected all the way through.
>
Only my initial tries were with Asterisk 1.8. Since that didn't work in any
way, I have downloaded and compiled Asterisk 13.0.1, and I am currently using no
other major version than 13 when doing the tests.
> 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'.
>
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).
> 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?
>
No, I just have captured all traffic on the machine where Asterisk runs (using
tcpdump), have imported the dump into Wireshark and have filtered out all
packets which are not IP packets to or from Asterisk (192.168.20.48). I am
convinced that I am seeing the complete conversation after that.
> 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!
>
I set session-timers = refuse because the ITSP instructed me to do so. I will
change that and test.
> What is the 'Refresh' value returned from 'sip show
registry'?
> 
*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.
> 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.
>
I suspect Asterisk 13 will just ignore it. To make things worse, there seems to
be a configuration directive named reinvite (not a typo); I have found it in at
least one example and one article, but with no documentation, so the difference
between canreinvite and reinvite is completely unclear to me. chan_sip seems to
be documented very poorly, unlike chan_pjsip / res_pjsip.
> 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.
> 
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.
> 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.
>
I'll try and report back.

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

On Mon, Dec 15, 2014 at 3:34 AM, Recursive <lists at binarus.de>
wrote:
>
<snip>
>> 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.
>>
> I suspect Asterisk 13 will just ignore it. To make things worse, there
seems to be a configuration directive named reinvite (not a typo); I have found
it in at least one example and one article, but with no documentation, so the
difference between canreinvite and reinvite is completely unclear to me.
chan_sip seems to be documented very poorly, unlike chan_pjsip / res_pjsip.
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.
>> 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.
>>
> 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.
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

-- 
Matthew Jordan
Digium, Inc. | Engineering Manager
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
Check us out at: http://digium.com & http://asterisk.org

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.

On 16.12.2014 11:41, Larry Moore wrote:
> 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?
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