Fax for Asterisk Problems

you wont be able to have an application that writes a callfile using a SIP channel because its always different.

customer A uses sip provider MucketyMuck who wants all calls delivered as SIP/+15025551212@MucketyMuck

customer B uses sip provider YadaYadaYada who wants calls delibered as SIP/5025551212@YadaYadaYada or SIP/15025551212@YadaYadaYada

customer C also uses MucketyMuck but he named his channel TrunkPeople so his string looks like SIP/+15025551212@TrunkPeople

customer D has a different trunk for each and every tenant defined in their outbound routes. Depending on the tenant Provider A might get used or providerB might get used. So his strings often look like SIP/15025551212@ProviderA-Tenant1, SIP/15025551212@ProviderA-Tenant2, and SIP/+15025551212@ProviderB-Tenant4

customerE uses a gateway that he passes all his calls to so his calls appear as SIP/5021234567+15025551212@Gateway

what does customer A do when a user of one of his tenant users puts 5551212 in the destination? Or when he puts in 5025551212 or even 15025551212.

what happens to customer B when customer A argues to have the callfile changed to +15025551212 for everyone and suddenly customerB's faxes fail at 100% 6mos later when he finally upgrades?

in order for this to work, one leg of the call HAS to navigate dialplan to follow the rules of outbound call routes. The only way I know how to make a callfile is to bridge a Channel to an application or bridge a Channel to a extension@context. In both examples there allways is a channel. I am not aware of any possibility to create a callfile where two Extensions get bridged togeather. I believe Channel is always required.

there is a separate request to create callfile templates that are editable, but this is also going to be something global. A CustomerD example is not going to get any sort of relief if he has your issue.

I also forgot to mention that since the call is originating directly from a SIP channel there would be no parsable CDR records and none of your billing software would be able to track the call. Additionally since no CALLERID is now being set on the call (this was being performed via outbound routes scripts) you will likely get calls refused by the provider. This further compounds your customized callfile as every single caller is going to have their CALLERID set to a single number. This limits its usability to STE builds only.

Well here is what Digium says. Basically they won't support the product if it uses a local channel:

What this boils down to is a dialplan issue. All of it can be done using standard Asterisk dialplan and call files, without using local channels. You (and Thirdlane) are correct in that it is more complicated from a scripting/development standpoint to avoid using local channels, but it can be done. All call files must create an active channel in order to process, so you will need to have either a SIP or DAHDI channel to use. You'd have to use a script to programmatically generate the call file and pass it to Asterisk.

Unfortunately, dialplan and scripting issues of this sort are outside of the scope of support provided with Fax for Asterisk. If you can demonstrate the original problem using a call file, skipping your Thirdlane dialplan and avoiding the use of local channels, we can take this information back to engineering for analysis and troubleshooting.

While you _technically_ can send something out a SIP channel; who is going to tell your users that they are just too inept to use the interface because they don't type the send string correctly? We can't code the gui around it since there is no such thing as international dialing standard and every provider has a different guideline and our software spans many many countries. We send the destination number to the callfile exactly the way its entered which is sent on its way to your from-inside context exactly the way a phone arrives there regardless of how they dialed a number. You could have a Fax machine at extension 120 as a dahdi extension and still send a fax to it internally through our portal.

So with that in mind the best I can do is push for a customizable template and basically put you on the hot seat for getting the template correct on the send channel. And when your customer types in 7 digits instead of +1NPANXXXXXX I guess you'll have to just spend the time on the phone training them. This is the entire point of outbound dial patterns in the first place; to modify the dial string to make it acceptable by the carrier. As I said this is not some standard so that's why the outbound route section exists in the fist place (allowing you to specify how the dial string is to be mutilated).

If chan_local was such a go/no-go as they claim, how is it that it worked so well for you until the last few weeks? Did you change something? Have you tried adding the 'f' option to the SendFax command in dialplan to disable T.38? FWIW Ive sent hundreds of faxes out DAHDI channels via chan_local in outbound routes.. but then again chan_local doesn't have T.30 issues. For that matter have you tried forging your own callfile testing SIP channel directly .. because it might just be a copout and nothing to do with your actual problem at all.

Did Digium tell you how T.38 is such a poorly written standard that 8 DSP programmers could all sit down at the same time writing a T.38 stack based directly on the 'standards' sitting next to them and not a single one of them would be able to talk to each other.

BTW why are you running 1.6.1.anything? Its got to be the worst branch of all time. The entire branch broke FSX DAHDI ports and even though I bugged it crashing asterisk at 100% every time call-waiting kicked in they didn't try and reproduce it. Its also 80% full of DTMF bugs (started failing around 1.6.1.5) . Those DTMF fixes didn't arrive till around 1.6.2.5ish.

I'm using 1.6.1.x on your recommendation actually. We'd planned on 1.6.2.x and you'd said that Thirdlane didn't support it and we should move back to 1.6.1. We needed at least 1.6.1 for multi tenant parking. We actually plan on an upgrade to 1.6.2 this weekend I think precisely because of the DTMF issues.

at the time 1.6.2 was in a .0 release and it had the same problems. We now know how to deal with the reload/restart problem now (theres an alias file that will make the commands work again). The parking is still manual for the time being.