Hello Max, Tuesday, July 17, 2007, 8:13:53 PM, you wrote:
MC> Checkov, Andrew ha scritto: >> #0 0x004d2ae1 in opbx_udptl_read (udptl=0x0) at udptl.c:360 >> 360 if (seq_no > s->rx_seq_no) ..... >> at all till the end of investigation. >> BTW, is their any way to get this data from core dump? MC> if you could grab a tcpdump of both RTP,UDPTL and SIP, we want to solve MC> this out. It's not easy - a) there few hundred gateways on this server b) this happens only with fax call to some specific gateway - the only way to find it is probably to turn udptl on and see which IP was the last in the logs when system crashes... I will try... >> 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. MC> Most of the things, out there, are functional. MC> So IMHO the best way is having it enabled and disable when needed. I see no difference between allowing/disallowing specific codecs for the whole system and for the specific peer and allowing/disallowing T.38. In case of codec I can disallow e.g. gsm codec in the system and allow it for the specific CPE. In case of T.38 currently I can disallow it at all or allow it to all EXCEPT specific CPEs. Meantime T.38 is required ONLY TO SPECIFIC GATEWAYS - not for all CPEs... I'm really happy with T38_DISABLE solution because I spent 2 nights making some universal patch - we has working patch for Asterisk which is adopted to CW for processing Cisco NSE protocol - so I worked on making some logic which will disable T.38 in case when CPE has announced NSE support - usually both fax protocols cannot live together. Thanks god on the 3rd day ];-)) CW has announced T38_DISABLE which is much easier solution to control this thing - so we has added to our billing system T.38 enable/disable radio-button which is "off" by default and solved the problem. Anyway I believe that system administrator should have a choice - either to enable T.38 by default and enable it for specific peer or disable it be default and enable it to specific peers - it will be much easier - and more freedom in different situations. BTW, I can share with NSE patch - it's very simple and really works with the most popular CPE - Linksys PAP2 and it's relatives. MC> If something doesn't support T38, then it won't accept the invite. I will do exact experiments and give you results but I'm sure that some CPEs in my zoo has the following behavior - it answers to incoming T.38 invite with something like "not supported" and drop the call... MC> I believe that instead of changing the behaviour (because what we do is MC> the best practice) we should solve tour problem. Again - look to the logic of controlling codecs - T.38 is the same story - so rules and choices should be the same... MC> MAx MC> _______________________________________________ MC> Callweaver-users mailing list MC> [email protected] MC> http://lists.callweaver.org/mailman/listinfo/callweaver-users -- Best regards, Andrew mailto:[EMAIL PROTECTED] _______________________________________________ Callweaver-users mailing list [email protected] http://lists.callweaver.org/mailman/listinfo/callweaver-users
