Yeah, there's a PROGRESS message. In the Q.931 spec it's under section 5.4 Since it seems pretty certain Dial() can't handle it, it's going to have to be some other funky solution.
Dave Donovan wrote: > 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]
