On Thu, Feb 14, 2008 at 7:43 PM, Jim Van Meggelen <[EMAIL PROTECTED]> wrote: > 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.
I think this probably won't work but I'll put it out there. What you'd really like it to do is disregard call progress and return immediately. I think the CALLPROGRESS option in zapata.conf is an analog feature for detecting tones, but if you're lucky it might have some effect on the PRI channel and force it to return regardless progress. I don't know why, but I find this problem appealing. Hmmm...... If I was dialing through Asterisk from a SIP set, would I hear the tone and be able to enter my code to proceed? I mean, are users prevented from dialing at all, or is it just stopping you from specifying the code in the dial() command? If users can do it then we might be able to have the dialplan pretend to be a user. I mean you could have an extension dialing an extension and the first one could provide the digits when the second one asked for them. If I'm being a moron, just wave me off. :-) Dave > 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]
