Vinícius Fontes wrote: > I've put it on pastebin because is was a lot of text. Here's the link: > http://pastebin.com/m7467cea1. That's all the information on the CLI with > verbose=3 and "sip set debug peer voxip".
OK, with the complete capture we can see that the problem is actually quite different. In this call, Asterisk sent a re-INVITE to T.38 mode from audio mode, the provider accepted it, and then Asterisk acknowledged it. Immediately afterwards, Asterisk sent a re-INVITE *back* to audio mode, which the provider accepted (and included T.38 capabilities in their response). Because of this, the FAX reception process failed since the T.38 session was destroyed. The most likely cause of this problem is a bug in chan_sip, but it has been fixed for quite some time now, and the fix is included in 1.6.1.13. This would also fit with your statement about not having this issue with Fax For Asterisk, as it does not generate any audio frames while negotiating T.38 as the receiver of a FAX. I would suggest opening an issue in the issue tracker at issues.asterisk.org and uploading your console trace there; there is clearly a bug here that needs to be found and fixed. -- Kevin P. Fleming Digium, Inc. | Director of Software Technologies 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA skype: kpfleming | jabber: [email protected] Check us out at www.digium.com & www.asterisk.org -- _____________________________________________________________________ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
