Steve Underwood ha scritto: > 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.
Don't know it it helps, but I have 2 new logs: http://www.navynet.it/t38/log/1/full http://www.navynet.it/t38/log/2/full The main difference is that in the first one (sorry for my terminlogy), it seems the two peers (txfax and the gateway) exchanged T38 capabilities but the fax was not transmitted correctly. In the second one, on the other side, it seems that in the initial RDP "conversation", a packet was missed and not recovered... so no T38 was negotiated. Is my interpretation correct ? In the first log, the starcomm gateway started sending udptl packets but there was no response from openpbx. Hope it may help. Max P.S.: would it be useful an ethereal dump of a real fax sent from the starcomm to a cisco ? _______________________________________________ Openpbx-dev mailing list [email protected] http://lists.openpbx.org/mailman/listinfo/openpbx-dev
