On 10/07/2011 04:42 PM, Kevin P. Fleming wrote:
You shouldn't be *receiving* CNG, as you are the calling endpoint.
You're right. Hadn't even thought about that.
If you are seeing UDPTL packets containing T.38 CED, V.21 preamble, DIS, etc. then something is badly wrong. ... and, that thing is probably the sequence number. Once Asterisk sees a packet with sequence number 0, any subsequent packets received with the same sequence number will be dropped (because according to the T.38 recommendation, they must be retransmissions... new packets would have higher sequence numbers). So these UDPTL packets are never making their way up to the FAX stack, and the FAX transaction never gets started. I guess it must be common for UDPTL stacks out there to just not care about repeated sequence numbers, although the one in Asterisk sure does (and it's based on the same code as the one in CallWeaver, FreeSwitch and maybe other packages too). If you'd like to experiment, you can comment out lines 495 and 511 of main/udptl.c, which will make Asterisk's UDPTL stack just not care at all about the incoming sequence number.
HEAD out of SVN + the sequence number change still gets no fax transmit. I do get a few addition fax status messages on the console, though. I'm getting
-- FAX handle 0: [ 000.062327 ], STAT_EVT_RX_IMG_STRT st: WT_DIS rt: UNEXPECT
4-9 times (with changing timestamps, of course), then nothing until disconnect.
It sounds like that Gafachi's T38 implementation is horribly, horribly broken. I'm not tied to them at all, so if their stuff is broken, I'll go somewhere else.
-- _____________________________________________________________________ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- New to Asterisk? Join us for a live introductory webinar every Thurs: http://www.asterisk.org/hello asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
