Dave Donovan wrote: > 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......
That's gotta be because you're a masochist. No other possible explanation. But this is telecom, so we're all a bit maso. > If I was dialing through Asterisk from a SIP set, would I > hear the tone and be able to enter my code to proceed? Yep. That works fine. > I mean, are users prevented from dialing at all, or is it just > stopping you from specifying the code in the dial() command? It just can't be done in Dial() > 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. That's the whole question. How to do that? >> 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] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
