Re: [asterisk-users] Still on spandsp/app_fax and T.38
- Steve Underwood ste...@coppice.org escreveu: Hi Vinícius, Don't post big things, like wireshark traces, to a mailing list. They are likely to ban you. The first two calls in your wireshark log decode to the attached images. There were no lost packets. The wireshark logs contains exactly what the far end sent, and it was not good. The first fax page has 12 bad pixel rows. This page was accepted, as minor defects like this are normally accepted. The second fax starts out OK, then then just falls apart. I think the receive modem in that gateway probably lost sync. The data looks like complete rubbish beyond the part that decodes to something sensible. The system you are trying to interwork with seems to have serious issues. It can be difficult to get providers to sort out T.38 issues, as many of them have very little understanding of the systems they have. Even big carriers can be very unresponsive, because they just don't know what to do. Regards, Steve So there's no packet loss, but the provider is sending me rubbish, if I understand correctly. I'll try to explain that to them, at least there are people with brains and willing to listen on that company. About the other issues we talked about, is app_fax having the same behaviour as FFA, as expected now? Also (if I'm not asking too much), could you tell me how you decoded the packet stream into a tif file? That would be really useful on showing the problem to the telco guys. -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] Still on spandsp/app_fax and T.38
- Steve Underwood ste...@coppice.org escreveu: Hi Vinícius, Don't post big things, like wireshark traces, to a mailing list. They are likely to ban you. The first two calls in your wireshark log decode to the attached images. There were no lost packets. The wireshark logs contains exactly what the far end sent, and it was not good. The first fax page has 12 bad pixel rows. This page was accepted, as minor defects like this are normally accepted. The second fax starts out OK, then then just falls apart. I think the receive modem in that gateway probably lost sync. The data looks like complete rubbish beyond the part that decodes to something sensible. The system you are trying to interwork with seems to have serious issues. It can be difficult to get providers to sort out T.38 issues, as many of them have very little understanding of the systems they have. Even big carriers can be very unresponsive, because they just don't know what to do. Regards, Steve On 02/18/2010 12:19 AM, Vinícius Fontes wrote: Can you try the attached version of spandsp with the T.38 gateway you are using? It behaves a lot more like FFA, and I want to see if this makes the gateway behave properly. If it does I will have to consider some more permanent changes to spandsp to increase its tolerance of yet another broken T.38 implementation. It really is depressing having to work around other people's broken systems like this. Steve Hi Steve. I installed the spandsp you sent me and made some tests. Before proceeding, it is important to share with you what I noticed today. Even before I installed the new spandsp lib I noticed that I started to receive faxes at 9600 bps, only problem being the fax won't get received in about 60% of the cases. I'm guessing the provider changed something at their side, because I don't remember changing any configs on Asterisk. Also important to say that it is happening to both app_fax and FFA now. Anyway, I installed the spandsp you sent me and noticed no difference on the behaviour. Attached to this message is a capture of four calls. As usual, you should only consider calls from 5433142499 to 5421047008. There are four calls, detailed as follows: 1) app_fax, returned an error. Here's the CLI: [Feb 17 13:55:16] -- Executing [5421047...@entrada-e1:1] Goto(SIP/voxip-0010, interno,7008,1) in new stack [Feb 17 13:55:16] -- Goto (interno,7008,1) [Feb 17 13:55:16] -- Executing [7...@interno:1] Goto(SIP/voxip-0010, macro-recebefax,s,1) in new stack [Feb 17 13:55:16] -- Goto (macro-recebefax,s,1) [Feb 17 13:55:16] -- Executing [...@macro-recebefax:1] Set(SIP/voxip-0010, DB(fax/count)=92) in new stack [Feb 17 13:55:16] -- Executing [...@macro-recebefax:2] Set(SIP/voxip-0010, FAXCOUNT=92) in new stack [Feb 17 13:55:16] -- Executing [...@macro-recebefax:3] Set(SIP/voxip-0010, FAXFILE=fax-92-rx) in new stack [Feb 17 13:55:16] -- Executing [...@macro-recebefax:4] Set(SIP/voxip-0010, LOCALSTATIONID=5421047008) in new stack [Feb 17 13:55:16] -- Executing [...@macro-recebefax:5] ReceiveFAX(SIP/voxip-0010, /var/spool/asterisk/fax/fax-92-rx.tif) in new stack [Feb 17 13:56:03] WARNING[3418]: app_fax.c:128 span_message: WARNING T.30 Page did not end cleanly [Feb 17 13:56:09] WARNING[3418]: app_fax.c:178 phase_e_handler: Error transmitting fax. result=40: Unexpected DCN after requested retransmission. [Feb 17 13:56:09] WARNING[3418]: app_fax.c:767 transmit: Transmission failed [Feb 17 13:56:09] -- Executing [...@macro-recebefax:6] NoOp(SIP/voxip-0010, FAXSTATUS = FAILED) in new stack [Feb 17 13:56:09] -- Executing [...@macro-recebefax:7] NoOp(SIP/voxip-0010, FAXERROR = Unexpected DCN after requested retransmission) in new stack [Feb 17 13:56:09] -- Executing [...@macro-recebefax:8] NoOp(SIP/voxip-0010, CALLID = 5433142499 ) in new stack [Feb 17 13:56:09] -- Executing [...@macro-recebefax:9] NoOp(SIP/voxip-0010, FAXPAGES = ) in new stack [Feb 17 13:56:09] -- Executing [...@macro-recebefax:10] NoOp(SIP/voxip-0010, FAXBITRATE = ) in new stack [Feb 17 13:56:09] -- Executing [...@macro-recebefax:11] NoOp(SIP/voxip-0010, FAXRESOLUTION = ) in new stack [Feb 17 13:56:09] -- Executing [...@macro-recebefax:12] NoOp(SIP/voxip-0010, FAXMODE = T38) in new stack [Feb 17 13:56:09] -- Executing [...@macro-recebefax:13] Hangup(SIP/voxip-0010, ) in new stack [Feb 17 13:56:09] == Spawn extension (macro-recebefax, s, 13) exited non-zero on 'SIP/voxip-0010' 2) app_fax, received the fax succesfully. No configs changed. 3) FFA, error. All I did in order to use FFA was this: module unload app_fax.so module load res_fax.so module load res_fax_digium.so Here's the CLI when the error happened: [Feb 17 13:56:35]
Re: [asterisk-users] Still on spandsp/app_fax and T.38
- Vinícius Fontes vinic...@canall.com.br escreveu: - Steve Underwood ste...@coppice.org escreveu: Hi Vinícius, Don't post big things, like wireshark traces, to a mailing list. They are likely to ban you. The first two calls in your wireshark log decode to the attached images. There were no lost packets. The wireshark logs contains exactly what the far end sent, and it was not good. The first fax page has 12 bad pixel rows. This page was accepted, as minor defects like this are normally accepted. The second fax starts out OK, then then just falls apart. I think the receive modem in that gateway probably lost sync. The data looks like complete rubbish beyond the part that decodes to something sensible. The system you are trying to interwork with seems to have serious issues. It can be difficult to get providers to sort out T.38 issues, as many of them have very little understanding of the systems they have. Even big carriers can be very unresponsive, because they just don't know what to do. Regards, Steve On 02/18/2010 12:19 AM, Vinícius Fontes wrote: Can you try the attached version of spandsp with the T.38 gateway you are using? It behaves a lot more like FFA, and I want to see if this makes the gateway behave properly. If it does I will have to consider some more permanent changes to spandsp to increase its tolerance of yet another broken T.38 implementation. It really is depressing having to work around other people's broken systems like this. Steve Hi Steve. I installed the spandsp you sent me and made some tests. Before proceeding, it is important to share with you what I noticed today. Even before I installed the new spandsp lib I noticed that I started to receive faxes at 9600 bps, only problem being the fax won't get received in about 60% of the cases. I'm guessing the provider changed something at their side, because I don't remember changing any configs on Asterisk. Also important to say that it is happening to both app_fax and FFA now. Anyway, I installed the spandsp you sent me and noticed no difference on the behaviour. Attached to this message is a capture of four calls. As usual, you should only consider calls from 5433142499 to 5421047008. There are four calls, detailed as follows: 1) app_fax, returned an error. Here's the CLI: [Feb 17 13:55:16] -- Executing [5421047...@entrada-e1:1] Goto(SIP/voxip-0010, interno,7008,1) in new stack [Feb 17 13:55:16] -- Goto (interno,7008,1) [Feb 17 13:55:16] -- Executing [7...@interno:1] Goto(SIP/voxip-0010, macro-recebefax,s,1) in new stack [Feb 17 13:55:16] -- Goto (macro-recebefax,s,1) [Feb 17 13:55:16] -- Executing [...@macro-recebefax:1] Set(SIP/voxip-0010, DB(fax/count)=92) in new stack [Feb 17 13:55:16] -- Executing [...@macro-recebefax:2] Set(SIP/voxip-0010, FAXCOUNT=92) in new stack [Feb 17 13:55:16] -- Executing [...@macro-recebefax:3] Set(SIP/voxip-0010, FAXFILE=fax-92-rx) in new stack [Feb 17 13:55:16] -- Executing [...@macro-recebefax:4] Set(SIP/voxip-0010, LOCALSTATIONID=5421047008) in new stack [Feb 17 13:55:16] -- Executing [...@macro-recebefax:5] ReceiveFAX(SIP/voxip-0010, /var/spool/asterisk/fax/fax-92-rx.tif) in new stack [Feb 17 13:56:03] WARNING[3418]: app_fax.c:128 span_message: WARNING T.30 Page did not end cleanly [Feb 17 13:56:09] WARNING[3418]: app_fax.c:178 phase_e_handler: Error transmitting fax. result=40: Unexpected DCN after requested retransmission. [Feb 17 13:56:09] WARNING[3418]: app_fax.c:767 transmit: Transmission failed [Feb 17 13:56:09] -- Executing [...@macro-recebefax:6] NoOp(SIP/voxip-0010, FAXSTATUS = FAILED) in new stack [Feb 17 13:56:09] -- Executing [...@macro-recebefax:7] NoOp(SIP/voxip-0010, FAXERROR = Unexpected DCN after requested retransmission) in new stack [Feb 17 13:56:09] -- Executing [...@macro-recebefax:8] NoOp(SIP/voxip-0010, CALLID = 5433142499 ) in new stack [Feb 17 13:56:09] -- Executing [...@macro-recebefax:9] NoOp(SIP/voxip-0010, FAXPAGES = ) in new stack [Feb 17 13:56:09] -- Executing [...@macro-recebefax:10] NoOp(SIP/voxip-0010, FAXBITRATE = ) in new stack [Feb 17 13:56:09] -- Executing [...@macro-recebefax:11] NoOp(SIP/voxip-0010, FAXRESOLUTION = ) in new stack [Feb 17 13:56:09] -- Executing [...@macro-recebefax:12] NoOp(SIP/voxip-0010, FAXMODE = T38) in new stack [Feb 17 13:56:09] -- Executing [...@macro-recebefax:13] Hangup(SIP/voxip-0010, ) in new stack [Feb 17 13:56:09] == Spawn extension (macro-recebefax, s, 13) exited non-zero on 'SIP/voxip-0010' 2) app_fax, received the fax succesfully. No configs changed. 3) FFA, error. All
Re: [asterisk-users] Still on spandsp/app_fax and T.38
- Kevin P. Fleming kpflem...@digium.com escreveu: Vinícius Fontes wrote: Will do. You guys will have my feedback on monday. If everything goes okay with that change, I'll post a patch on Mantis. No need for the patch; it's already on my radar, and if you confirm that it actually solves an interop problem, I'll commit the update to the various branches it belongs in. I'd still like to hear from Steve Underwood if I misinterpreted the MMR/JBIG transcoding function calls in spandsp that led me to enabling these features in the first place... - Vinícius Fontes vinic...@canall.com.br escreveu: Unfortunely it didn't solve the problem. Here's the session packet capture after editing app_fax.c. http://www.canall.com.br/wireshark_t38_jbig.gz I've tried everything. EVERYTHING. Almost every combination of maxdatagram sizes, error correction modes, hacking app_fax.c to limit the baudrate to 9600... nothing. Every single time I get rates like 2400, 4800 or if I'm very lucky, 7200. In ALL cases, *every single time*, FFA negotiated the connection at 9600bps and the fax was received cleanly. It's clear to me that the provider should not be blamed on this case. I tried using a Linksys SPA8000 and faxes are also received perfectly. Something, either in Asterisk, SpanDSP or app_fax is just not right. For now I'll have to stick with FFA for my company and my customers. They will not be happy to know that in order to transmit or receive more than one fax simultaneously they will need a US$40 license, but it's still better than quadrupling the phone bills because for some unknown reason the baudrate is 4 times slower than it should be. I'm still willing to solve this. I really want to get app_fax working as intended. I'm sure this is on the best interests of the community as well. Unfortunely I don't have the knowledge or skills on faxing protocols, DSP and C development or else I would have solved this myself. But I'm doing my part on this by providing all necessary info and running every single test I'm asked to. IMHO it would be a shame if we need to rely on a commercial piece of software because the open source equivalent is 4 times slower on some cases. For me it defies the very reason of Asterisk's existence: an open source alternative on a market flooded with proprietary solutions. -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] Still on spandsp/app_fax and T.38
On 02/15/2010 08:57 PM, Vinícius Fontes wrote: - Kevin P. Flemingkpflem...@digium.com escreveu: Vinícius Fontes wrote: Will do. You guys will have my feedback on monday. If everything goes okay with that change, I'll post a patch on Mantis. No need for the patch; it's already on my radar, and if you confirm that it actually solves an interop problem, I'll commit the update to the various branches it belongs in. I'd still like to hear from Steve Underwood if I misinterpreted the MMR/JBIG transcoding function calls in spandsp that led me to enabling these features in the first place... - Vinícius Fontesvinic...@canall.com.br escreveu: Unfortunely it didn't solve the problem. Here's the session packet capture after editing app_fax.c. http://www.canall.com.br/wireshark_t38_jbig.gz I've tried everything. EVERYTHING. Almost every combination of maxdatagram sizes, error correction modes, hacking app_fax.c to limit the baudrate to 9600... nothing. Every single time I get rates like 2400, 4800 or if I'm very lucky, 7200. In ALL cases, *every single time*, FFA negotiated the connection at 9600bps and the fax was received cleanly. It's clear to me that the provider should not be blamed on this case. I tried using a Linksys SPA8000 and faxes are also received perfectly. Something, either in Asterisk, SpanDSP or app_fax is just not right. For now I'll have to stick with FFA for my company and my customers. They will not be happy to know that in order to transmit or receive more than one fax simultaneously they will need a US$40 license, but it's still better than quadrupling the phone bills because for some unknown reason the baudrate is 4 times slower than it should be. I'm still willing to solve this. I really want to get app_fax working as intended. I'm sure this is on the best interests of the community as well. Unfortunely I don't have the knowledge or skills on faxing protocols, DSP and C development or else I would have solved this myself. But I'm doing my part on this by providing all necessary info and running every single test I'm asked to. IMHO it would be a shame if we need to rely on a commercial piece of software because the open source equivalent is 4 times slower on some cases. For me it defies the very reason of Asterisk's existence: an open source alternative on a market flooded with proprietary solutions. I've been travelling for the last week, so I only just got back to this problem. Let's be clear. The problem is a broken T.38 gateway at the far end. For some reason your other tests are not provoking the same bad behaviour. I have seen similar behaviour in a log before, but I was unable to follow up that time, and find what was really going on. A lot of the work in implementing T.38 is making it tolerant of other broken T.38 implementations. Let's see what we can do about this one. It looks like the T.38 gateway at the far end does something very wrong 3.5s after the end of the DIS and FTT messages from app_fax end. 3.5s is one of the key timeouts in the T.30 protocol, so I expect the gateway is confused, and is trying to incorrectly spoof the T.38 protocol. 3.5s after the DIS message ends, the far end FAX machine is sending TCF data, which suddenly corrupts. Even in the successful FFA packet trace I was given, there is minor corruption at the same point. Its not enough to upset transmission, though. With app_fax the TCF transmission is totally messed up. My guess is the far end gateway suddenly starts transmitting V.21 data to the FAX machine, even though it is already successfully decoding V.29 data from that FAX machine. I have seen other T.38 gateways start sending at an entirely wrong time. So, let's list the differences. The options offered in the DIS messages from FFA and app_fax are very similar. The timing of the messages is also very similar. The differences are: - app_fax is not sending an identity (CSI) frame, but FFA is. - FFA sends many no-signal packets, while app_fax only sends one. Either should be OK, and you'll see both practices used by various T.38 implementations. - FFA sends many v21-preamble and v29-9600-training packets, while app_fax only sends one. Again, either should be OK, and both are common practices. You could try defining the same identity string for app_fax that you have defined for FFA. Trying to make the other things more similar would require additional work. Maybe you should try that change first, as it is very simple, and requires no code changes. FFA sends its repeating no-signal and preamble packets with incrementing sequence numbers. While its not the only system which does that, it confuses some T.38 implementations. The T.38 spec is too vague to say whether the practice is right or wrong. In other applications of the FAX
Re: [asterisk-users] Still on spandsp/app_fax and T.38
Steve Underwood wrote: FFA sends its repeating no-signal and preamble packets with incrementing sequence numbers. While its not the only system which does that, it confuses some T.38 implementations. The T.38 spec is too vague to say whether the practice is right or wrong. In other applications of the FAX machine in spandsp, the software has been set up to send multiple copies on the key packets, with the same sequence number for all the copies. This seems to be the most compatible way to send these repeats. I don't know if the UDPTL infrastructure in Asterisk can do that. No, it can't without some modifications. The Asterisk UDPTL stack receives raw IFPs from the application, and generates sequence numbers itself. At this time internal Asterisk frames have no way of being marked as a 'repeat' frame, or marked as 'send this frame _x_ times', but that certainly could be done if it was deemed useful and worthwhile. -- Kevin P. Fleming Digium, Inc. | Director of Software Technologies 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA skype: kpfleming | jabber: kpflem...@digium.com Check us out at www.digium.com www.asterisk.org -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] Still on spandsp/app_fax and T.38
On 02/15/2010 11:27 PM, Kevin P. Fleming wrote: Steve Underwood wrote: FFA sends its repeating no-signal and preamble packets with incrementing sequence numbers. While its not the only system which does that, it confuses some T.38 implementations. The T.38 spec is too vague to say whether the practice is right or wrong. In other applications of the FAX machine in spandsp, the software has been set up to send multiple copies on the key packets, with the same sequence number for all the copies. This seems to be the most compatible way to send these repeats. I don't know if the UDPTL infrastructure in Asterisk can do that. No, it can't without some modifications. The Asterisk UDPTL stack receives raw IFPs from the application, and generates sequence numbers itself. At this time internal Asterisk frames have no way of being marked as a 'repeat' frame, or marked as 'send this frame _x_ times', but that certainly could be done if it was deemed useful and worthwhile. In callweaver we gave the frames an extra parameter, which is the number of copies to send. It is the UDPTL code which creates the extra copies on the wire. They are not spaced in time, which would probably be a good enhancement. Packet loss tends to be bursty, so if you loose one packet sent right now you probably loose all of them. Steve -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] Still on spandsp/app_fax and T.38
Steve Underwood wrote: In callweaver we gave the frames an extra parameter, which is the number of copies to send. It is the UDPTL code which creates the extra copies on the wire. They are not spaced in time, which would probably be a good enhancement. Packet loss tends to be bursty, so if you loose one packet sent right now you probably loose all of them. Presumably then for FEC/redundancy purposes you treat this as if the application had delivered 'n' copies of the IFP as well. Spacing them out in time could be complex, to say the least :-) -- Kevin P. Fleming Digium, Inc. | Director of Software Technologies 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA skype: kpfleming | jabber: kpflem...@digium.com Check us out at www.digium.com www.asterisk.org -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] Still on spandsp/app_fax and T.38
You could try defining the same identity string for app_fax that you
have defined for FFA. Trying to make the other things more similar
would
require additional work. Maybe you should try that change first, as it
is very simple, and requires no code changes.
My receiving fax macro, used both for app_fax and FFA is this one:
[macro-recebefax]
exten = s,1,Set(DB(fax/count)=$[${DB(fax/count)} + 1])
exten = s,n,Set(FAXCOUNT=${DB(fax/count)})
exten = s,n,Set(FAXFILE=fax-${DB(fax/count)}-rx)
exten = s,n,ReceiveFAX(/var/spool/asterisk/fax/${FAXFILE}.tif)
exten = s,n,NoOp(FAXSTATUS = ${FAXSTATUS})
exten = s,n,NoOp(FAXERROR = ${FAXERROR})
exten = s,n,NoOp(CALLID = ${CALLERID(name)} ${CALLERID(num)}
${REMOTESTATIONID})
exten = s,n,NoOp(FAXPAGES = ${FAXPAGES})
exten = s,n,NoOp(FAXBITRATE = ${FAXBITRATE})
exten = s,n,NoOp(FAXRESOLUTION = ${FAXRESOLUTION})
exten = s,n,NoOp(FAXMODE = ${FAXMODE})
exten = s,n,Hangup()
I don't set the identity string anywhere, not that I know of at least. I think
you're talking about the LOCALSTATIONID and LOCALHEADERINFO variables, that's
it? If so, I tried to set them before calling ReceiveFAX() and got the same
results, unfortunely.
--
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
asterisk-users mailing list
To UNSUBSCRIBE or update options visit:
http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] Still on spandsp/app_fax and T.38
- Kevin P. Fleming kpflem...@digium.com escreveu: Vinícius Fontes wrote: Will do. You guys will have my feedback on monday. If everything goes okay with that change, I'll post a patch on Mantis. No need for the patch; it's already on my radar, and if you confirm that it actually solves an interop problem, I'll commit the update to the various branches it belongs in. I'd still like to hear from Steve Underwood if I misinterpreted the MMR/JBIG transcoding function calls in spandsp that led me to enabling these features in the first place... -- Kevin P. Fleming Digium, Inc. | Director of Software Technologies 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA skype: kpfleming | jabber: kpflem...@digium.com Check us out at www.digium.com www.asterisk.org - Vinícius Fontes vinic...@canall.com.br escreveu: Unfortunely it didn't solve the problem. Here's the session packet capture after editing app_fax.c. http://www.canall.com.br/wireshark_t38_jbig.gz Atenciosamente, Vinícius Fontes Gerente de Segurança da Informação Canall Tecnologia em Comunicações Passo Fundo - RS - Brasil +55 54 2104-7000 Information Security Manager Canall Tecnologia em Comunicações Passo Fundo - RS - Brazil +55 54 2104-7000 Sorry for the shameless bump, but... any news on this? :) -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] Still on spandsp/app_fax and T.38
Unfortunely it didn't solve the problem. Here's the session packet capture after editing app_fax.c. http://www.canall.com.br/wireshark_t38_jbig.gz Atenciosamente, Vinícius Fontes Gerente de Segurança da Informação Canall Tecnologia em Comunicações Passo Fundo - RS - Brasil +55 54 2104-7000 Information Security Manager Canall Tecnologia em Comunicações Passo Fundo - RS - Brazil +55 54 2104-7000 - Kevin P. Fleming kpflem...@digium.com escreveu: Vinícius Fontes wrote: Will do. You guys will have my feedback on monday. If everything goes okay with that change, I'll post a patch on Mantis. No need for the patch; it's already on my radar, and if you confirm that it actually solves an interop problem, I'll commit the update to the various branches it belongs in. I'd still like to hear from Steve Underwood if I misinterpreted the MMR/JBIG transcoding function calls in spandsp that led me to enabling these features in the first place... -- Kevin P. Fleming Digium, Inc. | Director of Software Technologies 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA skype: kpfleming | jabber: kpflem...@digium.com Check us out at www.digium.com www.asterisk.org -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] Still on spandsp/app_fax and T.38
Hi Vinícius, Comparing the successful log using FFA and the failing one using app_fax, I see the following: In the call using FFA, the far end system sends a V.29/9600bps FAX page, using T.38, which transfers cleanly, and the call ends. In the call using app_fax/spandsp, the SIP has a couple of key difference. Asterisk incorrectly adds T38FaxTranscodingMMR T38FaxTranscodingJBIG to the SDP. I don't know if that might be confusing the far end. The T.38 exchange starts in a very similar way to the FFA call, up to the middle of the TCF data. This should be all zeros, but half way through the far end suddenly starts sending rubbish. Spandsp correctly rejects this. The other system sends bad training data at V.27ter/4800bps. Spandsp rejects it. The other system sends clean training data at V.27ter/2400bps. Spandsp accepts it. The other system sends a page at V.27ter/2400bps. Spandsp accepts it. The only wrongdoing I see is the far end going weird in the training data, yet this doesn't happen with the FFA call. Whatever makes the far end fall over must be something fairly subtle. Since the 2 SDP lines I listed above shouldn't be there, I think they should be removed, and the test tried again. Much of the work in developing a robust T.38 implementation is working around all the crappy implementations out there. Steve On 02/06/2010 01:47 AM, Vinícius Fontes wrote: There you go: http://www.canall.com.br/wireshark_trace_t38_ffa.gz Atenciosamente, Vinícius Fontes Gerente de Segurança da Informação Canall Tecnologia em Comunicações Passo Fundo - RS - Brasil +55 54 2104-7000 Information Security Manager Canall Tecnologia em Comunicações Passo Fundo - RS - Brazil +55 54 2104-7000 - Steve Underwoodste...@coppice.org escreveu: Hi Vinícius, Asterisk + Spandsp is working correctly in that call. The other system sends bad training data at V.29/9600bps. Spandsp rejects it. The other system sends bad training data at V.27ter/4800bps. Spandsp rejects it. The other system sends clean training data at V.27ter/2400bps. Spandsp accepts it. The other system sends a page at V.27ter/2400bps. Spandsp accepts it. The bad training data is *really* bad. It should be 1.5s of all zero bits. It starts off with zeros, but after a few hundred milliseconds it changes to complete rubbish. I can't believe the Commetrex engine in Digium's FAX for Asterisk would accept this. Perhaps something subtle means they are sent the correct data. Can you send a wireshark log of a call with FAX for Asterisk? Steve On 02/06/2010 12:43 AM, Vinícius Fontes wrote: No problem, hosted it on my company's website: http://www.canall.com.br/wireshark_trace_t38.gz. Atenciosamente, Vinícius Fontes Gerente de Segurança da Informação Canall Tecnologia em Comunicações Passo Fundo - RS - Brasil +55 54 2104-7000 Information Security Manager Canall Tecnologia em Comunicações Passo Fundo - RS - Brazil +55 54 2104-7000 - Steve Underwoodste...@coppice.org escreveu: On 02/06/2010 12:01 AM, Vinícius Fontes wrote: Here's the packet trace I promised: http://www.zshare.net/download/72186098494e6f8c/. As this is a production system, there were a few calls along with the one that interests us. The one you're looking for is that from 5433142...@10.150.65.16 to 5421047...@10.153.66.146. The provider has the address 10.150.65.16 and my box has the address 10.153.66.146. Can you put the file somewhere that actually works. I've downloaded it 5 times now, and it has been cutoff at different points each time. These free file sharing services all seem to do this. Maybe they all run the same broken software. Steve -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] Still on spandsp/app_fax and T.38
Steve Underwood wrote: The only wrongdoing I see is the far end going weird in the training data, yet this doesn't happen with the FFA call. Whatever makes the far end fall over must be something fairly subtle. Since the 2 SDP lines I listed above shouldn't be there, I think they should be removed, and the test tried again. In order to test that quickly, you could edit apps/app_fax.c and find the lines that set transcoding_mmr and transcoding_jbig to '1', and change them to '0' (zero) or remove them. -- Kevin P. Fleming Digium, Inc. | Director of Software Technologies 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA skype: kpfleming | jabber: kpflem...@digium.com Check us out at www.digium.com www.asterisk.org -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] Still on spandsp/app_fax and T.38
Will do. You guys will have my feedback on monday. If everything goes okay with that change, I'll post a patch on Mantis. Atenciosamente, Vinícius Fontes Gerente de Segurança da Informação Canall Tecnologia em Comunicações Passo Fundo - RS - Brasil +55 54 2104-7000 Information Security Manager Canall Tecnologia em Comunicações Passo Fundo - RS - Brazil +55 54 2104-7000 - Kevin P. Fleming kpflem...@digium.com escreveu: Steve Underwood wrote: The only wrongdoing I see is the far end going weird in the training data, yet this doesn't happen with the FFA call. Whatever makes the far end fall over must be something fairly subtle. Since the 2 SDP lines I listed above shouldn't be there, I think they should be removed, and the test tried again. In order to test that quickly, you could edit apps/app_fax.c and find the lines that set transcoding_mmr and transcoding_jbig to '1', and change them to '0' (zero) or remove them. -- Kevin P. Fleming Digium, Inc. | Director of Software Technologies 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA skype: kpfleming | jabber: kpflem...@digium.com Check us out at www.digium.com www.asterisk.org -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] Still on spandsp/app_fax and T.38
Vinícius Fontes wrote: Will do. You guys will have my feedback on monday. If everything goes okay with that change, I'll post a patch on Mantis. No need for the patch; it's already on my radar, and if you confirm that it actually solves an interop problem, I'll commit the update to the various branches it belongs in. I'd still like to hear from Steve Underwood if I misinterpreted the MMR/JBIG transcoding function calls in spandsp that led me to enabling these features in the first place... -- Kevin P. Fleming Digium, Inc. | Director of Software Technologies 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA skype: kpfleming | jabber: kpflem...@digium.com Check us out at www.digium.com www.asterisk.org -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] Still on spandsp/app_fax and T.38
On 02/05/2010 07:40 PM, Vinícius Fontes wrote: This message is pointed directly to Steve Underwood. I tought it would not be nice to directly email him with a question that interests a good part of the Asterisk community, so here it is. :) Steve, remember a few days ago when we discussed about issues on Asterisk 1.6.1.13 and T.38 fax reception? Well I opened an issue on Mantis (https://issues.asterisk.org/view.php?id=16756) and turns out it might be spandsp-related. What happens is, when I use app_fax to receive a fax using T.38, I get very low transmission rates, and about 30% of the faxes are just not transmitted at all. 2400bps is not uncommon. If instead of T.38 I use an analog landline connected to that very same Asterisk box, app_fax works wonderfully well transmitting at full 9600bps. Just to rule out Asterisk's T.38 handling, I noticed that Fax For Asterisk works perfectly with T.38, also on that same box. Is the FAX machine you are using only capable of 9600bps, because full speed should be 14400bps? Can you get a packet trace of a problem call, using wireshark, and mail it to me? I'll be happy to provide you any info that could help solve this issue. Steve -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] Still on spandsp/app_fax and T.38
Yes, the fax machine only transmits at 9600. That's normal and expected. I'll capture the packets and will provide you with a link to download it in a few minutes. Atenciosamente, Vinícius Fontes Gerente de Segurança da Informação Canall Tecnologia em Comunicações Passo Fundo - RS - Brasil +55 54 2104-7000 Information Security Manager Canall Tecnologia em Comunicações Passo Fundo - RS - Brazil +55 54 2104-7000 - Steve Underwood ste...@coppice.org escreveu: On 02/05/2010 07:40 PM, Vinícius Fontes wrote: This message is pointed directly to Steve Underwood. I tought it would not be nice to directly email him with a question that interests a good part of the Asterisk community, so here it is. :) Steve, remember a few days ago when we discussed about issues on Asterisk 1.6.1.13 and T.38 fax reception? Well I opened an issue on Mantis (https://issues.asterisk.org/view.php?id=16756) and turns out it might be spandsp-related. What happens is, when I use app_fax to receive a fax using T.38, I get very low transmission rates, and about 30% of the faxes are just not transmitted at all. 2400bps is not uncommon. If instead of T.38 I use an analog landline connected to that very same Asterisk box, app_fax works wonderfully well transmitting at full 9600bps. Just to rule out Asterisk's T.38 handling, I noticed that Fax For Asterisk works perfectly with T.38, also on that same box. Is the FAX machine you are using only capable of 9600bps, because full speed should be 14400bps? Can you get a packet trace of a problem call, using wireshark, and mail it to me? I'll be happy to provide you any info that could help solve this issue. Steve -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] Still on spandsp/app_fax and T.38
Here's the packet trace I promised: http://www.zshare.net/download/72186098494e6f8c/. As this is a production system, there were a few calls along with the one that interests us. The one you're looking for is that from 5433142...@10.150.65.16 to 5421047...@10.153.66.146. The provider has the address 10.150.65.16 and my box has the address 10.153.66.146. Atenciosamente, Vinícius Fontes Gerente de Segurança da Informação Canall Tecnologia em Comunicações Passo Fundo - RS - Brasil +55 54 2104-7000 Information Security Manager Canall Tecnologia em Comunicações Passo Fundo - RS - Brazil +55 54 2104-7000 - Vinícius Fontes vinic...@canall.com.br escreveu: Yes, the fax machine only transmits at 9600. That's normal and expected. I'll capture the packets and will provide you with a link to download it in a few minutes. Atenciosamente, Vinícius Fontes Gerente de Segurança da Informação Canall Tecnologia em Comunicações Passo Fundo - RS - Brasil +55 54 2104-7000 Information Security Manager Canall Tecnologia em Comunicações Passo Fundo - RS - Brazil +55 54 2104-7000 - Steve Underwood ste...@coppice.org escreveu: On 02/05/2010 07:40 PM, Vinícius Fontes wrote: This message is pointed directly to Steve Underwood. I tought it would not be nice to directly email him with a question that interests a good part of the Asterisk community, so here it is. :) Steve, remember a few days ago when we discussed about issues on Asterisk 1.6.1.13 and T.38 fax reception? Well I opened an issue on Mantis (https://issues.asterisk.org/view.php?id=16756) and turns out it might be spandsp-related. What happens is, when I use app_fax to receive a fax using T.38, I get very low transmission rates, and about 30% of the faxes are just not transmitted at all. 2400bps is not uncommon. If instead of T.38 I use an analog landline connected to that very same Asterisk box, app_fax works wonderfully well transmitting at full 9600bps. Just to rule out Asterisk's T.38 handling, I noticed that Fax For Asterisk works perfectly with T.38, also on that same box. Is the FAX machine you are using only capable of 9600bps, because full speed should be 14400bps? Can you get a packet trace of a problem call, using wireshark, and mail it to me? I'll be happy to provide you any info that could help solve this issue. Steve -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] Still on spandsp/app_fax and T.38
There you go: http://www.canall.com.br/wireshark_trace_t38_ffa.gz Atenciosamente, Vinícius Fontes Gerente de Segurança da Informação Canall Tecnologia em Comunicações Passo Fundo - RS - Brasil +55 54 2104-7000 Information Security Manager Canall Tecnologia em Comunicações Passo Fundo - RS - Brazil +55 54 2104-7000 - Steve Underwood ste...@coppice.org escreveu: Hi Vinícius, Asterisk + Spandsp is working correctly in that call. The other system sends bad training data at V.29/9600bps. Spandsp rejects it. The other system sends bad training data at V.27ter/4800bps. Spandsp rejects it. The other system sends clean training data at V.27ter/2400bps. Spandsp accepts it. The other system sends a page at V.27ter/2400bps. Spandsp accepts it. The bad training data is *really* bad. It should be 1.5s of all zero bits. It starts off with zeros, but after a few hundred milliseconds it changes to complete rubbish. I can't believe the Commetrex engine in Digium's FAX for Asterisk would accept this. Perhaps something subtle means they are sent the correct data. Can you send a wireshark log of a call with FAX for Asterisk? Steve On 02/06/2010 12:43 AM, Vinícius Fontes wrote: No problem, hosted it on my company's website: http://www.canall.com.br/wireshark_trace_t38.gz. Atenciosamente, Vinícius Fontes Gerente de Segurança da Informação Canall Tecnologia em Comunicações Passo Fundo - RS - Brasil +55 54 2104-7000 Information Security Manager Canall Tecnologia em Comunicações Passo Fundo - RS - Brazil +55 54 2104-7000 - Steve Underwoodste...@coppice.org escreveu: On 02/06/2010 12:01 AM, Vinícius Fontes wrote: Here's the packet trace I promised: http://www.zshare.net/download/72186098494e6f8c/. As this is a production system, there were a few calls along with the one that interests us. The one you're looking for is that from 5433142...@10.150.65.16 to 5421047...@10.153.66.146. The provider has the address 10.150.65.16 and my box has the address 10.153.66.146. Can you put the file somewhere that actually works. I've downloaded it 5 times now, and it has been cutoff at different points each time. These free file sharing services all seem to do this. Maybe they all run the same broken software. Steve -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
