Checkov, Andrew wrote: > 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 > If you can segfault the software there may be a security vulnerability as well as a segfault nuisance. We need to sort this out. I thought we had chased all these things out of the software.
Steve _______________________________________________ Callweaver-users mailing list [email protected] http://lists.callweaver.org/mailman/listinfo/callweaver-users
