Summary:ASTERISK-05817: New Feature: Make a call from the CLI
Reporter:crich (crich)Labels:
Date Opened:2005-12-12 01:49:17.000-0600Date Closed:2011-06-07 14:02:39
Versions:Frequency of
Environment:Attachments:( 0) res_testphone.patch.txt
Description:This patch creates a res_testphone.so which registers a CLI command:

testphone call <channel> <callerid>

With this CLI command you can test extensions or Trunks when you are configuring your dialplan.

Comments:By: Tilghman Lesher (tilghman) 2005-12-12 09:30:59.000-0600

You can already do this by using the ALSA or OSS channel.

By: crich (crich) 2005-12-12 09:41:03.000-0600

For Alsa/Oss I need a configured Soundcard. This is intended to be used on System where either no Sound device is installed or where the Sounddevice is not Configured or where no chan_alsa or chan_oss is wanted.

By: Tilghman Lesher (tilghman) 2005-12-12 09:57:16.000-0600

How else are you going to hear the audio of your telephone call, if not with a soundcard?

I guess I just don't understand the utility of setting up an audio path, if you're not going to be able to hear the audio.

By: crich (crich) 2005-12-12 10:08:14.000-0600

Well the tool will drop any received audio data. It is just implemented for the purpose to test certain extensions, probably you know that if you have, let's say a very advanced dialplan you often need to call the extension for testing, this will make it possible to do that directly on the CLI short after the ael reload/ extension reload.

Also if you for example setup a SIP/IAX/ZAP/mISDN or any Channel Trunk. Often you like to create a call over it just to check if everything works as you expect it. We've experienced that you need to attach/configure a phone and modify the dialplan to test that.

The other possibility is to create an outgoing callfile via the spool directory, this is what we've done so far, but it is quite nicer to have it on the CLI.

Also I'm planning to add a command like:

testphone digit <digit>

which overlap dials a digit additionally.

Hope this thoughts clarify the purpose of this tool.

By: Tilghman Lesher (tilghman) 2005-12-12 10:28:24.000-0600

I still don't see how this is going to help you, except in very limited circumstances, where you aren't manipulating ${CALLERID(..)}, ${CHANNEL}, and other variables that depend upon an actual channel to be calling.  Remember that without an attached channel, the only variables that can be used are global variables.

And if you aren't using variables or functions, your dialplan is going to be very simple and not complex enough to warrant needing to run the dialplan from the CLI.

By: crich (crich) 2005-12-12 10:39:11.000-0600

Well for testing dialplan extensions one needs a channel anyway, I don't see how to start the pbx without channel.

So you'll need of course chan_local to do that without any additional configuration than the dialplan itself:

testphone call Local/123@test-ctx

By: Russell Bryant (russell) 2005-12-12 22:45:44.000-0600

Please look at ASTERISK-5696 for a related patch and see if this suits your needs.

By: crich (crich) 2005-12-13 01:37:50.000-0600

Yep drumkilla, thats exactly what i wanted to do with this Patch. Still I want to go further and allow the setting of certain variables like the callerid.

Also I think it could be usefull to add something like:

testphone digit <channel> <digit>
testphone text <channel> <text>

to send additional information, after the call is established, so one can even test IVR's from the CLI.

By: Russell Bryant (russell) 2005-12-13 09:51:38.000-0600

Some of that stuff makes more sense as a console channel driver.

If you think it makes sense, we could propose to add a generic console channel driver with no audio support.  As a matter of fact, I already have one.  :)  I have a powerbook, so I wrote one so that I had a console channel driver to test things that didn't require hearing the audio.

By: Tilghman Lesher (tilghman) 2006-01-05 15:48:53.000-0600

Since the Originate command does what you wanted, I'm going to close this bug out.