Hi VladK VladK wrote:
>Thank you Steve. > Updated spandsp, recompiled openpbx and did several tests and put all >results/debug to ftp server. >Please check it out. > ftp://70.147.242.42/pub/ > >Here is the brief summary: >rxfax <-> HT488 - mostly works >txfax <-> HT488 - doesn't work. >rxfax <-> mediatrix - worked once or so, the rest failed. >txfax <-> mediatrix - doesn't work. > >BTW, just FYI I did tests with latest mediatrix firmware 5.0.15.92 > > The changes I made yesterday have allowed the mediatrix tests to get further. However, they now pass the initial training test and get stuck with the mediatrix box sending something like this: Dec 7 08:17:24 T.38 Rx 77: indicator T38_IND_V17_14400_SHORT_TRAINING Dec 7 08:17:24 T.38 Rx 78: data type T38_DATA_V17_14400/T38_FIELD_HDLC_SIG_END + 0 byte(s) After this there is no more signal from the mediatrix box. Things time out at the openpbx end after 6 seconds, and the software gives up. A quite blip of carrier like this is quite possible if something called TEP is enabled (its a short pulse of carrier before the real carrier), but the carrier should have been raised again, and real data exchanged. I think I have an explanation for the Grandstream not working 100% of the time with rxfax. I had changed to spandsp today, and there is a new snapshot available. Can you try this. The problem with txfax and the Grandstream, seems to be that the Grandstream does something odd in SIP negotiation. Can you try using txfax without setting T38_CALL, and see what happens? We have had problems with other boxes when we try to start in T.38 mode, rather than switching to it from audio mode. Regards, Steve _______________________________________________ Openpbx-users mailing list [email protected] http://lists.openpbx.org/mailman/listinfo/openpbx-users
