asterisk users - Aug 2004 - Bridging audio in cmd_dial() before connect completes?

Is it possible to make cmd_dial() bridge the audio going out to the network
back to the calling party as soon as dial() starts? Put another way, is it
possible to have the caller hear the outside dialtone and subsequent DTMF
digits? I notice that there is an option 'r' to dial(), thus:

r: Generate a ringing tone for the calling party, passing no audio from the
called channel(s) until one answers. Use with care and don't insert this by
default into all your dial statements as you are killing call progress
information for the user. 

Which implies that the caller should normally be able to hear the network
side ringing/busy etc., but is ambiguous on the actual dial sequence.

I ask because I'm using E&M tie lines from a Norstar, via Asterisk and I
get
no audio at all after dial() and before the connect status is reached. I'm
using in-band signalling at the moment and the 5 to 6 seconds of 'dead
line'
during dialing is confusing my users. I tried on hold music during connect
(option 'm'), but that confused them even more... For now they have
grudgingly accepted an 'outside transfer' playback before the silence
period.

I have tried including an Answer() before the dial to patch the audio, but
with no change. Obviously opening the channel to two-way audio before the
dialing sequence is complete would be a security problem so, any
suggestions?

Kris Boutilier
Information Systems Coordinator
Sunshine Coast Regional District

On Sun, 29 Aug 2004, Kris Boutilier wrote:
> Is it possible to make cmd_dial() bridge the audio going out to the network
> back to the calling party as soon as dial() starts? Put another way, is it
> possible to have the caller hear the outside dialtone and subsequent DTMF
> digits? I notice that there is an option 'r' to dial(), thus:
[snip]
> I ask because I'm using E&M tie lines from a Norstar, via Asterisk
and I get
> no audio at all after dial() and before the connect status is reached. 
This may not be of any help to you, but this is how asterisk already works
with isdn outgoing lines. The reverse audio path (from the b subscriber to
the a subscriber) is opened as soon as the network indicates that the call
is proceeding.

For analog lines I suspect the audio gets eaten by the channel driver to 
prevent the dialing party from getting a decond dialtone in their ear.

Peter