UCM62XX - FAX Intelligent Route


#1

hi,
Has anyone managed to make the “FAX Intelligent Route” function work on the Trunk?
It doesn’t work for me, maybe I miss a few steps.


#2

How does the call come in? What answers the call, so the system can determine that it is a fax?


#3

hi Larry,

Test scenario:

  • UCM with fax VFAX 695
  • Extension 201 for the item
  • on the trunk I enable the voice “intelligent fax” and send to fax 695
  • In the incoming path of the trunk imposed 201

Any incoming call to the trunk, whether it’s a fax or a voice call, UCM will divert it to 201.
So the recognition does not take place and an incoming fax instead of going towards 695 still goes to 201.


#4

So what answered the call?
Try to an IVR and then 201 and see.

You can see if that routes and then adapt as needed.


#5

Unfortunately I tried to put an IVR, but any incoming voice or fax calls still go to 201.
For that I ask if anyone has tried and knows exactly step by step how to solve.


#6

Let me see if I can set up a test today.

ps- I HATE FAX


#7

tnx

Damiano


#8

I started to engage on this yesterday, but got called out to a client.

In any event, as you know, I hate fax. I wish it would die a quick death. I started to investigate your query and in doing so, referred to the manual (yes, i know, not very manly). What I came across from the very start was -

FAX Intelligent Route
The UCM6200 can automatically detect Fax and phone signal coming from the FXO port, and then forward Fax or phone signal to the right destination. For example, when a regular phone call is coming, the UCM6200 will be able to detect the phone signal and forward it through the correct inbound route to the destination; if Fax signal is coming, the UCM6200 will be able to forward it to the FXS extension where the Fax machine is connected.

You indicated- “on the trunk I enable the voice “intelligent fax” and send to fax 695”. So, there is a slight conundrum as the UCM VoIP trunk settings have a setting for intelligent fax routing, but the manual makes no mention of such a setting for the VoIP trunks. I have a earlier Beta of UCM software that is currently in development and this version has no fax settings at all in the trunk settings. However, this is a Beta and may not represent what finally gets released. I reverted back to 19.27 for testing.

Additionally, when hovering over the description for intelligent fax in the trunk settings, it indicates that the connection must be to a fax extension or an FXS extension with a fax machine connected.
As you have indicated you have it set to a fax extension, I assume this to be acceptable.

So, in my initial test I -

  1. Set up VoIP trunk for fax detect and intelligent fax routing with a destination of 7200 which is a UCM fax extension.
  2. Set up the inbound rule to my extension with no fax settings in the route. Voicemail is disabled but t.38 is enabled.

Sent a fax and captured the call. The call came in as a voice call and was immediately routed to my extension. As I suspected, it does not appear that unless the call is answered, the UCM is not able to detect that the call is a fax as there is no re-invite. The call is always treated as voice.

I then changed the inbound route to an IVR, which if after 10 seconds no response, it would send the call to my extension.
I sent another fax and while monitoring the fax via the UCM active call page, it indicated no calls, yet the fax was active. I then examined the pcap file, and indeed a call had come in.

The call flow shows the Invite coming from the provider, and the UCM answers the call and there is a subsequent re-invite from the UCM seeking a t.38 exchange. The provider responds with a 100 trying followed by an immediate bye and a busy here, which seems odd. The reason for the bye was:
Reason:Q.850;cause=27;text=“DESTINATION_OUT_OF_ORDER”

I will do some more checking, but the INVITE is correct and the ports are forwarded for fax 4000-5000UDP.

You might try on your end and see what happens if you do a IVR and get the call answered. I will likely have to file a ticket.


#9

hi Larry,

Meanwhile, thank you for your attention (I think the topic interests many readers here),

“In any event, as you know, I hate fax. I wish it would die a quick death.” -> I hate it as much as you do, except that every now and then customers bring out this request, it bothers me to see that UCM has the fax server integrated and does not always work (for mysterious reasons).

In my personal experience a PDF is usually sent regularly, a PDF created by a scan almost always fails.

“However, this is a Beta and may not represent what is eventually released. I’m back at 7:27 p.m. for testing.” -> not about the post but can I ask you if they have generally implemented other import/export functions?

“I’ll do some more checking, but the INVITE is correct and the ports are forwarded by fax 4000-5000UDP.” -> do you want to tell me that in addition to the classic range RTP 10.000-20.000 UDP should also make the NAT ports with range 4.000-5000 UDP?

“You might try on your end and see what happens if you do a IVR and get the call answered. I will likely have to file a ticket.” -> I tried it normally and it fails 100%, I tried it with IVR and 1 time out of 10 it recognizes the fax and forwards it correctly inside the fax. 10% I think I can say that the fax recognition of UCM is not much use.

Damiano


#10

Damiano -

I have done more testing with a couple of different ITSP providers as well as different PBX systems.

I have it working reasonably well on the UCM.

Set up the trunk to do fax detect and intelligent routing and set the fax extension to which you want the fax to go. You then set up an IVR and have the DID directed to that IVR.

I have my IVR set up with nothing other than the default welcome message from GS and a couple of options from which a caller can choose.

When the call comes in, the IVR will answer at a voice level (g711u or, a in your case) it will use the RTP voice ports initially and when the tone is heard, the call will be directed to the fax extension you set in the trunk. The fax extension will then re-Invite to t.38 and if the provider supports, they will accept and the UDP will be in the 4000-5000 range at this point whereupon they will negotiate and then exchange the info.

I get the email, but it seems that I am getting two files - I get the tiff file, but then I also get the binary file of the PDF in a text file. I can go into the UCM and in t.38/fax I see the Tiff and the PDF, so am uncertain as to why the system is not sending me the PDF. What is really strange, is that yesterday when I got back to testing I was getting the tiff and the PDF. ECM was on throughout the testing.

One provider supports t.38 on a voice circuit, the other wants to have the DID set on their end to be either voice or fax, but it set to fax, it works as well. I tried the same settings on a different make of Asterisk and it also works in the same manner.


#11

Thank you, Larry,
seems to me a solution a little confusing to activate at the customer (I think that nothing is certain or obvious).
You’re talking about the range of ports 4.000-5000 on the fax transaction, so it’s better to do the NAT in the range of ports 4.000-5.000 in addition to the range RTP 10.000-20.000? It seems strange to me, however, that UCM does not report anywhere this range.

Damiano


#12

The 4K-5K port range is standard for Asterisk. The re-Invite upon seeing the t.38 will shift from the normal voice ports to this range and you have no control over which port is used unless you can get into the core files and change. This is a chart showing the default Asterisk port usage for communications -

If no forwarding is done, then I assume the PBX will open the needed ports by sending a packet out the needed receive port which is the same as the send port for the UCM when sending or receiving based upon the Invite and the subsequent 200OK, if the re-INVITE is accepted. However, as I detest fax so much rather that testing it to see if such is the case, I have always done forwarding as I can see the ports used in captures, know the range and I really don’t care if the PBX does it or not, so I open them.


#13

interesting, thank you,
I asked you, because in checking the pcap I never find the doors 4000-5000

Damiano


#14

Here is a flow of an actual fax call, the IP to the left is the provider, middle is the UCM and to the right is the media server for the provider (RTP and fax)

You see the call starts at a voice level using my RTP ports (22000-22250)
When the UCM answers the call at the IVR, the system then sends the call internally to 7200 my virtual fax extension. Upon getting to 7200 the UCM then sends a re-INIVITE back to the provider for t.38 and the provider responds with a 200OK/SDP and off we go with a fax.

The re-INVITE is telling the provider the port the UCM wants to see the fax come in:

The provider 200OK/SDP does the same so the UCM knows what port to deliver the return stream:

So, as you can see in the streams, the UCM is using 4086 while the provider is using 49412.


#15

as soon as I succeed I try and tell you if I see improvements with the nat on 4000-4999 (which strangely involve the 4569 - IAX, so I do the nat 4000-4568 and 4570-4999)


#16

If you are using IAX and have the port set, then the system is bound to that port and won’t use it for fax. As a result, you can still forward the range and not have any issues.


#17

I tried now, even making the NAT of ports 4000-4999 unfortunately does not improve the situation

Damiano


#18

Take a capture and PM it to me.