V14SP1 - incoming Fax - T38 Software

[Futureweb]

Hello,

we want to use http://www.t38faxvoip.com/ for handling incoming/outbound T38 Faxes. When the Software is connected directly to our Trunk - incoming Faxes work like a Charm. When I connect it through 3CX - all incoming Faxes are failing (The call dropped prematurely)
Outbound is working if it's connected directly or if it's connected through 3CX.
T38FaxVoip is connected to a 3CX FAX-Extension. Incoming Route is EXT-->Send Fax to *Fax Extension Number*

Is 3CX modifying the SIP Data passed to the Fax Software attached to the Fax-Extension? Can I tell 3CX to pass the Stream 100% unmodified?
Anyone any Idea how to get this Setup running?

Thx, bye from Austria
Andreas Schnederle-Wagner

 

[lneblett]

In looking at their site, they only list Axon as a compatible PBX.

Now then, I assume that when you mention the "fax extension number" that this is really a fax server extension as created by 3CX using the tab labeled "FAX"? if so, then this is a receive only function, so I then assume when you indicate that you can send via 3CX this is being done from a normally created extension.

The fax server is the only type of extension that will make use of the t38 protocol. The media server will use the other codecs for the non-fax server extensions and presumably you are using a g711 codec when sending.

It is unlikely that 3CX is modifying the SIP headers on the receive, but only a wireshark capture will show the whole story. My guess is that the fax call from the 3rd party software is not being presented correctly. By this I mean that the fax server extension will only accept a t38 connection. As the 3rd party is apparently receiving it (supposedly as a t38) and then relaying the output in some fashion, I think it likely that it is incompatible with the fax server extension. I could not find enough detail on how it handles incoming faxes so I am guessing to an extent, The site does not reflect being able to relay or how it is delivered other than to say:

"Incoming Routing Methods (Route through e-mail, Store in a folder, Print) allow you to route incoming faxes to recipients on the network."

I can only suggest that instead of sending to the fax server extension you might try sending to the same regular extension from which you reported having success in sending a fax.

 

[Futureweb]

Hi lneblett,

thank you for taking the time looking into this problem! ;-)

When speaking about "Fax Extension" I indeed talk about Extensions created within the Tab "Fax":

T38FaxVoip is connecting to 7779 EXT and is able to SEND T38 Faxes with no Problems?

System Extensions Status while sending Fax:

So I guess the 3CX Fax Extensions are not "receive only"?!

System Extensions Status while sending a Fax:

T38FaxVoip Status:

<-- states the Fax was sended using T.38

Inbound Routing:

System Extensions Status while receiving Fax:

T38FaxVoip Status:

So it seems that 3CX isn't just proxying the T.38 through to the Fax extension? As I know the Software is working with the Trunk - but not when connected behind the 3CX Fax Extension! :-(

Guess I need to install Wireshark on the 3CX Server and get a Package Capture of a receiving Fax?

Andreas

 

[Futureweb]

Hi,

I created a Package Dump for a failed Fax call to my Fax-EXT 7779 - unfortunately I'm not really used to SIP/T.38 Protocoll - so I'm not really capable to see where the problem is! :-/
Maybe someone more experienced can help me here? ;-)

3CX Log:

26-Nov-2015 15:18:26.263   Leg L:1157.2[Fax] is terminated: Cause: BYE from PBX
26-Nov-2015 15:18:26.262   [CM503008]: Call(C:1157): Call is terminated
26-Nov-2015 15:18:26.262   Leg L:1157.1[Line:10000<<Anonymous] is terminated: Cause: BYE from PBX
26-Nov-2015 15:18:19.804   [CM503007]: Call(C:1157): Fax:7779 has joined, contact <sip:[email protected]:5070>
26-Nov-2015 15:18:19.803   [CM503007]: Call(C:1157): Line:10000<<Anonymous has joined, contact <sip:[email protected]:5060>
26-Nov-2015 15:18:19.801   L:1157.2[Fax] has joined to L:1157.1[Line:10000<<Anonymous]
26-Nov-2015 15:18:19.759   Currently active calls - 3: [1151,1156,1157]
26-Nov-2015 15:18:19.668   [CM503025]: Call(C:1157): Calling T:Fax:7779@[Dev:sip:[email protected]:5070] for L:1157.1[Line:10000<<Anonymous]
26-Nov-2015 15:18:19.635   [CM503027]: Call(C:1157): From: Line:10000<<Anonymous ("Anonymous" <sip:[email protected]:5060>)  to  T:Fax:7779@[Dev:sip:[email protected]:5070]
26-Nov-2015 15:18:19.635   [CM503004]: Call(C:1157): Route 1: from L:1157.1[Line:10000<<Anonymous] to T:Fax:7779@[Dev:sip:[email protected]:5070]
26-Nov-2015 15:18:19.635   [CM505003]: Provider:[TrunkProvider] Device info: Device Not Identified: User Agent not matched; Capabilities:[reinvite, replaces, able-no-sdp, recvonly] UserAgent: [PBX] PBX contact: [sip:[email protected]:5060]
26-Nov-2015 15:18:19.634   [CM503001]: Call(C:1157): Incoming call from Line:10000<<Anonymous to <sip:[email protected]:5060>
26-Nov-2015 15:18:19.634   Line limit check: Current # of calls for line Lc:10000(@TrunkProvider[<sip:[email protected]:5060>]) is 2; limit is 8
26-Nov-2015 15:18:19.614   [CM503012]: Inbound any hours rule (7779) for 10000 forwards to Fax:7779

SIP Package Dump: http://temp.in.futureweb.at/3cx/faxto7779.txt

Flow - Fax to working 3CX Fax (777): http://temp.in.futureweb.at/3cx/flow777.jpg
Flow - Fax to not working EXT 7779: http://temp.in.futureweb.at/3cx/flow7779.jpg

Andreas

 

[lneblett]

It indictaed that there was a 488 response code sent as the codecs (t38) were not being matched up. The subsequent BYE message was:

BYE sip:[email protected]:5060 SIP/2.0
Via: SIP/2.0/UDP 10.4.0.0:5060;branch=z9hG4bK-d8754z-b0006d663120e72e-1---d8754z-;rport
Max-Forwards: 70
Contact: <sip:[email protected]:5060>
To: "Anonymous"<sip:[email protected]>;tag=as2cb2882f
From: <sip:[email protected]>;tag=12094a77
Call-ID: [email protected]:5060
CSeq: 4 BYE
User-Agent: 3CXPhoneSystem 14.0.45826.228 (45008)
Reason: SIP;description="Application Rejected Sdp(usually no common codec)"
Content-Length: 0


Where you show "states the fax was sent via t.38" is where I am confused. To me, this is software that is being used to send & receive faxes. In your case, you seem to be attempting to use 3CX as an equivalent SIP trunk provider that would normally handle the carriage from this device to the other end remote device. Where the confusion arises is knowing that the fax server is receive only how a send is possible. The device is showing sent, but I would really like to see a capture of a send.

I see that the company offers a free 15 day evaluation, so perhaps if time allows I will do so in the next few days (holiday in the States) and see more about what the product does.

I did notice that it does have an option for a T38 reinvite, you might try and toggle this feature to see what reaction it gets.

 

[Futureweb]

Here is a capture while sending a T.38 Fax with T38FaxVoip Software through 3CX (logged in with Fax-EXT 7779): http://temp.in.futureweb.at/3cx/faxfrom7779.txt

As far as I can say - 3cx is piping all Data 1:1 as they arrive from EXT 7779 directly to the Trunk - am I right?
Shouldn't it do the same when receiving a FAX?

As for the Codecs/reinvite - tried almoast all options available within T38FaxVoip - nothing helped! :-/

 

[lneblett]

The fax server is receive only.

So maybe I understand it now.........maybe.

You are using the software as a virtual fax machine and then using 3CX... if correct, a fax is received by 3CX from an external source (SIP provider?) and then sent to your device running the software. When sending, you send from a system which uses the device to send to 3CX and 3CX relays back to an external destination using a SIP provider. Is this correct?

 

[Futureweb]

Outgoing Fax: *Users in our Company Workstation* --> MS Fax Role (Network Shared Fax Printer) --> T38VoipFax --> 3CX --> Trunk --> some Fax
Incoming Fax: some Fax --> Trunk --> 3CX --> T38VoipFax --> delivery to some Folders/Mail (some delivery Rules)

MS Fax Role & T38VoipFax & 3CX is installed on the same Server - that's why Wireshark isn't capturing their Traffic (Server-internal Traffic) ... need to install Npcap for Loopback Capture of this Traffic ... (Hope it's working with Windows Server 2012R2??? --> https://wiki.wireshark.org/CaptureSetup/Loopback)

I need 3CX to just act as a Proxy for incoming Faxes on EXT 7779.
Need more complex delivery Rules than I can do with 3CX Fax Server ... otherwise I would just use 3CX Fax-Server.

ps) how can I send through EXT 7779 if 3CX Fax Extensions are Receive only?! :-/

 

[lneblett]

The fax server is receive only; hence why it sends to an email. The fax extensions are where the system is using the rules to connect to a device such as a gateway or ATA.

 

[lneblett]

In looking at some documentation, I may be incorrect and that extensions will also use t.38, but not sure if for both sending and receiving, so will look at again to get a better clarification later. However, they do appear to use it in some form.

 

[Futureweb]

According to http://www.3cx.com/docs/fax-server/ it should be possible to use T.38 Software behind a Fax Extension.
Sending T.38 Fax with such an Extension is woking well ... problem is just receiving ... :-/

Will do some Package Captures including the local SIP Traffic (T38FaxVoip <--> 3CX <--> Trunk) tomorrow ... it's already late here in Austria! ;-)

Andreas

 

[lneblett]

I worked with the package over the weekend. I am running v14 SP1 which may not be the same as you. Their appears to be some flakiness in how the two packages (3cx & FaxVoip) work together.

I have 3cx installed on a server running windows 2012 server essentials and the faxvoip software running on a client machine with Win 10 Pro.

I first used the standard fax server to test receiving and this worked well without any issues (faxvoip not used). I just wanted to ensure that my DID was fine and negotiating t38. It was.

I installed the software and configured it and established a fax extension. There appears to be an intemittent issue with faxvoip when initialing registering. If I started with UDP, it would seldom register, but after using TCP it had no problem. I could then switch to UDP after using TCP and then all was well.

Once registered, I then tried to do some testing but was met with a 502 bad gateway response code from 3CX. Initially, the SDP headers had a 169.254.x.x address and I have no idea where that came from. All NIC cards and applications had either a FQDN or IP applied. It was 3CX sending this and faxvoip immediately sent the 502 and dropped the call. I saw nothing in the initial register or the subsequent Invite that provided a clue as to why this occurred.

I worked with it for some period of time and could never get the 502 to go away, but prior to giving up on it....... my client machine suffered a blue screen of death and rebooted. I did not go further with it after that until this morning.

This morning I rechecked the settings in faxvoip. I had no issue receiving faxes. Under capi incoming I have specified SIP and then indicated receive as a file, leaving the other fields to "any" (default). I had also set up the SMTP section and I was receiving the files via email without issue. A wireshark and the console showed t38 receive.

I then tried sending. I am able to send, but it does not seem to be consistent in this regard. I sent a fax using t38 and it failed indicating that a fax signal was not received. I tried again and this time it went thru. I do not know if the issue lies between the client and server or the server and my provider. I never had an issue sending an audio (g711u) fax as this worked consistently, but my server and client are on the same network and I did not have wireshark running on the server side at the time. However, my testing was limited and the application shows enough merit in my opinion to deserve a more thorough look. t38 reinvite was off so it may be that when on the two would work together and be more consistent.

It is also not clear to me when some of the setting in faxvoip actually take effect. I started out changing the default rates down to 9600 from their normal 14400. The faxes were handled in this manner. I then changed to 14400 and clicked apply, but the next couple also were handled at 9600. After a few minutes they started being handled at 14400.

There is still some checking to do to better understand the application, but I can receive which was the crux of your issue.
I have no idea if the reboot of the client had anything to do with it working for me. Maybe a reboot or PM me and I will send you screenshots of setup.