What is a FoIP
FoIP – FAX over IP, is the technology used to allow faxing via the computer network. Because Fax is not ideally suited to travel via a normal phone call, the T38 protocol was developed.
A FoIP (FAX) call is very similar to a normal VoIP (voice) call. In essence it is a call that transmits FAX data over an IP network.
How the 3CX Phone System FAX Server Service receives Faxes
3CX Phone System has a separate fax server service, that acts as a SIP client and is dedicated to receiving faxes.
What is the difference between a FoIP call and a VoIP call?
The main difference from a normal VoIP call is the type of media established between the two endpoints, hence the SDP attachment in the SIP signaling is also slightly different. Traditionally the media of a FoIP call is a T.38 stream. T.38 is an ITU standard for sending FAX across IP networks. T.38 sessions are described in an SDP attachment using the “image/t38” mime type detailed in RFC 3362. It is necessary to use T.38 media in FAX calls as opposed to normal voice codecs because voice codecs are lossy and are therefore unreliable for data transition. A T.38 media stream contains RAW FAX data. When analyzing a FoIP call you will notice two distinct features:
1. Instead of having a RTP media stream containing voice data a FoIP call contains a T.38 media stream containing a FAX image.
2. SDP negotiation SIP signaling is nearly identical to a VoIP call with the exception for the listed image media.
The following is an example INVITE from a SmartNode that contains T.38 in it’s SDP;
INVITE sip:email@example.com SIP/2.0 Via: SIP/2.0/UDP 10.172.0.115:5060 Contact: <sip:firstname.lastname@example.org:5060> To: "100"<sip:email@example.com> From: "anonymous"<sip:firstname.lastname@example.org:5060>;tag=1 Call-ID: email@example.com Cseq: 1 INVITE Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE, SUBSCRIBE, INFO Content-Type: application/sdp Max-Forwards: 70 User-Agent: SN-4114 Content-Length: 215 v=0 o=user1 53655765 2353687637 IN IP4 10.172.0.115 s=- t=0 0 c=IN IP4 10.172.0.115 m=audio 6000 RTP/AVP 0 a=rtpmap:0 PCMU/8000 a=sendrecv m=image 4908 udptl t38 a=T38FaxUdpEC:t38UDPRedundancy a=sendrecv
NOTE: that the only additional headers here are the last three, i.e;
m=image 4908 udptl t38 a=T38FaxUdpEC:t38UDPRedundancy a=sendrecv
This first line is an instruction to the callee to send media of type “image” to port “4908” where “t38” is most preferred. The following lines (a=) are media attributes. The following lines in the INVITE describe the media type and the direction of streams (bi-directional). i.e. the connection will be set in send and receive mode. The callee will know which IP it must send media to from the IP stated in the SDP “GLOBAL” Connection Information Header (c=).
NOTE: The Global Connection only applies when there is no connection information for the media description (m=). Each media description MAY have a distinct Connection Information header (under m=) but if this is not defined the callee must default to the “GLOBAL” Connection Header described in the session level. This is described in more detail RFC 2327 under section 6.
Informing the PBX Server of it’s whereabouts – FAX Client REGISTERs
On service start up the FAX service reads from the 3CX Phone System database the FAX special DN, the fax extension authentication ID and the fax extension Password. The FAX client will then REGISTER against the PBX using these credentials with a (default) refresh interval of 10 minutes. The status monitor will show the following log entry:
17:11:42.229 FaxCfg::updateContact [CM504008]: Fax Service: registered as sip:888@3CXPhoneSystem with contact sip:firstname.lastname@example.org:5100;user=phone
To review the details of the registration the OK response to the REGISTER request can be reviewed from the 3CX Phone System Trace logs (SIP server logs). In verbose mode the PBX will dump the SIP response in it’s logs using the following format:
17:37:30.874|DialogUsageManager.cxx(800)|Debug8|Resip|::ResipLogger:SEND: SIP/2.0 200 OK Via: SIP/2.0/UDP 10.130.0.2:5100;branch=z9hG4bK-29D6-2 Contact: <sip:email@example.com:5100;user=phone>;expires=600 To: <sip:888@3CXPhoneSystem;user=phone>;tag=0b0ffd5b From: <sip:888@3CXPhoneSystem;user=phone>;tag=CBB Call-ID: 0@3CXPhoneSystem CSeq: 2 REGISTER User-Agent: 3CXPhoneSystem 5.0.3665.0 Content-Length: 0
Searching through verbose logs can be tedious and time consuming, in order to quickly find this entry in the logs search for the FAX extension number. Notice that the Contact Header contains the IP and port where the Client is listening. By default the FAX service will listen for SIP messages on port 5100 as opposed to the usual 5060. The FAX service is set up in this manner because it is usually installed along side the PBX where port 5060 is already occupied by the PBX. The contact URI must be a valid contact reachable by the calling endpoint. It may be that the PBX never received any REGISTER request. In this case you can review if the service is trying to REGISTER at all in the “%ProgramData%\3CX\Data\Logs\3CXFAXServer.log” log file. If the service is tries to register lines similar to the following will appear;
11:46:24.345|0eec|(0):FAXServer, ♪(nai 0, conn_id 0) SSC Evt (Register): Send SSC_REGISTER_RQ
If it is necessary to review the mentioned REGISTER request this can be found in “%ProgramData%\3CX\Data\Logs\FaxTraces\audittrace.log”. These are the NetBrick trace logs which should only be generated when the database logging level is set to trace mode. Since these logs are quite vast it is best practice to search for the time of the listed REGISTER request (in the FAXserver.log file). Once located the REGISTER request will look like this;
74- 81- 49| 50- 50|001e1e04-001fdddc| 0.530-I| None | |SIP-IP |SOCK_U_DA_RQ | 0: 1: 0#466: ............................REGISTER sip:10.130.0.2:5060 SI»-- SIP Primitive -- To Remote IP address: 10.130.0.2 (5060)REGISTER sip:10.130.0.2:5060 SIP/2.0 Allow: INVITE,BYE,ACK,OPTIONS,CANCEL Call-ID: 0@3CXPhoneSystem Contact: <sip:firstname.lastname@example.org:5100;user=phone> CSeq: 1 REGISTER Expires: 600 From: <sip:888@3CXPhoneSystem;user=phone>;tag=27CB Max-Forwards: 70 To: <sip:888@3CXPhoneSystem;user=phone> User-Agent: Netbricks-Sip-T.38IAF/2.01 (PRODUCT ID:5, 05 Jul 2007) Via: SIP/2.0/UDP 10.130.0.2:5100;branch=z9hG4bK-7EE7-1 Content-Length: 0The REGISTER request can be reviewed for incorrect IP addresses. Also pay attention to the logs line where Fax client describes the remote IP where it has sent the REGISTER request;…REGISTER sip:10.130.0.2:5060 SI»-- SIP Primitive --
Routing calls to the FAX service
Calls are routed to the FAX client via configuration of the FAX routing rule in “Line Settings” of any given line. Specific mailbox destinations can be chosen when routing calls to FAX. This is done indirectly by choosing an extension under the “Send fax to email of extension” drop down menu. The PBX will manipulate the display part of the “To” Header of an incoming INVITE and populate this with the selected extension number. The PBX will then forward the manipulated INVITE to the FAX client, otherwise the INVITE will be sent un-altered with FAX ID in the “To” SIP Header.
Converting the FAX
Once an INVITE has been received by the FAX client, it can negotiate the call with the caller (gateway device). Note that the media stream has to be passed directly from the gateway to the FAX service and it can NEVER be done on a device that is “bound to Media Server”. T.38 cannot be transcoded by the Media server hence the gateway must operate with Media Server in pass-through or bypass mode. On a successful call and once a successful T.38 stream is received from the caller the FAX data is dumped in the FAX service’s working directory as a RAW FAX. This RAW FAX file alone is useless without the data descriptor which is in Fax client session memory. The FAX service accesses this information along with the RAW FAX file to build a TIF file containing the FAX image. Generated TIF files are saved in the “%ProgramData%\3CX\Data\Fax\Faxes\ToSend” with an xml descriptor. The xml is populated with the target extension ID. E.g.:
<INFO CALLEE_ID="100" CALLER_ID="anonymous" FAX_ID="" PAGES="0">
Converting and sending the FAX
The FAX service will then attempt to send this TIF file to the correct recipient. It will retrieve the callee ID from the xml and query the database for the callee’s mailbox address. If the FAX service finds the attachment to be a TIF file it will convert it to PDF and send to the retrieved mailbox. If there is no FAX data then an email with no attachment will be sent with the following note of information;
No Fax was received. Call was either not from a fax machine, or else fax handshaking failed.
The email’s subject will be “Fax From: 888888”, where the number “888888” is the FAX ID of the machine that sent the FAX. The Senders “Name” will be populated with the “Display Name” field found in the “From” Header of the INVITE of the FAX call.
Failed FAXes will go to the “%ProgramData%\3CX\Data\Fax\Faxes\Failed” folder. The reason for failure is located in the <ERROR> tags. This is usually an SMTP response. eg.:
<ERROR>Failed to send SMTP message, response: '', error: No recipients defined</ERROR>
If you have a failed fax that needs to be resent you can move the xml and the corresponding pdf with the same name to the “\ToSend” folder. A small alteration will be necessary, this involves removing all the <FLAGS>, <NOTIFICATION>, <NOTIFIED> tags along with their data. e.g. removing a block of text similar to this;
<FLAGS>10</FLAGS> <NOTIFICATION ATTEMPTS="10"> <ERROR>Failed to send SMTP message, response: '', error: No recipients defined</ERROR> <LASTATTEMPT>20071129154018.168</LASTATTEMPT> </NOTIFICATION> <NOTIFIED>20071129154018.168</NOTIFIED>