Adam Megacz wrote:
The bounty stands at $5,500. I'm seriously considering taking a shot
at it if I can find a decent T.38 provider to test with (I'm still
hoping for reliable PAYG T.38).
It looks like a lot of very smart people have done a lot of very hard
work (t38modem, spandsp) that would go towards getting this working.
At this point it appears to be mostly a matter of integration
(libspandsp+asterisk), encapsulating T.38 inside IAX2 (not too hard),
and testing (tedious and time-consuming). Basically the easier but
less-fun part of the "big-picture" task.
t38modem is of little use for this. It is purely a terminating program.
spandsp is, of course, applicable as its modems are a core requirement.
Doing a quick botch up of T.38 isn't too hard. A solid reliable
implementation takes considerably more effort. Some real R as well as D
is needed to do it properly. The bounties give no indication of criteria
for judging completeness.
My main question is this: how is the bounty divided? Does the person
who does this "grunt work" get the whole $5,500, or does part of it go
to the authors of t38modem/spandsp (which would surely be a large part
of any solution)?
I think you should forget these bounties. There is nobody administering
them, so I think the chances of a payout are minimal.
I guess on one hand it would be unjust *not* to divide the bounty with
them, but on the other hand, if the bounty is to be divided, I think
the uncertainty about exactly how that would happen might be a factor
in why the bounty has gone unclaimed for so long.
It has gone unclaimed for so long because the problem is not trivial,
and I have been too busy with other things to complete my
implementation. It has been sitting here half finished since the
beginning of the year. Passthrough is simple, but the interesting things
are termination, and PSTN gateway operation. The code I have, tidied up,
would provide UDPTL-to-UDPTL passthrough operation for SIP, which many
would find useful. Maybe I should tidy and commit it as an interm step.
It implements the UDPTL transport, with full FEC handling, and offer
some simple botches to sip.c to make it udptl and T.38 aware. I have
most of a gateway and termination implementation, too, but it isn't
close to being ready to commit. I find sip.c is currently too messy to
produce anything more than a botch for it. A couple of people have said
they are reworking sip.c to make the addition of new codecs, transports,
etc. and their renegotiation function smoothly. I haven't seen any
results so far. I did only minimal work on sip.c in the hope that one
those efforts would bear fruit in * 1.2.
As with many things in *, the licencing forced me to do rather more work
than necessary. If * were GPL, I could have used some GPL'ed ASN.1 code
I found. To make code that could be committed to CVS I had to spend
quite some time rolling my own routines. The final result is faster, but
it took a lot more effort.
Regards,
Steve
_______________________________________________
Asterisk-Users mailing list
Asterisk-Users@lists.digium.com
http://lists.digium.com/mailman/listinfo/asterisk-users
To UNSUBSCRIBE or update options visit:
http://lists.digium.com/mailman/listinfo/asterisk-users
