Do you see anything in the PRI debug that looks like a request for those digits?
It has to be a two stage process. I mean it can't expect it as part of the initial call setup because it doesn't play the tone if it's a local call (at least on our system). If I misdial a long distance number, I don't get a prompt tone, I get an SIT message like number not in service. So, it does some qualification of the dialed number before it asks for the billing code. Do you think that tone is generated by the CO (far end) or by the PBX (near end)? I mean, is the audio channel established already? If yes, maybe you could bridge to the channel (using manager API or something) and shove the digits down that way, much like agent whisper in a call centre. Dave On Thu, Feb 14, 2008 at 3:58 PM, Jim Van Meggelen <[EMAIL PROTECTED]> wrote: > I think that the crux of the problem is that the circuit has not yet been > answered, so there is very little that Dial() is going to do - it is waiting > for an answer before it does anything further. > > It's a nasty one. > > > > > Dave Donovan wrote: > > Hi Jim, > > > > Someone posted within the last few weeks with the same issue. > > I don't think it was ever solved. > > > > One outside the box answer is to tell your carrier that you > > don't want billing codes anymore so they turn off the prompt. > > > > Another suggestion I gave in the last thread was using > > playback to generate actual in-band audio, like > > playback(DTMF-1.wav) for the 1 key etc. > > > > I have the same service on my circuit here at work but > > haven't put Asterisk on it yet. I expect to run into the > > same problem so I'm interested to hear what works and what doesn't. > > > > Good luck, > > Dave > > > > > > On Thu, Feb 14, 2008 at 2:30 PM, Jim Van Meggelen > > <[EMAIL PROTECTED]> wrote: > >> Folks, > >> > >> Got an interesting one. > >> > >> We have a client who's carrier requires a long distance code on the > >> call before proceeding. > >> > >> The challenge is that this happens before the call is answered, (via > >> a PROGRESS message I guess), so if the caller is making the call > >> manually, they can key in the digits, but if we want to script > >> something in the back end, we can't tell Dial() to send the code in > >> response to the PROGRESS event. > >> > >> It seems this can be done for incoming calls via the PROGRESS() app, > >> but I can't see a way to send anything on outgoing calls that > >> encounter this. > >> > >> Any thoughts? Experience? War stories? > >> > >> Thanks, > >> > >> Jim > >> > >> FYI, I think section 5.4 applies here, but it doesn't help much > >> (http://www.itu.int/rec/T-REC-Q.931-199805-I/en) > >> > >> > >> -- > >> Jim Van Meggelen > >> Core Telecom Innovations > >> [EMAIL PROTECTED] > >> www.coretel.ca > >> 416-425-6111 x6001 > >> 877-CORETEL x6001 (Canada) > >> www.oreillynet.com/pub/au/2177 > >> http://downloads.oreilly.com/books/9780596510480.pdf > >> > >> > > --------------------------------------------------------------------- > >> To unsubscribe, e-mail: [EMAIL PROTECTED] For additional > >> commands, e-mail: [EMAIL PROTECTED] > >> > >> > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] For > > additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
