SPA 112 Fax Issue

curry0707 · ‎02-22-2016

Hi all,

I'm working on getting our analog fax machine to work with our VOIP server and have purchased an SPA112 to that end. Essentially I just set it up to use the VOIP server as a proxy. I had no issue getting the device to register and outbound faxes work fine. I'm also able to send and receive internally, but my inbound faxes from outside are failing for some reason, whether I use T.38 or not. I've lowered the fax speed to 9600 on the fax machine and disabled ECM. Also tried enabling all the NAT settings, but faxes are still failing inbound. Wanted to post a log to see if anyone has any input on what may be going on. In the log below, the fax came in at about 12:33.

Dan Lukes · ‎02-22-2016

It's not easy to debug this kind of issues.

A fax has decided to hangup the call for unknown reason. Even SPA112 don't know why the fax has not been satisfied with the data and decided to tear down the call.

I have no answer to you, just few notices.

Unless you have end-to-end T.38 connection it's better to use uncompressed (G711a or G711u) codec than T.38. If you are using T.38, but the signal is converted on the path (because there's no-T.38 compatible link), the overall experience depends on quality of T.38<->X conversion gateway. Moreover, if X is an compressed codec, the faxing may be impossible at all. On the other side, if your Internet connection quality is low (so many packets lost, so high jitter, ...) the T.38 may be better than G711 despite the conversions.
Try RTP Packet Size = 0.010 (instead of 0.020 you have configured now). It may help faxing success at the cost of use of slightly more bandwith.
Try even lower speeds, like 4800 or 2400Bd. If you need to turn off ECM to receive something, then the connection quality seems to be rather low.
Turn off T.38, capture session packets (SIP as well as RTP). Use wireshark to analyze the stream for missed/delayed/out of order packets (we can help you with it if you fee not skilled enough). It may disclose insufficient quality of your network connection. If the other end is also VoIP, then capture SIP & RTP on both ends at the same time. It will allow you to analyze both directions of RTP flow.
Turn on T.38, capture session packets (SIP as well as RTP). An external analyzer may disclose details of fax protocol used by end fax devices. It may help to analyze the issue.

Hope it help a lot ...

curry0707 · ‎02-22-2016

I appreciate the input.

I did notice some "CC_EV_TMR_INVALID" messages in the logs, do you think this might indicate some sort of configuration issue on the SPA?

Dan Lukes · ‎02-22-2016

Well, neither syslog nor debug messages are documented by Cisco, thus we can guess the meaning only.

But I wish those messages disclose no issue. The 'INVALID' seems to refer to call state CC_CST_INVALID.

Call had been already disconnected by remote entity (SIP_EV_DLG_BYED), it has entered the CC_CST_INVALID state (new state CC_CST_INVALID). CPC is configured, so it needs to be issued after predefined delay - thus timer CC_EV_TMR_INVALID has been scheduled (CPC statr timer CC_EV_TMR_INVALID).

Once event has fired, the associated function had run CPC sequence and has moved call state to CC_CST_IDLE.

So, the CC_EV_TMR_INVALID seems to be common part of call tearing down sequence.

curry0707 · ‎02-26-2016

Interestingly enough, some faxes come through just fine, but faxes seem to fail from certain numbers/machines. I did a packet capture between the SPA, our VOIP server and our SBC and noticed that when the faxes failed, communication was established but eventually I see an hdlc-fcs-BAD-sig-end response from what I think is the remote machine.

I'm no T.38 expert, but would I be correct to interpret this as some sort of packet loss/jitter type of issue? And if so is there anything in the SPA settings that might help?

Dan Lukes · ‎02-26-2016

I'm no T.38 expert, but would I be correct to interpret this as some sort of packet loss/jitter type of issue?

Well, I'm no T.38 expert as well, but I understand the matter:

Fax over T.38/IP connection:

[ FAX1 ] ...... [ ATA1 ] ------(IP)------ [ ATA2 ] ......(POTS)...... [ FAX2 ]

Legend:

(IP)	VoIP network
(POTS)	classic (non-IP) public phone network
......	analog (POTS) line - casual fax T.30 over a V.x (modem) stream
------	digital link - T.38 over RTP
ATAn	POTS to T.38 bridge (ATA1=SPA112 on your side)
FAXn	fax

The T.38's hdlc-fcs-BAD-sig-end has been send by ATA2 to you to announce event received by ATA2 from FAX2. It announce the end of HDLC frame with no correct FCS has been received from FAX2. Such HDLC frame has been flagged to be final frame.

In short, hdlc-fcs-BAD-sig-end is just digital form of message sent by FAX2 in analog format (it has been converted to digital form by ATA2).

This message has not been caused by issue on digital part of path, but by issue on ATA2<->FAX2 part of path.

As it has happened on remote end of path, out of your control, there's little you can do with it. You may assume the issue has been caused by ATA2 T.38<->POTS conversion process. Try to use G711u instead of T.38.

curry0707 · ‎03-02-2016

Thanks for the input. I've done some testing with G711u and it seems to be intermittent, with some faxes received and some not. Sending works fine.

Any chance you can take a quick look at the attached PCAP to see if you have any thoughts on why this inbound fax from HP Fax Test Service failed?

The fax is from 1-888-473-2963 to my internal number. The initial outbound fax to the number went through with no issue, but the inbound fax seems to have dropped after a minute or so of data transmission. If it's any help, the 73.187 is the SPA device and the 105.27 is my gateway.

Dan Lukes · ‎03-03-2016

Any chance you can take a quick look at the attached PCAP to see if you have any thoughts on why this inbound fax from HP Fax Test Service failed?

I will do my best, but it will take some time. I wish I will make a conclusion tomorrow or so.

Dan Lukes · ‎03-03-2016

There's timestamp jump in the stream 105.27 -> 154.14 (SSRC=0x5b782f24).

The packet seq 33127 with timestamp 2880 carry 20ms of audio data. It should be followed within 20ms by packet seq 33128 with timestamp 3040. It's followed after 60ms (e.g. delayed) by packet seq 33128 with timestamp 35200 instead.

But it should recover from something like it. I see nothing critical.

I listened the streams and didn't heard something suspicious. Of course, I have no modem embedded in my head, so I'm unable to identify wrong timing and slight distortions of stream. I have no tool suitable for precise analysis of audio recorded.