Chris wrote:
I think for the beginning it would be nice to have all the AGI-features available in PD, like dtmf-recognition or letting asterisk say numbers or letters.
Agreed. I figure that I will probably end up with two interfaces as a part of this project. I need one interface to transfer media, and some other interface for things like sending key press events into Pd, or as you have suggested, having a way for Pd to send requests back into Asterisk for some action to be taken.
But having audio in- and output would be hot. But it's difficult, as other people in this list said, there are many possibilities. I would prefer the exclusive solution, the person who is first calling gets connected to Pd, and for all other callers the pd-interface would report busy.
I agree, it would be hot. :)
However, I won't be happy with a solution that only lets you hook in one caller. If it's a bit more difficult, oh well! We'll get it working ...
You can still have some group-action, you could connect the pd-interface to a meetme-application. Or you can handle individual calls and have them connected to individual Pd-instances or to different places in one patch.
Maybe having something like a chan_jack.so for the audio would be handy, where you could do a Dial(jack/1) to connect a caller to a asterisk-jack-device. You would have a config like exten => _.,1,Answer exten => _.,2,Dial(jack/1) exten => _.,3,Dial(jack/2) exten => _.,4,Dial(jack/3) exten => _.,5,Busy for a maximum of three callers who get assigned to different jack-channels for use in Pd or any other application. (This would be a great feature for Podcasters to record calls!) And it would also provide some load-balancing-functions, you could just do a Dial(IAX/other.asterisk.server) and have another server with pd handle another 10 callers.
But it's not possible to send meta-data like keypresses over jack.
Yes, I do like the idea of using Jack. However, (warning, getting into Asterisk details), I don't think I would want to implement it as a channel driver as you suggested in the configuration. An Asterisk channel interface has to implement more than just an audio interface, it has to have its own implementation of call signaling. And, as you stated, it's not possible to pass stuff like key presses, or whatever other information that would be needed for call signaling, over jack directly.
I've been thinking about it a bit today, so tell me what you think of these ideas. I'm thinking of making two interfaces that use Jack. The first, and more simple one, is just an application.
; ; Connect to the jack channel indicated by the 4 digit ; number that was dialed. The audio from the caller is sent out ; through the Jack interface. The audio that comes back is what gets ; sent back to the caller. ; exten => _XXXX,1,Answer exten => _XXXX,2,Jack(${EXTEN})
The second interface is a bit more tricky, but is where things get quite cool, in my opinion.
exten => _XXXX,1,Answer ; ; Enable the Jack Audio-hook. This would send the audio from the ; caller through Jack. What comes back from Jack replaces the original ; stream from the caller. This would allow for audio manipulation or ; analysis of a call that is off doing other things. ; exten => _XXXX,2,Set(JACK_HOOK(${EXTEN})=on) ; ; Call the victim. The audio that they hear is the audio that is being ; manipulated through the Jack interface that has been turned on. ; exten => _XXXX,3,Dial(${VICTIM})
Alternatively, this third step could be anything. It could be MeetMe (conference calling application), or anything else you can do with an Asterisk call.
Video processing sounds great, maybe asterisk could connect video-callers to a v4l-device, so you could use this in gem.
Yeah, I'd like to add support for video, as well. But for me, it's a lower priority at first than the audio part. Video just really has never caught on very well in the telephony world for various reasons ...
Well, some weird thoughts. I have no idea how hard this all would be to code, but anyway I'd like to beta-test when there's something ready.
Everything that we have talked about is reasonable. I will certainly say something on this list once I have something usable.
-- Russell Bryant