-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Sun, 2 Apr 2006, Steve Underwood wrote: >>> Here's a hint: "it doesn't work" is a completely useless report. :-) >>> What does happen? What do the logs show? Does it negotiate T.38 at all? >> Firstly, >> that branch is under development.. Or, it would be if it wasn't for a >> lot of other things that I need to do and the fact that I haven't had >> the time to read the T.38 specs yet =) > The T.38 spec is not that illuminating when you read it. :-)
Oh... Well, do you have anything illuminating on the subject? =) >> I've been testing with RxFax and trying to receive a fax using UDPTL >> The problems so far are: >> * chan_sip doesn't seem to detect the fax tones. I don't really see >> why, but it seems the goertzel detector doesn't detect it. WHat I >> found is that this check >> if (!hit && (fax_energy >= FAX_THRESHOLD) && >> (fax_energy >= DTMF_TO_TOTAL_ENERGY*s->energy) >> the second line never gets to be true. If I remove it it seems to >> detect the faxtones. But I don't understand what it does so I don't >> really want to remove it. Steve, if you could look at that it would >> be great! > That sounds like the signal is disorted by the codec to the point where > it lacks sufficient purity to be detected as a single tone. Which codec > did you use for the audio? G.711 ALAW was what I used. If I turn off T.38 I can send a fax to RxFax the "normal" way using the exact same setup. So RxFax seems to be able to make sense of the audio. >> * A really annoying bug in chan_sip/rtp/udptl/idontknowyet causes >> openpbx to ignore incoming frames until it has sent the first frame >> itself. So RxFax doesn't receive audio / udptl at all until it has >> sent the first frame itself. I needed to add a PlayTones() before >> the call to RxFax to hear the initial fax-tones in my test-phone and >> via the modem. > I think this is something to do with NAT handling, isn't it. I guess I > could make an initial transmission, just to kick things off. Might be. In any case RxFax shouldn't have to do anything about it since I can clearly see packets coming in to my pbx openpbx just doesn't seem to see them until it has sent something. And since this issue seems to exist with both udptl and rtp it should be fixed. I've tried to see what's wrong but the mechanism for reading/writing data in opbx is..well..odd to say the least so no luck so far. >> If anyone has any experience with T.38 and feels like looking at it, >> please do so! I probably won't have the time for a while =/ > You need to use a recent snapshot of spandsp. A couple of silly issues > in the T.38 code were reported to me, and fixed - bits being packed in > the wrong order at one point was something of a killer :-) People have > reported sending faxes in both directions with a recent snapshot, but > don't read too much into that. There are a lot of grey things in the > T.38 spec, and further work to ensure interworking with a lot of kit > that implements the T.38 spec in their own sweet way will be needed. > Also, I don't expect the current code to be that robust. Its really not > mature right now. The frame structure gained the sequence number of the > frames a while ago. It isn't used to the fullest extent, though. For > example, it should be used to define the sequence number of UDPTL frames > going out, and it isn't. This is important, since to make UDPTL robust > certain key frames should be repeated to minimise the risk of loss. This > is not specified, but it is common and sane practice. Ok, The t.38 branch requires a recent snapshot, and my tests so far have been using the 20060305 snapshot. But I haven't gotten to the T.38 part yet due to the problems above with getting opbx to see incoming udptl frames. /B - -- * GPG-Key: http://evil.gnarf.org/mrbk.pgp A: Because we read from top to bottom, left to right. Q: Why should i start my reply below the quoted text? - -- http://www.i-hate-computers.demon.co.uk/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFEL5nFckvkFeO3ANARAq1PAKDfAMtgDgkNCL+hdIXrixZtQMrG5wCeKeEW 282YtPAg2191APBLmrU7gcU= =gcOH -----END PGP SIGNATURE----- _______________________________________________ Openpbx-dev mailing list [email protected] http://lists.openpbx.org/mailman/listinfo/openpbx-dev
