[asterisk-dev] Outbound Call Implementation

Nick Khamis symack at gmail.com
Wed Sep 28 11:38:41 CDT 2011


Hello Tilghman,

Thanks again for your response. Is the incompatibility due to the
asynchronously nature of the
originate functionality, making it almost impossible to implement in a
reasonable manner (i.e.
without the use of a thread or cron). I have two weeks that I can
dedicate full time for this. With
some direction and suggestions, I have no problem implementing the
realtime call origination
layer. As for if the functionality will be included in the source
tree, I will leave it to you gentlemen
to decide on that.

Nick.

On Wed, Sep 28, 2011 at 12:18 PM, Tilghman Lesher <tilghman at meg.abyt.es> wrote:
> On Tuesday, September 27, 2011 02:10:19 PM Nick Khamis wrote:
>> On Tue, Sep 27, 2011 at 1:34 PM, Tilghman Lesher wrote:
>> > On Tuesday, September 27, 2011 08:46:11 AM Nick Khamis wrote:
>> >> I am interested in the internal working of Asterisk, mainly how
>> >> asterisk actually makes a call. I was looking to modify the call
>> >> functionality to
>> >> query a database realtime for the call details. As is done with
>> >> peer/friend register, MOH etc... Out of the box, does asterisk use
>> >> call files to
>> >> make the calls? Any direction is greatly appreciated. If I am
>> >> successful in moving the call details to my/pgsql, I have no
>> >> problem sharing my
>> >> solution with everyone.
>> >> Providing "realtime call" will open a whole lot of possibilities
>> >> for those not wanting to use AGI, AMI etc..
>> >
>> > Realtime currently uses an outside request to know when to pull
>> > information from the database.  Realtime is not self-starting.
>> >  Keeping this in mind, how would Asterisk know when a new record
>> > was inserted asynchronously into the database, to know when to
>> > query it?  Are you suggesting a new thread that does nothing but
>> > query the database on a regular interval?  That's potentially
>> > quite a lot of CPU.
>>
>> Thank you so much for your response. I agree that an infinite thread
>> would add to the fingerprint, and may be undesirable
>> for those that don't care for such functionality. Another approach is
>> to develop a database hook that fires after a record is inserted? But
>> before that, when you mention that realtime uses an outside request
>> to know when to query the database, I assume this is a hook of some
>> sort? And can the same idea be applied to call initiation? It would
>> be nice to keep the realtime
>> module consistent even with call origination.
>
> Such an event trigger by the database might look like a connection to
> AMI.  Once you have AMI in the equation, you don't need to have realtime
> in place, just feed the data directly from the database into an AMI
> Originate request.
>
> I agree that the realtime database layer has great uses, but in this
> case, you're trying to fit a square peg into a round hole.
>
> --
> Tilghman
>
> --
> _____________________________________________________________________
> -- Bandwidth and Colocation Provided by http://www.api-digital.com --
>
> asterisk-dev mailing list
> To UNSUBSCRIBE or update options visit:
>   http://lists.digium.com/mailman/listinfo/asterisk-dev
>



More information about the asterisk-dev mailing list