Hi list, it's my first post here - so please be kind ;-)
First of all, my compliments to Steve and whoever else is involved in T.38/fax development. THANK YOU for all your efforts, you're doing a great job! Two days ago I compiled Callweaver 1.2svn (r4602, SpanDSP 0.0.4pre18) on on Debian Etch. Last time I gave Callweaver a try has been around the beginning of this year. I was surprised even there, but right now I'm really impressed! Some things that worked out of the box (for those who care): - sending faxes through my "SIP-Carrier" (supporting T.38 via Cisco) to an old PSTN fax device (9600, Canon Fax-L240) - send faxes through the same carrier to a Fax-Inbound service provider (14400 - no idea what Soft/Hardware they're using) - recieve faxes via G.711 from an older (not T.38-speaking) SIP ATA (AVM Fritzbox Fon 7050), using another Fax device (cheap old Philips HFC 141) There is only one thing causing trouble: most of my faxes will have to travel in outgoing direction through my "uplink SIP provider"'s Cisco routers. The problem with them is that they nearly always seem to suppress silence - and I have no influence on their configuration. Callweaver shows notices like > rtp.c:363 process_rfc3389: Comfort noise support incomplete in > CallWeaver (RFC 3389). Please turn off on client if possible. Client > IP: w.x.y.z and Callweaver's fax tone sounds really choppy (as heard in front of my fax device - and also verified listening to the captured G.711 RTP stream). Two out of more than 20 faxes succeeded - but that has been pure luck. Sniffer shows me that in these cases there has been no interruption of the fax tone, it seems that one router in their pool doesn't suppress silence. I searched through your mailing list, but have been unable to find some- thing similar. It seems that RxFax behaves like Asterisk when playing MusicOnHold to a silence-suppression-using client - could this be the case? If yes: what timing source does Callweaver use for it's RTP mixing? Please note that I did not install any ztdummy or similar module, and Callweaver is running in a Linux-vServer partition with limited access to the host systems /dev and /proc. However, adding the /dev/rtc device node didn't help much, neither did granting CAP_SYS_NICE, allowing Callweaver to run with "real-time priority". If RTC could be the bad boy, here some more details: -> currently loaded rtc module is rtc (not genrtc) -> CONFIG_HZ=100 -> # CONFIG_HZ_1000 is not set -> CONFIG_HPET_TIMER=y -> CONFIG_X86_PM_TIMER=y System is idling most of the time, no I/O wait, 4 cores, lot's of free memory, 64bit. Internet access is 100Mbit FastEthernet, switched - and no packet loss in my RTP streams. If one of the latter could be the root my problems please let me know! Otherwise I can also provide further details (config, captures...) if you need them. Next days I'll run some more tests with other T.38-capable hardware, at least with some Grandstream ATAs and newer AVM routers. Let me know If you're interested in the results - if so, I'll for sure post them. Kind regards, Thomas Gelf _______________________________________________ Callweaver-users mailing list [email protected] http://lists.callweaver.org/mailman/listinfo/callweaver-users
