On 10/07/2011 03:29 PM, James Sharp wrote:
On 10/07/2011 04:04 PM, Kevin P. Fleming wrote:
First, we can see that Gafachi's T.38 implementation still has some
breakage in it (although the problems are ones that Asterisk has been
taught to deal with). In its 200 OK to the T.38 re-INVITE, it has
"a=T38FaxRateManagement:transferredTCFlocalTCF"; this is not valid (the
valid values for this are 'transferredTCF' and 'localTCF'). In addition,
even though Asterisk sent "a=T38FaxUdpEC:t38UDPRedundancy", Gafachi
replied with "a=T38FaxUdpEC:t38UDPFEC". For T.38 version 0 (which is in
use here), the only valid response was either what Asterisk sent, or no
T38FaxUdpEC value at all.
However, it is unlikely those are causing the call failure here. It's
hard to say for sure without seeing the contents of the UDPTL packets,
but based on their sizes, they are very likely "t38-nosignal" packets,
and if that's all the FAX stack in Asterisk ever received, it would not
trigger a FAX transaction to begin. Another possible problem is the
repeated 'seq 0' in all the UDPTL packets, but this could be a problem
with the UDPTL stack debugging messages themselves (this was just fixed
in the Subversion branches for Asterisk 1.8 and later a couple of days
ago).
Theres a few t30-nosignal packets at the beginning, but then they
transition to other t30 packets, including CNG, CED, preambles, training
and data. Wireshark says the sequence number is always 0, so it appears
that Asterisk is not mis-displaying
You shouldn't be *receiving* CNG, as you are the calling endpoint.
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.
--
Kevin P. Fleming
Digium, Inc. | Director of Software Technologies
Jabber: kflem...@digium.com | SIP: kpflem...@digium.com | Skype: kpfleming
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
Check us out at www.digium.com & www.asterisk.org
--
_____________________________________________________________________
-- 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
