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