From: Michael V. D. <mv...@va...> - 2004-01-25 02:48:23
|
On Sat, 24 Jan 2004 19:37:27 -0600, Steven Sokol = <ss...@so...> wrote: >Has anybody experimented with directing audio from a file (i.e. a wave = file) >over the IAX connection from the client end? How about directing = incoming >audio _to_ a file? I think Steve K had some file code but I couldn't = figure >out how it worked. I would like to be able to implement the following = three >features: > >1. Record both the input stream and output stream to a file (for call >recording purposes). This would be similar to the monitor function >available from the Manager interface (and/or CLI). I would guess that = at >some point in the input and output process it would be feasible to = direct a >copy of the data to a file. It would be great to be able to put a = "record >locally" feature into the phone allowing users to click to record/stop >recording. This sounds a feature that ought to eventually be in the library, but I = don't (personally) miss it yet. >2. I would like people to play file data over the line. This could be = used >to play custom answering messages, and it could also be used to create a >very cool off-board IVR functionality. Think about custom, client-side >scripting of play/record over IAX? I would really like to see this. >3. Can IAX endpoints receive DTMF (or the equivalent thereof) digits? I'd like to be able to do this. DTMF is currently rported by the library= as Unkown event of type 5. A quick and dirty fix would be to send the DTMF as an iaxc_ev_text, but I= think that it would be better do make a new struct like: --8<--- struct iaxc_ev_dtmf { int callNo; int char digit; } --8<---- and add it to the ev union in the iaxc_event_struct struct. IAXC_EVENT_DTMF would be 4. >I think you can see where I am going. It would be an extremely powerful >extension to the library to be able to create automated telephony >applications off-board of the Asterisk. It also seems like cool >functionality to build into advanced soft-phones. > >I realize that most of you want to get the current library stable before= we >go hacking further functionality into it. I respect that. If you think= I >should hold off (or at least not tap the group's collective power) = please >let me know. I'm not sure what I think on this. On one hand, I would love to see = additional functionality, and think that I could be of help. On the other hand, I recognize the need to maximize the stability. On the gripping hand, I'm not real sure that we can do much more in the = area of stability until the iax2 protocol white paper is published. It appears = to me that any problems with libiaxclient are to to a lack of understanding of = the iax2 protocol. I would therefore propose that hold off on a feature freeze until the = white paper is published. Then we shift our attention to white paper = compliance Steve K, how bout I put Steve S' blind transfer stuff in CVS tomorrow, = and we trade diffs amongst ourselves next week while you're gone? -- Michael (aka Steve V) |