Problems sending Fax via IP phone

G711
Fax

asked 2019-08-21 19:08:03 +0000

sugar76
9 ●3 ●5 ●8

updated 2019-09-02 08:10:47 +0000

Hello,

we are using a fax software which sends and receives faxes by encapsulating the G711 fax protocol in IP packets.

We encounter serious issues as the remote station often cancels the fax transmission process.

I recorded a capture of the fax send process (see the link below). Without knowing anything about the details of the G711 protocol I see some TCP Dup ACK and TCP Retransmission packets in the capture. Does this indicate any kind of network problem? Or are there any other packets in the capture indicating network problems?

Capture Clientside (Filtered): https://1drv.ms/u/s!AphLkdj_V9pOpil7h...

Capture Router/Gateway: https://1drv.ms/u/s!AphLkdj_V9pOpivie...

EDIT: The fax sender is 192.168.73.150. It sends to the router (192.168.73.1) which acts as local registrar/gateway. For RTP, any port between 10240-11263 is used.

I'm not quite sure how to figure out the RTP statistics. In RTP stream View, I see two entries between 192.168.73.150 and 192.168.73.1. One (192.168.73.1 to 192.168.73.150 port 10004) indicates a packet loss of about 3%. But the other one (192.168.73.150 192.168.73.1 port 10354) shows 0% packet loss. Isn't the one using port 10354 the actual sending stream? And isn't the main problem here Jitter not packet loss?

The second capture (Capture Router/Gateway) is the result of a fax sending process recorded on the gateway. The packet loss is very little (1 Packet lost). I recorded four sending processes and all look almost exactly the same. The transmission process is always cancelled by the remote station after a short time period.

edit retag flag offensive close merge delete

Comments

Can you provide the hosts and ports involved in this communication?

Spooky ( 2019-08-23 02:55:10 +0000 )edit

Go to Telephony | VoIP Calls and you'll see it.

Jaap ( 2019-08-23 05:28:20 +0000 )edit

@Spooky Please see my edits.

sugar76 ( 2019-08-26 07:25:29 +0000 )edit

add a comment

2 Answers

Sort by » oldest newest most voted

answered 2019-08-26 19:04:43 +0000

Jaap

13720 ●683 ●115

updated 2019-08-26 19:05:54 +0000

The sending of the RTP packets from 192.168.73.150 is erratic. In SDP (packet 4306) it is agreed to send 20 ms packets (ptime: 20). Then it starts sending packets with 30 ms in between or almost consecutive. Per packet there's 20 ms worth of PCMU encoded sound sampled at 8 kHz (=160 samples of 8 bits). So it seems as though the system is not comfortable with sending 20 ms packets. Filtering and listening to the streams, with 80 ms jitter buffer, learns that the stream from 192.168.73.150 sounds fine, the stream from 192.168.73.1 has some ticks in it, and you can even faintly hear the echo of 192.168.73.150 sending, but should probably be fine too. So even though the receiving stations jitter buffer should be able to handle this it might be worth to try setting things up for 30 ms RTP packets and see what changes.

edit flag offensive delete link

Comments

I recorded a fax sending process on the gateway (see Capture Router/Gateway in the main question). There is almost no packet loss but the transmission process is cancelled anyway by the remote station. I guess this is because of the 30 ms interval (as seen in the reverse direction)?

sugar76 ( 2019-09-02 08:14:02 +0000 )edit

Listen to the stream from 192.168.73.150 with a jitter buffer of 20 ms and 30 ms, running of Jitter buffer timing. There's a distinct difference between them, so this might indeed be relevant.

Jaap ( 2019-09-02 16:12:34 +0000 )edit

add a comment

answered 2019-08-23 09:51:09 +0000

SYN-bit

18344 ●9 ●301 ●255 https://SYN-b.it

G.711 is transported over RTP. RTP can be transported over UDP or TCP. But in your trace, it is transported over UDP. To analyze RTP, go to "Telephony -> RTP streams" and then select the two RTP flows and click on Analyze. In the resulting overview, you can see that there is ~3% packet loss from 192.168.73.1 -> 192.168.73.150. I suspect that this amount of packet-loss is enough to kill the Fax transmission, but I'm not 100% sure.

As the capture was made on 192.168.73.150 (as can be seen by the frames with a length smaller than 60 bytes), there could of course also be packetloss towards the 192.168.73.1, but you would need to capture on the .1 side to be able to determine this.

Please check the switch port statistics of the involved switches to see if there are any discards and/or errors on the ports.

From the ARP requests I assume the subnetmask for 192.168.73.150 is 255.255.255.0, which means 192.168.73.1 would be in the same subnet, however I see that the IP TTL of packets from 192.168.73.1 is 63. This indicates that there was a routing hop involved. Is 192.168.73.1 a NAT address? Or is the subnetmask for 192.168.73.1 misconfigured perhaps?

edit flag offensive delete link

Comments

Yes, the subnet is 192.168.73.x for both. I checked the subnetmask, it's set to 255.255.255.0 so it's OK.

sugar76 ( 2019-08-26 07:35:27 +0000 )edit

@SYN-bit: please see my edits regarding the RTP stream.

sugar76 ( 2019-08-26 07:41:10 +0000 )edit

I'm not quite sure how to figure out the RTP statistics. In RTP stream View, I see two entries between 192.168.73.150 and 192.168.73.1. One (192.168.73.1 to 192.168.73.150 port 10004) indicates a packet loss of about 3%. But the other one (192.168.73.150 192.168.73.1 port 10354) shows 0% packet loss. Isn't the one using port 10354 the actual sending stream?

As you captured on the sending side (192.168.73.150), it is logical that you see no packet-loss. The packets have not crossed the network yet. Make a capture on both sides to analyze the packet-loss in each direction.

And isn't the main problem here Jitter not packet loss?

The jitter from 192.168.73.1 to 192.168.73.150 was not that high so that should not have ...(more)

SYN-bit ( 2019-08-26 08:18:28 +0000 )edit

Have a look in the RTCP packets. It says in the Source description packet (5725) SDES item: [email protected], so it seems there is a hop behind the 192.168.73.1 proxy.

Jaap ( 2019-08-26 18:37:42 +0000 )edit

Nice catch! @Jaap

SYN-bit ( 2019-08-26 19:28:07 +0000 )edit

add a comment

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account.

Add Answer

Problems sending Fax via IP phone

Comments

2 Answers

Comments

Comments

Your Answer

Question Tools

Stats

Related questions

Problems sending Fax via IP phone edit

Comments

2 Answers

Comments

Comments

Your Answer

Question Tools

Stats

Related questions

Problems sending Fax via IP phone