[Home]

Summary:ASTERISK-14593: T38 Faxing failing on 1.6.1 svn
Reporter:Darren Philips (dazza76)Labels:
Date Opened:2009-08-04 06:28:09Date Closed:2009-08-17 10:21:16
Priority:MinorRegression?No
Status:Closed/CompleteComponents:Core/General
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) full
( 1) t.38_call_with_Fail.pcap
( 2) t38-1.4.pcap
( 3) t38-1.6.211586.pcap
( 4) t38-1.6.pcap
( 5) t38-1.zip
Description:I am attempting to send faxes via t.38 through 2 asterisk servers
i.e
patton -> asterisk 1.6.1 -> asterisk 1.6.1 -> carrier
what i have noticed is the fax negotiates but no data seems to make it,

when watching the console the below lines appear
this does not happen on 1.6.1.1 or 1.6.1.2 but does happen on the svn rev 209900

the reason for the upgrade is the due to a segfault of ulaw fallback  on 1 carrier i.e issue 15290
Please let me know what log files are required.

****** ADDITIONAL INFORMATION ******

[Aug  4 21:16:54] WARNING[26851]: udptl.c:999 ast_udptl_write: UDPTL asked to send 53 bytes of IFP when far end only prepared to accept 15 bytes; data loss may occur.
[Aug  4 21:16:54] ERROR[26851]: udptl.c:292 encode_open_type: Buffer overflow detected (53 + 59 > 72)
[Aug  4 21:16:54] NOTICE[26851]: udptl.c:1010 ast_udptl_write: UDPTL Transmission error to 125.213.162.38:11724: Message too long
Sent UDPTL packet to 125.213.162.38:11724 (type 0, seq 253, len -1)
Got UDPTL packet from 10.1.20.183:16676 (type 0, seq 0, len 140)
Comments:By: Kevin P. Fleming (kpfleming) 2009-08-04 09:38:35

Please upload either a raw packet capture (tcpdump/wireshark/etc) of the SIP traffic between the servers, or a console log with the 'debug' loglevel included and 'sip set debug on' enabled... but the packet capture would be preferred. Thanks.
By: Darren Philips (dazza76) 2009-08-04 21:13:55

So you can Understand them

182 = Vfe3   (Currently Callweaver 1.2 svn)
176 = Vbe2  (asterisk 1.6.1 svn)
125 etc (Carrier)

Let me know if you need any more info .
Cheers Daz
By: Kevin P. Fleming (kpfleming) 2009-08-06 13:21:00

The pcap file seems to be incomplete, as I don't see any of the packets that arrived from the carrier IP (125.x.x.x), only packets to it. Regardless, I can tell from the console log that the carrier's gateway told us we can't send it a T.38 datagram more than 72 bytes in size (T38FaxMaxDatagram), but that it wants us to use UDP redundancy (sending copies of the last three frames) when we sent T.38 IFP frames to it. Combining these two means we can only send *very* small IFP frames, in fact the limit is so low that spandsp and our UDPTL stack cannot cope with it. In this case, spandsp generated an IFP frame of 53 bytes (a very reasonable and safe size), but we couldn't send it because adding redundancy would mean it went well over the 72 byte limit imposed by the other end.

This is currently a subject of discussion in the SIP Forum FoIP working group, about how this particular session parameter is not well defined, and implementations tend to treat it in very different ways. You seem to have found a particularly bizarre implementation. I'll try to come up with a workaround and post here when it's available.
By: Darren Philips (dazza76) 2009-08-06 17:18:47

1 Add i can give is
1.6.1.1 works so does 1.6.1.2 and 1.4.26.1
i will do a capture on 1.4.26.1 and post shortly
By: Kevin P. Fleming (kpfleming) 2009-08-07 08:04:04

That is not necessary. I already told you the problem is understood and that I'd provide a workaround, and this problem was introduced in the branches after 1.6.0.10 and 1.6.1.2 were tagged, so that all makes sense.

I'm about to commit a change that will resolve this problem; please retest with that change and reopen this issue if the problem is not resolved. Thanks.
By: Digium Subversion (svnbot) 2009-08-07 08:08:20

Repository: asterisk
Revision: 210992

U   trunk/main/udptl.c

------------------------------------------------------------------------
r210992 | kpfleming | 2009-08-07 08:08:19 -0500 (Fri, 07 Aug 2009) | 13 lines

Workaround broken T.38 endpoints that offer tiny MaxDatagram sizes.

Some T.38 endpoints treat T38FaxMaxDatagram as the maximum IFP size that should
be sent to them, rather than the maximum packet payload size. If such an
endpoint also requests UDPRedundancy as the error correction mode, we'll end
up calculating a tiny maximum IFP size, so small as to be unusable. This patch
sets a lower bound on what we'll consider the remote's maximum IFP size to be,
assuming that endpoints that do this really can accept larger packets than
they've offered to accept.

(closes issue ASTERISK-14593)
Reported by: dazza76

------------------------------------------------------------------------

http://svn.digium.com/view/asterisk?view=rev&revision=210992
By: Digium Subversion (svnbot) 2009-08-07 08:09:16

Repository: asterisk
Revision: 210993

_U  branches/1.6.0/
U   branches/1.6.0/main/udptl.c

------------------------------------------------------------------------
r210993 | kpfleming | 2009-08-07 08:09:16 -0500 (Fri, 07 Aug 2009) | 20 lines

Merged revisions 210992 via svnmerge from
https://origsvn.digium.com/svn/asterisk/trunk

........
 r210992 | kpfleming | 2009-08-07 08:08:00 -0500 (Fri, 07 Aug 2009) | 13 lines
 
 Workaround broken T.38 endpoints that offer tiny MaxDatagram sizes.
 
 Some T.38 endpoints treat T38FaxMaxDatagram as the maximum IFP size that should
 be sent to them, rather than the maximum packet payload size. If such an
 endpoint also requests UDPRedundancy as the error correction mode, we'll end
 up calculating a tiny maximum IFP size, so small as to be unusable. This patch
 sets a lower bound on what we'll consider the remote's maximum IFP size to be,
 assuming that endpoints that do this really can accept larger packets than
 they've offered to accept.
 
 (closes issue ASTERISK-14593)
 Reported by: dazza76
........

------------------------------------------------------------------------

http://svn.digium.com/view/asterisk?view=rev&revision=210993
By: Digium Subversion (svnbot) 2009-08-07 08:09:58

Repository: asterisk
Revision: 210994

_U  branches/1.6.1/
U   branches/1.6.1/main/udptl.c

------------------------------------------------------------------------
r210994 | kpfleming | 2009-08-07 08:09:58 -0500 (Fri, 07 Aug 2009) | 20 lines

Merged revisions 210992 via svnmerge from
https://origsvn.digium.com/svn/asterisk/trunk

........
 r210992 | kpfleming | 2009-08-07 08:08:00 -0500 (Fri, 07 Aug 2009) | 13 lines
 
 Workaround broken T.38 endpoints that offer tiny MaxDatagram sizes.
 
 Some T.38 endpoints treat T38FaxMaxDatagram as the maximum IFP size that should
 be sent to them, rather than the maximum packet payload size. If such an
 endpoint also requests UDPRedundancy as the error correction mode, we'll end
 up calculating a tiny maximum IFP size, so small as to be unusable. This patch
 sets a lower bound on what we'll consider the remote's maximum IFP size to be,
 assuming that endpoints that do this really can accept larger packets than
 they've offered to accept.
 
 (closes issue ASTERISK-14593)
 Reported by: dazza76
........

------------------------------------------------------------------------

http://svn.digium.com/view/asterisk?view=rev&revision=210994
By: Digium Subversion (svnbot) 2009-08-07 08:10:30

Repository: asterisk
Revision: 210995

_U  branches/1.6.2/
U   branches/1.6.2/main/udptl.c

------------------------------------------------------------------------
r210995 | kpfleming | 2009-08-07 08:10:30 -0500 (Fri, 07 Aug 2009) | 20 lines

Merged revisions 210992 via svnmerge from
https://origsvn.digium.com/svn/asterisk/trunk

........
 r210992 | kpfleming | 2009-08-07 08:08:00 -0500 (Fri, 07 Aug 2009) | 13 lines
 
 Workaround broken T.38 endpoints that offer tiny MaxDatagram sizes.
 
 Some T.38 endpoints treat T38FaxMaxDatagram as the maximum IFP size that should
 be sent to them, rather than the maximum packet payload size. If such an
 endpoint also requests UDPRedundancy as the error correction mode, we'll end
 up calculating a tiny maximum IFP size, so small as to be unusable. This patch
 sets a lower bound on what we'll consider the remote's maximum IFP size to be,
 assuming that endpoints that do this really can accept larger packets than
 they've offered to accept.
 
 (closes issue ASTERISK-14593)
 Reported by: dazza76
........

------------------------------------------------------------------------

http://svn.digium.com/view/asterisk?view=rev&revision=210995
By: Darren Philips (dazza76) 2009-08-09 20:55:14

Issue Still Exists
Please see attachments

1.4 works

1.6 does not, same resulting error

[Aug 10 11:46:16] WARNING[11361]: udptl.c:1003 ast_udptl_write: UDPTL asked to send 53 bytes of IFP when far end only prepared to accept 45 bytes; data loss may occur.
[Aug 10 11:46:16] ERROR[11361]: udptl.c:292 encode_open_type: Buffer overflow detected (53 + 59 > 72)
[Aug 10 11:46:16] NOTICE[11361]: udptl.c:1014 ast_udptl_write: UDPTL Transmission error to 125.213.162.38:12112: Message too long
[Aug 10 11:46:16] WARNING[11361]: udptl.c:1003 ast_udptl_write: UDPTL asked to send 53 bytes of IFP when far end only prepared to accept 45 bytes; data loss may occur.
[Aug 10 11:46:16] ERROR[11361]: udptl.c:292 encode_open_type: Buffer overflow detected (53 + 59 > 72)
[Aug 10 11:46:16] NOTICE[11361]: udptl.c:1014 ast_udptl_write: UDPTL Transmission error to 125.213.162.38:12112: Message too long
[Aug 10 11:46:16] ERROR[11361]: udptl.c:292 encode_open_type: Buffer overflow detected (53 + 27 > 72)
[Aug 10 11:46:16] NOTICE[11361]: udptl.c:1014 ast_udptl_write: UDPTL Transmission error to 125.213.162.38:12112: Message too long
[Aug 10 11:46:21] ERROR[11361]: udptl.c:292 encode_open_type: Buffer overflow detected (41 + 47 > 72)
[Aug 10 11:46:21] NOTICE[11361]: udptl.c:1014 ast_udptl_write: UDPTL Transmission error to 125.213.162.38:12112: Message too long
[Aug 10 11:46:21] ERROR[11361]: udptl.c:292 encode_open_type: Buffer overflow detected (41 + 47 > 72)
[Aug 10 11:46:21] NOTICE[11361]: udptl.c:1014 ast_udptl_write: UDPTL Transmission error to 125.213.162.38:12112: Message too long
[Aug 10 11:46:21] ERROR[11361]: udptl.c:292 encode_open_type: Buffer overflow detected (41 + 47 > 72)
[Aug 10 11:46:21] NOTICE[11361]: udptl.c:1014 ast_udptl_write: UDPTL Transmission error to 125.213.162.38:12112: Message too long

Thanks for the help ,

I have also reported this issue to the carrier.

D


By: Kevin P. Fleming (kpfleming) 2009-08-10 10:28:31

As before, your packet capture file is not complete. For example, at packet 928 I see Asterisk sending an INVITE out, and at packet 938 is ACKs the response it got, but the response is not present in the capture.

It would really be extremely helpful if you got a capture on the Asterisk 1.6.x box itself, of *all* (and *only*) the SIP traffic. We don't need all the RTP and other junk that is in these captures. When you upload that, I'll also need the exact IP addresses of the endpoints involved in the call.
By: Darren Philips (dazza76) 2009-08-10 18:12:46

Sorry i can understand the frustration
So you can Understand them

10.1.20.183 = Vfe3 (Currently Callweaver 1.2 svn)
10.1.20.176 = Vbe2 (asterisk 1.6.1 svn) (Where wireshark is running)
202.137.160.86 = Vbe2 External interface
125.213.160.145 etc (Carrier)

and this is a wireshark from the server capturing all vlans on the interface

currently i am capturing using

tethereal -i eth0 -w ~/t38-1.6.pcap

Do you have a recommended tethereal configuration you would like me to use

Cheers

D
By: Kevin P. Fleming (kpfleming) 2009-08-11 06:34:02

It's much easier to use tcpdump than tethereal, first of all. Second, if you have traffic going out this 'external interface', then capturing only on eth0 is not going to get all of the SIP traffic.

I would suggest something like this, assuming you are running on Linux:

$ tcpdump -i any -n -s 0 -w ~/t38-1.6.pcap udp port 5060

This should get all traffic on any ports that is UDP and on UDP port 5060.
By: Darren Philips (dazza76) 2009-08-11 23:51:58

OK I have attached the new file ,

and Fyi i use multiple vlans not interfaces

10.1.20. is on 1000
202.137.160.86 is on 4

Hope it has the info you require .

D
By: Kevin P. Fleming (kpfleming) 2009-08-12 07:56:16

On Linux (like many other platforms), using VLANs means you have virtual interfaces on top of the real interface, and the virtual interfaces are where the IP addresses live and the packet captures are normally done. In any case, this packet capture does seem to be complete.

I can see one small bug in this capture which we can fix, although I don't believe it is the source of the problem. I'll continue looking into it this morning when I get to the office. In the meantime, you should also contact the CallWeaver folks and tell them they have a bug; Asterisk sent a T.38 reINVITE to CallWeaver with "T38FaxUdpEC:t38UDPFEC" and CallWeaver responded with "T38FaxUdpEC:t38UDPRedundancy", which is a protocol violation (according to the T.38 recommendation, it must respond with t3UDPFEC if that's what we offered or no EC mode at all).
By: Kevin P. Fleming (kpfleming) 2009-08-12 08:05:03

OK, we're getting closer to understanding the cause of this problem, but I'll need one more packet capture; use the tcpdump method I posted here, but don't filter it to just port 5060, because we'll need to see the UDPTL traffic as well.

# tcpdump -i any -n -s 0 -w ~/t38-1.6.pcap udp

That should do the trick. Thanks for your quick responses and patience... we'll get this figured out!
By: Darren Philips (dazza76) 2009-08-12 20:12:00

Well this is interesting it managed to negotiate and ifp size of 58 and 2400 baud the fax did succeed with SVN-branch-1.6.1-r211958M.
nothing like the ifp 238 and 14400 Baud but 1 step at a time hey.

I have always had it to run t38UDPRedundancy as it is the only one that has ever worked for me and the asterisk box had it set aswell.
next to that the next issue to get t38 working was for all parties to talk using the same codec but allowing for failover to ulaw if required.
1 way to improve it would be a force all devices to the same codec if t38 is requested.
By: Kevin P. Fleming (kpfleming) 2009-08-13 10:52:17

Based on that packet trace, it appears that the T.38 negotiation worked as expected, and the 'minimum IFP override' that has been added to Asterisk worked as planned.

I have no idea what this other codec-related issue you are talking about is, but it sounds like something that should be discussed on the mailing lists as desired behavior or configuration, rather than a bug in Asterisk.

I don't know how we are going to be able to send a larger IFP size out when we get T38FaxMaxDatagram of 72 bytes from your carrier; we cannot send them an IFP larger than that and expect things to work, so I have no clue how you ever got a successful FAX with an IFP size of 238 bytes.
By: Darren Philips (dazza76) 2009-08-16 19:32:24

Thanks for your help,
I am now chasing with the carrier about the issue ..
D