| From | Sent On | Attachments |
|---|---|---|
| jo...@spectross.com | Nov 21, 2008 10:01 pm | |
| Russell Bryant | Nov 22, 2008 3:15 pm | |
| jo...@spectross.com | Nov 23, 2008 8:24 pm | |
| jo...@spectross.com | Nov 24, 2008 7:03 am | |
| Russell Bryant | Nov 24, 2008 8:17 am |
| Subject: | [asterisk-dev] possible bug in chan_vpb | |
|---|---|---|
| From: | jo...@spectross.com (...@) | |
| Date: | Nov 24, 2008 7:03:19 am | |
| List: | com.digium.lists.asterisk-dev | |
Hi Russell,
I am trying to port Asterisk over our system based on ARM 9. We have a TSI to handle voice traffic switching & DSP as a off-load engine to handle conferencing & CPT generation.
The Char Device Driver I wrote for our DSP interface, shall simply read & write data-structures to/from the DSP-queue without any knowledge of the data being written i.e. there exists no channel (FXO/FXS/ISDN etc...) level abstraction.
Well, I understand "chan_zap" communicates with its device driver through a separate node for each of the channel i.e. there exists a well defined channel level abstraction in the driver itself.
So, What do you recommend - Where should I implement this channel-level abstraction to my driver:
1) In my device driver itself by maintaining a separate queue for each channel(Kernel level), separate node & a poll implementation. --> chan_zap approach.
2) In another user-level layer which interfaces with my current naive driver on one side & on the other side interfaces with Asterisk through pipes i.e. each channel would have 2 pipes for cmd as well as event. Hence all driver specific fds (file-descriptors) in Asterisk would be actually replaced with pipe fds. --> simpler to implement & can still keep my channel driver very similar to chan_zap.
3) In the same way as chan_iax2 & chan_vpb were implemented, as discussed earlier. --> Will have to do a lot for making it as powerful as chan_zap.
Any better suggestions are welcome.
Regds. John
John Nicholas Team Lead Spectross Digital Systems Pvt. Ltd.
----- Original Message ----- From: <jo...@spectross.com> To: "Russell Bryant" <russell at digium.com>; "Asterisk Developers Mailing List" <asterisk-dev at lists.digium.com> Cc: "Ish Sir" <ish at spectross.com> Sent: Monday, November 24, 2008 9:55 AM Subject: Re: [asterisk-dev] possible bug in chan_vpb
Hi Russell,
Thanks, you are right, "chan_vpb.cc" also uses the same technique.
The monitor thread here checks for events over both owned & orphan channels & as an event is detected over an owned channel it creates a frame and queues it up by calling "ast_queue_frame()".
Could you please recommend some document which would aid in understanding the Asterisk Architecture(Developer's point of view). I found many E-books for Asterisk users but not one for fresh Asterisk developers.
Thanks & Regds. John
John Nicholas Team Lead Spectross Digital Systems Pvt. Ltd.
----- Original Message ----- From: "Russell Bryant" <russell at digium.com> To: <john at spectross.com>; "Asterisk Developers Mailing List" <asterisk-dev at lists.digium.com> Sent: Sunday, November 23, 2008 4:45 AM Subject: Re: [asterisk-dev] possible bug in chan_vpb
On Nov 22, 2008, at 12:02 AM, <john at spectross.com> <john at spectross.com> wrote:
I was browsing through "chan_vpb.cc" today. I see that no "fds" (file descriptors) are assigned while creation of an "ast_channel" structure in "vpb_new".
What I am not able to understand is: How would the "ast_waitfor*" functions work as the events are captured using the "poll" api.
I have never touched that code, but I can say that there is one other method for a channel driver to indicate that data is available. Channel drivers can queue up media frames onto the channel using ast_queue_frame(). This puts the frame into a queue on the ast_channel, and also writes data to an alert pipe on the channel that is used to wake up poll(). chan_iax2 uses this method quite heavily since there is no dedicated socket per channel like there is for a call using RTP.
-- Russell Bryant Senior Software Engineer Open Source Team Lead Digium, Inc.





