Thanks abc123! Actually I've already done some Wireshark captures and managed to find out what is going on (at my end, at least).
3CX does indeed send the T.38 re-INVITE back, and always has been, but you'd never know it from the logs it produces in the GUI ("Server Activity Log"). I can see now that it's quite normal for 3CX to use port 10002/10003 for the initial audio RTP connection. That connection only lasts for a second though, and then 3CX sends the re-invite back to the VoIP provider and does indeed use port 10000 as per the config file (though you don't see any this in the 3CX logs -- you have to use Wireshark).
I still don't have faxing working. My VoIP provider seems to be ignoring the T.38 packets coming back at it, even though it accepts the T.38 re-invite and provides a media IP and port to use in its SIP SDP. So no audio is heard at the other end, no matter which phone or fax machine I call from. But at least I can see from the Wireshark captures that 3CX is indeed sending out the T.38 v21-preamble (fax handshaking signal), etc. It's just that that never gets converted to audio to make it through to the other end of the call.
I don't expect to hear the fax tones when calling from an internal extension or some phone on my SIP network as I realise that usually won't work and is therefore not a good test. All of my test calls are from another regular line/fax machine, or cell phone.
I've contacted my provider and hope to hear more back from them. They've already assured me that they definitely support T.38 and that many customers are using it. And based on the Wireshark captures I can even see that they're advertising T.38 in the initial SIP INVITE SDP that they send when a call arrives. So I don't doubt that they do indeed support T.38. But for some reason, the 3CX-generated T.38 packets are being rejected or ignored by the provider. I've checked that they're being sent to the correct IP/port that the provider specifies in the SDP after accepting the re-invite, and they are.
So I'm really at a loss now. Are there just weird compatibility problems with T.38 that could cause the protocol to fail in many environments? I want to tweak values, but nothing in the 3CX Fax Service provisioning files are really properly documented, other than the basic network/NAT settings.
Yes, I have all the appropriate ports open and I can clearly see the traffic coming in and leaving correctly (except I don't seem to get any T.38 packets from the VoIP provder on port 10000 -- but the port is definitely open and forwarded and 3CX is correctly specifying it in the SDP of the re-invite, so I think this is related to the whole general issue that the provider doesn't seem to like 3CX T.38 packets).
It makes me wonder, is this whole "initiate call, wait for one second, then re-invite back using T.38" the typical way of handling FoIP? Or is it just a 3CX thing? (Sure, I know the concept of re-invites in general is pretty standard, but I mean in relation to handling fax calls). Maybe some providers just aren't geared up for that approach. They say they have heaps of customers using Asterisk with T.38, so I'm wondering if Asterisk uses the same approach.
Any thoughts at this stage are really helpful!
And any explanations for some of the values in the provisioning files. Eg. I can see that in the default in_session.cfg the "T.38 remote capabilities" section has TCP parameters that are commented out. Are these important if TCP is to be used, in relation to the "kind of T.38 transport = " setting above. There's a comment about this latter setting, but it doesn't also mention those TCP settings below. Anyway, I'm using UDP and expecting it should work as a baseline. Also the "incoming call no filter = FALSE" setting in the "T.38 media address" section is possibly of interest, but not documented anywhere. Even Google doesn't bring up anything much for any of these settings except for basically a couple of posts on this forum (now my post will cause more!).
Cheers!
irectSDP is 1 then there is most likely an error in your config files.
