Hello all,

I suggest to think about reversed logic of T.38 processing - IMHO it will
be better to _disable_ it by default and _enable_ with some variable like
T38_ENABLE for selected peers or sessions.

Currently we are in process of switching our customers
from Asterisk-based server to CW-based and we realized that there a
lot of problems with different CPE gateways: some of them just disconnect
outgoung call when receive INVITE with T.38, some of them sends
totally wrong UDPL packets - e.g. yesterday one of our CW-servers was ruined
by some unknown gateway which results with constant segfault in the following
function:

#0  0x00455ae1 in opbx_udptl_read (udptl=0x0) at udptl.c:360
360             if (seq_no > s->rx_seq_no)

I will try to findout which exact model was the killer and which
packets it sends, but currently I have to disable UDPTL on this server
at all till the end of investigation.
BTW, is their any way to get this data from core dump?

With T38_ENABLE it will be possible to enable T.38 only to _selected_
gateways which a) really need it   b) has really working T.38
implementation.

IMHO using session variable is very flexible way because we
can control T.38 processing in both ways - through SetVar in SIP peer
definition and through dialplan.

Andrew Checkov
-- 
Best regards,
 Andrew                            mailto:[EMAIL PROTECTED]

_______________________________________________
Callweaver-users mailing list
[email protected]
http://lists.callweaver.org/mailman/listinfo/callweaver-users

Reply via email to